I never thought I would come across the opportunity to use an OSPF virtual link in a production environment, but sure enough, yesterday was the day. The Maryland area had dual links from a 6500 running VSS into our OSPF backbone. Because of a fiber cut, both adjacencies into area 0 were lost (interfaces stayed up). This 6500 also had interfaces in area 18 as redundancy. In theory, the area 0 links would be lost, the 6500 would no longer be an ABR and traffic would re-route back through area 18 to the other ABR.

False.

Why? The 6500 still believed it was an ABR and the loop prevention rules of OSPF ABRs kicked in:

A type-3 LSA learned via a non-backbone area will not be forwarded back into the backbone area. This is similar to split-horizon with Distance Vector routing protocols.

ABRs will ignore LSAs advertised by other ABRs when calculating least cost paths. An ABR must not select a path through a non-backbone area to reach the backbone area.

Rule #2 applies to this particular situation. Summary LSAs from area 0 were in the OSPF database of the 6500. However, the LSAs were not being considered for SPF calculation because they were learned via a non-backbone area.

A couple reasons why this failed:

The interfaces in area 0 on the 6500 stayed up, though, the neighbor adjacencies were lost so the 6500 still considered itself as an ABR. This caused area 0 to become partitioned relative to this ABR. In certain IOS releases (I believe) if the adjacency is lost the interface will be marked as “down” from an OSPF standpoint. Here’s an example from 12.4 mainline code: *Mar 1 00:55:28.407: %OSPF-5-ADJCHG: Process 100, Nbr 10.4.4.2 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired
!
R4#sh int fast 1/0
FastEthernet1/0 is up, line protocol is up
!
R4#sh ip ospf Area BACKBONE(0) (Inactive)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:00:17.356 ago
SPF algorithm executed 5 times
Area ranges are
Number of LSA 14. Checksum Sum 0x085E01
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 9
Flood list length 0

While digging around during the outage, the 6500 chassis had two port-channel interfaces in area 0 pointing back into the location. I have no idea why. So even if the IOS version running behaved as decribed above, because of these port-channels, the 6500 would have still considered itself an ABR and not considered the summary LSAs learned via area 18 for SPF calculation.

Now what this will do is defeat the loop prevention rules mentioned above, specifically #2. As you can see, the virtual link between the ABRs is essentially the same as having a link in area 0. This will then allow each ABR to learn LSAs via area 0 and consider them for SPF calculation. This is a nice alternative to a tunnel because traffic is natively routed. If you look at the routing table, an intra-area router will be the next-hop for a route learned via the opposing ABR. There is a caveat in that virtual links cannot be used if the underlying transit area is a stub. Why? Intra-area stub routers lack full OSPF databases which means it lacks forwarding information which means there is a possibility of loops. As mentioned before regarding virtual links, traffic is not tunneled but natively routed so the intra-area routers must have complete forwarding information if they are to be used as a next-hop router for an ABR. This is similar to the iBGP full-mesh requirement.