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.

CCDE – MPLS-TE Auto Tunnels
Tagged on:                 

6 thoughts on “CCDE – MPLS-TE Auto Tunnels

  • January 13, 2016 at 3:31 pm
    Permalink

    Great post Daniel.
    If I may suggest another alternative for l3VPN by using IP LFA for the IGP, LDP FRR for the MPLS core (or less preferably hierarchical TE FRR) and BGP PIC for the edge. I think this would overcome the stringe need for RSVP-TE extensions and is much more efficient in terms of scalability and troubleshooting.
    As for L2VPN high availability, I would definitely use PBB-EVPN.
    Thanks

    Reply
    • January 13, 2016 at 4:25 pm
      Permalink

      Hi Michel,

      I agree with your thoughts. It’s definitely less complex and the way forward to use IP FRR and technologies like PIC Edge.

      Reply
      • January 14, 2016 at 4:53 am
        Permalink

        Hi Daniel,

        Great article with a strong focus on design implications. I tend to agree that IP FRR is a great alternative to TE-FRR, but it isn’t as widely supported (as you mention). For example, Brocade does not support IP FRR for any IGP on any product (as of 4 months ago). I am not sure how Juniper pans out. In a multi-vendor environment, migrating from TE-FRR to IP FRR might take a little time.

        IP FRR also has its own complexities behind the scenes; I think you were there for Luc’s class last year 🙂 Fortunately, it scales well and requires no signaling, unlike TE-FRR which is neither.

        One drawback of the auto-backup + auto-primary approach is that it provides NHOP (link) protection only. Auto-backups by themselves, as you state, will compute NHOP and NNHOP tunnels by default, but primary one-hop tunnels don’t even have an NNHOP 🙂

        This is also a general limitation of mLDP-based LSM since TE-FRR can only ever protect links, never nodes, and is another reason why some people still prefer RSVP P2MP TE (that, and the bandwidth reservations of course).

        We are going to test the auto-backup + auto-primary link protection in our lab within the next few months on some ASR1000s and CSR1000vs, I will let you know how that goes.

        Reply
        • January 14, 2016 at 12:58 pm
          Permalink

          Thanks for that information, Nick. Very useful.

          So that means that we only have link protection with the combination of auto primary and auto backup. I would imagine that link failures are far more common than node failures though, so that would be something to consider in the design.

          Like you mention, the auto backup tunnels can calculate NNHOP. So if we were to use manually configured tunnels we could use auto backup to provide both link and node protection?

          Thanks for the info and please keep me posted.

          Reply
          • January 14, 2016 at 7:28 pm
            Permalink

            That is correct. With an ordinary (non-primary) LSP requesting FRR, auto-backup will create NHOP and NNHOP tunnels by default. OF course, the NNHOP tunnels are preferred over NHOP when both are available.

            Normally, when deploying it with auto-primary one-hop tunnels, you would use the “nhop-only” option with auto-backup so that you don’t needlessly create NNHOP tunnels. I think the router is smart enough not to create them anyway, but as a best practice, I typically do this.

  • Pingback:CCDE Success: References Used – localpref.net

Leave a Reply to Michel B Cancel reply

Your email address will not be published. Required fields are marked *