Russ
Author Archives: Russ
- Home → Author's archive:
Russ
IT/IT: A GUI and a Wizard
One of the brilliant things about conferences like Interop is the hallways (and if you’re not going to Interop, this is why you should be!). It’s not that I don’t enjoy the sessions, but — like the IETF — I often get much more out of the conversations with folks who know networking, and yet have a completely different view of the problems we face in the networking industry, and hence completely different ideas about the way forward in resolving those problems. One of my major problems in life is I often can’t think of a solid answer when I’m sitting there in the conversation itself (one of the reasons I always converted TAC cases to email, rather than sitting on the phone with a customer).
One such conversation (with @cigoodwi) brought out a phrase I thought I’d never hear in the networking world — “a GUI and a wizard.” The context was this: what most x% (your beliefs about the percentage may vary) companies need is a network they can run with a GUI and a wizard. It’s a startling statement, of course, but — in reality — true in many respects. Given this is our Continue reading
Face to Face, Machine to Machine
The post Face to Face, Machine to Machine appeared first on 'net work.
Own the Problem
In the late 1990’s, I was on the routing protocols TAC team in Raleigh — which means I answered the phone, and said things like, “This is Russ from Cisco TAC, how can I help you?” Generally what followed was a crash, or, well, just about anything. The design on the left is what we had on the back of our shirts — including what we called ourselves, the Gateway of Last Resort.
Of course it’s a play on words, as you might imagine — where does a host send traffic it doesn’t know what to do with? The gateway of last resort. And what is the gateway of last resort? A router. And what the RP team worked on was, well, routers. But there’s another reason we adopted this slogan for ourselves — because it was, generally speaking, how the CRC (the folks who took the initial call and figured out which backline team to hand it off to) conceived of our little team. The PIX, the 7200, VIP cards, crashes, hangs, tracebacks, any sort of routing protocol problem, lots of hardware problems, anything to do with the forwarding path, memory fragmentation, and just about anything else. A Continue reading
IT/IT: Observations on Ownership
We are clearly moving to a software focused world — this conclusion is almost as inevitable and natural as taking your next breath (or eating that next Little Bits burger — but don’t get the big one unless you’re really hungry).
But, as with all things, there is a flip side to the world going to software. It could actually turn out that the IT world is on the path to becoming our own worst enemies. This, by the way, is what caught my eye this week, and what causes me to rant a little.
The cost and hassle of repairing modern tractors has soured a lot of farmers on computerized systems altogether. In a September issue of Farm Journal, farm auction expert Greg Peterson noted that demand for newer tractors was falling. Tellingly, the price of and demand for older tractors (without all the digital bells and whistles) has picked up. “As for the simplicity, you’ve all heard the chatter,” Machinery Pete wrote. “There’s an increasing number of farmers placing greater value on acquiring older simpler machines that don’t require a computer to fix.”
The issue at stake, at least in the United States, is the Digital Continue reading
Williamsburg
The post Williamsburg appeared first on 'net work.
In theory…
I don’t normally peruse the reviews of my books — while I appreciate well thought out criticism, I normally find personal notes from folks who’ve read my books more profitable for mining out where I’m falling down on the job as a writer than reviews posted on book seller or book review sites. But one specific book review caught my eye the other day that I think points to a larger issue in the world of engineering, especially network engineering. The reviewer stated, in essence, that there was not enough practical application in my more recent tomes, and that I’m covering the same information over and over again.
Let me begin here — I’m not writing this as a defense of my own writing so much as to think through a habit of mind I think doesn’t really help us as an engineering community.
As far as the facts on the ground go, the reviewer is right on both counts, and wrong on both counts. Let’s imagine, for a moment, that you want to understand how a car works. You approach three different people — one a race car driver, another a top flight mechanic, and another an engineer who Continue reading
IT/IT: Merge Lane
You’re probably living in a bubble (or sleeping on a mat in the data center — remind me to tell you about the sleeping bag I carried in the back of my truck for a while…) if you’ve not heard about the Nokia/Alcatel merger. What’s interesting, from a network engineering perspective, is what this means. To get a better idea, it’s important to consider another story posted this last week.
The white box switching market could see some monumental change within even one year, according to Dell’Oro Group analyst Alan Weckel. That’s mainly because of the rise of hyperscale cloud players — specifically Amazon, Facebook, Google, and Microsoft. Their buying power has grown substantially in the past few years — and white boxes have progressed rapidly during that time, too.
So what does white box have to do with the Nokia/ALU merger? Just about everything, most likely. To better understand, we need to first posit that the world is going software. Not that we won’t have hardware any longer, but rather that the hardware is going to become much less interesting over the next five to ten years as the software used to run the hardware is separated out and Continue reading
The facts, while interesting, are irrelevant
Maybe my excuse should be that it was somewhere around two in the morning. Or maybe it was just unclear thinking, and that was that. Sgt P. and I were called out to fix the AN/FPS-77 RADAR system just at the end of our day (I normally came into the shop around 6:30AM after swimming a mile in the Ft. Dix pool, showering, and eating breakfast, so I truly had an early start), so we’d been fighting this problem for some seven or eight hours already. For some reason, a particular fuse down in the high voltage power supply kept blowing. Given this is the circuit that fed the magnetron with 250,000 volts at around 10 amps (yes, that’s a lot of power, especially for a device originally built in 1964), it made for some interesting discussion with the folks in base weather, who were thus dependent on surrounding weather RADAR systems to continue flight operations.
They weren’t happy.
We traced the problem back, using our best half splitting skills in a high voltage circuit that took minutes to power up and down, and finally decided it was a particular resistor located over on a corner of one assembly (we Continue reading
Freedom to
Pardon me if I go a little bit on the philosophical side of life as a network engineer this week, but we need to have a little talk about freedom. This last week, Ethan wrote a post on his new criteria for network design and architecture. While I agree with the points Ethan makes in his post, there was one thing that put me sideways. In fact, this one thing has always put me sideways to our modern world.
Freedom.
Ethan gives what is a pretty standard (Lockian) definition of the idea when he says, “Freedom is the power or right to act, speak or think as one wants without hindrance or restraint.”
But, harking back to the story of Ishmael and Isaac, we need to remember there is a real difference between freedom from and freedom to. Freedom from constraint might feel like real freedom, but it’s the freedom of the wilderness. Freedom to create might feel like slavery with its self-discipline and bounds, but it’s the freedom to build — to create.
Let’s turn to one of Ethan’s examples here — open standards, and vendors sticking to them, to bring the point to the world of network Continue reading
Learning from Germanwings
On the 24th of March, the pilot of Germanwings flight 4U9525 into a field, killing everyone on board, including himself. This is a human tragedy — beyond what many of us will experience in our lifetimes. But it’s also an important object lesson to those of us who live in the world of engineering. Think through the entire realm of airline safety that has been put into place since the terrorist attacks on the 11th of September in 2001.
- Advanced scanning machines (which are not without their own share of controversy)
- Increased security inside the airplane, including locked cockpit doors
- Stricter regulations on liquids carried onto the airplane
- Removal of electronic items from bags so they can be independently assessed
The list feels almost endless to the person on the receiving end of all these new measures. The pilot, in this case, either bypassed the protection, or used it to his advantage. Advanced scanning machines, liquids restrictions, and laptop inspections can’t prevent someone intent on harming lots of people if they have control of the airplane itself. The locked cockpit door just created a “safe space” in which the co-pilot could work his plan out.
So what’s the point of Continue reading