Russ

Author Archives: Russ

Reaction: Complexity Sells

Over at IPSpace this last week, Ivan pointed to a paper by Dijkstra (and if you don’t know who that is, you need to learn a thing or two about the history of routing protocols—because history makes culture, and culture matters—or, as the tagline on this blog says, culture eats technology for breakfast). In this paper, Dijkstra points out some rather important things about computer science and programming that can be directly applied to the network engineering world. For instance, Ivan says—

People tend to forget that “doing away with the programmer” was COBOL’s major original objective. —Replace “programmer” with “networking engineer” and COBOL with SDN ?

I was fascinated with Ivan’s take on this paper—particularly in that complexity is an area I find interesting and very useful in my everyday life as a designer—that I went and read the original article. You should, too.

I think Ivan’s observations are spot on, but I think it’s worthwhile to actually broaden them. From where I sit, after 25 years building and breaking networks, I agree that complexity sells—but it sells for two particular reasons. The reason, as Dijkstra said all those years ago (in computer terms), is this:

Since the Continue reading

Getting to the point of dual homing

I wonder how many times I’ve seen this sort of diagram across the many years I’ve been doing network design?

dual-homing

It’s usually held up as an example of how clever the engineer running the network is about resilience. “You see,” the diagram asserts, “I’m smart enough to purchase connectivity from two providers, rather than one.”

Can I point something out? Admittedly it might not be all that obvious from the diagram, but… Reality is just about as likely to squish your network connectivity like a bug no a windshield as it is any other network. Particularly if both of these connections are in the same regional area. The tricky part is knowing, of course, what a “regional area” might happen to mean for any particular provider.

The problem with this design is very basic, and tied to the concept of shared link risk groups. But let me start someplace a little simpler than that—with the basic, and important, point that putting fiber in the ground, and maintaining fiber that’s in the ground, is expensive. Unless you live in Greenland, fiber can be physically buried pretty easily (fiber in Greenland is generally buried with dynamite by a blasting crew, or Continue reading

DNS Cookies and DDoS Attacks

DDoS attacks, particularly for ransom—essentially, “give me some bitcoin, or we’ll attack your server(s) and bring you down,” seem to be on the rise. While ransom attacks rarely actually materialize, the threat of DDoS overall is very large, and very large scale. Financial institutions, content providers, and others regularly consume tens of gigabits of attack traffic in the normal course of operation. What can be done about stopping, or at least slowing down, these attacks?

To answer, this question, we need to start with some better idea of some of the common mechanisms used to build a DDoS attack. It’s often not effective to simply take over a bunch of computers and send traffic from them at full speed; the users, and the user’s providers, will often notice machine sending large amounts of traffic in this way. Instead, what the attacker needs is some sort of public server that can (and will) act as an amplifier. Sending this intermediate server should cause the server to send an order of a magnitude more traffic towards the attack target. Ideally, the server, or set of servers, will have almost unlimited bandwidth, and bandwidth utilization characteristics that will make the attack appear Continue reading

No Capes, No Wands

As a keen observer of the network engineering world for the last twenty… okay, maybe longer, but I don’t want to sound like an old man telling stories quite yet… years, there’s one thing I’ve always found kind-of strange. We have a strong tendency towards hero worship.

I don’t really know why this might be, but I’ve seen it in Cisco TAC—the almost hushed tones around a senior engineer who “is brilliant.” I’ve seen it while sitting in a meeting in the middle of an argument over some technical point in a particular RFC. Someone says, “we should just ask the author…” Which is almost always followed by something like: “Really? You know them?”

To some degree, this is understandable—network engineering is difficult, and we should truly honor those in our world who have made a huge impact. In many other ways, it’s unhelpful, and even unhealthy. Why?

First, it tends to create an “us versus them,” atmosphere in our world. There are engineers who work on “normal” networks, and then there are those who work on, well, you know, special ones. Not everyone needs those “special skills,” so we end up creating a vast pool of people Continue reading

When prepend fails, what next? (3)

We began this short series with a simple problem—what do you do if your inbound traffic across two Internet facing links is imbalanced? In other words, how do you do BGP load balancing? The first post looked at problems with AS Path prepend, while the second looked at de-aggregating and using communities to modify the local preference within the upstream provider’s network.

There is one specific solution I want to discuss a bit more before I end this little series: de-aggregation. Advertising longer prefixes is the “big hammer” of routing; you should always be careful when advertising more specifics. The Default Free Zone (DFZ) is much like the “commons” of an old village. No-one actually “owns” the routing table in the global Internet, but everyone benefits from it. De-aggregating don’t really cost you anything, but it does cost everyone else something. It’s easy enough to inject another route into the routing table, but remember the longer prefix you inject shows up everywhere in the world. You’re fixing your problem by taking up some small amount of memory in every router that’s connected to the DFZ in the world. If everyone de-aggregates, everyone has to buy larger routers and more Continue reading