The post Worth Reading: Hacking wireless keyboards appeared first on 'net work.
In the second post in this series, we considered the use of IGP-Prefix segments to carry a flow along a specific path in a data center fabric. Specifically, we looked at pulling the green flow in this diagram—
—along the path [A,F,G,D,E]. Let’s assume this single flow is an elephant flow that we’re trying to separate out from the rest of the traffic crossing the fabric. So—we’ve pulled the elephant flow onto its own path, but this still leaves other flows to simple ECMP forwarding through the fabric. This means some number of other flows are still going to follow the [A,F,G,D,E] path. The flows that are randomly selected (or selected by the ECMP has) to follow the same path as the elephant flow are still going to contend with the elephant flow for queue space, etc.
So we need more than just a way to pull an elephant flow onto a specific path. In fact, we also need a way to pull a specific set of flows off a particular path in the ECMP set. Returning to our diagram, assume we want all the traffic other than the elephant flow to be load shared between H and B, and Continue reading
The post Worth reading: The making of algorithm markets appeared first on 'net work.
What is at stake here is the standardization versus innovation. Should Docker standardize their container technology or not?
On the one side is the belief that standardizing squashes innovation. Once you’ve standardized something, and other people start building on it, you can’t change the standard without a lot of agreement and effort—after all, other people are now depending on your product remaining the same across many cycles of development. This certainly kills innovation, as implementing new things both exposes your ideas to public view before you can implement them, and slows down the pace at which new ideas can be deployed in the real world.
On the other side is the belief that standardizing is necessary for the market to mature, and for a healthy ecosystem to develop that’s better for the entire community. How can customers and other vendors build products around a particular product if the Continue reading
The post Worth Reading: The geeks guide to the Barton Aquaduct appeared first on 'net work.
In last week’s post, we looked at how snaproute’s implementation of BGP in Go moves into trying to connect to a new peer—we chased down the connectRetryTimer
to see what it does, but we didn’t fully work through what the code does when actually moving to connect. To jump back into the code, this is where we stopped—
func (st *ConnectState) processEvent(event BGPFSMEvent, data interface{}) {
switch event {
....
case BGPEventConnRetryTimerExp:
st.fsm.StopConnToPeer()
st.fsm.StartConnectRetryTimer()
st.fsm.InitiateConnToPeer()
....
When the connectRetryTimer
timer expires, it is not only restarted, but a new connection to the peer is attempted through st.fsm.InitiateConnToPeer().
This, then, is the next stop on the road to figuring out how this implementation of BGP brings up a peer. Before we get there, though, there’s an oddity here that needs to be addressed. If you look through the BGP FSM code, you will only find this call to initiate a connection to a peer in a few places. There is this call, and then one other call, here—
func (st *ConnectState) enter() {
....
st.fsm.AcceptPeerConn()
st.fsm.InitiateConnToPeer()
}
The rest of the instances of InitiateConnToPeer() are related to the definition of the function. Continue reading
The post Worth Reading: The languages that almost became CSS appeared first on 'net work.
The post Worth Reading: Top performance items to watch appeared first on 'net work.
The post Worth Reading: Hot Commodities appeared first on 'net work.
The post On the ‘net: The future of networking appeared first on 'net work.
The post Worth Reading: Ten years of Cisco Live appeared first on 'net work.
I was recently a guest on the Packet Pushers Podcast, where I talked with Ethan for a bit about the concept of layered control planes, and how the idea related to complexity.
The post On the ‘net: Layered Control Planes appeared first on 'net work.
The post Worth Reading: One second warning appeared first on 'net work.
The post Worth Reading: Learning from email breaches appeared first on 'net work.
We often think the entire Internet, as we know it, just popped out of “thin air,” somehow complete and whole, with all the pieces in place. In reality, there have been many side roads taken, and many attempts to solve the problem of pushing the maximum amount of data across a wire along the way. One of these ways came to mind this last week, when I ran across this story—
Pulling layer 2 into the network to centralize the edge—where have I heard this before? Maybe it was all those years ago, when I was in TAC, and we used to support Cisco 1001’s, or the LEX—LAN Extenders. The promise then was the same as the promise now: a lightweight, easy to manage device that would relocate all the intelligence from the network edge into the access layer of the “mother ship,” where it could be properly managed.