OSPF Virtual Links and IP Unnumbered Interfaces

OSPF virtual-links are a well-know subject to many CCIE candidates. One aspect of them seems to be troubling many students I talked to. That aspect is using OSPF virtual links in conjunction with “ip unnumbered” links. Let’s see what all the fuss is about.

Please note: This article is in a way an answer and the detailed explanation of the problem presented in the Interactive Troubleshooting Blog: OSPF Routing article posted on April 30, 2012.

I don’t like empty talks and promises, you all know that much by now. So, we’ll explore this topic with a heavy hands-on approach, similar to the one I use in my CCIE bootcamps when students ask me these questions.

I’ll be using the network shown on the diagram. Please take note that no other interfaces are configured on any of the routers. Particularly pay attention to the absence of any Loopback interfaces. In itself, this is not important for virtual links in any way, but when go over the OSPF routing tables, it will be important not to expect to see them there!

Here are the relevant configurations on all the routers.

R2:

interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
 ip ospf 1 area 0
!
interface Serial0/2/0
 ip unnumbered GigabitEthernet0/1
 ip ospf 1 area 254
!
router ospf 1
 router-id 0.0.0.2
!

R5:

interface Serial0/0/0
 ip address 192.168.45.5 255.255.255.0
 ip ospf 1 area 254
!
interface Serial0/2/0
 ip unnumbered Serial0/0/0
 ip ospf 1 area 254
!
router ospf 1
 router-id 0.0.0.5
!

R4:

interface FastEthernet0/1
 ip address 192.168.46.4 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface Serial0/1/0
 ip address 192.168.45.4 255.255.255.0
 ip ospf 1 area 254
!
router ospf 1
 router-id 0.0.0.4
!

R6:

interface FastEthernet0/1
 ip address 192.168.46.6 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
router ospf 1
 router-id 0.0.0.6
!

With the network set-up like this, we should be able to spot the problem immediately. We have a split area 0 (backbone). While having any other area split is not in itself a problem, a split backbone is a problem. Before we rush to fix it, let’s see the problem.

The Need for Virtual Link

Here are the OSPF routes in the routing tables on all the routers.

R2:

R2#show ip route ospf
O IA 192.168.46.0/24 [110/129] via 192.168.45.5, 00:22:20, Serial0/2/0
O    192.168.45.0/24 [110/128] via 192.168.45.5, 00:22:39, Serial0/2/0

Routing table on R2 appears to be in order. We see all the routes we should be seeing.

R5:

R5#show ip route ospf
O IA 192.168.46.0/24 [110/65] via 192.168.45.4, 00:23:02, Serial0/0/0
O IA 192.168.2.0/24 [110/65] via 192.168.2.2, 00:23:21, Serial0/2/0

Situation on R5 is just about the same as it is on R2. We see OSPF route advertised by R2 and we see the OSPF route advertised by R4.

R4:

R4#show ip route ospf

R6:

R6#show ip route ospf
O IA 192.168.45.0/24 [110/65] via 192.168.46.4, 00:36:57, FastEthernet0/1

Situation on R4 and R6 is dramatically different. Neither one of these two routers have the route for R2′s 192.168.2.0/24 network. The reason for that is the loop prevention mechanism in OSPF that prevents inter-area (Type 3) LSAs from being used by ABRs and advertised back into the backbone area when they have been received from a neighbor in non-backbone areas.

If you’re scratching your head and asking yourself how comes then that R2 has the route for 192.168.46.0/24 in its routing table, I’ve done an excellent job in creating this scenario. Allow me to clarify this a little bit. In this case R2 claims to be the ABR, which we can see if we examine the OSPF database.

R5:

R5#show ip ospf database router 0.0.0.2

            OSPF Router with ID (0.0.0.5) (Process ID 1)

		Router Link States (Area 254)

  Routing Bit Set on this LSA
  LS age: 557
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 0.0.0.2
  Advertising Router: 0.0.0.2
  LS Seq Number: 80000003
  Checksum: 0xD010
  Length: 36
  Area Border Router
  Number of Links: 1
[...]

However, R2 doesn’t have any valid adjacencies in area 0 and in order to preserve the connectivity with the rest of the network, it will accept Type 3 LSAs from non-backone area. In other words, the loop prevention rule I described earlier is relaxed.

On R4, we don’t have the “luxury” of not being connected to the rest of the network. R4 has a valid adjacency in area 0 with R6, hence it does not accept any Type 3 LSAs from non-backbone areas to be passed into the backbone and its own routing table. Again, this is something we can prove by looking into the database on R4.

R4:

R4#show ip ospf database

            OSPF Router with ID (0.0.0.4) (Process ID 1)

		Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
0.0.0.4         0.0.0.4         1749        0x80000003 0x006B73 2
0.0.0.6         0.0.0.6         1739        0x80000002 0x00528A 2

		Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.45.0    0.0.0.4         1749        0x80000002 0x004F12

		Router Link States (Area 254)

Link ID         ADV Router      Age         Seq#       Checksum Link count
0.0.0.2         0.0.0.2         1784        0x80000003 0x00D010 1
0.0.0.4         0.0.0.4         1749        0x80000002 0x001D47 2
0.0.0.5         0.0.0.5         1732        0x80000003 0x009D6A 3

		Summary Net Link States (Area 254)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.2.0     0.0.0.2         1784        0x80000002 0x00BD10
192.168.46.0    0.0.0.4         1750        0x80000002 0x00CBD3

The only Type 3 LSA we see in the database for area 0 is the summary LSA for 192.168.45.0/24 network. In the database for the area 254 we can see the information for 192.168.2.0/24 network, but this will never make it to the routing table, nor the the database for area 0. If it’s not in the database on R4, it won’t be there on R6.

This is the kind of a problem designed to be solved using OSPF virtual links. Let’s give it a spin.

The Problem

In our configuration, R2 and R4 are apparent area border routers. What we need to do is interconnect the split backbone area between them. It’s perfectly logical to start building a virtual link between these two nodes. Let’s start on R2′s side.

R2:

router ospf 1
 area 254 virtual-link 0.0.0.4
!

Important point to note here is that virtual links are built between OSPF Router-IDs and not between IP addresses. So, with this configuration in place, are any OSPF packets reaching R4? If we just take a look at the log output on R4 the answer should be obvious.

R4:

 %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID,
   from backbone area must be virtual-link but not found from 192.168.2.2, Serial0/1/0

Excellent, the packets are making it to R4. Take a second look at that error message. What was the source IP address of the incoming packet?

The source address of the incoming virtual link packet was 192.168.2.2, which is the same address we’re using for “ip unnumbered” configuration for Serial0/2/0 link on R2. Given that the serial interface is the only interface in area 245 on R2 this is to be expected. This situation is a cause of concern though. Even though our virtual link configuration has not been finished yet, we can sense the problem at this stage. I will explain in a moment, but you spend a minute thinking about it. In the meantime, let’s see how R2 perceives the newly configured virtual link.

R2:

R2#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 0.0.0.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 254, via interface Serial0/2/0, Cost of using 128
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06

We can see that R2 thinks the link is perfectly fine i.e., it shows as “ip”. When configuring and troubleshooting OSPF virtual links, this can be very deceiving. What we’re after is a full adjacency between neighbors. At this stage, this is impossible, since we have not configured anything on R4. Let’s do that.

R4:

router ospf 1
 area 254 virtual-link 0.0.0.2
!

The moment we configure this, the error message that kept repeating on R4 will stop. Let’s see the status on the virtual link on R4 then.

R4:

R4#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 0.0.0.2 is down
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 254, Cost of using 65535
  Transmit Delay is 1 sec, State DOWN,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

This is not so good; R4 perceives the virtual link as down. Why would that be, when it can clearly receive traffic from R2? Can it send the traffic back though?

R4:

R4#show ip route 192.168.2.2
% Network not in table

Here’s our problem; R4 can receive the traffic from R2, since R2 is able to resolve to which IP to send the virtual link packets. However, R4 is unable to do the same thing, which is something that is clearly identified as a possible situation in the RFC 2328, section 15:

        Just as the virtual link's cost and viability are determined by
        the routing table build process (through construction of the
        routing table entry for the other endpoint), so are the IP
        interface address for the virtual interface and the virtual
        neighbor's IP address.  These are used when sending OSPF
        protocol packets over the virtual link. Note that when one (or
        both) of the virtual link endpoints connect to the Transit area
        via an unnumbered point-to-point link, it may be impossible to
        calculate either the virtual interface's IP address and/or the
        virtual neighbor's IP address, thereby causing the virtual link
        to fail.

So, how do we solve the problem at hand then?

Solution

First, we have to understand that we’re dealing with a serious problem of R4 not having the routes required to talk to R4. R2 and R4 are ABRs, but is there anything preventing us from making R5 an ABR? We shouldn’t change any interface area memberships, but we could build a virtual-link between R4 and R5. That will extend the area 0 all the way to R5 from R4. At the same time, I will remove the old virtual link configurations from R2 and R4, since they clearly do nothing.

R2:

router ospf 1
 no area 254 virtual-link 0.0.0.4
!

R4:

router ospf 1
 no area 254 virtual-link 0.0.0.2
 area 254 virtual-link 0.0.0.5
!

R5:

router ospf 1
 area 254 virtual-link 0.0.0.4
!

At this stage, we have a virtual link up on R5 and we should be able to extend the area 0 to R2. Let’s take a look.

R5:

R5#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
0.0.0.4           0   FULL/  -           -        192.168.45.4    OSPF_VL0
0.0.0.4           0   FULL/  -        00:00:34    192.168.45.4    Serial0/0/0
0.0.0.2           0   FULL/  -        00:00:35    192.168.2.2     Serial0/2/0

We can see that the virtual link is up and running, but…

R5:

R5#show ip route ospf
O    192.168.46.0/24 [110/65] via 192.168.45.4, 00:03:15, Serial0/0/0

We have just extended the problem from R4 to R5! See how now R5 no longer has a route to R2′s 192.168.2.0/24 network. If I tried to build the virtual link between R2 and R5, I would fail miserably for the same exact reasons as before. What can I do? For starters, I can get rid of all the virtual links.

R4:

router ospf 1
 no area 254 virtual-link 0.0.0.5
!

R5:

router ospf 1
 no area 254 virtual-link 0.0.0.4
!

Next, I need to examine my topology and realize that R5 is the key to our solution. If I can make area 0 extend to R5 from both sides, I’d be good. How can I do that without compromising the routing?

Extending area 0 from R4 to R5 seems to be straight-forward, as we’ve proven just now. If I do that however, R5 will lose the route to 192.168.2.0/24, making it impossible for R5 to connect to R2 using virtual link. Do I really need that route at all? All I really need is an IP address for R2 – any IP address. Is there a technology that can inject a host route?

R2:

interface Serial0/2/0
 encapsulation ppp
!

R5:

interface Serial0/2/0
 encapsulation ppp
!

Of course there is – PPP. By default, when using PPP encapsulation on the link, we’ll install a /32 route to our neighbor.

R5:

R5#show ip route connected
C    192.168.45.0/24 is directly connected, Serial0/0/0
     192.168.2.0/32 is subnetted, 1 subnets
C       192.168.2.2 is directly connected, Serial0/2/0

So, that problem is now fixed. Let’s try building a virtual-link between R2 and R5. I will start from R5.

R5:

router ospf 1
 area 254 virtual-link 0.0.0.2
!

R5#show ip ospf virtual-links
Virtual Link OSPF_VL3 to router 0.0.0.2 is down
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 254, Cost of using 65535
  Transmit Delay is 1 sec, State DOWN,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

The virtual link is still down. Why now, when we have the route to R2? As it turns out, Cisco’s implementation of the virtual links code requires the route to the remote side not only to be available, but it needs to be intra-area route in the transit area. At this point, I have to confess that this could hidden somewhere in one of the OSPF RFCs, but I couldn’t find a reference. It makes perfect sense, though.

Does this mean we’re hopelessly stuck and unable to solve the problem? Of course not, since we always have the ultimate duct tape of networking available – GRE tunnels!

R2:

interface Tunnel0
 tunnel mode gre ip
 ip unnumbered GigabitEthernet0/1
 tunnel source Serial0/2/0
 tunnel destination 192.168.45.5
 ip ospf 1 area 0
!

R5:

interface Tunnel0
 tunnel mode gre ip
 ip unnumbered Serial0/0/0
 tunnel source Serial0/2/0
 tunnel destination 192.168.2.2
 ip ospf 1 area 0
!
router ospf 1
 no area 254 virtual-link 0.0.0.2
!

With this in place, we now have OSPF area 0 on R5.

R5:

R5#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Tu0          1     0               Unnumbered Se0/0/0 1000  P2P   1/1
Se0/2/0      1     254             Unnumbered Se0/0/0 64    P2P   1/1
Se0/0/0      1     254             192.168.45.5/24    64    P2P   1/1

Now, we can use virtual links to connect R5 to R4.

R4:

router ospf 1
 area 254 virtual-link 0.0.0.5
!

R5:

router ospf 1
 area 254 virtual-link 0.0.0.4
!

Let’s verify.

R2:

R2#show ip route ospf
O    192.168.46.0/24 [110/129] via 192.168.45.5, 00:00:00, Serial0/2/0
     192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks
O       192.168.45.0/24 [110/128] via 192.168.45.5, 00:14:10, Serial0/2/0

R2#ping 192.168.46.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.46.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

R5:

R5#show ip route ospf
O    192.168.46.0/24 [110/65] via 192.168.45.4, 00:00:10, Serial0/0/0
     192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
O       192.168.2.0/24 [110/65] via 192.168.2.2, 00:00:10, Serial0/2/0

R4:

R4#show ip route ospf
O    192.168.2.0/24 [110/129] via 192.168.45.5, 00:00:05, Serial0/1/0

R6:

R6#show ip route ospf
O IA 192.168.45.0/24 [110/65] via 192.168.46.4, 2d02h, FastEthernet0/1
O    192.168.2.0/24 [110/1066] via 192.168.46.4, 00:00:00, FastEthernet0/1

R6#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Perfect, everything seems to be working fine.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

OSPF Virtual Links and IP Unnumbered Interfaces, 4.5 out of 5 based on 8 ratings

Tags: CCIE, OSPF, OSPF Backbone, Troubleshooting