CCDE – MPLS-TE Auto Tunnels

This post will briefly discuss the challenges of manually setting up MPLS-TE tunnels and how Auto Tunnels can lessen the burden of MPLS-TE tunnels.

One of the main challenges with traffic engineering and MPLS-TE is the number of tunnels that will be needed. To setup tunnels between all PE’s may not be a scalable solution. For a provider with 200 PE’s, 199 tunnels would have to be configured on each PE and that is if only one traffic class is used. This would mean that 39800 tunnels would be present in the network. If you then want to add a tunnel for voice at each PE you end up with 398 tunnels per PE and a total of 79600 tunnels.

Another option is to enable tunnels only on the P routers. If the number of P routers are 20, then each P router would need 19 tunnels and we would have 380 tunnels in total or 760 if adding an extra tunnel for voice. This is a much more reasonable number. It would require to enable LDP over the tunnels if MPLS L3VPNs are in use to have an end to end LSP. With the P to P tunnels we would not have end to end traffic engineering.

Regardless if PE-to-PE or P-to-P tunnels are deployed, there is a big configurational burden to configure the tunnels unless an offline tool is used.

One option to lessen the burden is to use what is called Auto Tunnel Mesh. A mesh group is then used to group LSRs together and form tunnels between them. Membership to the group can be identified by matching a TE router ID against an ACL (IOS-XR and IOS) or IGP mesh-group advertisement (IOS). The second option depends on signalling in the LSA’s. Each member then automatically creates a tunnel upon detection of a member. The tunnels are instantiated from a template, think of something like VPDN where an virtual access template is used. The individual tunnels will not be displayed in configuration but should be visible by using the show derived-config command.

Please note that this is simply an automation of the creation of the tunnels which means the operational burden (OPEX) is less but we still have the same scalability concerns as before.

Often when deploying MPLS-TE, it will be deployed in combination with Fast Reroute (FRR). MPLS-TE is well known for having very fast recovery times through link and/or node protection. One drawback though is that it only protects the TE tunnels and not IP or LDP traffic. It may also be desirable to deploy FRR without deploying MPLS-TE tunnels. This is exactly where Auto Tunnel Primary Tunnels comes into play. It can protect all traffic and it doesn’t rely on MPLS-TE tunnels being deployed first. The Auto Tunnel Primary Tunnel will not use FRR by itself though. It is used to build a one-hop primary tunnel on all TE links and that tunnel will then be protected by a backup tunnel. This means that every TE enabled router builds an one-hop tunnel to all of its adjacent routers if TE is enabled on the interface towards them. Once again, this means that only a few commands need to be enabled and the rest of the configuration will be derived. Backup tunnels can be automatically or manually configured but it’s most reasonable to think that they would be automatically configured if the goal is to reduce the configurational burden.

Normally backup tunnels would be manually configured. This may be configuration intensive as the operator would have to specify a diverse path in the network and possibly point out all the next-hops in the path or at least exclude next-hops that should not be part of the path. To automate the function of backup tunnels there is a feature called Auto Tunnel Backup Tunnel. What it does is that it detects if a primary tunnel requires protection and is not already protected. It will compute a backup path to NHOP (Next-Hop) and NNHOP (Next-Next-Hop) which excludes the protected facility. It may optionally also exclude links that belong to the same SRLG (Shared Risk Link Group) for added diversity. It will then of course signal the tunnel.

These three features are all used to minimize the amount of configuration the operator has to put in themselves. For operators that don’t want to have all of the features of MPLS-TE and the complexity that comes with it, the auto tunnels are a nice option to provide FRR to the traffic in the network. There are other options such as IP-FRR though, which may be a better option if it is supported.

Deploying MPLS-TE is complex and the usage of auto tunnels helps in reducing the complexity in those use cases where the goal of using MPLS-TE is to provide FRR.