Home / Routing / IGP / ISIS / Link state protocols and Areas concept

Link state protocols and Areas concept

Link state protocols have introduced the concept of multiple routing areas withing the same routing domain. Link state protocols depend on the fact that all routers must have an identical link state database and then each router will start calculating its very own routing table from this information.

However, this rule sometimes introduce scalability limitations to network designers. In very large networks all routers must maintain the same link state database; this induces some scalability limitations in these networks.

One of these limitations is that all routers in the network must have sufficient processing power and storage capacity to handle the large link state database. Another kind of limitation is that database flooding and synchronization operations may consume lots of the available network resources causing spikes in both bandwidth and processor utilization.

The concept of Areas comes in hand to resolve these kind of scalability limitations. By dividing the large IGP domain into multiple areas we can isolate network changes, link state database flooding/sync operations within the single area. Routers with low memory and processing power can still be used by putting them in small areas

But what about real life situations ?! From my own experience I have not seen networks applying this concept of Areas to solve scalability issues. I have worked for two service providers one of them is running OSPF in the core and the other is running IS-IS and both of them have no scalability problems with a single area design, specially with the increasing of processing and memory power of today’s routers.

Multiple areas can also be used to control traffic from one part of your network to another even if not having scalability limitations.

End of story is that areas are one tool in your arsenal as a network designer, you can still use in your network whenever you find a real need for using them, however the main rule is to keep things simple.

That was my experince with area desing, what do you think from your own experince?


  1. I agree with Wael, JDoyle has a very nice discussion about this issue on his post in the comments part


  2. Dave, I think Jeff doyel is one of the authorities in large scale network design in the world today.

  3. we run OSPF with one area, no major problems but sometimes small routers peak to 100% cpu when a link flaps heavily…

  4. Dear Wael,

    Regarding to the Area concepts of the OSPF, every area should be attached to Area 0 via ABR to be able to get the latest LSAs that roams in the Area 0. Ok, that’s cool, but why?

    When tested via dynamips, I reached that, the router which for example, gather Area 1 and Area 2 isn’t marked as ABR when we do “sh ip ospf”, so the router consider itself as non-ABR and shouldn’t flood LSAs from Area 1 to Area 2.

    That’s also cool, and logical.

    Now, I’ve configured the non-ABR which attach Area 1 with Area 2 with a loopback interface and put this interface in Area 0 at the interface level, so the non-ABR router became an ABR and it’s now flood the LSAs learnt from the other Areas into the isolated Area!

    So, I guess it worked fine, I can receive the interarea and external routes perfectly! Why then we need to creat a virtual link when we can do a “fake Area 0” at the loopback of the non-ABR we want to make it as ABR?

    Thanks for your effort.

  5. Mohamed,

    Good question; it needs a separate post to cover the issues you have touched in the comment.

    But we can try to briefly clarify it here

    – The rule that Inter-area routing must traverse area zero is only a recommendation in the RFC and was made as an obligation by CISCO implementation only.

    – Having routes moving from area to area without traversing a common backbone can introduce routing loops.

    – The trick you have done works in simple networks (between two areas only). Try to add an area zero adjacency to one of the other routers in different areas you will see that LSAs will not be installed in routing tables of other ABR routers.

    This is only a simple fast clarification for your case and I promise to make a detailed post.

    Good lucks with your LABs

  6. Hi Mohamed,

    I do like your analysis methodology. As Wael stated we can cover these tiny details in separate posts, comments from people like your self energizes us to proceed.

    Back to the last part of your question, I like to address it from another prospective, the loopback trick is fine when we are talking about a single router connected to multiple areas having only a single router per area connected to it, but in reality you might have a situation with multiple routers connected to multiple areas (most probably when repairing a partitioned backbone area), and thus you need a mean of moving the Inter-area information to the other router(s) in order for the other areas on the other router(s) to be able to learn them (since Inter-area information can never go from an area to another directly – at least with Cisco’s implementation), and here comes the virtual-link, it would provide a virtual backbone connection between the different routers in order to be able to exchange the different Inter-area information that each knows (notice that with Inter-area things tend to distance-vector behavior).

    Well as Wael said, these details require separate posts, and again comments as yours energizes us to go on with such posts.

    Mohammed Mahmoud.

  7. Thanks Wael and Mohammed for the comprehensive answer! I’d really spend a long time trying to figure out the reason.

    Thanks again 🙂

  8. Thanks Wael and Mohamed for your comprehensive answer! I’d really spend a long time trying to figure out the reason.

    Thanks again 🙂