One-Hop Auto-Tunnels
Load flash:mpls.te.onehop.init.cfg
Currently the network is fully operational with LDP enabled everywhere. However, the operator is concerned about outages due to link failures in the paths between CSR8 and XRv11. This includes routers R8, R9, R10, R6, XR12, and XR11.
Using MPLS-TE auto-tunnels, enable onehop tunnels and fast-reroute on these nodes. This will allow the operator to dynamically use MPLS-TE’s FRR capabilities without having to deploy a complex full mesh of TE tunnels. It also saves the operator from having to upgrade their equipment to run SR.
Answer
Explanation
Onehop primary auto-tunnels are a useful feature for implementing MPLS-TE FRR functionality without actually using a mesh of TE tunnels for traffic steering. MPLS-TE is simply used for its FRR capability.
The idea is that each router automatically forms a onehop tunnel with each directly connected neighbor. Every tunnel will simply have an outgoing label of imp-null. However, the power of this is that you can now protect this tunnel using auto-tunnel backup. The routers will only create NHOP tunnels (there is no NNHOP with a onehop tunnel), so only link-protection is achieved.
You might be thinking - what is the difference between this and just doing basic IP FRR using LFA? I believe the big difference is that you can achieve 100% link protection, because an explicit path can be signaled even if the underlying IGP backup path is not loop-free.
Let’s examine this on CSR8. It has four tunnels for which it is a headend: two that are primary onehop tunnels, and two that are backup NHOP tunnels.
Let’s examine the tunnels to CSR6. The first, primary onehop tunnel, simply has an explicit-path which includes the outgoing link to CSR6.
We can see the derived-config of this onehop auto-tunnel. Notice that FRR is enabeld, no bandwidth is reserved, and autoroute is enabled. As far as I know, this can not be changed. If you wanted to change this, I believe you would have to use the auto-tunnel mesh feature and manually specify your nexthops as your directly connected neighbors in an ACL.
The backup tunnel that protects this onehop tunnel is shown below:
Because this is a onehop tunnel, the router knows not to try to attempt to form a node-protecting backup tunnel.
Let’s now get into the configuration. On IOS-XE this is very straightforward. We enable the feature with a single command. We also must enable tLDP sessions so that LDP labels can be learned over these tunnels and pushed onto the stack when forwarding over these tunnels.
Additional features that can be configured are very similar to backup auto-tunnels, such as the unnumbered interface, timers, and tunnel range.
Remember to also enable MPLS-TE for the IGP and all interfaces. A TED needs to be built in order for the onehop tunnels to come up. But RSVP bandwidth does not need to be allocated for these onehop tunnels, so you do not need to explicitly enable RSVP on each interface. (RSVP is enabled by default by the mpls traffic-eng tunnels command under the interface. ip rsvp bandwidth is only needed to define the available bandwidth. Without this, a value of zero bandwidth is advertised into the IGP.)
Configuration on IOS-XR is much more complex. First, the onehop feature is hidden within the auto-mesh configuration. You also must specify the tunnel range, unlike IOS-XE. Additionally, we must specify options using an attribute-set. IOS-XE automatically enables autoroute and fast-reroute on the onehop tunnels, but this is not the case on IOS-XR. Finally, you must also remember to set the unnumbered interface globally!
Additionally, there is no way to dynamically enable LDP on the onehop auto-tunnels on IOS-XR. You can manually specify each dynamically created interface under LDP, although this isn’t an ideal solution. But it works.
Finally, enabling backup auto-tunnels is the same as usual. You must specify the range manually and then activate the backup auto-tunnel per-interface.
Verification
Let’s examine CSR9. We have four backup tunnels that are ready to protect four primary onehop auto-tunnels. There is one auto-tunnel for each directly connected neighbor: CSR8, CSR6, CSR10, and XR12.
Note that the order in which you apply the config might affect this. I activated the auto-tunnel features before activating MPLS-TE globally. This resulted in some backup-tunnels not working correctly. However, if you remove and re-add the feature, you should be able to get the output above.
Let’s enable RSVP Hellos between CSR9 and CSR10 and test failover.
We must also force traffic to take this path. To do this, we can lower the IGP cost of the CSR9-CSR10 link to 1.
Now we can initiate an extended ping and watch for lost packets.
We see only one packet is lost. The backup tunnel on CSR10 will remain active indefinitely, however, the IGP will update routing on CSR10 to avoid this link now. So this backup tunnel is only used while the IGP is in the process of reconverging. The primary onehop tunnel uses an explicit-path that includes the link, so the onehop tunnel will fail to come back up until the link is restored. By default, the onehop primary auto-tunnel is never deleted. You can use the timer keyword to set how often the router checks for tunnels which can be deleted.
Last updated
