Russ

Author Archives: Russ

snaproute Go BGP Code Dive (10): Moving to Established

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—

  • func (st *OpenSentState) processEvent()
  • st.fsm.StopConnectRetryTimer()
  • bgpMsg := data.(*packet.BGPMessage)
  • if st.fsm.ProcessOpenMessage(bgpMsg) {
    • st.fsm.sendKeepAliveMessage()
    • st.fsm.StartHoldTimer()
    • st.fsm.ChangeState(NewOpenConfirmState(st.fsm)) }

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

DC Fabric Segment Routing Use Case (5)

In this, the last post on DC fabrics as a Segment Routing use case, I mostly want to tie up some final loose ends. I will probably return to SR in the future to discuss other ideas and technical details.

Anycast

Anyone who keeps up with LinkedIn knows anycast plays a major role in many parts of the infrastructure. This isn’t unique to LinkedIn, though; most DNS implementations and/or providers, as well as just about every large scale public facing web application, also uses anycast. Which leads to an obvious question—how would SR work with anycast? The answer turns out to be much simpler than it might appear. The small diagram below might be helpful—

anycast-01

Assume A and B have two copies of a single service running on them, and we want hosts behind F to use one service or the other, just depending on which the routing system happens to route towards first. This isn’t quite the classical case for anycast, as anycast normally involves choosing the closest service, and both of the services in this example are equal distance from the hosts—but this is going to be the case more often than not in a data center. In Continue reading

On Definitions: Whatever is Forwarding Information?

After last week’s, a reader left a comment noting “I2RS doesn’t manipulate forwarding data.” If I2RS isn’t “manipulating forwarding data,” then what, precisely, is it doing? I thought it’s worth a post to try and help folks understand the definitions in this space—except, as you’ll soon discover, there are no definitions here. In fact, it’s almost impossible to create a single set of definitions that will clarify the issues involved in understanding the various sorts of state in a network device. The following illustration might be helpful in trying to understand the vagaries of the various kinds of state, and the confusion that results from the various names used in different places.

device-model-definitions

It would be “nice” to say something like: information held in the forwarding table, that’s actually used to forward traffic through the router, is the only real “forwarding data.” This makes for a nice clean definition that clearly separates, say, what the RIB does and what the FIB does in most of the hardware based switching devices produced today. There are two problems with this clean definition, however.

First, there are, and always will be, devices produced that simply don’t have a forwarding table. Instead of Continue reading