Russ

Author Archives: Russ

New Ways of Thinking

Rule 11 definitely applies to most new technology that’s being hyped (and overhyped) in the networking world. But while some things stay the same, others actually do change. From one of my readers—

Much of the current “trends” in networking are largely just new marketing-speak on old concepts, but some (I’ll propose) are actually new, or require new ways of thinking—which is which, or for a simpler version: how (really) should I change my thinking to reflect the new-networking-order?

This question rebounds through the networking industry today—how, really, do I need to change my thinking to cope with the new networking order? There are, on the face of it, three options available. Let me begin with a story from a prior career to set the stage.

A long time ago, in a galaxy far away, I worked on airfield electronics and communication systems. Things like RADAR systems, wind speed measurement systems, TACANs, VORs, crypto hardware, MUX’s, inverse MUX’s, and even telephone switches. There was a point when I saw something interesting happening where I lived and spent my time. The TACAN and VOR, for instance, were replaced by new gear. Instead of half splitting, measuring things, and replacing individual components, Continue reading

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