Today’s post is about one of the most basic OSPF rules.
I was often called upon, in past jobs, to conduct technical interviews with applicants to network engineering and professional services positions. A CCIE and experience commensurate with that certification was typically a gateway to just being considered for a technical interview, so these job candidates were no slouches in what they knew.
Unless the candidate came from a service provider background they probably had no practical MPLS and IS-IS, and only basic BGP, experience. So I usually couldn’t dig very deep there, and only tried to determine their capacity for quickly coming up to speed on those protocols. I did, however, expect every candidate to have extensive experience with OSPF and that’s where I focused most of my questions.
That leads to my favorite technical interview question, one that I asked almost every time. It’s a question that reveals whether a person has some understanding of how the protocol works, rather than just how to configure it. And I am still surprised how often people stumble on it.
Here it is:
Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?
Comparing three fundamental concepts of link state protocols, concepts that even most OSPF beginners understand, easily derives the answer to the question.
The first concept is this:
Every link state router floods information about itself, its links, and its neighbors to every other router. From this flooded information each router builds an identical link state database. Each router then independently runs a shortest-path-first calculation on its database – a local calculation using distributed information – to derive a shortest-path tree. This tree is a sort of map of the shortest path to every other router.
One of the advantages of link state protocols is that the link state database provides a “view” of the entire network, preventing most routing loops. This is in contrast to distance vector protocols, in which route information is passed hop-by-hop through the network and a calculation is performed at each hop – a distributed calculation using local information. Each router along a route is dependent on the router before it to perform its calculations correctly and then correctly pass along the results. When a router advertises the prefixes it learns to its neighbors it’s basically saying, “I know how to reach these destinations.” And because each distance vector router knows only what its neighbors tell it, and has no “view” of the network beyond the neighbors, the protocol is vulnerable to loops.
The second concept is this:
When link state domains grow large, the flooding and the resulting size of the link state database becomes a scaling problem. The problem is remedied by breaking the routing domain into areas: That first concept is modified so that flooding occurs only within the boundaries of an area, and the resulting link state database contains only information from the routers in the area. This, in turn, means that each router’s calculated shortest-path tree only describes the path to other routers within the area.
The third concept is this:
OSPF areas are connected by one or more Area Border Routers (the other main link state protocol, IS-IS, connects areas somewhat differently) which maintain a separate link state database and calculate a separate shortest-path tree for each of their connected areas. So an ABR by definition is a member of two or more areas. It advertises the prefixes it learns in one area to its other areas by flooding Type 3 LSAs into the areas that basically say, “I know how to reach these destinations.”
Wait a minute – what that last concept described is not link state, it’s distance vector. The routers in an area cannot “see” past the ABR, and rely on the ABR to correctly tell them what prefixes it can reach. The SPF calculation within an area derives a shortest-path tree that depicts all prefixes beyond the ABR as leaf subnets connected to the ABR at some specified cost.
And that leads us to the answer to the question:
Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.
This is my little gift to you. The next time you are being interviewed by an old coot that likes to use this question to weed out the cookbook operators from those who actually understand a little about OSPF, you can bring a smile to his grizzled face.
Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.
|
|
Why does OSPF require all
Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?
Well, this question assumes a particular implementation of OSPF protocol from vendor C, isn't it?
Cisco's implementation is detailed in RFC 3509 ("Alternative Implementations of OSPF Area Border Routers"), which requires a router connected to two non-backbone area not to identify itself as an ABR, while an implementation conforming to RFC 2328 would do so and allow some traffic to pass between two non-backbone areas without touching area 0.
Though, I totally aree about OSPF's distance-vector behavior when it comes to inter-area routing. I think, it was spelled out in some of your books, but anyway thanks for stressing that one more time.
Re: Why does OSPF require all
I’m not assuming a Cisco implementation at all. RFC 3509 provides some modifications for corner cases (and I’ve used scenarios similar to the last example in that RFC when I want to give an interviewee a really ugly problem to explain), but in almost all cases connecting two non-backbone areas somewhere other than at area 0 is a bad idea. The person doing it might know exactly what they’re doing, and might have considered the contingencies well. But eventually some regular schlub like me is going to have to troubleshoot it or modify it, and then you get problems.
Whether from differing interpretations or differing customer demands, you can get ABRs behaving differently from different vendors – IOS and JUNOS, for example – and thus the capability to do some curious things with OSPF topologies. And playing around with oddball multi-area OSPF topologies in the lab is a great way to get a deeper understanding of the protocol, so I encourage that. But in production networks I stand by the assertion that correct multi-area design is the traditional “daisy” (area 0 in the middle, all other areas the petals connected around area 0, and no petals touching each other anywhere else).
Here’s a scenario that demands some semantic hand-waving, though:
Take a single ABR that connects areas 1, 2, and 3. That ABR does not actually need to be connected to area 0 for the three areas to communicate (depending, as you cite, on the specific vendor implementation). So traffic is passing inter-area without passing through an area 0.
In this scenario the letter of the law is broken but not the spirit: The ABR itself serves as the backbone, and the OSPF topology is still loop-free, which is the point. You just have the ABR as the middle of the daisy rather than area 0.
I absolutely agree on the
I absolutely agree on the notion that sane design rules require area 0 in the middle, other's connecting to it and not to each other.
But your question was worded "why does OSPF require" and not "why does sane design require", so I couldn't help but nitpick on that. :)
By the way, while we are at it, may I ask you to write an entry on draft-thorup-ospf-harmful? I think that the draft had some valid points. I'm very interested to know your opinion. I think other readers would be interested too.
Re: I absolutely agree on the
The Thorup draft expired in February 2004, so for those readers who want to see what we’re talking about I put a copy on my website; you can read it here.
The draft does indeed have some valid points; I dislike OSPF areas, perhaps because I’ve seen so many poorly designed multi-area topologies. Big, single area OSPF topologies can solve a multitude of routing weirdnesses, MPLS traffic engineering difficulties, and just general operational challenges.
That’s one of the major reasons I’m a fan of IS-IS: It’s simpler and, in my opinion, a little more scalable in single-area topologies. On the other hand, multi-area IS-IS is a bigger headache than multi-area OSPF.
OSPF and IS-IS were designed in the early 1990s when router CPU and memory resources were limited and there was far less industry experience with designing link state protocols or networks that run link state protocols. As a result OSPF and IS-IS continue to this day with a few features meant to address those concerns, and which just no longer matter. Areas sprang out of that early concern, although I would not classify them as a feature that does not matter any more; they do still have their uses and are sometimes unavoidable.
When I design an OSPF network I start with a single area and only add non-backbone areas when I can convince myself that they’re necessary. (On the other hand, defending a single-area design is often a matter of convincing my customer that multiple areas are not necessary.)
So how big can a single OSPF area get? Here’s an anecdote (and apologies to all if I’ve told the story on this blog before; I don’t recall): I was once brought in by a network operator to assess their single-area OSPF network that contained just over 1,000 routers. Although they had not experienced any problems, they were planning to make some additions and were worried that the changes would be enough to tip the whole thing over. I did a careful analysis and could find no performance or memory problems; the customer made the planned changes and the network is still humming along in a single area.
Having said all that, I don’t agree with everything in the draft. For example, the grid topology of Figure 2 is unrealistic as is the 4*sqrt(n)-4 formula for ABRs he associates with it: A 50-router area with 26 ABRs simply would not be found in any remotely rational network. Thorup’s intent is to clearly punctuate his position that areas can cause an information increase, but the example is so extreme it becomes a straw-man.
He does go on to make some better points about areas later, including some of the gains you can get (and tradeoffs incurred) by summarizing at the ABR.
So bottom line: Areas are used in networks far more often than they are actually needed, but when they are needed they’re tremendously useful for scaling and control. A cardinal rule of network design is to start as simple as possible and then add complexities (such as areas) only when they are the simplest solution to an identified problem.
--Jeff
Thank you
Thank you very much for sharing your thoughts about the draft, Jeff.
I have very similiar feelings about this document and the whole issue of OSFP areas. So I'm delighted that you have confirmed my understanding.
Thanks for a really
Thanks for a really informative article Jeff. I'm still pretty new to OSPF myself and sometimes wondered why OSPF area 0 was a necessity eventhough i knew the fundamentals that you mentioned in your first post.
My question is regarding your comment "Big, single area OSPF topologies can solve a multitude of routing weirdnesses, MPLS traffic engineering difficulties"
Can you please comment on the kind of potential issues that can arise within the Context of MPLS TE and a Multi Area OSPF deign.
Thanks
Re: Thanks for a really
Hi Norm,
MPLS-TE builds a traffic engineering database, very similar to the link state database, from which the paths of LSPs are calculated based on the constraints you specify. Each router must communicate to all the other MPLS-TE routers the traffic engineering parameters of its links so that they can build the traffic engineering database.
Both OSPF and IS-IS have extensions that support the flooding of these traffic engineering parameters. OSPF uses a Traffic Engineering LSA, which is based on a Type 10 Opaque LSA (see RFC 3630 for OSPF TE extensions, and RFC 2370 for a description of Opaque LSAs). The link TE parameters the LSA carries are:
The same LSA can also carry GMPLS parameters, but that’s not relevant to what we’re discussing here.
Here’s the rub: The Type 10 Opaque LSA has an area scope, the same as Types 1, 2, and 3 LSAs, meaning it cannot be flooded outside of an area. So just as with normal link state databases, the TE database cannot “see” outside of an area and the paths calculated from it are bounded by the area. (IS-IS TE extensions carry the same information and have a level flooding scope which is more or less the same as the OSPF area scope, and so has the same limitations).
So the usual way of designing MPLS-TE networks is to put it all in one area – which is where single-area scalability concerns come into play.
There are a few design tricks and vendor solutions that help you run inter-area MPLS-TE, but they just add unwanted complexity.
--Jeff
Thank You Sir..
Thank You Sir for the wonderful explanation.
best,
Norm
Jeff, could please share the
Jeff, could please share the tricks which you are talking about that would help to run inter-area MPLS-TE & after reading above discussion I am crystal clear that its highly recommended to run MPLS-TE in single area.
Thanks & Regards,
Akhtar
Hi Jeff, Quoting your post
Hi Jeff,
Quoting your post
"Take a single ABR that connects areas 1, 2, and 3. That ABR does not actually need to be connected to area 0 for the three areas to communicate (depending, as you cite, on the specific vendor implementation). So traffic is passing inter-area without passing through an area 0."
Could you possibly explain this a bit more. Maybe I haven't interpreted this correctly but is it actually possible for non-backbone area's to communicate without an area 0.
One more question which is a bit unreleated is on IS-IS. Could you possibly start up a topic on IS-IS explaining its similarities, benefits and shortcomings to OSPF. I am particularly interested in understanding how is IS-IS able to avoid loops for inter-area communication. My trivial understanding of IS-IS is that L1 routers equate to Intra-Area routers in OSPF terminology, L1/L2 routers would be ABR's and L2 routers would be ABR/ASBR's. (I am using the term "area" purely because I can't seem to remember if there was another term describing them in IS-IS). In order to connect 2 different area's you would have to use a L1/L2 router or a pure L2 router. However how does this avoid loops. Is there some sort of topology of the backbone routers created and advertised in other area's in order to avoid loops. Thanks for your help.