Archive

Category Archives for "Russ White"

Reaction: Forced Updates

The controversy over Microsoft forcing upgrades on users is in the news again, as the EFF has posted an article once again about the forced upgrades to Windows 10, and the various data collection schemes Microsoft has put in place. I understand the concern, but… A couple of points to consider, starting with forced upgrades—

When I worked in customer support I sometimes wished we had forced upgrades (rather than paid ones, in fact). There are so many times someone doesn’t upgrade past an obvious bug. We would spend hours working around the bug because they didn’t want to upgrade. It probably cost the company I worked for millions of dollars in support a year so we could refrain from saying, “take two upgrades and call me in the morning.”

As an operator, I see the other side of this story—if I don’t need the upgrade, or I’m not hitting the bug, I shouldn’t need to upgrade.

The world of IoT—in fact, the world in which we live, where millions of machines are used as botnets without the knowledge of their owners—is pretty frightening without forced upgrades. I wonder how many millions of dollars a year machines with Continue reading

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—