Russ

Author Archives: Russ

Reaction: BGP convergence, divergence & the ‘net

Let’s have a little talk about BGP convergence.

We tend to make a number of assumptions about the Internet, and sometimes these assumptions don’t always stand up to critical analysis. . . . On the Internet anyone can communicate with anyone else – right? -via APNIC

Geoff Huston’s recent article on the reality of Internet connectivity—no, everyone cannot connect to everyone—prompted a range of reactions from various folks I know.

For instance, BGP is broken! After all, any routing protocol that can’t provide basic reachability to every attached destination must be broken, right? The problem with this statement is it assumes BGP is, at core, a routing protocol. To set the record straight, BGP is not, at heart, a routing protocol in the traditional sense of the term. BGP is a system used to describe bilateral peering arrangements between independent parties in a way that provides loop free reachability information. The primary focus of BGP is not loop free reachability, but policy.

After all, BGP convergence is a big deal, right? Part of the problem here is that we use BGP as a routing protocol in some situations (for instance, on data center fabrics), so we have a hard time adjusting our thinking Continue reading

DoS’ing your mind: Controlling information inflow

Everyone wants your attention. No, seriously, they do. We’ve gone from a world where there were lots of readers and not much content, to a world where there is lots of content, and not many readers. There’s the latest game over here, the latest way to “get 20,000 readers,” over there, the way to “retire by the time you’re 32” over yonder, and “how to cure every known disease with this simple group of weird fruit from someplace you’ve never heard of (but you’ll certainly go find, and revel in the pictures of perfectly healthy inhabitants now),” naggling someplace at the back of your mind.

The insidious, distracting suck of the Internet has become seemingly inescapable. Calling us from our pockets, lurking behind work documents, it’s merely a click away. Studies have shown that each day we spend, on average, five and a half hours on digital media, and glance at our phones 221 times. -via connecting

Living this way isn’t healthy. It reduces your attention span, which in turn destroys your ability to get anything done, as well as destroying your mind. So we need to stop. “Squirrel” is funny, but you crash planes. “Shiny thing” is funny, but Continue reading

New Address

To make this blog a little easier to find, I’ve pointed rule11.us here as well. ntwrk.guru will continue to work, as well, but people seem to have a hard time remembering the url, so I added a second one.

LinkedInTwitterGoogle+FacebookPinterest

The post New Address appeared first on 'net work.

Slicing and Dicing Flooding Domains (1)

This week two different folks have asked me about when and where I would split up a flooding domain (IS-IS) or area (OSPF); I figured a question asked twice in one week is worth a blog post, so here we are…

Before I start on the technical reasons, I’m going to say something that might surprise long time readers: there is rarely any technical reason to split a single flooding domain into multiple flooding domains. That said, I’ll go through the technical reasons anyway.

There are really three things to think about when considering how a flooding domain is performing:

  • SPF run time
  • flooding frequency
  • LSDB size

design-files
Let’s look at the third issue first, the database size. This is theoretically an issue, but it’s really only an issue if you have a lot of nodes and routes. I can’t ever recall bumping up against this problem, but what if I did? I’d start by taking the transit links out of the database entirely—for instance, by configuring all the interfaces that face actual host devices as passive interfaces (which you should be doing anyway!), and configuring IS-IS to advertise just the passive interfaces. You can pull similar tricks in OSPF. Continue reading

Security ‘net: Internet of Things and iPhones edition

One of my college professors has suggested that the question of whether or not Apple should help the FBI break the encryption on the iPhone used by a terrorist is an ideal diagnostic question for your view of all things privacy. There are, of course, gray area answers, like “Apple should help the FBI break the encryption in this case, but not others.” The problem is, of course, that this isn’t the simple answer it might seem. First, there are motives behind the apparent motives. Many people see Apple as just “doing what’s right to save the world.” I don’t see it that way at all. Given I’m a bit cynical (who would have guessed), I see two motives from Apple’s point of view.

First, Apple is trying to protect a marketing stance. They’ve as much as admitted this in court documents and the implied threat of suing the U.S. Government for loss of revenue if they’re forced to build a version of their O/S that will allow the FBI to break the encryption. Just Security notes—

There are other interests at stake here too. Apple has a liberty interest in not being dragooned into writing forensic Continue reading

Why you should care about complexity

If you look across a wide array of networking problems, you will see what is an apparently wide array of dissimilar and unrelated problems engineers deal with on a daily basis. For instance—

  • Should I split this flooding domain into multiple parts? If so, where should I divide it?
  • Which routing protocol should I use on this network topology, and to solve this set of problems?
  • How should I configure the Quality of Service parameters on this network?
  • Should I use MPLS on my data center fabric, or straight IP?

Over my years as a network engineer, I’ve always treated these as separate sorts of problems, each with their own tradeoffs, concepts, and models. In fact, I’ve been a kindof “collector of models” over the years, trying to find different models to address each situation. In the Art of Network Architecture, there’s an entire chapter on the models Denise and I have run in to over the years, where they seem to be useful, and where they seem to be limited. complexity-model

But keeping all of these models in my head didn’t help me generalize the problems I faced in building and troubleshooting networks. For instance, in the flooding domain instance Continue reading

1 90 91 92 93 94 117