One-Hop Auto-Tunnels

Load flash:mpls.te.onehop.init.cfg

#IOS-XE
config replace flash:mpls.te.onehop.init.cfg

#IOS-XR
configure
load bootflash:mpls.te.onehop.init.cfg
commit replace
y

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

#CSR6, CSR8, CSR9, CSR10
mpls traffic-eng tunnels
!
mpls traffic-eng auto-tunnel primary onehop
mpls traffic-eng auto-tunnel primary config mpls ip
mpls traffic-eng auto-tunnel backup
!
router isis 132
 mpls traffic-eng router-id lo0
 mpls traffic-eng level-2

#CSR6
int GigabitEthernet2.568
 mpls traffic-eng tunnels
int GigabitEthernet2.569
 mpls traffic-eng tunnels
int GigabitEthernet2.562
 mpls traffic-eng tunnels
int GigabitEthernet2.560
 mpls traffic-eng tunnels

#CSR8
int GigabitEthernet2.568
 mpls traffic-eng tunnels
int GigabitEthernet2.589
 mpls traffic-eng tunnels

#CSR9
int GigabitEthernet2.589
 mpls traffic-eng tunnels
int GigabitEthernet2.569
 mpls traffic-eng tunnels
int GigabitEthernet2.590
 mpls traffic-eng tunnels
int GigabitEthernet2.592
 mpls traffic-eng tunnels

#CSR10
int GigabitEthernet2.560
 mpls traffic-eng tunnels
int GigabitEthernet2.590
 mpls traffic-eng tunnels
int GigabitEthernet2.501
 mpls traffic-eng tunnels
int GigabitEthernet2.502
 mpls traffic-eng tunnels

#XR11
ipv4 unnumbered mpls traffic-eng loopback0
!
router isis 132
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback0
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.501
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.512
  auto-tunnel backup
  !
 !
 auto-tunnel mesh
  group 10
   onehop
   attribute-set ONEHOP_ATTRS
  !
  tunnel-id min 9990 max 9999
 !
 auto-tunnel backup
  tunnel-id min 10000 max 10999
 !
 attribute-set auto-mesh ONEHOP_ATTRS
  autoroute announce
  fast-reroute
!
mpls ldp
 int tunnel-te9990
 int tunnel-te9991

#XR12
ipv4 unnumbered mpls traffic-eng loopback0
!
router isis 132
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback0
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.502
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.512
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.562
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.592
  auto-tunnel backup
 !
 auto-tunnel mesh
  group 10
   onehop
   attribute-set ONEHOP_ATTRS
  !
  tunnel-id min 9990 max 9999
 !
 auto-tunnel backup
  tunnel-id min 10000 max 10999
 !
 attribute-set auto-mesh ONEHOP_ATTRS
  autoroute announce
  fast-reroute
!
mpls ldp
 int tunnel-te9990
 int tunnel-te9991
 int tunnel-te9992
 int tunnel-te9993

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.

#IOS-XE
mpls traffic-eng auto-tunnel primary onehop
mpls traffic-eng auto-tunnel primary config mpls ip

Additional features that can be configured are very similar to backup auto-tunnels, such as the unnumbered interface, timers, and tunnel range.

#IOS-XE
mpls traffic-eng auto-tunnel primary config unnumbered-interface Lo0
mpls traffic-eng auto-tunnel primary timers removal rerouted seconds
mpls traffic-eng auto-tunnel primary tunnel-num min 1000 max 1999

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!

#IOS-XR
ipv4 unnumbered mpls traffic-eng loopback0
!
mpls traffic-eng
 auto-tunnel mesh
  group 10
   onehop
   attribute-set ONEHOP_ATTRS
  !
  tunnel-id min 9990 max 9999
 !
 attribute-set auto-mesh ONEHOP_ATTRS
  autoroute announce
  fast-reroute

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.

#XR12
mpls ldp
 int tunnel-te9990
 int tunnel-te9991
 int tunnel-te9992
 int tunnel-te9993

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.

#XR12
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.502
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.512
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.562
  auto-tunnel backup
  !
 !
 interface GigabitEthernet0/0/0/0.592
  auto-tunnel backup
!
 auto-tunnel backup
  tunnel-id min 10000 max 10999

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.

#CSR9, CSR10
ip rsvp signalling hello
!
int Gi2.590
 ip rsvp signalling hello

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.

#CSR9, CSR10
int Gi2.590
 isis metric 1

Now we can initiate an extended ping and watch for lost packets.

#XR13
ping 14.14.14.14 so lo0 repeat 100000

#CSR9
int Gi2.590
 shut

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.