Virtual-Links and Tunnels

In my opinion, there are certain network topics we need to understand and be able to configure them without any trouble. Virtual-links are likely to be tested in the CCIE Lab because it helps to solve a problem which is a big thing in OSPF – ALL AREAS HAVE TO BE DIRECTLY CONNECTED TO THE BACKBONE AREA 0. Virtual-links are meant to be configured for a scenario where you have some area not connected to the backbone. It is important to mention that this is a bad design. You dont want to have ospf areas all over the place, virtual-links everywhere and confusion. The goal of a netwok is to keep it simple and functional.

To be honest, the point of this article is not so much the virtual-links because you probably have heard about it 100000 times but the interface tunnels. I would like to mention as well that I am more focus in in a small explanation and configuration than giving you a full boring description of the technology itself. You cal always get that sort of information in Cisco website.

As usual, we have a topology where I have already configured all the ip addresses and ospf.

The problem we run into is the routing table in R4. Because area 2 is not directly connected to the backbone, R4 is not receving any ospf routes installed.
R4#sh ip route ospf

R4#

Once again, in the real world this would be a bad design, but if you have run into it during a lab or exam you need to configure a virtual-link between R2 and R3 through area 1 as such:

R2#sh run | s ospf
router ospf 1
router-id 2.2.2.2
area 1 virtual-link 3.3.3.3
network 10.10.0.2 0.0.0.0 area 0
network 10.10.1.2 0.0.0.0 area 1

R3#sh run | s ospf
router ospf 1
router-id 3.3.3.3
area 1 virtual-link 2.2.2.2
network 10.10.1.3 0.0.0.0 area 1
network 10.10.2.3 0.0.0.0 area 2

Now if we look again to the routing table of R4 we have received the ospf routes as expected. And when I say expected I have to mention something that Brian Dennis has said in a video that always stayed in my head which is something like this – At CCIE level you should be able to look into your topologies and be able to know how your routing tables should look like.
Strong advice.

R4#sh ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O IA 10.10.0.0 [110/21] via 10.10.2.3, 00:01:04, FastEthernet0/0
O IA 10.10.1.0 [110/11] via 10.10.2.3, 00:01:29, FastEthernet0/0

So far so good. Another scenario would be if they would tell to configure area 1 as stub area, totally stubby area, NSSA and so on…
First, I will remove the virtual-links, configure the area as a stub and try to apply the virtual-link command once again, and let’s see what happens

R2(config)#router ospf 1
R2(config-router)#area 1 stub
R2(config-router)#no area 1 virtual-link 3.3.3.3
% OSPF: Area 1 is a stub or nssa so virtual links are not allowed

Yes, virtual links are not allowed in stub or nssa areas. In order to solve this problem, instead of virtual-links we have to use GRE tunnels. Take a look in the configuration bellow.

R2#sh run int tu 0
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source Ethernet0/1
tunnel destination 10.10.1.3

R2#sh run | s ospf
router ospf 1
area 1 stub
network 10.10.0.2 0.0.0.0 area 0
network 10.10.1.2 0.0.0.0 area 1
network 172.16.1.2 0.0.0.0 area 0

R3#sh run int tu 0
interface Tunnel0
ip address 172.16.1.3 255.255.255.0
tunnel source Ethernet0/1
tunnel destination 10.10.1.2

R3#sh run | s ospf
router ospf 1
area 1 stub
network 10.10.1.3 0.0.0.0 area 1
network 10.10.2.3 0.0.0.0 area 2
network 172.16.1.3 0.0.0.0 area 0

It is actually very simple if you follow some simple steps. Create a tunnel interface, give it an ip address (or use ip unnumbered of a netwrok that is being advertised to area 0) and advertise it under ospf to AREA 0, then just apply the tunnel source and destination commands and you are good to go.

And once again, the routing table on R4

R4#sh ip route ospf
172.16.0.0/24 is subnetted, 1 subnets
O IA 172.16.1.0 [110/11112] via 10.10.2.3, 00:03:14, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
O IA 10.10.0.0 [110/11122] via 10.10.2.3, 00:03:04, FastEthernet0/0
O IA 10.10.1.0 [110/11] via 10.10.2.3, 00:03:14, FastEthernet0/0

We have received all the ospf routes.

Authentication:
As a final note, if you get asked to authenticate area 0 either with md5 or clear-text, you need to authenticate the virtual-links or the interface tunnels if it is the case. Remember that R3 now believes it is directly connected to the backbone so it needs to be authenticated in order to receive all the routes.

If you have the possibility of trying this article in GNS3 or real equipment is a plus. Sometimes, we think we know just because we read about it but when it comes to configure it ourselves ups…besides it is good to try all different scenarios that work or not, at least we will know.

OSPF Basics

The OSPF network command is used to activate OSPF on the specified interfaces. Specifying an interface with the command will include the interface into the OSPF routing process. On broadcast and point-to-point network types, the router will automatically start the neighbor discovery process by sending hello packets to the AllSPFRouters multicast address (224.0.0.5) after an interface has been integrated into the OSPF process.

If there’s another OSPF router on that link and their Hello packets match, they will try to form an adjacency but that’s another story.

The OSPF network command uses the following syntax:

network ip-address wildcard-mask area area-id

The usage of the ip address and the wildcard mask allows us to specify one or multiple interfaces with one statement and assign them to the specified OSPF area. The Cisco IOS software sequentially evaluates the ip-address wildcard-mask pair for each interface as follows:

1. The wildcard-mask argument is logically ORed with the interface IP address.
2. The wildcard-mask argument is logically ORed with the ip-address argument in the network command.
3. The software compares the two resulting values. If they match, OSPF is enabled on the associated interface and this interface is attached to the OSPF area specified.

When enabling OSPF on interfaces you got three different options to do so:

1. The definition of only one interface
Definitions of only one interface are done with a wildcard-mask of 0.0.0.0 and the exact IP address of the given interface. This will match exact on that interface and nothing else.

2. The definition of mutiple but not all interfaces into one area
If you have to specify multiple interfaces and the IP concept has been done nicely, you might be able to summarize them all into one network statement. So if we have an address range like 116.1.16.0/21 which belongs to area N we can use network 116.1.16.0 0.0.7.255 area N to define them in one network statement. Every new interface on that router with an IP in that range will automatically be added into the OSPF process and added to that area.

3. The definition of all interfaces into one area
If you want to specify all interfaces on the router, the network statement network 0.0.0.0 255.255.255 area N will do the trick. Every new interface with an IP address on the router will automatically join OSPF and this area.

In older IOS versions the order in which the OSPF network statements have been configured if the area definitions have been overlapping. Nowadays Cisco IOS still doesnt allow an interface to be in more then one area:

Any individual interface can only be attached to a single area. If the address ranges specified for different areas overlap, the software will adopt the first area in the network command list and ignore the subsequent overlapping portions. In general, we recommend that you configure address ranges that do not overlap in order to avoid inadvertent conflicts.

but its not a problem any more in what order the statements got configured. The Cisco IOS will automatically reorder the network statements and places the most specific statements at the top and the least specific at the bottom. The following example will show this behavior:

view plaincopy to clipboardprint

1. R6(config)#do sh ip int brief | e una
2. Interface                  IP-Address      OK? Method Status                Protocol
3. FastEthernet0/0 116.1.100.6 YES manual up                    up
4. FastEthernet0/1 116.1.99.6 YES manual up                    up
5. Loopback0 99.99.6.6 YES manual up                    up
7. R6(config)#router ospf 1
8. R6(config-router)#network 0.0.0.0 0.0.0.0 area 20
9. R6(config-router)#network 116.1.0.0 0.0.255.255 area 10
10. R6(config-router)#network 116.1.99.6 0.0.0.0 area 0
12. R6#sh run | sec router ospf
13. router ospf 1
14. log-adjacency-changes
15. network 116.1.99.6 0.0.0.0 area 0
16. network 116.1.0.0 0.0.255.255 area 10
17. network 0.0.0.0 255.255.255.255 area 20
19. R6#sh ip ospf int | i is up|Area
20. FastEthernet0/1 is up, line protocol is up
21. Internet Address 116.1.99.6/24, Area 0
22. FastEthernet0/0 is up, line protocol is up
23. Internet Address 116.1.100.6/24, Area 10
24. Loopback0 is up, line protocol is up
25. Internet Address 99.99.6.6/24, Area 20

R6(config)#do sh ip int brief | e una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            116.1.100.6     YES manual up                    up
FastEthernet0/1            116.1.99.6      YES manual up                    up
Loopback0                  99.99.6.6       YES manual up                    up

R6(config)#router ospf 1
R6(config-router)#network 0.0.0.0 0.0.0.0 area 20
R6(config-router)#network 116.1.0.0 0.0.255.255 area 10
R6(config-router)#network 116.1.99.6 0.0.0.0 area 0

R6#sh run | sec router ospf
router ospf 1
log-adjacency-changes
network 116.1.99.6 0.0.0.0 area 0
network 116.1.0.0 0.0.255.255 area 10
network 0.0.0.0 255.255.255.255 area 20

R6#sh ip ospf int | i is up|Area
FastEthernet0/1 is up, line protocol is up
Internet Address 116.1.99.6/24, Area 0
FastEthernet0/0 is up, line protocol is up
Internet Address 116.1.100.6/24, Area 10
Loopback0 is up, line protocol is up
Internet Address 99.99.6.6/24, Area 20

So based on the above note from Cisco and the shown behavior it is possible to create overlapping network statements without the need to think about the network statement order, but also as Cisco says it should be avoided if possible.