Overview

If an OSPF Normal Area isn’t physically connected to the OSPF Backbone Area, a Virtual Link tunnel can be used to logically connect them together.

All areas must be logically connected to the backbone area. (If an area is physically connected to the backbone area, it is also logically connected.)

One Normal Area, and only one Normal Area, that is not physically connected to the backbone area can be logically connected with a Virtual Link tunnel.

There are scenarios, such as company mergers / acquisitions where we may want to join two separate OSPF domains. Such cases may require a big project to implement a re-design to properly join the two networks into a single OSPF domain. The delay could be a significant setback for business goals.

To satisfy business goals until a proper re-design and implementation can be done, a Virtual Link tunnel can be used as a temporary solution. This technology can cause a problem in the future if an administrator isn’t aware of, and familiar with, the deployment of this “work-around” solution.

​How it Works

A virtual link tunnel joins a dis-contiguous normal area to the backbone area by tunneling OSPFv3 update information (i.e. LSAs) so that routers can share OSPFv3 routing information. Virtual link tunnels do not carry data.

A virtual link can’t join a stub area because the area must be able to carry all types of OSPF updates.

The normal area that the virtual link tunnels across is called a Transit Area. Since the virtual link tunnel carries routing information and not data traffic, OSPFv3 updates and OSPF data traffic can take different routes to destinations. A mess could be made of things if in the future if an administer isn’t aware of, and familiar with, the deployment of the virtual link tunnel. This is a reason why virtual link is meant to be a temporary solution.

Pro Tip: There are some cases where an administrator may want to consider using a GRE tunnel instead of a Virtual Link tunnel. More information about this can be found here: Cisco: OSPF Virtual Link.

In this lesson, we’ll do two labs.

  1. A single area that is not physically connected to the backbone area will be connected logically with a virtual link tunnel.
  2. Combine two physically separated backbone areas into one logical backbone area.

​Configuration and Verification

All devices have already been configured with OSPFv3 on their interfaces. Only the virtual link tunnel needs to be configured. (If you'd like to learn how to configure basic OSPFv3 see the Basic OSPFv3 Configuration and Verification lesson.

Lab 1

In this lab, our company has acquired a small branch office.

The network isn’t ready to have the HQ’s OSPF Backbone Area directly connected to the branch office’s OSPF Area 34, but the company is demanding connectivity right away…

OSPFv3 Area Not Connected to Backbone
OSPFv3 Area Not Connected to Backbone

Since HQ’s Area 0 isn’t directly connected to the Branch’s Area 34, Area 34 can’t send/receive OSPF updates such as LSAs from the other areas...it can’t share routes with other OSPF routers.

As a temporary solution, we’ll create a virtual link tunnel going through the Normal Transit Area of Area 23 (From R-2 to R-3). This will logically connect Area 0 to Area 34.

OSPFv3 Virtual Link Tunnel
OSPFv3 Virtual Link Tunnel

Note: While Area 23 in this lab is part of the HQ location, Area 23 could also be a WAN technology.

Step 1 - Verify Current State of OSPFv3 Domain

It’s always a good idea to check the state of a devices before making changes to the configuration. Let's begin by verifying the current state of the OSPFv3 domain:

R-1

Let's see what routes R-1 has learned via OSPFv3:

R-1#sh ipv6 route ospf 
IPv6 Routing Table - default - 8 entries 
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route 
      B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP 
      H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea 
      IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO 
      ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect 
      RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 
      OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 
      la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid 
      lA - LISP away, a - Application 
O   2001:2::2/128 [110/1] 
    via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0 
OI  2001:3::3/128 [110/2] 
    via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0 
OI  2001:23::/64 [110/2] 
    via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0

  • R-1 has learned about R-2’s Loopback 26 as an Intra-Area (O) route. This is because R-2’s Lo 26 was configured in Area 0. (Intra means within the same area.)
  • R-3’s loopback (2001:3::3) and Area 23's subnet (2001:23::/64) were learned as Inter-Area (OI) routes.
  • R-1, as expected, hasn’t received any routes for area 34. Area 34 can’t share OSPFv3 updates because it isn’t connected to Area 0.

Pro Tip: Take time to review the list of Codes in the above output. Be familiar with the codes that you may see in your networking environment(s).

It should be obvious that a ping to R-3's loopback (2001:3::3) would succeed:

R-1#ping 2001:3::3 source 2001:1::1 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds: 
Packet sent with a source address of 2001:1::1 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

While a ping from R-1 to R-4 would fail:

R-1#ping 2001:4::4 source 2001:1::1 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 2001:4::4, timeout is 2 seconds: 
Packet sent with a source address of 2001:1::1 
..... 
Success rate is 0 percent (0/5) 

R-4

Seeing how Area 34 isn't connected to a Backbone Area, I predict that:

  • R-4 will have no OSPFv3 routes, even though it has R-3 as an OSPFv3 neighbor
  • R-4 will only have OSPFv3 Link State Database (LSDB) entries for itself and its directly connected neighbor (R-3's Type-1 Router LSA and Type-8 Link LSA).

R-4#show ipv6 route ospf 
(Code output omitted)
R-4#

R-4#sh ipv6 ospf neighbor 

            OSPFv3 Router with ID (4.4.4.4) (Process ID 6)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/BDR        00:00:32    3               GigabitEthernet0/0

R-4#show ipv6 ospf database 

            OSPFv3 Router with ID (4.4.4.4) (Process ID 6)

                Router Link States (Area 34)

ADV Router       Age         Seq#        Fragment ID  Link count  Bits
 3.3.3.3         476         0x80000002  0            1           None
 4.4.4.4         475         0x80000002  0            1           None

                Net Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Rtr count
 4.4.4.4         475         0x80000001  2          2

                Link (Type-8) Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Interface
 3.3.3.3         511         0x80000002  3          Gi0/0
 4.4.4.4         510         0x80000002  2          Gi0/0

                Intra Area Prefix Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Ref-lstype  Ref-LSID
 4.4.4.4         475         0x80000003  0          0x2001      0
 4.4.4.4         475         0x80000001  2048       0x2002      2

While understanding the concept of an OSPFv3 Virtual Link Tunnel is detailed, the configuration is easy.

OSPFv3 Virtual Link Tunnel
OSPFv3 Virtual Link Tunnel

We need to logically connect Area 0 to Area 34.

We'll do this by creating a Virtual Link tunnel from R-2 to R-3 through the Transit Area of Area 23.

R-2

Simply enter the OSPFv3 router process configuration mode and issue a command that specifies the Transit Area's ID and the OSPFv3 Router ID of the connecting router:

R-2#conf t
R-2(config)#ipv6 router ospf 6
R-2(config-rtr)#area 23 virtual-link 3.3.3.3
R-2(config-rtr)#end

Finished.

R-3

When we look at R-3's CLI after issuing the virtual link commands on R-2, we see some expected error message:

*Aug  3 10:07:28.966: %OSPFv3-4-ERRRCV: OSPFv3-6-IPv6 Received invalid packet: Received packet with global address. Must be virtual-link, but not found from 2001:23::2, GigabitEthernet0/0

R-3 is complaining that it's receiving Virtual Link packets. It hasn't been configured to do anything with them...yet:

R-3#conf t
R-3(config)#ipv6 router ospf 6
R-3(config-rtr)#area 23 virtual-link 2.2.2.2
R-3(config-rtr)#end
*Aug  3 10:10:38.264: %SYS-5-CONFIG_I: Configured from console by console
*Aug  3 10:10:38.266: %OSPFv3-5-ADJCHG: Process 6, Nbr 2.2.2.2 on OSPFv3_VL0 from LOADING to FULL, Loading Done

We see that we have an adjacency change with R-2 for Virtual Tunnel 0.

We can further verify the creation of the new Virtual Link tunnel interface (VL0):

R-3#sh ipv6 ospf int br
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
VL0          6     0               10         1     P2P   1/1
Lo36         6     23              9          1     LOOP  0/0
Gi0/0        6     23              2          1     DR    1/1
Gi0/1        6     34              3          1     BDR   1/1

Step 3: Final Verification

Let's begin by using the same verification commands used in Step 1 to verify the state of the OSPFv3 domain before adding the virtual link:

R-1#show ipv6 route ospf 
(Outpu abbreviated)
O   2001:2::2/128 [110/1]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0
OI  2001:3::3/128 [110/2]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0
OI  2001:4::4/128 [110/3]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0
OI  2001:23::/64 [110/2]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0
OI  2001:23::2/128 [110/1]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0
OI  2001:34::/64 [110/3]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0

This is great. Our output includes routes learned from Area 34.

Again, pinging R-3's loopback (2001:3::3) should succeed:

R-1#ping 2001:3::3 source 2001:1::1 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

The important test is to see if a ping from R-1 to R-4 can succeed now that the Virtual Link tunnel has been implemented:

R-1#ping 2001:4::4 source 2001:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4::4, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

We now can ping from R-1's loopback to R-4's loopback. Success!

R-4

When we ran the show ipv6 route ospf command before the virtual link tunnel configuration there wereno learned routes. After implementating the Virtual Link:

R-4#show ipv6 route ospf
(Abbreviated output)
OI  2001:1::1/128 [110/3]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0
OI  2001:2::2/128 [110/2]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0
OI  2001:3::3/128 [110/1]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0
OI  2001:12::/64 [110/3]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0
OI  2001:23::/64 [110/2]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0
OI  2001:23::2/128 [110/2]
     via FE80::EC2:A0FF:FE44:3201, GigabitEthernet0/0

R-4 has learned routes throughout the OSPFv3 domain!

What about OSPFv3 neighbors?

R-4#sh ipv6 ospf neighbor

            OSPFv3 Router with ID (4.4.4.4) (Process ID 6)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/BDR        00:00:34    3               GigabitEthernet0/0

No change here. The virtual link doesn't cause new neighbors to be created.

An important verification is, of course, the OSPFv3 LSDB:

R-4#show ipv6 ospf database

            OSPFv3 Router with ID (4.4.4.4) (Process ID 6)

                Router Link States (Area 34)

ADV Router       Age         Seq#        Fragment ID  Link count  Bits
 3.3.3.3         1106        0x80000005  0            1           B
 4.4.4.4         325         0x80000005  0            1           None

                Net Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Rtr count
 4.4.4.4         325         0x80000004  2          2

                Inter Area Prefix Link States (Area 34)

ADV Router       Age         Seq#        Prefix
 3.3.3.3         1106        0x80000002  2001:3::3/128
 3.3.3.3         1106        0x80000002  2001:23::2/128
 3.3.3.3         1106        0x80000002  2001:23::/64
 3.3.3.3         1106        0x80000004  2001:1::1/128
 3.3.3.3         1106        0x80000002  2001:2::2/128
 3.3.3.3         1106        0x80000002  2001:12::/64
          
                Link (Type-8) Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Interface
 3.3.3.3         345         0x80000005  3          Gi0/0
 4.4.4.4         325         0x80000005  2          Gi0/0

                Intra Area Prefix Link States (Area 34)

ADV Router       Age         Seq#        Link ID    Ref-lstype  Ref-LSID
 4.4.4.4         325         0x80000006  0          0x2001      0
 4.4.4.4         325         0x80000004  2048       0x2002      2

Notice here than all of the LSAs are the same, except the Inter-Area LSAs. Understanding this is important!

Now that we have configured and fully verified the Virtual Link tunnel, we should write the new running-configuration to the startup-configuration file!!!

R-1#wr
R-2#wr
R-3#wr
R-4#wr

Lab 2

Headquarters needs to extend its OSPFv3 domain to a new medium sized branch office. The branch office is already running OSPFv3 that has its own Backbone Area (Area 0).

A proper re-design is needed, but will take months to implement. Our task is to implement a temporary solution so that the business goals can be met.

For this solution, a deeper understanding of the OSPFv3 Virtual Link tunnel is needed.

Many say that there is a rule that says that an OSPF domain may only have one virtual link. This is not really the way it works.

Many say that there is a rule that says that an OSPF domain may only have one virtual link. This is not really the way it works.

Lab 1, above, used only one virtual link. However, multiple links can be used to make the virtual link tunnel.

To be clear:

An OSPFv3 domain may only have one Virtual Link tunnel.

The Virtual Link tunnel may have multiple virtual links.

Let's take a look at this lab's topology:

Virtual Link with Two Backbones
Virtual Link with Two Backbones

This OSPFv3 domain has two issues that need to be resolved:

  1. There are two dis-contiguous Area 0s. An OSPFv3 domain may only have one Area 0.
  2. Area 23 isn’t directly connected to either Area 0.

To solve both of these issues, we’ll add multiple virtual links to create a virtual link tunnel from one Area 0, across the OSPFv3 domain, to the other Area 0.

  1. This will logically join the two Area 0s.
  2. It will also logically connect Area 23 to the new logical Area 0.

The desired result is to have end-to-end connectivity (from R-1's Lo14 to R-4's Lo46).

Step 1 - Verify Current State of OSPFv3 Domain

Let's begin by examining the OSPFv3 routes in the routing table on each router.

R-1

R-1#show ipv6 route ospf 
O   2001:2::2/128 [110/1]
     via FE80::EC2:A0FF:FE8A:F700, GigabitEthernet0/0

R-1 has only learned of R-2's loopback (2001:2::2/128) as an Intra-Area (O) route. This is because R-1's Gi0/0 interface and R-2's loopback are both in Area 12:

R-1#sh ipv6 ospf int br
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Lo16         6     0               9          1     LOOP  0/0
Gi0/0        6     12              2          1     BDR   1/1

R-2#sh ipv6 ospf int br
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Lo26         6     12              9          1     LOOP  0/0
Gi0/0        6     12              2          1     DR    1/1
Gi0/1        6     23              3          1     BDR   1/1

Inter-Area routes don't need to go through a Backbone Area because they are in the same area.

Since R-1 doesn't have a route to R-4's Lo46 (the output from show IPv6 route would also have no route), of course a ping would fail:

R-1#ping 2001:4::4 source 2001:1::1
Sending 5, 100-byte ICMP Echos to 2001:4::4, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
.....
Success rate is 0 percent (0/5)

We can compare this failed ping attempt to the successful ping attempt after implementing the Virtual Link tunnel.

R-2

R-2#show ipv6 route ospf 
OI  2001:1::1/128 [110/1]
     via FE80::EC2:A0FF:FEF7:6300, GigabitEthernet0/0
O   2001:3::3/128 [110/1]
     via FE80::EC2:A0FF:FE44:3200, GigabitEthernet0/1

R-2 has learned of R-1 loopback (2001:1::1) as an Inter-Area route.

It also has learned of R-3's loopback. R2 can learned of R-3's loopback without a Backbone Area because it is an Intra-Area route. Intra-Area routes don't need to travel through a backbone because they are in the same area:

R-2#sh ipv6 ospf int br
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Lo26         6     12              9          1     LOOP  0/0
Gi0/0        6     12              2          1     DR    1/1
Gi0/1        6     23              3          1     BDR   1/1

Gi0/1 is in Area 23...

R-3#sh ipv6 ospf int br
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Lo36         6     23              9          1     LOOP  0/0
Gi0/0        6     23              2          1     DR    1/1
Gi0/1        6     34              3          1     BDR   1/1

...and Lo36 is also in Area 23.

R-3

R-3#sh ipv route ospf
OI  2001:4::4/128 [110/1]
     via FE80::EC2:A0FF:FE00:2E00, GigabitEthernet0/1

R-3 only learns R-4's lo from OSPFv3. There are no Intra-Area routes to learn from R-3 and no other areas are connected to this Backbone Area.

R-4

R-4#sh ipv rou ospf
R-4#

R-4 has learned no routes from OSPFv3.

We could test with pings and traceroutes. We could verify with more verifications commands. But we have a lot of information already to confirm that we have a lack of OSPFv3 learned routes due to the two dis-contiguous backbone areas and area 34 not being connected to any backbone area.

Let's move forward with implementing a Virtual Link tunnel.

The commands to configure an OSPFv3 Virtual Link tunnel are the same as Lab 1 above. In this lab, however, every router in the OSPFv3 domain needs to be virtual linked together.

The devices are smart enough to combine the two dis-contiguous Backbone Areas into one logical area and to logically connect Area 34 to the new logical Backbone Area.

To continue reading, please login or become a member for full access...