How OSPF capability transit can prevent virtual-link routing loops

By | December 30, 2021

We will understand the use of capability transit command. By default this enabled. So I will disable it and will check. So we can understand the issues which can create due to it as well understand more how OSPF works.

I will focus on R2’s path to R4’s loopback of 4.4.4.4. Each router’s interface IP address ends with the router number. So we can understand easily where traffic is flowing. Below is the topology:

How OSPF capability transit can prevent virtual-link routing loops

Now, I have disabled capability transit on all routers using below command, but I found that in this lab R2 is where the action is, so that might be only place we need to do it:

router ospf 1
  no capability transit

R1 has a virtual link to R3 in order to connect area 234 to area 0. This works fine. R3 has become an ABR and R2 will use R3 to get R4’s loopback:

R2#sho ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "ospf 1", distance 110, metric 66, type inter area
Last update from 192.168.23.3 on Serial1/0, 00:00:07 ago
Routing Descriptor Blocks:
* 192.168.23.3, from 3.3.3.3, 00:00:07 ago, via Serial1/0
  Route metric is 66, traffic share count is 1

Now let’s say R2 needs to add a network to area 2 as follows

R2(config)#int lo 0
R2(config-if)#ip address 2.2.2.2 255.255.255.255
R2(config-if)#ip ospf 1 area 2

Since, R2 does not have an interface in area 0. So we can build a virtual-link to R1:

R2(config)#router ospf 1                    
R2(config-router)#area 123 virtual-link 1.1.1.1 

R1(config)#router ospf 1              
R1(config-router)#area 123 virtual-link 2.2.2.2
*Mar  1 00:59:19.191: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on
OSPF_VL3 from LOADING to FULL, Loading Done

Lets take a look at that route towards R4 again:

R2#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 194, type inter area
  Last update from 192.168.12.1 on Serial1/1, 00:00:04 ago
  Routing Descriptor Blocks:
  * 192.168.12.1, from 3.3.3.3, 00:00:04 ago, via Serial1/1
      Route metric is 194, traffic share count is 1

Definitely, a loop has been occurred. lets check by trace command:

R2#trace 4.4.4.4      

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 192.168.12.1 72 msec 24 msec 8 msec
  2 192.168.12.2 56 msec 20 msec 84 msec
  3  *  *  *
  4  *  *  *

Yes, we have a loop. ok no problem, we will fix it on R2:

R2(config)#router ospf 1
R2(config-router)#capability transit

R2#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R2#

Lets check now:

R2#sho ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 66, type inter area
  Last update from 192.168.23.3 on Serial1/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 192.168.23.3, from 3.3.3.3, 00:00:18 ago, via Serial1/0
      Route metric is 66, traffic share count is 1

Now, loop has been prevented.

“The OSPF Area Transit Capability feature provides an OSPF Area Border Router (ABR) with the ability to discover shorter paths through the transit area for forwarding traffic that would normally need to travel through the virtual-link path.”

From Cisco

OSPF Area Transit Capability 

So in this case, we have allowed R2 to use it direct path to R3 instead of it’s own path through the backbone area. We have basically made area 123 a transit area that can carry traffic to destinations not in it’s own area. We are flowing from Area 0 (R2 is an ABR now) to Area 123 to Area 234.

Since this command is enabled by default on recent IOS versions.

Thanks for reading blog ……….

Recommended links:

Leave a Reply

Your email address will not be published.