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