Routing – 3 subnets, 2 OSPF areas – Will This Work

ospfredundancyroute-summarizationroutingsubnet

Will any issues occur if I have a topology involving 3 subnets and two OSPF areas where one subnet is in AREA 0 and the other two subnets are both in AREA 1?

For example:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

Best Answer

Regarding the question of splitting area 1 across the backbone (area 0):

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

[area 1, subnet 1]---[Router #1]---[area 0, subnet 2, end device #1]---[Router #2]---[area 0, subnet 2, end device #2]---[Router #3]---[area 1, subnet 3]

Short answer: There is no problem with your proposal...

Long answer:

Even Peter's answer, which argues that reusing area numbers is bad design, offers no proof that this is a bad design; if you examine the hyperlinks he used, there is no explanation of undesirable consequences for this design. Furthermore, the argument that you might have problems connecting R1 and R3 falls short, since the R1 to R3 link could legitimately be configured in either Area 0 or Area 1, depending on what traffic you want to transit it. The difficulties he mentions are a false dilemma.

In RFC 2328, Section 3.7 OSPF explicitly allows you to use discontiguous non-backbone areas (which are called "area partitions", below):

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

Thus whether you use the proposed discontiguous Area 1 is just a matter of taste... some people find it illogical to use the configuration in your diagram; these people might suggest that you keep OSPF area numbers together... so you'd have to change [area 1, subnet 3] on Router #3 to [area 3, subnet 3]. Other people see no problem with reusing Area 1, since OSPF area numbers are only locally significant to the router originating OSPF hellos.

Either way, we should admit that OSPF is a remarkably flexible protocol; regardless of choosing one side or another in this debate.

OSPF Backbone

Why is area 0 the backbone area in OSPF? Why must all other areas connect to it?

This is explained very well in RFC 3509, Section 1.2¹:

1.2 Motivation

In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. 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.

OSPF is usually considered a link-state protocol. What some people miss is that OSPF uses both link-state protocol and distance-vector protocol algorithms.

Routes within the backbone, or a non-backbone area are computed as a link-state protocol does (ref Dijkstra's algorithm).
When OSPF must carry non-backbone routes through the backbone, it uses some distance-vector behavior (i.e. parts of the Bellman Ford algorithm) to propagate Type3 LSA metrics into non-backbone areas.

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 I mentioned above.

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.

¹_{RFC 3509 describes Cisco IOS's ABR behavior}

OSPF – Stub vs Totally Stub Areas

You can have multiple ABRs which connect an area to Area 0. With a stub area, a router in the area could choose the best ABR in the path to the destination, but with a totally stubby area, it will just choose the nearest ABR.

For instance, if you have two ABRs for your area (Area 1), each ABR will have, at least Area 0 and Area 1 interfaces, but one of them could also have an Area 2 interface, or it could be directly connected to an Area 2 ABR with a low cost, but the other ABR would have a higher cost to get to Area 2. It would make sense, when sending traffic to Area 2, to send it to the ABR with the lowest cost to Area 2, but a totally stubby area doesn't know how to do that.

Best Answer

Related Solutions

OSPF Routing – Why Must All Areas Connect to Area 0 Backbone?

OSPF Backbone

Connecting non-backbone OSPF areas at an ABR

OSPF – Stub vs Totally Stub Areas

Related Topic