Home » Bury the hatchet » The endless story of OSPF vs IS-IS

The endless story of OSPF vs IS-IS

Whenever you have a little IGP chit chat you’ll hit this endless story. I’ve tried to reach a final solid conclusion my self but IMHO its all about personal preference and taste. It is something like a Ferrari vs Lamborghini story, they offer comparable performance, but totally different feeling. It is all about a good design, that contains a balanced mixture of scalability, convergence, flexibility, extensibility, resources consumption, configuration, troubleshooting, etc.

In this series of posts I’ll try to contrast their likes and differences (not the Ferrari vs Lamborghini of course!), however I am not going to try to influence your opinion (vote for IS-IS ;)), rather I’ll try to share with you a deep enough in-depth knowledge to feel both protocols.
First of all let’s go over the story of link-state routing protocols in general. The whole idea behind a link state routing protocol is simply building the Link State Database on each router, and then each router uses Dijkstra Algorithm (Shortest Path First (SPF) calculation) to independently process the information in its link state database to build up a shortest path tree defining the best path to every destination (consider it as a map).

Link-state routing protocols leverage a hierarchical design methodology in contrast to a flat design (OSPF uses the Area logic, while IS-IS uses the Level logic), which helps the protocol to scale and better converge. In general a hierarchical design reduces resources consumption (memory and CPU), and organize the network topology in an essence that facilitates taking decisions and isolate network changes effect to a consolidated area/level rather than affecting the whole domain (the topology of an area/level is invisible from the outside of the area/level, you’ll feel this as we go), while also introducing points of aggregation (summarization). However in practice the use of areas/levels adds undesired complexity in some scenarios (most commonly when talking about a Service Provider IGP), and thus in such scenarios such a design methodology is unappealing. The bright side is that with the horse power of today’s routers, link-state routing protocols can be deployed in a flat design while having an acceptable level of scalability and convergence, again it is all about a good design.

NOTE In order not to be confused, in hierarchical IS-IS networks, IS-IS divides the routing domain into multiple sub-domains, and each sub-domain is called an area and is assigned an area address, however in IS-IS terminology routing within an area is referred to as Level-1 routing (intra-area routing), while routing between Level-1 areas is referred to as Level-2 routing (inter-area routing).

The scalability of a routing protocol in a flat design is a function of the physical topology design, links stability, number of IP subnets and the memory and CPU of the routers, what works for one network doesn’t work for another, and thus there will be no absolute figures. Another attribute that affects the routing protocol scalability is how the routing protocol itself distributes the routing information and stores it in the link-state database, and that’s why IS-IS is considered more scalable in a flat design. This has to do with how the protocol exchange routing information, IS-IS uses one LSP per router per level this LSP contains many TLVs each represents a piece of routing information (the IS-IS database entry is LSP – we’ll be covering this in depth later on), where in OSPF a router originates multiple LSAs one for each information type (the OSPF database entry is LSA – again we’ll cover this in depth later on). A nice statement that I like a lot; IS-IS is less chatty and can scale to support larger networks, remember this statement as we go.

To have a loop free topology all routers (in the same area/level) must have an identical Link State Database. Inside the same area/level once the link-state routing protocol speaking routers form adjacencies with each other, they start exchanging their link-state information, and the information is flooded allover the area/level/domain (according to the flooding scope) to again have the required identical link state database inside the same area/level such that each router can calculate it’s map for the network topology. The inter-area/level communication part is a bit protocol dependent in its details, but from a a very high level consider inter-area/level as tree leafs they have nothing to do with the tree structure (network topology), in other words consider the overall topology as interconnected trees, and each tree represents a separate consolidated overall topology part (area/level), while again the topology of each area/level is invisible from the outside of the area/level.

Fine, now let’s summarize and point out the whole process:

  1. Hellos are used to detect neighbors and form adjacencies (and ultimately maintain them).
  2. A summary of the link state database is first exchanged between the neighbors.
  3. Required information (most probably a more recent information) is requested and accordingly delivered.
  4. The previous step is repeated until the link state database is completely synchronized between both neighbors.
  5. Finally each router independently runs Dijkstra Algorithm on its link state database to draw its image of the network topology.
  6. Inter-area and external routing is accomplished according to the specific protocol implementation and network design.
  7. Whenever a network change occurs, routing information is flooded (according to it’s flooding scope), and the network converges accordingly (the required calculation and accordingly the convergence time depends upon the network design and the protocol implementation).

In the next post we’ll be covering the bibliography and history of both protocols before diving in details, until then please do enjoy digesting what we have covered so far.

I hope that I’ve been informative.

Leave a Reply

Your email address will not be published. Required fields are marked *