Categories R&S

OSPF – Implement and troubleshoot path preference – Non backbone transit areas

Theory:

From the Cisco website:

« 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. »

 

Requirements:

Make sure traffic from R11 to R4 loopback transit following the virtual-link between R10 and R3.

 

Diagram:

OSPF - Non backbone transit areas

 

Configuration and verification:

We currently have a virtual-link configured between R10 and R3, allowing the router in OSPF area 100 to receive OSPF routes:

R10#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 33.33.33.33 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 3, via interface Ethernet0/0
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           20        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

 

We would think that the traffic from R11 to R4 loopback will follow the virtual link:

R11#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.101.1 1 msec 0 msec 1 msec
  2 10.10.3.8 1 msec 1 msec 0 msec
  3 10.10.18.1 1 msec 4 msec 2 msec
  4 10.10.14.2 2 msec 1 msec *

But as you can see in the traceroute, it goes to R10 and then R8. This is due to the OSPF Area Transit Capability feature  enabled by default.

 

On R10, the route to R4’s loopback is preferred via R8 :

R10#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 10", distance 110, metric 13, type inter area
  Last update from 10.10.3.8 on Ethernet0/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 10.10.3.8, from 22.22.22.22, 00:00:26 ago, via Ethernet0/0
      Route metric is 13, traffic share count is 1

 

If we want to make sure that the traffic doesn’t go via R8, we need to disable the transit capability on R10:

R10(config)#router ospf 10
R10(config-router)#no capability transit

 

On R10, the preferred route to R4’s loopback is now seen via R9:

R10#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 10", distance 110, metric 23, type inter area
  Last update from 10.10.3.9 on Ethernet0/0, 00:00:10 ago
  Routing Descriptor Blocks:
  * 10.10.3.9, from 22.22.22.22, 00:00:10 ago, via Ethernet0/0
      Route metric is 23, traffic share count is 1

 

Traceroute from R11, shows the traffic is following the path through the virtual link:

R11#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.101.1 1 msec 0 msec 0 msec
  2 10.10.3.9 0 msec 1 msec 1 msec
  3 10.10.39.1 0 msec 1 msec 0 msec
  4 10.10.1.2 1 msec 1 msec 1 msec
  5 10.10.24.2 1 msec 2 msec *

 

This area transit capability gave me some trouble, but it might be useful to influence the path during the CCIE rsv5 exam.

But there is for sure a good reason why it is on by default with Cisco and I guess that’s because it routes the traffic in a more optimum way.

Virtual links are here for OSPF to form an adjacency and not to be followed like a tunnel.

 

There is some very good explanation about it in this blog post from INE:

http://blog.ine.com/2009/09/14/understanding-ospf-transit-capability/

 

 

Thank you for reading.

 

OSPF – Implement and troubleshoot path preference – Non backbone transit areas