OSPF Transit Capability

In OSPF the router is considered to be an ABR only if it has at less one link in the backbone area (area 0) and other link in non-backbone area, but what if we have situation where the router have two links where they are both in different non-backbone areas ?!

In this case this router must have link in area 0 and to achieve this virtual link was introduced which is an ip unnumbered interface that is always in area 0, this virtual link is established between an ABR and this router.

Now the interesting part come which is OSPF transit capability which is the main purpose of this post and to explain this feature take a look at the picture and try to find which router is ABR and which one is not :-


This is very simple to find out by just applying the rule above :-

R1 is ABR
R2 is not
R3 is not

Now I know it’s a BAD design but the designers of OSPF people smarter than you and me think of all possible possibilities and how to deal with each one.

Back to the picture, to make R2 and R3 an ABR we need to established virtual link between :-

R1 <-----> R2
R1 <-----> R3

This solution make area 123 a transit area which is have this OSPF transit capability feature, now what is this capability feature, let find what cisco say about it :-

“The OSPF Area Transit Capability feature is enabled by default. RFC 2328 defines OSPF area transit capability as the ability of the area to carry data traffic that neither originates nor terminates in the area itself. This capability enables the OSPF ABR to discover shorter paths through the transit area and forward traffic along those paths rather than using the virtual link or path, which are not as optimal”

This sentence is very very vague and this post is about to explain it in very fashion way, I know the only think you understand is that it is enabled by default :stuck_out_tongue_winking_eye::stuck_out_tongue_winking_eye:

Now the only way to examine this is to trace the traffic from area 2 to area 3 one time when this feature is enabled and other one when it’s disabled :-

1- when it’s enable the traffic will go direct from R2 to R3.

2- when it’s disabled the traffic will go from R2 to R1 via virtual link then from R1 to R3 via virtual link but since the path from R1 to R3 is via R2 the actual traffic will go to R2, now R2 check the destination and find it’s reachable via virtual link to R1 so it will send it back to R1, “ladies and gentlemen we have a loop”.

Now this ring the bell in your head and at this moment I believe that you are clearly understand what cisco mean in there sentence above.

To find out this by yourself you can download the EVE-LAB from this link :-

Note :-
If you test this feature issue this command “no capability transit” under router OSPF configuration of R2 or R3 to disable OSPF transit capability.

Hussein Sameer

Hello Hussein

Your detailed description of this topology is excellent and thank you so much for sharing it with us. I have the following question. You state that:

When R1 sends traffic to R3 via the virtual link, the path does indeed go via R2. However, my understanding is that R2 will not examine this traffic and resend it via its own virtual link. This is because the virtual link created between R1 and R3 involves tunnelled packets with a source tunnel interface on R1 and a destination tunnel interface on R3. R2 will not “look inside” the tunnelled packets but they will only be looked at once they exit the tunnel at R3.

Just an additional idea to bounce off of you. Let us know what you think!


1 Like

You are welcome @lagapides

Keep in mind that virtual link is ip unnumbered link and it does not create tunnel but rather it established between RIDs and it’s used to expand the backbone area database, but in case you are using GRE tunnel then R2 will not examine the traffic for sure.

One thing I’d like to mention is that virtual link does not come up only if you have at less one stub network in both routers that exist in the database of transit area.

To explain what I mean take a look at this picture :-

In OSPF area 0 must exist and also must be contiguous so in the picture above area 0 exist but it is not contiguous so in this case we must create virtual link between R2 and R4 but in this lab the virtual link not coming up because I make the interface se1/0 of R4 ip unnumbered interface loopback 34 and advertise interface loopback 34 of R4 in area 0 that make R4 not having any stub network in area 234 so to solve this problem you have to create virtual link between R2-R3 then create GRE tunnel between R3-R4 that expand area 0 database from R2 to R3 then R4 and finally make area 0 contiguous.

This lab is about having connectivity between Loopback 1 of R1 and Loopback 5 of R5 and the problem above is the first problem but there is another problem that did not make this connectivity happen if you like to find it you can download the EVE-LAB that I uploaded form this link :-


Hussein Sameer
Best Regards

Hello Hussien

Once again, thank you for your thoroughness and sharing this with the forum.

Concerning your comment:

Take a look at the following Cisco documentation:

According to Cisco,

After the routers know how to reach each other through the transit area, they try to form adjacency across the virtual link. The OSPF packets between the two ends of the virtual link are not multicast packets. They are tunneled packets from source to the destination, because they are tunneled to the other end of the virtual link.

In any case your examples are excellent and it shows a great desire to dig deep into the workings of OSPF in all its configuration possibilities.

Thanks once again and keep doing what you’re doing!


1 Like

Hello @lagapides

I feel good when I share what I know and feel further good when I see activity about what I sharing.

Now back to OSPF :wink:
Once again, it’s very defficult to understand cisco doc because they are very vague, and what they are mean in the doc that you mention is that hello packet that belong to area 0 is send unicast over transit area, they indeed said tunnel but they do not mean the actual traffic even the hello packet need to be encapsulated but as I said they mean the hello that belong to area 0 are tunneled over transit area, and believe me I see them in wireshark and they are send unicast without any encapsulation, but if you are wondering what are the source and destination address of these unicast hello packet !? think about my previous comment when I said there must be at less one stub network in the routers that established the virtual link that belong to the transit area because these hello packet are sourced from lowest cost stub network in local router and send to the lowest cost stub network in remote router

When I say stub network I do not mean router LSA but it also can be router that connect to shared segment so to be more clearly I mean there must be at less one IP address that is reachable in this transit area so it can be used in these unicast hello packet of virtual link.

Also I’d like to mention is that virtual link is DC (Demand Circuit) and in OSPF when the link is DC that mean the hello packet and re flooding of LSA every 30 minute are suppressed and this is the reason of seeing the DNA bit in LSA that across the virtual link also the dead time never updated which mean the hello packet is suppressed after virtual link established.

Sham link also by default consider to be DC and you can configure only PTP and PTMP network type to be DC by issue “ip ospf demand-circuit”.

This is just a brief of how DC work but there is a lot of things that related to it so I will make another demonstration for it :wink:.

Finally I’d like to tell that I do not post or say any things before I test it in a LAB and make sure 100% what is the exact behavior of each command or feature especially in these advanced and involved features.

Hussein Sameer

Hello Hussien

As always, its great conversing with you! Once again, thanks for the thoroughness. This is definitely something to look over, understand and go in depth with! Thanks for the opportunity to go more in depth into such topics. Keep it up!


1 Like

Thank you for your wonderful words @lagapides and you are welcome at any time.

1 Like