Interarea Routing is Distance-Vector

In this article I make the argument that interarea routing in both ISIS and OSPF is just distance-vector. It is not link-state. Should we call ISIS and OSPF hybrid link-state/distance-vector protocols? Well you could, but people might look at you funny.

ISIS and OSPF both use pure link-state for intra-area routing. Both protocols build a map of all routers in the area, with all routers’ links and their associated cost. Normally every router runs SPF from their own point of view, but because the LSDB is syncronized among all routers in an area, any router can actually run the SPF algorithm from any other routers point of view in the same area. This technique is used with TI-LFA.

Storing and syncing the LSDB suffers from a scale problem. The more routers you add to an area, the larger the LSDB becomes, the longer it takes to run SPF, and the harder it is to sync the LSDB. Modern devices can easily run hundreds of routers in the same ISIS or OSPF area these days, but 20 years ago, this was a real concern.

ISIS and OSPF offer a solution to this scalability problem, and the answer is multi-area. Each area only syncs the LSDB within the area itself. The map/topology of the area is not shared outside the area. Instead routers which border on the areas use distance-vectory mechanisms to signal reachability to prefixes in other areas.

BGP is the ultimate scalable routing protcol, and while path vector, instead of distance vector, serves as a comparison. In BGP, each router only reports its best route to a given prefix to its neighbor. BGP offers mechanisms to filter which routes and sent and received. Instead of associating a cost (distance) with the prefix, BGP associates a path (AS path) with the prefix. One reason you can’t use distance vector in BGP is because different ASs might use metrics differently. One AS may use metrics to represent physical distance, one may use it to represent latency, etc.

However, within the AS you can assume that the cost represents the same “thing.” So ISIS and OSPF can use distance vector, because one area should assume that cost in that area is comparable to cost in another area.

By using distance vector for inter-area routing, scalability is addressed. Each border router only advertises its best cost to a prefix, not the total of all possible costs. The border routers do not advertise the state of the links in that area, as that would defeat the purpose of running inter-area in the first place - scalability.

In my opinion, this is almost a separate routing protocol altogether. Intra-area and inter-area can be considered totally separate protocols. Inter-area takes advantage of the LSDB flooding mechanism in order to desseminate information, rather than using a new control mechanism. However, they are still completely different methods of determining reachability. In fact, in both ISIS and OSPF, intra-area routes are always preferred over inter-area routes, even if an inter-area route has a lower cost. Think of this as two separate protocols which have different ADs. EIGRP routes are always better than RIP routes, for example.

Inter-area offers the ability to filter routes, which is impossible in a pure link-state protocol. In intra-area routing, you cannot filter routes from a set of routers in that area. This breaks the entire principal of link-state routing, which is to have a single syncronized database among all routers in the area.

With inter-area routing, you are now longer running link-state, so the rule does not apply. Now you can do things like summarize prefixes and filter prefixes altogether. Isn’t this just like BGP?

By default ISIS actually filters inter-area routes. L2 routes are not propagated (leaked) into L1 areas. Instead, a flag indicating that a route is attached to the L2 is included on L1 LSPs. This allows L1 routes to build a 0/0 route to the L1/L2 router(s). Inter-area prefixes are completely hidden from L1 areas by default. This is comparable to a totally NSSA area in OSPF, because L1 routers can inject external prefixes into ISIS.

In both OSPF and ISIS, each ABR advertises its best cost to a prefix in a non-backbone area to the backbone. ABRs for other non-backbone areas then advertise their own best cost to these prefixes into the other non-backbone areas.

ISIS is a bit more simple in its approach to advertising inter-area prefixes than OSPF is. With OSPF, you have the Type 3 Network LSA which advertises an inter-area route and is originated by the ABR which is attached to the source area.

With ISIS, there are no new TLVs for inter-area prefixes. They are simply considered as reachability information - a prefix and cost attached to a router. In this way, an L1 router does not have a way of knowing whether a prefix attached to an L1/L2 router came from L2 or not. For example, the L1/L2 router’s loopback address and loopback addresses of other L2 routers are advertised into L1 (when route leaking is configured) with the same TLV.

This introduces a problem when there are two L1/L2 routers in an L1 area. How does one L1/L2 router know not to re-advertise a L2-learned prefix that was leaked into L1 back into L2? The answer is that an L1/L2 router sets the down bit on a prefix when it is leaked from L2 into L1. This is the only way a router knows that the prefix is inter-area as opposed to intra-area.

Both ISIS and OSPF use a two-layer hierarchical design for inter-area. In ISIS L1 areas cannot communicate directly to each other. They can only communicate through the L2. Similarly in OSPF, non-backbone areas cannot communicate directly. They must communicate through the backbone area (0).

In ISIS this is enforced by preventing two L1-only routers from forming an adjacency. Two routers in different areas can only form an L2 adjacency.

In OSPF this is enforced by a different mechanism, since interfaces belong to areas. (In ISIS, the entire router belongs to an area). In OSPF, type 3 LSAs are only created for non-backbone area prefixes when they are being injected into the backbone, or being injected from the backbone into a non-backbone area. Non-backbone area prefixes are not injected into other non-backbone area prefixes.

In both cases, this creates the hierarchy in which inter-area routing always traverses the backbone (L2 or area 0).