Archive

Category Archives for "Russ White"

Writing books still matters—reading them does, too

Ivan, over at ipspace.net, has an interesting post up on writing books —

Why would you want to write a book? If you think you’ll earn a lot of money, think twice… unless you plan to write a science fiction bestseller, Swift-for-Dummies, or 50 Shades of Something.

Several points in reply…

No, you won’t make a lot of money. Writing books for a living (in fact, writing for a living at all) has been pretty much destroyed by several factors, including the absolute dismal rate at which our culture reads (I’m considered something of a freak with my goal of reading 100 books/year; C.S. Lewis read that many in a few weeks in the hospital, across four or five languages), and the rate at which people try to “climb the author pile” by writing for free on blogs/etc.

There is one comment here that I think is really worth pointing out: To make matters worse, core networking is not exactly a popular topic (compared to Swift Programming or Introduction to IPv6)… I’ve heard this a lot in my time as an author—for instance, my books simply don’t sell as well as just about anything at the CCIE level, Continue reading

Reaction: The 650 Gb/s software router

I’m forever seeing announcements like this in the software defined networking world—

The Linux-based CloudRouter Project, which is working on code for an open source virtual router, released version 3.0 this week. It adds Linux Data Plane Development Kit (DPDK) kernel enhancements and claims throughput in excess of 650 Gb/s on commodity hardware.

But you need to note one specific thing about this announcement. How did they achieve these forwarding rates? By using DPDK to offload the actual, well, forwarding to a custom ASIC on a NIC. The reality is that we’ve always done the control plane in software, and we’ve always done the forwarding in hardware. There have been precious few router platforms over the years where the forwarding plane is actually an “embedded system.”

Certainly we’re seeing a world where open source operating systems are learning to interact with commodity ASICs so it’s possible to separate the software from the hardware, and the operating system from the control plane, and this is all too the good. But if this is software defined networking, then we’ve been doing this since sometime in the 1990’s, perhaps even earlier…

Perhaps we’ve become so accustomed to considering the network operating Continue reading

Securing BGP: A Case Study (6)

In my last post on securing BGP, I said—

Here I’m going to discuss the problem of a centralized versus distributed database to carry the information needed to secure BGP. There are actually, again, two elements to this problem—a set of pure technical issues, and a set of more business related problems. The technical problems revolve around the CAP theorem, which is something that wants to be discussed in a separate post; I’ll do something on CAP in a separate post next week and link it back to this series.

The CAP theorem post referenced above is here.

securing-bgpBefore I dive into the technical issues, I want to return to the business issues for a moment. In a call this week on the topic of BGP security, someone pointed out that there is no difference between an advertisement in BGP asserting some piece of information (reachability or connectivity, take your pick), and an advertisements outside BGP asserting this same bit of information. The point of the question is this: if I can’t trust you to advertise the right thing in one setting, then why should I trust you to advertise the right thing in another? More specifically, if you’re using Continue reading

The Candy Jar Effect

When I first started in Cisco TAC, as a lowly grade 3 engineer taking hardware RMA calls, I didn’t know anyone. I had just moved to North Carolina, we hadn’t found a church yet, I’m not the most social person on the face of the earth (in fact, if anything, I’m antisocial), and I was sitting in a cubicle surrounded by people who’d been working in serious networking for a lot longer than I had. Not only that, but a lot of them were a lot smarter than I was (and still are). These people were really busy; it was hard to sip from the firehose, and I really needed to find my way around. How could I go about building a network?candy-jar-effect

What to do… ??

I put a candy jar on my desk, and filled it with interesting candy. How would a candy jar work? Well, it attracted all sorts of interesting people to my desk throughout the day, and as I got to know what different people liked, it gave me an excuse to bring stuff to their desk—along with a question about a case I was working on, of course. In a sense, I learned all I Continue reading

The CORD Architecture

Edge provider networks, supporting DSL, voice, and other services to consumers and small businesses, tend to be more heavily bound by vendor specific equipment and hardware centric standards. These networks are built around the more closed telephone standards, rather than the more open internetworking standards, and hence they tend to be more expensive to operate and manage. As one friend said about a company that supplies this equipment, “they just print money.” The large edge providers, such as AT&T and Verizon, however, are not endless pools of money. These providers are in a squeeze between the content providers, who are taking large shares of revenue, and consumers, who are always looking for a lower price option for communications and new and interesting services.

If this seems like an area that’s ripe for virtualization to you, you’re not alone. AT&T has been working on a project called CORD for a few years in this area; they published a series of papers on the topic that make for interesting reading:

Reaction: Should routing react to the data plane?

Over at Packet Pushers, there’s an interesting post asking why we don’t use actual user traffic to detect network failures, and hence to drive routing protocol convergence—or rather, asking why routing doesn’t react to the data place.

I have been looking at convergence from a user perspective, in that the real aim of convergence is to provide a stable network for the users traversing the network, or more specifically the user traffic traversing the network. As such, I found myself asking this question: “What is the minimum diameter (or radius) of a network so that the ‘loss’ of traffic from a TCP/UDP ‘stream’ seen locally would indicate a network outage FASTER than a routing update?”

This is, indeed, an interesting question—and ones that’s highly relevant in our current software defined/drive world. So why not? Let me give you two lines of thinking that might be used to answer this question.

First, let’s consider the larger problem of fast convergence. Anyone who’s spent time in any of my books, or sat through any of my presentations, should know the four steps to convergence—but just in case, let’s cover them again, using a slide from my forthcoming LiveLesson on IS-IS:

Convergence Steps

There Continue reading