
Author Archives: Russ
Author Archives: Russ
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—
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—
Assume—
The post Worth Reading: What Sauron Tells Us appeared first on 'net work.
The post Worth Reading: Lawless government hacking appeared first on 'net work.
The post Worth Reading: Hosts versus the network appeared first on 'net work.
The post Worth Reading: Reopening the going dark debate appeared first on 'net work.
A lot of people seem to be looking forward to the day we build a network without an operator; to wit—
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.
And 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
The post Worth Reading: Container defense in depth appeared first on 'net work.
The post Worth Reading: Your chance to say no appeared first on 'net work.
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?
Or 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
The post Worth Reading: Tracking the hackers appeared first on 'net work.
The post Worth Reading: Network monitoring appeared first on 'net work.
The post On the ‘net: Crashes and Complexity appeared first on 'net work.
The post Worth Reading: Networking needs information, not data appeared first on 'net work.
The post Worth Reading: IPv6 inside LinkedIn appeared first on 'net work.
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
The post Worth Reading: Email optimization appeared first on 'net work.
The post Worth Reading: NTP is still a security risk appeared first on 'net work.