OSPF: Difference between revisions

* Why do we use Backbone Area?

The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem.

OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes,

and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.

Simple example of OSPF's distance-vector behavior:

<-- Area 5 --><-- Area 0 --><-- Area 4 -->

R5-----------R1-----------R2------------R3---------------------R4

Cost 3 Cost 5 Cost 7 Cost 12

LSA--> LSA-->

Type3 LSA Type3 LSA

{From R1} {From R2}

R5 cost is 3 R5 cost is 8

Consider what happens to a /32 Loopback route for R5:

R5 sends a Type1 LSA containing the /32 Loopback

R1 (Area 5 ABR), is connected to Area 0; it translates the Type1 LSA into a Type3 LSA with a cost of 3.

R2 (Area 4 ABR) receives R1's Type3 LSA (metric 3) and changes the metric to R5's Loopback, based on R2's cost to R1.

Now R2's Type3 LSA for R5 has a cost of 8. This is the distance-vector behavior.

Requiring all non-backbone routes to go through the backbone is a loop-prevention mechanism.

Connecting non-backbone OSPF areas at an ABR:

If 2 areas aren't connected through area 0 (discontiguous), how does OSPF behaving as a link state protocol increase the possibility of routing loops?

As we saw above, OSPF uses distance-vector behavior to send routes through the Area 0 backbone.

Distance-vector protocols have well-known limits, such as the count-to-infinity problem.

OSPF would be vulnerable to the same issues, if we didn't have boundaries on its behavior.