Russ

Author Archives: Russ

DC Fabric Segment Routing Use Case (4)

In the last post in this series, I discussed using SR labels to direct traffic from one flow onto, and from other flows off of, a particular path through a DC fabric. Throughout this series, though, I’ve been using node (or prefix) SIDs to direct the traffic. There is another kind of SID in SR that needs to be considered—the adj-sid. Let’s consider the same fabric used throughout this series—

benes-segment-03

So far, I’ve been describing the green marked path using the node or (loopback) prefix-sids: [A,F,G,D,E]. What’s interesting is I could describe the same path using adj-sids: [a->f,f->g,g->d,d->e], where the vector in each hop is described by a single entry on the SR stack. There is, in fact, no difference between the two ways of describing this path, as there is only one link between each pair of routers in the path. This means everything discussed in this series so far could be accomplished with either a set of adj SIDs ore a set of node (prefix) SIDs.

Given this, why are both types of SIDs defined? Assume we zoom in a little on the border leaf node in this topology, and find—

border-leaf

Assume—

Beware the network without an operator

A lot of people seem to be looking forward to the day we build a network without an operator; to wit—

Containerized solutions and machine learning may soon be more than tangentially related. Containerized solutions will usher in an era of operations that don’t require human intervention. Once humans are taken out of operations, we will be free to apply machine learning techniques to what is left. —The New Stack

I hope not, because machines are more brittle than humans. Totally automated security fails much more often than security that uses a blend of people and algorithms. Machines do well at repetitive tasks, humans at catching the things that don’t fit into the algorithm’s state machine. Taking the person out of the network just means there’s no-one there to see when the state machine fails.

reaction-02And it will fail—at some point. I know we like to believe that machines break less often, but I’m pretty certain there’s a counterpoint to this: when machines break, it’s more likely to be catastrophic. I’m not convinced replacing people with algorithms always reduces damage so much as move the potential damage around.

I hope not, because machines separate the decision from the decision maker. Continue reading

Self-Improvement Through Time Travel

There are some days I wish I could travel back in time and “fix” the time I wasted through an hour, a day, or a week working on something that really wasn’t worth my time, or just wandering through links on the Internet, looking at things I don’t really (ultimately) care about. My time management skills are, honestly, often lacking. There doesn’t seem to be a way, does there, though?

future-procrastinationOr maybe there is. Let’s twist our brains a little and think about it this way. Tomorrow is going to be the day we wish we could travel into from the day after tomorrow to fix, right? So what if we did reverse time travel and fix tomorrow today? Sure, sounds nice, but how? The answer might seem a little trivial, but it’s only apparently trivial, rather than trivial in real life.

Once answer is the humble todo list. I know, you’ve made one of these before—in fact, you probably already have one, don’t you? And it’s never really helped, right? Well, let’s see if we can figure out how to supercharge to make it a bit more effective. To begin, we have to try to understand how a todo Continue reading

snaproute Go BGP Code Dive (8): Moving to Open

Last week we left off with our BGP peer in connect state after looking through what this code, around line 261 of fsm.go in snaproute’s Go BGP implementation—

func (st *ConnectState) processEvent(event BGPFSMEvent, data interface{}) {
  switch event {
  ....
    case BGPEventConnRetryTimerExp:
      st.fsm.StopConnToPeer()
      st.fsm.StartConnectRetryTimer()
      st.fsm.InitiateConnToPeer()
....

What we want to do this week is pick up our BGP peering process, and figure out what the code does next. In this particular case, the next step in the process is fairly simple to find, because it’s just another case in the switch statement in (st *ConnectState) processEvent

case BGPEventTcpCrAcked, BGPEventTcpConnConfirmed:
  st.fsm.StopConnectRetryTimer()
  st.fsm.SetPeerConn(data)
  st.fsm.sendOpenMessage()
  st.fsm.SetHoldTime(st.fsm.neighborConf.RunningConf.HoldTime,
    st.fsm.neighborConf.RunningConf.KeepaliveTime)
  st.fsm.StartHoldTimer()
  st.BaseState.fsm.ChangeState(NewOpenSentState(st.BaseState.fsm))
....

This looks like the right place—we’re looking at events that occur while in the connect state, and the result seems to be sending an open message. Before we move down this path, however, I’d like to be certain I’m chasing the right call chain, or logical thread. How can I do this? This code is called when (st *ConnectState) processEvent is called with an event Continue reading