RFC 3509 (rfc3509) - Page 2 of 12
Alternative Implementations of OSPF Area Border Routers
Alternative Format: Original Text Document
RFC 3509 OSPF ABR Behavior April 2003 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. The last restriction leads to a problem when an ABR has no backbone connection (in OSPF, an ABR does not need to be attached to the backbone). Consider a sample OSPF domain depicted in the Figure 1. . . . Area 0 . +--+ +--+ ..|R1|.. ..|R2|.. . +--+ .. +--+ . . .. . . +--+ . . Area1 |R3| Area2 . . +--+ +--+ . . .. |R4| . . . . +--+ . ....... ....... Figure 1. ABR dropping transit traffic In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone connections, while R3 doesn't. Following the section 12.4.1 of [Ref1], R3 will identify itself as an ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [Ref1]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2. Consequently, according to section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only summary-LSAs covering destinations in the directly attached areas, i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the summary-LSAs for Area 2. Zinin, et al. Informational
