Layer 2 Routing—Haven’t we been here before?
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.
Worth Reading: Days of the Week
With deep, purple bags under his eyes, Beagin Tiredly plops down into his swivel chair with a loud whoosh. His unsweetened, black coffee sloshes onto the desk as he sets it down, adding new spots to the coffee stains from previous mornings. Despite being at the ripe, young age of 25, this early hour has him looking twenty years older. —Nenshou Fire Continue reading
snaproute Go BGP Code Dive (6): Starting a Peer
In our last post on BGP code, we unraveled the call chain snaproute’s Go BGP implementation uses to bring a peer up. Let’s look at this call chain a bit more to see if we can figure out what it actually does—or rather, how it actually works. I’m going to skip the actual beginning of the FSM itself, and just move to the first state, looking at how the FSM is designed to move from state to state. The entire thing kicks off here—
func (st *IdleState) processEvent(event BGPFSMEvent, data interface{}) {
st.logger.Info(fmt.Sprintln("Neighbor:", st.fsm.pConf.NeighborAddress, "FSM:", st.fsm.id,
"State: Idle Event:", BGPEventTypeToStr[event]))
switch event {
case BGPEventManualStart, BGPEventAutoStart:
st.fsm.SetConnectRetryCounter(0)
st.fsm.StartConnectRetryTimer()
st.fsm.ChangeState(NewConnectState(st.fsm))
....
}
What we need to do is chase down each of these three calls to figure out what they actually do. The first is simple—it just sets a retry counter (connectRetryCounter) to 0, indicating we haven’t tried to restart this peer at all. In other words, this is the first attempt to move from idle to a full peering relationship. This counter is primarily used for telemetry, which means it’s a counter used to show you, Continue reading
Worth Reading: Learning is hard
The post Worth Reading: Learning is hard appeared first on 'net work.
Worth Reading: How to Interpret Cisco math
The post Worth Reading: How to Interpret Cisco math appeared first on 'net work.
Worth Reading: Sniffing and censoring in real life
The post Worth Reading: Sniffing and censoring in real life appeared first on 'net work.
Worth Reading: Google Site Reliability
The post Worth Reading: Google Site Reliability appeared first on 'net work.
Worth Reading: The History of the URL
The post Worth Reading: The History of the URL appeared first on 'net work.
DC Fabric Segment Routing Use Case (2)
In the first post we covered a bit of the basics around segment routing in the data center. Let’s return to the first use case to see if we can figure out how we’d actually implement the type of traffic steering needed to segregate mouse and elephant flows. Let’s return to our fabric and traffic flows and think about how we could shape traffic using segment routing.
There are two obvious ways to shape traffic in this way—
IGP-Prefix segments
The first way would be to impose a label stack that forces traffic along a path that touches, or passes through, each of the devices along the path. In this case, that would mean imposing a path on the traffic originating behind the ToR at A so it must pass through [F,G,D,E]. The flow of traffic through the data center will look something like—
- Somehow classify the traffic as belonging to the flow that should be shaped to follow only the [F,G,D,E] path
- Impose the path as a label stack, so the SR header (really just a label stack in this situation, remember?) will contain [F,G,D,E]
- Forward the packet, with the label, to the next hop in the stack, Continue reading
Worth Reading: Developing the Internet of Things
The post Worth Reading: Developing the Internet of Things appeared first on 'net work.
General – The Future of Networking – Russ White
Hello my friends,
Lately I have been thinking a lot about the future of networking and the career paths in this domain. As you probably know I like to guide and mentor people and with everything going on in the industry it can be confusing to find your way and to know what skills to work on to stay ahead of the curve.
I decided to reach out to some of my friends to ask them of their vision of the role of the future networking engineer and how to prepare for the changes that we are now seeing. First out is my friend Russ White who is also the co-author of the book Unintended Features that we wrote together.
Daniel: What are the major skills that people in networking need to learn to stay ahead of the curve?
Russ: Some of these have never changed — for instance, communication and abstraction. Some skills have been more important forever, such as people skills and project manage, but they never seem to really rise to the top in terms of actual demand. I don’t think this is going to change much; companies say they want people skills, and then recruit based Continue reading
Worth Reading: The Microsoft Ireland Case
The post Worth Reading: The Microsoft Ireland Case appeared first on 'net work.
I will be speaking at Net-Centric 2016 in the Washington DC area—you can find more information on the ISOCORE web site.Worth Reading: Solving network documentation with code
The post Worth Reading: Solving network documentation with code appeared first on 'net work.