MPLS TE Notes

Below are some important MPLS-TE notes;

MPLS TE- Traffic Engineering

  • In an IP network, routing based only on Destination address. Result in one link being over utilized and another link to under-utilized.
  • We can never do load balancing equally with adjusting the cost alone.
  • TE is the solution;
    • Efficient spreading of traffic.
    • Configured BE, link attributes are taken into account.
    • TE adapts itself to changing BW and link attributes.
    • Source based routing can be performed, as switching in MPLS takes places with reference to a label and not IP address.
  • Terminologies;
    • Head end router;
      • Where we configure a tunnel interface with some specifications.
    • Tail end router;
      • Where the tunnel ends.
    • A link-state routing protocol has to be run between Head and tail end router.
    • An LSP is created between head end and tail end LSR and called “TE tunnel”. TE tunnel is unidirectional and configuration is only on the head end router.
  • Building blocks of MPLS TE;
    • Link constraints.
    • OSPF / ISIS protocol with TE extension.
    • Algorithm to calculate best path from the head and tail end router using above protocol database. (PCALC or Constrained SPF-CSPF)
    • A signaling protocol – Resource reservation protocol (RSVP) to signal a tunnel.
      • We had CR-LDP but the usage is deprecated.
    • Forward traffic into tunnel.
  • OSPF protocol with TE extension;
    • A link state protocol should able to carry TE resources of a link such as;
      • TE metric;
        • Metric used to construct a TE tunnel. Can be different from link cost used by IGP.
      • Maximum BW;
        • Total BW of the link or configured BW on the physical interface.
      • Maximum reservable BW;
        • BW available to TE operation. Configured using “ip rsvp bandwidth” command.
      • Unreserved BE;
        • Maximum reservable BE – BW already reserved by other TE/s
      • Administrative group;
        • 32-bit value which can be set by administrator for his own usage.
    • OSPF opaque LSA-9 has flooding scope = link-local only
    • OSPF opaque LSA-10 has flooding scope = area wide (stopped by ABR)
    • OSPF opaque LSA-11 has flooding scope = whole OSPF AS wide
    • A bit “o” in the option field is set to indicate the capability of sending/receiving opaque LSA.
    • Configuration required to enable MPLS TE with OSPF
      • Need to enable “mpls traffic-eng tunnels” under global mode.
      • Same command should be configured on interfaces that carry TE.
      • Under router ospf process;
        • “mpls traffic-eng area x”
        • “mpls traffic-eng <router-id interface>”
    • BW values are expressed in kilobytes per second.
  • ISIS protocol with TE extension;
    • Extented link metric from max of 63 to 224-1
    • Usage of Sub-TLVs and down bit.
    • Extended IS reachability (TLV type-22) which carries TE information by Sub-TLVs.
    • Extended IP reachability (TLV type-135)
    • Configuration under router isis;
      • “mpls traffic-eng level-2”
      • “mpls traffic-eng router-id <interface>’
      • “metric-style wide”
  • Under following circumstance, IGP protocol floods the TE information.
    • When the link state change/configuration change;
    • Periodic flooding;
      • In OSPF, by default the entire database is flooded every 30 mins;
        • CLI to change ; “ timers pacing lsa-group <seconds>”
      • In ISIS, be default, the entire database is flooded every 15 mins;
        • CLI to change; “lsp-refresh-interval <seconds>”
      • By default, TE information is flooded every three mins.
        • CLI to change; “mpls traffic-eng link-management timers periodic-flooding x”
      • Small changes in reserved BW are not flooded immediately. Flooding occurs in triggered manner. %
        • Default Triggers for down: 100,99,98,97,96,95,90,85,80,75,60,45,30,15
        • Default triggers for UP: 15,30,45,60,75,80,85,90,95,97,98,99 and 100
    • When Tunnel setup failure
      • There are chances that another tunnel just reserved more BW such that new tunnel will not be created. This information may not flood by IGP as the trigger might not be reached. In this case, the router immediately floods again.
  • Link TE attributes;
    • Maximum reservable BW;
      • BW of the interface that can be used by TE. Explained above.
    • Attribute flags
      • Configured via “mpls traffic-eng attribute-flags <value>”
      • 32 bit value which has no syntax. Configured by administrator.
      • “Affinity bits and mask” of a TE tunnel configured on head-end LSR is compared with attribute flag to control whether the tunnel is allowed to cross this link.
    • TE metric
      • “mpls traffic-eng administrative-weight <value”
      • Default TE metric is equal to IGP cost of the link.
    • Shared risk link groups (SLRG)
    • Maximum reservable sub-pool bandwidth
      • “sub-pool” is the pool where the DiffServ-aware TE tunnels obtain their BW.
  • MPLS TE Tunnel (Trunk) attribute;
    • Tunnel destination
      • Router ID of the tail-end router.
    • Desired BW;
      • BE needed for TE tunnel.
      • “tunnel mpls traffic-eng bandwidth [sub-pool|global] <value>”
    • Path setup options;
      • Explicit or dynamic options are available.
        • In Explicit, we need to specify the link IP address/TE router ID of the intermediate LSRs via which a tunnel has to be created.
        • More explicit path options can be configured with different priority.
        • Lower priority takes precedence. If a tunnel cannot be signaled via lowest priority path, next lowest priority path is tried.
        • If dynamic is configured, PCALC determines the intermediate LSRs.
        • If none of the paths can be selected for TE tunnel, tunnel cannot be signaled and hence will be in “down” state.
        • Commands;
          • “tunnel mpls traffic-eng path-option <priority> explicit name <list>
          • Explicit list may contain “next-address” or “exclude-address” configured.
          • “tunnel mpls traffic-eng path-option <priority>  dynamic”
          • In “show mpls traffic-eng tunnels tunnel x” look for “Active path option” to see which path-option is selected.
    • Set-up and holding priority
      • Priorities are configured to make sure more important tunnels can be established by pre-empting the less important TE tunnels.
      • Lower the priority value, the higher the importance.
      • Setup priority;
        • How important a tunnel to preempt other tunnels.
        • High-important tunnel has to be configured with less priority.
        • Setup priority of a tunnel cannot be lower than the holding priority.
      • Holding priority
        • Indicates whether the tunnel can be dropped when high importance tunnel has to be establish.
        • If the setup priority value of new tunnel is less than holding priority of the current tunnel, the new tunnel will preempt the current tunnel.
      • Configured “tunnel mpls traffic-eng priority <setup> <holding>” on TE tunnel interface.
    • Re-optimization
      • There are chances that current TE tunnel path is less optimized than other.
      • Periodic re-optimization;
        • By default every one hour, reoptimization occurs.
        • Changed by “mpls traffic-eng reoptimize timers frequency <interval>”
        • Interval can be between 0 sec and 7 days.
        • To  turnoff this globally,“mpls traffic-eng reoptimize timers frequency 0”
        • To turnoff for particular tunnel;
          • “tunnel mpls traffic-eng path-option xxx lockdown”
      • Event reoptimization;
        • When a link comes up or more BW is configured for TE, it will not trigger any reoptimization of tunnel, by default.
        • To enable; “mpls traffic-eng reoptimize events link-up”
      • Manual reoptimization;
        • Using “mpls traffic-eng reoptimize” on router prompt on head end LSR.
        • “mpls traffic-eng reoptimize tunnel <number>” for particular tunnel.
  • Dual Metric;
    • By default TE uses “TE metric” of the links to route the TE tunnels.
    • And by default, TE metric is same as IGP link metric. We can override TE metric using “mpls traffic-eng administrative-weight x”.
    • We can configure one tunnel to take TE metric and another tunnel to take IGP metric.
    • Command “tunnel mpls traffic-eng path-selection metric igp|te”
  • PCALC/CSPF;
    • SPF algorithm which gives the path to be taken for a TE tunnel.
    • Calculation based on TE-IGP database and takes into account all link attributes.
    • If there are multiple paths with same cost and same constraints;
      • Path with largest minimum BW is chosen
      • If tie, the path with few hops
      • Still tie, IOS picks one.
  • Basic operation of signaling
    • RSVP PATH message is sent from head end to tail end LSR and carries a request for Label. It has Explicit Route Object (ERO) which has the information(IP address) about how the PATH message to travel.
    • Each router on the path when receives the PATH message, it extracts it IP address from the ERO and send it to next-hop specified in ERO.
    • On reaching Tail end router, it sends RSVP RESV message which carries a label. Each LSR on the path reserves the bandwidth specified and returns a label with RESV message, which finally reaches head-end LSR.
    • RSVP messages;
        • Path
          • From head-end to tail-end to signal a tunnel.
        • PathTear
          • From head-end to tail-end to signal tunnel has to be down (admin shut)
        • Resv
          • From tail-end to head-end in response to “Path” message.
        • ResvTear
          • From tail-end to head-end in response to “pathTear” message. As ACK.
        • PathError
          • Towards head-end LSR from path LSR. When a link used by TE becomes down. Has “Local Repair” set in case of FRR.
    • RSVP PATH from head end LSR to tail end has;
      • Session object
        • IPv4 address of Egress router
        • Tunnel ID
        • Extended Tunnel ID
        • Request label
        • Sender_Tspec
          • Carries the BW of the tunnel as ‘average rate’. Expressed in bytes/sec
        • Session attribute
          • Setup and holding priority and some flags regarding local-protection and affinity bits.
        • ERO
        • RRO (optional)
          • IP address of the routers that the TE tunnel traversed.
          • Same as ERO except TE is rerouted via backup.
    • RSVP RESV message from tail end LSR to head end LSR has;
      • Session object
      • Label Object
      • Sender_Tspec
      • RRO (optional)
    • Shared explicit style (SE style);
      • When an LSR needs to be re-routed, the old TE LSP will not be torn down until new TE LSP is signaled.
      • Avoids double booking of BW.
  • FRR- Fast ReRoute
    • A backup tunnel for each protected link or node is created in advance. So that when the protected link goes down, the traffic is not disturbed and label-switched to backup tunnel temporary.
    • Backup tunnel doesn’t not reserve any bandwidth
    • When a protected link goes down, path LSR sends “PathErr” to head-end router to notify to create signal a tunnel via another path.
    • Link protections;
      • “NHOP backup Tunnel” is created between point of local repair (PLR) and merge point(MP).
      • Below command is configured on PLR on the protected link;
        • “mpls traffic-eng backup-path <tunnel number>”
        • Below command is configured on head-end router which set a bit in session attribute indicating the tunnel wants local-protection.
          • “tunnel mpls traffic-eng fast-reroute”
        • “show mpls traffic-eng fast-reroute database detail”
        • State of the backup tunnel can be;
          • Ready- tunnel is signaled but not currently used.
          • Active- tunnel is rerouting a number of TE tunnels LSPs.
          • Partial- backup tunnel is not signaled yet.
    • Node protection;
      • Here, a router is protected with a backup tunnel.
      • “tunnel mpls traffic-eng fast-reroute node-protect” is configured on head-end LSR.
      • “NNHOP backup tunnel” is created between PLR and MP router.
  • Shared Risk link group;
    • A link/s is configured with same SRLG value which maps same fiber or conduit.
    • If the protected link and a set of links are configured with same SRLG number, the backup tunnel will avoid those links.
    • “mpls traffic-eng srlg <number>” on the links.
    • A link can be part of several SRLG group.
    • Global command; “mpls traffic-eng auto-tunnel backup slrg exclude [force|preferred]”
      • Force – instruct the backup tunnel should never take same SLRG interface as protected link. If no such link available. Backup tunnel will not be formed.
      • Preferred –  prefers to have backup tunnel via interface which has different SLRG.

Forwarding Traffic onto MPLS tunnel


  • Creating Tunnel is one job. Forwarding traffic is yet another job.
  • Consider a tunnel as a “virtual link” and use it as an interface connecting head end and tail end router.
  • Six ways we can use tunnel to forward traffic;
    • Static routing;
      • “ip route <prefix>/<network> tunnel x”
    • Policy Based routing (PBR)
      • We can map a traffic and then forward those via tunnel interface.
      • In route-map, “set interface tunnel” command is used.
    • Auto-route announce;
      • “tunnel mpls traffic-eng autoroute announce” configured on tunnel interface of head end router.
      • To make this head-end LSR to insert IP destinations into the routing table with tunnel interface as next-hop or outgoing interface.
    • Forwarding adjacency; – Enabled by default.
      • IGP can see TE LSP as a link.
      • A two-way tunnel has to be established from head-end to tail-end and vice versa
      • “tunnel mpls traffic-eng forwarding-adjacency holdtime x” configured on tunnel interface of head end router.
      • As tunnel interface is unnumbered, ospf uses Ifindex to identify the interface.
    • Based on COS value.
  • Cost calculation of Tunnel interface.
    • When using “autoroute announce”, the cost of the TE tunnel as used by the IGP for the prefix with tunnel as next-hop is always the lowest IGP total cost of the path, though the lowest cost path is not spanned by tunnel.
    • The general rule is that for a prefix on the tail end router, only a tunnel that ends on that tail end router is used to forward packets. No load balancing occurs between the TE tunnel and the IP path in this case. Even if the TE tunnel is not on the lowest IGP cost path (it might have an explicit path that is not on the shortest path, or it might be waiting to be reoptimized), all traffic that is destined for prefixes connected to the tail end router goes into the TE tunnel.
    • Adjusting cost calculation
      • “tunnel mpls traffic-eng autoroute metric {absolute|relative} <value>”
  • Load Balancing;
    • When multiple TE tunnels have same cost, load-balancing takes place.
    • This load-balancing can also be unequal. Proportional to the bandwidth allocation of each tunnel though the tunnel has same cost.

MPLS TE and MPLS VPN

  • TE tunnels between PE routers;
    • Two tunnels exist between PE routers.
    • BGP next-hop of the VPNv4 address is pointing to TE tunnels.
    • Packet will have 2 labels;
      • Top label is TE label
      • Bottom label is VPN label.
    • LDP need not to be enabled.
  • TE tunnels with P-router as Tail end router;
    • LDP is enabled on all links;
      • Because, as the tail-end of TE tunnel sends implicit-null as label, the double labeled packet becomes single label (VPN label alone) and the P-router will have no info about the VPN label.
    • An LDP session exists between the head end and tail end router of TE tunnel LSP.Can be achieved in two ways;
      • Two tunnels between end-end LSR and LDP is enabled on both tunnel interfaces
      • A targeted LDP session between PE(or P) and P router.
      • In above cases, there would be three labels when the packets traverse in the tunnel.
        • Top label –  TE label
        • LDP label
        • Bottom label – VPN label
  • We can have each VRF pointing to each TE Tunnel from ingress PE to egress PE router. To do this, we need to specify different loopback IP address as BGP next-hop for each VRF.
    • Need to enable “bgp next-hop <interface>” under VRF mode on egress router.
Advertisements
This entry was posted in mpls and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s