Author Archives: Russ
Author Archives: Russ
What about I2RS performance?
The first post in this series provides a basic overview of I2RS; there I used a simple diagram to illustrate how I2RS interacts with the RIB—
One question that comes to mind when looking at a data flow like this (or rather should come to mind!) is what kind of performance this setup will provide. Before diving into the answer to this question, though, perhaps it’s important to ask a different question—what kind of performance do you really need? There are (at least) two distinct performance profiles in routing—the time it takes to initially start up a routing peer, and the time it takes to converge on a single topology and/or route change. In reality, this second profile can be further broken down into multiple profiles (with or without an equal cost path, with or without a loop free alternate, etc.), but for our purposes I’ll just deal with the two broad categories here.
If your first instinct is to say that initial convergence time doesn’t matter, go back and review the recent Delta Airlines outage carefully. If you are still not convinced initial convergence time matters, go back and reread what you can Continue reading
Precisely.
But what are we to do about it. Tom’s Take is that we need to push back on applications. This, also, I completely agree with. But this only brings us to another problem—how do we make the case that applications need to be rewritten to work on a simpler network? The simple answer is—let’s teach coders how networks really work, so they can figure out how to better code to the environment in which their applications live. Let me be helpful here—I’ve been working on networks since somewhere around 1986, and on computers and electronics since Continue reading
The post Worth Reading: Your comfort zone may destroy the world appeared first on 'net work.
The post Wroth Reading: Exascale might prove difficult appeared first on 'net work.
The post Worth Reading: Joining forces against mass collection appeared first on 'net work.
The post Worth Reading: IPv6 versus v4 performance map appeared first on 'net work.
My daughter has started a new fiction series on her blog; I’ll just link to it here for anyone who’s interested.
The post Nenshou Fire: Recoil appeared first on 'net work.
The post Worth Reading: Big buffers and reality appeared first on 'net work.
The post Worth Reading: Binding to an IPv6 subnet appeared first on 'net work.
A mythical conversation on firewalls, and some observations
“Let’s put the firewall here, so it can protect the servers in this part of the network.”
“How would you define a firewall?”
“You know, the appliance that, well, protects servers and other machines from outside threats…”
“And how does it do this?”
“By filtering the traffic using some sort of stateful mechanism, and network address translation, and deep packet inspection, and blocking certain ports, and…”
“In other words, it’s a bunch of services on a single device?”
“Yes…”
“Then maybe we should think in terms of services instead of appliances.”
I’ve never actually had this conversation, but I’ve had many similar ones across my times as a network engineer. I’ll admit, in fact, that it took a lot of conversations like this (with me on the receiving end) to grock the difference between a service and an appliance, and to see that my constant thinking in terms of appliances (or even devices) was actually hindering my ability to design networks. Let me give you two specific reasons you should think of security services, instead of security appliances.
First, When you disaggregate the “things a firewall Continue reading
The post Worth Reading: HPE trims back appeared first on 'net work.
The post Worth Reading: Ransomware and backups appeared first on 'net work.
The post Worth Reading: Hardware slaves to the master algorithm appeared first on 'net work.
In the last post on this topic, we traced how snaproute’s BGP code moved to the open state. At the end of that post, the speaker encodes an open message using packet, _ := bgpOpenMsg.Encode()
, and then sends it. What we should be expecting next is for an open message from the new peer to be received and processed. Receiving this open message will be an event, so what we’re going to need to look for is someplace in the code that processes the receipt of an open message. All the way back in the fifth post of this series, we actually unraveled this chain, and found this is the call chain we’re looking for—
I don’t want to retrace all those steps here, but the call to func (st *OpenSentState) processEvent()
(around line 444 in fsm.go
) looks correct. The call in question must be a call to a function that processes an event while the peer is in the open state. This call seems to satisfy both Continue reading
The post Worth Reading: gRPC appeared first on 'net work.