Russ

Author Archives: Russ

VIRL on Packet Cloud—Some thoughts

For the last couple of days I’ve been messing with Cisco’s VIRL on Packet’s bare metal service. I don’t do enough labbing now to spend multiple thousands of dollars building a lab in my house, and I want something that I can use from anywhere without opening a lot of holes in my home network when I’m on the road, so the Packet service seems like something useful to get running.

Forthwith, some observations and hints for those who might be thinking about doing this. Some of this might be obvious to other folks, I know, but—maybe me writing them down here will be somehow helpful, and save other folks some time.

An observation—this all feels a little (okay, maybe a lot) clunky’ish. There’s a lot of steps, it takes a long time to set up, etc. There are a lot of moving parts, and they interconnect in interesting ways. Maybe this will all get better over time, but for now, if you’re going to do this, plan on spending at least a half a day, probably more, just getting all the pieces to work.

Some places I ran into trouble, and things I needed to configure that I had Continue reading

Do what you love?

How many times have you heard this? Or this?

Love-Quote-Do-what-you-love-and-you'll-never-work-a-day-in-your-life 92bce9fa2b136aa1c3ca5839e4aafad9

Two of the most oft repeated, and driven home, ideas in modern times are be true to yourself and do what you love. But just because they’re oft repeated and driven home doesn’t mean they are actually true. The problem with both statements is they have just enough truth to sound really plausible—and yet they are both simplistic enough to be dangerous when taken raw.

Or maybe it’s just that I’m a grumpy old man who’s been in a bad mood for the last couple of weeks, and misery likes company. ?

Let’s try to put some reality into the do what you love statement.

Sometimes you’re just not very good at what you love to do. When I was a kid, I wanted to be an artist. And then a musician. Apparently there are no real jobs for artists or musicians with my somewhat mediocre skills in these two areas. I just have to face it—I’m never going to be a professional basketball player, either. Sometimes it doesn’t matter how much you love something, you just don’t have the skills to master it.

Sometimes there’s just no market for what you Continue reading

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