Russ

Author Archives: Russ

Flooding Domains versus Areas

At a fundamental level, SPF and IS-IS are similar in operation. They both build neighbor adjacencies. They both use Dijkstra’s shortest path first (SPF) to find the shortest path to every destination in the network. They both advertise the state of each link connected to a network device. There are some differences, of course, such as the naming (OSI addresses versus IP addresses, intermediate systems versus routers). Many of the similarities and differences don’t play too much in the design of a network, though.

One difference that does play into network design, however, is the way in which the two protocols break up a single failure domain into multiple failure domains. In OSPF we have areas, while in IS-IS we have flooding domains. What’s the difference between these two, and how does it effect network design? Let’s use the illustration below as a helpful reference point for the two different solutions.

flooding-domains-02

In the upper network, we have an illustration of how OSPF areas work. Each router at the border of a flooding domain (an Area Border Router, or ABR), has a certain number of interfaces in each area. Another way of saying this is that an OSPF ABR is Continue reading

Flooding Domains versus Areas

At a fundamental level, OSPF and IS-IS are similar in operation. They both build neighbor adjacencies. They both use Dijkstra’s shortest path first (SPF) to find the shortest path to every destination in the network. They both advertise the state of each link connected to a network device. There are some differences, of course, such as the naming (OSI addresses versus IP addresses, intermediate systems versus routers). Many of the similarities and differences don’t play too much in the design of a network, though.

One difference that does play into network design, however, is the way in which the two protocols break up a single failure domain into multiple failure domains. In OSPF we have areas, while in IS-IS we have flooding domains. What’s the difference between these two, and how does it effect network design? Let’s use the illustration below as a helpful reference point for the two different solutions.

flooding-domains-02

In the upper network, we have an illustration of how OSPF areas work. Each router at the border of a flooding domain (an Area Border Router, or ABR), has a certain number of interfaces in each area. Another way of saying this is that an OSPF ABR is Continue reading

Securing BGP: A Case Study (8)

Throughout the last several months, I’ve been building a set of posts examining securing BGP as a sort of case study around protocol and/or system design. The point of this series of posts isn’t to find a way to secure BGP specifically, but rather to look at the kinds of problems we need to think about when building such a system. The interplay between technical and business requirements are wide and deep. In this post, I’m going to summarize the requirements drawn from the last seven posts in the series.

Don’t try to prove things you can’t. This might feel like a bit of an “anti-requirement,” but the point is still important. In this case, we can’t prove which path along which traffic will flow. We also can’t enforce policies, specifically “don’t transit this AS;” the best we can do is to provide information and letting other operators make a local decision about what to follow and what not to follow. In the larger sense, it’s important to understand what can, and what can’t, be solved, or rather what the practical limits of any solution might be, as close to the beginning of the design phase as possible.

In the Continue reading

RFC Reading List

While we normally think of RFCs as standards, there is actually a lot of useful information published through the IETF process that relates to basic network engineering concepts. Since this information is specifically and intentionally vendor independent, it often goes back to the theoretical basis of a line of thinking, or explains things in a way that’s free of vendor implementation jargon. From time to time, I like to highlight these sorts of drafts, to bring them to the notice of the wider networking community.

A lot of basic research has gone into quality of service from the perspective of queuing, marking, and dropping mechanisms. The result of this research is a wide array of quality of service mechanisms, which tend to be explained either using deep math, or in terms of “look what feature we’ve implemented, and here’s how to configure it.” RFC7806, published this month, is a useful intermediary between the high math and vendor implementation styles of presentation. This RFC describes a model often used for understanding quality of service, the Generalized Processor Sharing model, and how it applies to a few packet queuing, marking, and drop strategies.

Benchmarking routing protocols might not be something you Continue reading

Something Old, Something New…

Some time back a reader sent this question in—

Is there some list of design fundamentals which were “true” or at least “good rules of thumb” in the past (2 months to 20 years and beyond) which are still proclaimed as true and good, which we need to throw out, or at least question closely today?

It’s an interesting question—the problem is, of course, that there are two sorts of answers to this type of question. The first is rather specific, and the second is rather general. Let’s try the more specific answer first, and see if we can get to the more general one.

There are several rules of thumb that are no longer useful today.

OSPF and IS-IS flooding domains should be limited to 50/100/200 routers/intermediate systems. The old “50 in an area rule” is something several of us asked to be removed from Cisco Online something like 10 years ago, as it didn’t even apply then. I’ve heard 200 more recently, but the reality is—there is no right number here. I just did a two post series on dividing up flooding domains that might be useful here (part 1 and part 2).

There are provider Continue reading