OSPF Virtual Links in the Real World

Posted in Networking by shaw38 on May 13, 2009

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.


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

  1. 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.
  2. 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 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.

There are a couple ways to address this situation:

  • Build a virtual link to the other ABR. :
  • ABR1#conf t
    Enter configuration commands, one per line. End with CNTL/Z.
    ABR1(config)#router ospf 100
    ABR1(config-router)#area 18 virtual-link
    ABR2#conf t
    ABR2(config)#router ospf 100
    ABR2(config-router)#area 18 virtual-link
    *Mar 1 01:33:56.075: %OSPF-5-ADJCHG: Process 100, Nbr on OSPF_VL2 from LOADING to FULL, Loading Done
    *Mar 1 01:33:58.403: %OSPF-5-ADJCHG: Process 100, Nbr on OSPF_VL3 from LOADING to FULL, Loading Done
    ABR2#show ip ospf interface
    OSPF_VL3 is up, line protocol is up
    Internet Address, Area 0
    Process ID 100, Router ID, Network Type VIRTUAL_LINK, Cost: 2

    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.


2 Responses

Subscribe to comments with RSS.

  1. Nick said, on October 12, 2010 at 11:59 am

    I have tried to emulate the problem you had but when I down the connection between the ABR and the backbone (connection is via a switch so interface stays up but adjacency is lost) the ABR installs the LSA type 3’s it learnt from another ABR in the same nonbackbone area. Am I missing something or did Cisco change this behaviour at some point? ABR shows Backbone area 0 as inactive and it always states it is an ABR in the show ip ospf output.

    Any help/pointers would be gratefully appreciated as I am trying to learn more about OSPF 🙂


    • shaw38 said, on October 19, 2010 at 9:33 am

      Hey Nick,

      You’re not going insane. This issue appears depending on the platform/code train from what I have seen. The issue I wrote about was experienced on a 6500 running a 12.2(18)SXF flavor, if I remember correctly but I have also seen it occur on a 7200 plugged into a piece of transport gear (i.e. ATM switch (LS1010)). In both cases, the OSPF area 0 adjacency goes down, but the interface in area 0 will stay up. However, if you if you fire up dynamips with a 3725 running 12.4(15)T, you will not see this issue. It appears YMMV.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: