JNCIP-SP: the virtual link.
In this article I will be establishing connectivity between area 150 and the rest of the network.
In the picture above, you can see that area 50 is located between the backbone area and area 150. To OSPF, this is a problem. Normally, all areas must be directly connected to the backbone area. In this article I will explain that by means of a virtual-link we will be able to connect area 150 to the backbone area. To achieve this, we will need to configure the virtual link to transit area 50 between R4 and R11;
A thing to note is that the transit area, in our case area 50, cannot be a stub area. Let’s start with the configuration of the virtual link:R11:
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 18.104.22.168 transit-area 0.0.0.50R4:
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 22.214.171.124 transit-area 0.0.0.50
The configuration above is really all there is to the configuration of a basic virtual link. To verify if the configuration task was a success, you can check the following;
In the picture above, we can see that a neighbor-relationship has formed across interface vl-126.96.36.199.
The other things we can see in the printout is that the virtual-link is transiting area 50 and the routers are exchanging the default timers across the link.
Let’s move on and configure some authentication for the virtual-link. Also, let’s speed up the interval in which the routers can detect the virtual-link is down:R11:
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 188.8.131.52 transit-area 0.0.0.50 hello-interval 1 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 184.108.40.206 transit-area 0.0.0.50 dead-interval 3 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 220.127.116.11 transit-area 0.0.0.50 authentication md5 14 key "$9$OM2sRhyMWXxNVgokmfz/9"R4:
set protocols ospf area 0.0.0.0 virtual-link neighbor-id 18.104.22.168 transit-area 0.0.0.50 hello-interval 1 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 22.214.171.124 transit-area 0.0.0.50 dead-interval 3 set protocols ospf area 0.0.0.0 virtual-link neighbor-id 126.96.36.199 transit-area 0.0.0.50 authentication md5 14 key "$9$QY6zn/AB1EhSl8XY4aUkq"
To verify this, we use the same command again;
When we proceed to log in to R3, we can see that the configuration of the virtual-link has enabled connectivity from R3 towards the rest of the network.
By using the commands displayed above, we can see two things. The first command shows us that the database in area 0.0.0.150 is filled with routes generated by R4. From the R3 point-of-view, R4 is the area 0.0.0.0 ABR that is generating the summary-LSAs etc. The second command verifies that R3 has IP connectivity with router R15 (see previous posts), which is located at the other end of the network.
Another thing is that the routers exchange hello packets across the virtual link from neighbor relationship purposes, same as on other ‘normal’ OSPF interfaces. However, these Hellos will not be multicast packets send to 188.8.131.52. Instead, they will have a unicast destination:
Pretty trivial thing unless there is a firewall in between. This firewall needs to have IP protocol 89 enabled between the IP addresses of the outgoing interfaces of the two routers engaged in the virtual-link.
As an alternative to using a virtual-link, you might consider using a GRE Tunnel. By using a GRE tunnel, you can go through a Stub area. The drawbacks of using GRE are that the data is encapsulated inside GRE packets. This is contrary to only having the routing updates tunneled when using a virtual-link.
Another note is that the virtual link can also serve another purpose. Examine the picture below;
The picutre above demonstrates how you could implement the virtual link to repair a discontiguous backbone area. Not as a design decision of course, but as a temporary fix to some issue, like having to merge two OSPF networks together.
I would like to close with a random FYI. Initially, I started the topic by configuring a virtual-link from R15 (in area 1). This router was advertising several router-LSAs into area 1 that are summarized by R12 into area 0. As soon as I configured the virtual-link from R15 to R12, the summarization was not working anymore. This was due to the fact that all three routes were turned into area 0 router-LSAs. If there is a lot of summarization going on in a network, it might be worth your while to check if the creation of a virtual link might have any adverse effect on this. In this lab, it was only about 3 router-LSAs. Could be you have a router redistributing hundreds of static routes. Enabling a virtual link could suddenly flood all that into you’re backbone area.