Forwarding Adjacency with OSPF

Load mpls.te.base.config.with.ospf.cfg

#IOS-XE
config replace flash:mpls.te.base.config.with.ospf.cfg

#IOS-XR
configure
load bootflash:mpls.te.base.config.with.ospf.cfg
commit replace
y

Configure a bidirectional TE tunnel between CSR8 and XRv11. Announce this TE tunnel into the IGP so that R5 will only use this TE tunnel to get to R8. Configure the tunnels so that when the tunnel goes down, the router waits 5 seconds before removing the tunnel from the IGP.

Answer

#R8
int tun0
 tunnel dest 11.11.11.11
 tunnel mode mpls traffic-eng
 ip unn lo0
 tunnel mpls traffic-eng path-option 1 dynamic
 tunnel mpls traffic-eng forwarding-adjacency holdtime 5000
 ip ospf 1 area 0
 ip ospf cost 1

#XR11
int tunnel-te0
 dest 8.8.8.8
 ip unn lo0
 path-option 1 dynamic
 forwarding-adjacency holdtime 5000

Explanation

Using FA with OSPF has a few quirks on IOS-XE. First, if you configured the loopback interface for OSPF under the interface, you must activate OSPF on the tunnel explicitly. If you used the network command to activate OSPF on the loopback, then you don’t need to do this step.

#R8
int tun0
 ip ospf 1 area 0

Next, IOS-XE uses a very low bandwidth on the TE tunnel by default. This is the “physical line” bandwidth, not the RSVP signaled/requested BW for the LSP. This causes the OSPF metric to be extremely high. So you should set the OSPF metric manually.

#R8
int tun0
 ip ospf cost 1

IOS-XR doesn’t appear to have either of these problems. The TE tunnel’s bandwidth is 0, and the router uses an OSPF metric of 1 by default.

The holdtime parameter is specified in msec. When the TE tunnel goes down, the router will wait for the holdtime interval before removing the link from the LSA or LSP. This allows the TE tunnel to briefly flap during path re-convergence without affecting the IGP.

Verification

We should see the TE tunnel between R8-XR11 advertised as a link into the IGP. OSPF is not literally running over this link, so there is not actually an R8-XR11 adjacency that is maintained via OSPF Hellos. Instead, this allows routers in the area to use this link in their SPF calculations.

On R5, notice that R8 and XR11 report an adjacency with cost 1 between each other. To SPF on R5, this appears as just a regular link connecting them directly.

R5 uses the TE tunnel as the primary path to R8 now, because the total cost is only 3 (1 to XR11, 1 for the TE tunnel, and 1 for the loopback of R8).

If the TE tunnel goes down, the routers will wait 5 seconds before removing their adjacency in the Router LSA. We can simulate this by running an extended ping on R5 to 8.8.8.8, and breaking MPLS TE on the R1, R6, and R9 links facing R8.

#R5
ping 8.8.8.8 repeat 100000000

#R1
int GigabitEthernet2.518
 no mpls traffic-eng tunnels

#R6
int GigabitEthernet2.568
 no mpls traffic-eng tunnels

#R9
int GigabitEthernet2.589
 no mpls traffic-eng tunnels

From this test, I see that R8 properly waits 5 seconds to remove the link to XR11, but XR11 removes the link immediately. Perhaps the holdtime functionality is not implemented in the XRv.