Thursday, February 6, 2014

NTS: Advanced MPLS-TE

Advanced MPLS-TE



FRR (Fast ReRoute) extensions for RSVP-TE are defined in RFC 4090.
Inter-Area MPLS TE is described in RFC 4105.
Inter-AS MPLS TE is described in RFC 4216.


LSP Protection

  • path protection - long term
  • local protection (FRR) - short term
    • link protection
    • node protection

Backup tunnels are usually used for a short period of time, until the head-end recomputes and signals a new path. When the new path is established and traffic is switched over to it, the backup path is torn down.

PLR = Point of Local Repair
MP = Merge Point

The constraints of the backup path are signaled by the head-end to the PLR using the Fast Reroute Object (FRO) of RSVP.

  • many-to-one backup (facility backup)
    • an extra label is pushed by the PLR
    • MP advertises an implicit-null label (PHP)
    • traffic arrives at the MP with the same label as the main path
  • one-to-one backup (detour backup)
    • the top label is swapped by the PLR
    • MP advertises a normal label (label swap)
    • traffic arrives at the MP with a different label from the main path

Expect to see only the many-to-one backup being used.

The failure and the local restoration of a main path are signaled by the PLR to the head-end using an RSVP Path-Error message (code="Notify", subcode="Tunnel locally repaired") and an RRO flag.


FRR (Fast Reroute)

MPLS-TE/FRR is a mechanism for protecting MPLS TE LSPs from link and node failures by locally repairing the LSPs at the point of failure.  It allow traffic to continue to flow on the LSPs, while their head-end routers attempt to establish new end-to-end LSPs to replace them.

FRR repairs locally the protected LSPs by rerouting them over backup tunnels that bypass these failed links or nodes.

  • NHOP backup tunnels
    • backup tunnels that bypass only a link of the LSP's path 
    • they provide link protection by rerouting the LSP's traffic to the next-hop
    • can be specified by simply excluding the protected link (interface address)
  • NNHOP backup tunnels 
    • backup tunnels that bypass a node of the LSP's path
    • they provide node (& link) protection by rerouting the LSP's traffic to the next-next-hop
    • can be specified by simply excluding the protected node (loopback address)

FRR prefers NNHOP over NHOP backup tunnels, when both are available.


Configuration Steps
  • PE (head-end)
    • enable FRR under the tunnel
  • PLR (point of local repair)
    • configure a backup tunnel with a path that avoids the link/node to be protected
    • enable the backup tunnel under the link to be protected
    • enable RSVP hellos or BFD under the link to be protected (for faster detection)


PE (head-end)

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 19.19.19.19
 tunnel mpls traffic-eng path-option 1 explicit name X
 tunnel mpls traffic-eng fast-reroute

IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 19.19.19.19
 fast-reroute
 path-option 1 explicit name X


You also have the following options if you want to influence the backup tunnel selection on the PLR:

IOS
R2(config-if)#tunnel mpls traffic-eng fast-reroute ?
  bw-protect    bandwidth protection desired
  node-protect  node protection desired

IOS-XR
CRS(config-if)#fast-reroute protect ?
  bandwidth  Enable bandwidth protection request
  node       Enable node protection request


IOS-XR by default tries to provide the best available protection, even if the above two options aren't activated.


PLR (point of local repair)

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 5.5.5.5
 tunnel mpls traffic-eng path-option 1 explicit name AVOID-X
!
ip explicit-path name AVOID-X enable
 exclude-address x.x.x.x
!
interface FastEthernet0/0
 mpls traffic-eng backup-path Tunnel0
 ip rsvp signalling hello



IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 5.5.5.5
 path-option 1 explicit name AVOID-X
!
explicit-path name AVOID-X
 index 1 exclude-address ipv4 unicast x.x.x.x
!
mpls traffic-eng
 interface TenGigE0/0/0/0
  backup-path tunnel-te 0


The same "rsvp signalling hello" type (RSVP hellos or BFD) must be configured on the other side too for fast detection to take place.
IOS-XR supports only BFD for fast detection (< 1sec). RSVP hellos can be used for simple reroute (detection > 10sec) or GR.


 Verification


PE (head-end)

IOS
R2#sh mpls traffic-eng tunnels protection
P2P TUNNELS:
R2_t0
  LSP Head, Tunnel0, Admin: up, Oper: up
  Src 2.2.2.2, Dest 19.19.19.19, Instance 46
  Fast Reroute Protection: Requested
    Outbound: Unprotected: no backup tunnel assigned
      LSP signalling info:
        Original: out i/f: Fa0/0.23, label: 18, nhop: 20.2.3.3
                  nnhop: 4.4.4.4; nnhop rtr id: 4.4.4.4
  Path Protection: None


PLR (point of local repair)

before the activation of the backup tunnel

IOS
R4#sh mpls traffic-eng tunnels backup
R4_t0
  LSP Head, Admin: up, Oper: up
  Tun ID: 0, LSP ID: 3, Source: 4.4.4.4
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.45
    Protected LSPs/Sub-LSPs: 1, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0


R4#sh mpls traffic-eng fast-reroute database role middle

P2P LSP midpoint frr information:
LSP identifier                 In-label Out intf/label   FRR intf/label   Status
---------------------------    -------- --------------   --------------   ------
2.2.2.2 0 [46]                 16       Fa0/0.45:18      Tu0:18           Ready


R4#sh mpls traffic-eng fast-reroute database role middle detail
FRR Database Summary:
  Protected interfaces    : 1
  Protected LSPs/Sub-LSPs : 1
  Backup tunnels          : 1
  Active interfaces       : 0

P2P LSPs:

 Tun ID: 0, LSP ID: 46, Source: 2.2.2.2
 Destination: 19.19.19.19
  State        : Ready
  InLabel      : 16
  OutLabel     : Fa0/0.45:18
  FRR OutLabel : Tu0:18


after the the activation of the backup tunnel

R4#sh mpls traffic-eng tunnels backup
R4_t0
  LSP Head, Admin: up, Oper: up
  Tun ID: 0, LSP ID: 3, Source: 4.4.4.4
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.45
    Protected LSPs/Sub-LSPs: 1, Active: 1
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0


R4#sh mpls traffic-eng fast-reroute database role middle

P2P LSP midpoint frr information:
LSP identifier                 In-label Out intf/label   FRR intf/label   Status
---------------------------    -------- --------------   --------------   ------
2.2.2.2 0 [46]                 16       Fa0/0.45:18      Tu0:18           Active

R4#sh mpls traffic-eng fast-reroute database role middle detail
FRR Database Summary:
  Protected interfaces    : 1
  Protected LSPs/Sub-LSPs : 1
  Backup tunnels          : 1
  Active interfaces       : 1

P2P LSPs:

 Tun ID: 0, LSP ID: 46, Source: 2.2.2.2
 Destination: 19.19.19.19
  State        : Active
  InLabel      : 16
  OutLabel     : Fa0/0.45:18
  FRR OutLabel : Tu0:18


When using MPLS-TE/FRR for node protection, a label_recording flag is included into the SAO in order to signal that the RRO should also include labels (because these labels are actually used by the PLR for NNHOP backup tunnels), although it's not shown in the tunnel config.


IOS
R2#sh mpls traffic-eng tunnels | b Resv
    RSVP Resv Info:
      Record   Route:  3.3.3.3(20) 4.4.4.4(20)
                       5.5.5.5(20) 19.19.19.19(0)

If you explicitly enable it in the config, then you get the address of the physical interfaces too.

R2#sh mpls traffic-eng tunnels | b Resv
    RSVP Resv Info:
      Record   Route:  3.3.3.3(21) 20.3.4.3(21)
                       4.4.4.4(21) 20.4.5.4(21)
                       5.5.5.5(21) 20.5.19.5(21)
                       19.19.19.19(0) 20.5.19.19(0)

The path when using the backup tunnel is not reflected in the above output.


You can also use the following command on the PLR in order to verify the FRR operation.

IOS
R4#sh ip rsvp sender detail
...
  Tun Dest:   19.19.19.19  Tun ID: 0  Ext Tun ID: 2.2.2.2
  Tun Sender: 2.2.2.2  LSP ID: 25
...
  Fast-Reroute Backup info:
    Inbound  FRR: Not active
    Outbound FRR: Ready -- backup tunnel selected
      Backup Tunnel: Tu1        (label 19)
      Bkup Sender Template:
        Tun Sender: 20.3.4.4  LSP ID: 25
      Bkup FilerSpec:
        Tun Sender: 20.3.4.4, LSP ID: 25


or the following command on the head-end.

R2#sh ip rsvp reservation detail
...
Reservation:
  Tun Dest:   19.19.19.19  Tun ID: 0  Ext Tun ID: 2.2.2.2
  Tun Sender: 2.2.2.2  LSP ID: 25
  Next Hop: 20.2.3.3 on FastEthernet0/0.23
  Label: 20 (outgoing)
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
  Resv ID handle: 0A000415.
  Created: 13:32:42 UTC Sat Jan 11 2014
  Average Bitrate is 20M bits/sec, Maximum Burst is 1K bytes
  Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes
  RRO:
    3.3.3.3/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 20
    20.3.4.3/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 20
    4.4.4.4/32, Flags:0x25 (Local Prot Avail/Has BW/to NHOP, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    20.4.5.4/32, Flags:0x5 (Local Prot Avail/Has BW/to NHOP)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    5.5.5.5/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    20.5.19.5/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    19.19.19.19/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 0
    20.5.19.19/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 0
  Status:
  Policy: Accepted. Policy source(s): MPLS/TE


Then the backup tunnel gets activated, the output will change to:

IOS
R2#sh ip rsvp reservation detail
...
    4.4.4.4/32, Flags:0x23 (Local Prot Avail/In Use/to NHOP, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 16
    20.3.4.4/32, Flags:0x3 (Local Prot Avail/In Use/to NHOP)
      Label subobject: Flags 0x1, C-Type 1, Label 16




Path Protection

Apart from having link & node protection using FRR, you also have the option of enabling path protection end-to-end for a tunnel. You can have multiple backup path options per primary path option.

It's not as fast as FRR, but it's still faster than having a second path-option or relying on IGP, because it pre-calculates the whole backup path (like FRR).

It can be used with intra-area, inter-area and inter-AS scenarios.

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 2.2.2
 tunnel mpls traffic-eng path-option 1 explicit name PATH1
 tunnel mpls traffic-eng path-option protect 1 explicit name PATH1-BAK


R1#sh mpls traffic-eng tunnels protection

P2P TUNNELS:
R1_t0
  LSP Head, Tunnel0, Admin: up, Oper: up
  Src 1.1.1.1, Dest 2.2.2.2, Instance 3
  Fast Reroute Protection: None
  Path Protection: Requested


You can also view the details about SRLGs:

R1#sh mpls traffic-eng tunnels tunnel0

Name: R1_t0                             (Tunnel0) Destination: 2.2.2.2
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type explicit PATH1 (Basis for Setup, path weight 20)
    Path Protection: 2 Common Link(s), 1 Common Node(s)
      Link Sharing Detail:
        P2P Links:             0
        Multiacces Links:      2
           Both interfaces:         2
           1 interface:             0
           0 interfaces:            0 (only media is shared)
    path protect option 1, type explicit PATH1-BAK (Basis for Protect, path weight 20)

Latest IOS software releases support enhanced path protection (up to 8 secondary path options).


IOS-XR
interface tunnel-te0
 path-protection
 path-option 1 explicit name R2-R3-R4
 path-option 2 dynamic 
!
interface tunnel-te1
 path-protection
 path-option 1 explicit name R2-R3-R4 protected-by 2
 path-option 2 explicit name R2-R5-R6


Path-protection is not supported on C12k platform for IOS-XR.

In IOS-XR you can either have explicit path as primary and dynamic as backup, or explicit path as primary and backup. IOS-XR provides automatic path diversity.


Backup Tunnel Selection

You can have multiple backup tunnels protecting the same or different LSPs, each one terminating on the same destination or a different one.

The backup tunnel is configured on the PLR, under the physical interface to be protected.

IOS
interface X
 mpls traffic-eng backup-path Tunnel0
 mpls traffic-eng backup-path Tunnel1


IOS-XR
mpls traffic-eng
 interface X
  backup-path tunnel-te 0
  backup-path tunnel-te 1


The selection priority between multiple backup tunnels is based on the following table.


Preference Backup Tunnel Destination Bandwidth Pool Bandwidth Amount
1 (Best) Next-next hop Sub-pool or global-pool Limited
2Next-next hop Any Limited
3Next-next hop Sub-pool or global-pool Unlimited
4Next-next hop Any Unlimited
5Next-hop Sub-pool or global-pool Limited
6Next-hop Any Limited
7Next-hop Sub-pool or global-pool Unlimited
8 (Worst) Next-hop Any Unlimited


The general idea is the following:
  • NNHOP tunnels have priority over NHOP tunnels
  • backup-bw tunnels have priority over no backup-bw tunnels
  • specific pool tunnels have priority over any pool tunnels

After a backup tunnel has been chosen for an LSP, various conditions may change on the network, that will cause the router to reevaluate this choice. This promotion can happen immediately in case of a backup tunnel going up/down, or periodically every 5 mins. This time be changed by using the command "mpls traffic-eng fast-reroute timers". Set it to 0 if you want to disable promotion for LSPs.


backup protection algorithm

If the main tunnel doesn't have any bandwidth configured, then it can use only backup tunnels that don't have any backup-bandwidth configured.

In the following example, main tunnel (that doesn't have any signaled bandwidth configured) can use only backup tunnel #2.

main tunnel
interface Tunnel0

backup tunnel #1
interface Tunnel1
 tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2
interface Tunnel2


If the main tunnel has a bandwidth configured, then it can use only backup tunnels that either don't have any backup-bandwidth configured or have sufficient backup-bandwidth configured.

In the following example, main tunnel (that has a bandwidth of 35M configured) can use only backup tunnel #2 and #3.

main tunnel
interface Tunnel0
 tunnel mpls traffic-eng bandwidth 35000

backup tunnel #1
interface Tunnel1
 tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2
interface Tunnel2

backup tunnel #3
interface Tunnel3
 tunnel mpls traffic-eng backup-bw 40000


Generally, the backup-bandwidth is assumed to be unlimited when it's not configured. Is this case no bandwidth protection is provided.

If you don't configure a global-pool or a sub-pool, then any pool is assumed.

When using global-pool or sub-pool in order to limit the type of backup-bandwidth (and not the amount), then you have to explicitly define as unlimited the backup-bandwidth, like below:

IOS
interface Tunnel1
 tunnel mpls traffic-eng backup-bw global-pool unlimited
 tunnel mpls traffic-eng backup-bw sub-pool unlimited

IOS-XR
interface tunnel-te1
 backup-bw global-pool unlimited
 backup-bw sub-pool unlimited


If there are two or more backup tunnels with backup-bandwith configured that have sufficient available backup-bandwith, then the one with the least amount of currently available backup bandwidth is chosen, in order to keep the largest amount available for other LSPs (main tunnels) with bigger needs.

If there are two or more backup tunnels with no backup-bandwith configured, then the one with the least amount of currently used backup bandwidth is chosen, in order to distribute the LSPs (main tunnels) as evenly as possible. If the LSP (main tunnel) doesn't have any bandwidth configured, the backup tunnel with the fewest protecting LSPs is chosen.

If you want to change the above backup protection preemption algorithm, you can use the following command on the PLR:

IOS
R2(config)#mpls traffic-eng fast-reroute backup-prot-preempt ?
  optimize-bw  Reduce bandwidth wastage (default: minimize LSPs preempted)


Keep in mind that backup tunnels can have their signaled-bandwidth configured, just like any other tunnel, in order to have the LSRs on the backup path do the appropriate admission control (in production networks this might not be recommended in order to avoid reservation of resources for a tunnel rarely used). On the other hand, the backup-bandwidth is used solely by the PLR (head-end of he backup tunnel) locally. Theoretically, both signaled-bandwidth and backup-bandwidth should be the same for proper operation.

In general:
  • signaled-bandwidth on the main tunnel
    • xxx (global pool is assumed)
    • sub-pool xxx
  • backup-bandwidth on the backup tunnel
    • xxx (any pool is assumed)
    • global-pool xxx
    • sub-pool xxx

You need to enable RDM for RSVP if you are using sub-pools.


TE auto-bandwidth

TE auto-bandwidth samples the average output rate for each tunnel configured for automatic bandwidth adjustment and periodically (i.e. once per day) adjusts the tunnel’s signaled-bandwidth to be the largest sample for the tunnel since the last adjustment.

Auto-bandwidth basically performs the following steps:
  • every X interval, traffic over a tunnel is measured
  • every Y interval, the largest sample from the above measurement is collected
  • if this sample value exceeds a Z threshold, then it's used to set the new tunnel bandwidth

Configuration Steps
  • globally
    • enable statistics collection & auto-bw adjustments (enabled by default)
    • frequency: define the interval between tunnel bw statistics collection (5m by default)
  • per tunnel
    • frequency: define the interval between auto-bw adjustments (24h by default)
    • max-bw: define the max auto-bw allowed (no limit by default)
    • min-bw: define the min auto-bw allowed (no limit by default)
    • adjustment-threshold: define the delta threshold over which the new bw is actually signaled/used (10% by default)


IOS
mpls traffic-eng auto-bw timers frequency 60
!
interface Tunnel0
 load-interval 30
 tunnel mpls traffic-eng bandwidth 20
 tunnel mpls traffic-eng auto-bw frequency 300 adjustment-threshold 1 max-bw 100 min-bw 1


IOS-XR
mpls traffic-eng
 auto-bw collect frequency 1
!
interface tunnel-te0
 load-interval 30
 signalled-bandwidth 20
 auto-bw
  bw-limit min 1 max 100
  adjustment-threshold 1
  application 5


IOS-XR auto-bw intervals are defined in mins, while IOS ones are defined in secs.

It's good practice to have: tunnel load-interval < global sampling frequency < tunnel adjust frequency.

IOS
R2#sh mpls traffic-eng tunnels
...
  Config Parameters:
    Bandwidth: 20    kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute announce: enabled  LockDown: disabled Loadshare: 1        bw-based
    auto-bw: (300/155) 7  Bandwidth Requested: 1
          Adjustment Threshold: 1%
          Samples Missed: 0  Samples Collected: 2


after the auto-bw adjustment interval timer expires, the largest sample (7) is now requested/used

R2#sh mpls traffic-eng tunnels
...
  Config Parameters:
    Bandwidth: 20    kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute announce: enabled  LockDown: disabled Loadshare: 7        bw-based
    auto-bw: (300/283) 0  Bandwidth Requested: 7
          Adjustment Threshold: 1%
          Samples Missed: 0  Samples Collected: 0


Don't forget to also configure the load-interval on the tunnel interface accordingly.

Traffic samples for tunnels that were down during the sampling period, are ignored.

If auto-bw is configured for a tunnel, the "tunnel mpls traffic-eng bandwidth" command sets only the initial tunnel bandwidth. Setting the initial bandwidth is not required for auto-bw to work.

The latest requested/signaled bandwidth is automatically saved to the tunnel running config.

In latest software releases you can also set an overflow or underflow threshold in order to make the bandwidth adjustment earlier than the configured interval (so you don't have to wait for all the samples to be collected). That way you can set a large auto-bw adjustment frequency and use these two thresholds in such a way that you can react quickly to traffic changing conditions.



Auto-Tunnels


3 types:
  • backup auto-tunnels
    • no need to configure manual backup tunnels
    • no need to assign backup tunnels to a protected interface
  • primary one-hop auto-tunnels
    • no need to configure tunnels to directly connected neighbors with FRR for protection
  • mesh-group auto-tunnels
    • no need to configure tunnel to all interested PEs with FRR for protection


backup auto-tunnels

It must be configured on the PLR, like normal backup tunnels.  After activation, dynamic backup NHOP/NNHOP tunnels are created automatically whenever an LSP requests FRR protection.

If there is a static configured backup tunnel for a specific interface, then backup auto-tunnels won't be created for this.

IOS
mpls traffic-eng auto-tunnel backup


IOS-XR (4.0.0)
mpls traffic-eng
 auto-tunnel backup


Extra options available:

IOS
R3(config)#mpls traffic-eng auto-tunnel backup ?
  config      Config commands to apply to all backup auto-tunnels
  nhop-only   Automatically create n-hop backup tunnels only
  srlg        Shared Risk Link Groups influence backup tunnel path selection
  timers      Configure timers for backup auto-tunnels
  tunnel-num  Configure tunnel I/F numbers for backup auto-tunnels


You can enable "debug mpls traffic-eng auto-tunnel backup all" if you want to see the actual cli commands used to create the backup auto-tunnels.

IOS
R3#debug mpls traffic-eng auto-tunnel backup all
MPLS TE Auto-Tunnel Backup all debugging is on

TE_AUTO_TUN: backup CLI command:
interface tunnel65436
no logging event link-status
ip unnumbered Loopback0
tunnel destination 6.6.6.6
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65436
  index 1 exclude-address 20.3.6.3

TE_AUTO_TUN: backup CLI command:
interface tunnel65436
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65436
end

TE_AUTO_TUN: backup CLI command:
interface tunnel65437
no logging event link-status
ip unnumbered Loopback0
tunnel destination 5.5.5.5
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65437
  index 1 exclude-address 6.6.6.6

TE_AUTO_TUN: backup CLI command:
interface tunnel65437
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65437
end


R3#sh mpls traffic-eng tunnels backup
R3_t65436
  LSP Head, Admin: up, Oper: up
  Tun ID: 65436, LSP ID: 1, Source: 3.3.3.3
  Destination: 6.6.6.6
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.36
    Protected LSPs/Sub-LSPs: 0, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0
R3_t65437
  LSP Head, Admin: up, Oper: up
  Tun ID: 65437, LSP ID: 1, Source: 3.3.3.3
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.36
    Protected LSPs/Sub-LSPs: 1, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0



primary one-hop auto-tunnels

It must be configured on every router you want to create a TE tunnel to all the TE-enabled routers that are one hop away. Each auto-tunnel has "autoroute announce" and "fast-reroute" activated by default, but you can add some extra configuration too.

That way you can create automatically multiple tunnels covering all possible paths in a network.

IOS
mpls traffic-eng auto-tunnel primary onehop

IOS-XR
not supported


Extra options available:

IOS
R1(config)#mpls traffic-eng auto-tunnel primary ?
  config      Config commands to apply to all primary auto-tunnels
  onehop      Automatically create tunnel to all next-hops
  timers      Configure timers for backup auto-tunnels
  tunnel-num  Configure tunnel I/F numbers for primary auto-tunnels


You can enable "debug mpls traffic-eng auto-tunnel primary all" if you want to see the actual cli commands used to create the primary one-hop auto-tunnels.

IOS
R1#debug mpls traffic-eng auto-tunnel primary all
MPLS TE Auto-Tunnel Primary all debugging is on
 
TE_AUTO_TUN: Found a new router id 2.2.2.2 off of FastEthernet0/0
TE_AUTO_TUN: primary CLI command:
interface tunnel65336
no logging event link-status
ip unnumbered Loopback0
tunnel destination 2.2.2.2
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: primary CLI command:
interface tunnel65336
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng fast-reroute
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65336
  index 1 next-address 10.1.2.1

TE_AUTO_TUN: primary CLI command:
interface tunnel65336
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65336
end

TE_AUTO_TUN: Found  Down Tunnel65336 to router id 2.2.2.2 out FastEthernet0/0


auto-tunnel mesh groups

It must be configured on the PE routers. After activation, it creates a mesh of TE tunnels to all the PE routers which are either configured for the same mesh-group (assuming OSPF is used), or their TE Id is matched by an ACL. The address that are used in the ACL must exist in the TE database in order to have the auto-tunnel created..

IOS
mpls traffic-eng auto-tunnel mesh
!
access-list 1 permit 20.20.20.20
access-list 1 permit 30.30.30.30
!
interface Auto-Template1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination access-list 1
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic


The interface auto-template is configured like a normal TE tunnel.

You can also use explicit paths, which use the exclude-address keyword.


IOS-XR (4.1.1)
mpls traffic-eng
 auto-tunnel mesh
  group 99
   destination-list 1
!
ipv4 prefix-list 1
 10 permit 20.20.20.20/32
 20 permit 30.30.30.30/32

You cannot configure Inter-Area or Inter-AS tunnels for auto-tunnel mesh groups.

You cannot configure a static route to route traffic over auto-tunnel mesh group TE tunnels. You should use only the autoroute for tunnel selection. 

In IOS-XR there is no need to configure a dynamic path-option; it's enabled by default.

When using mesh-group numbers (instead of an ACL) to match the PEs, you have to enable IGP flooding of mesh information under the IGP of the PEs.

IOS
interface Auto-Template1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination mesh-group 99
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng mesh-group 99 Loopback0 area 0


R2#sh mpls traffic-eng topology | i mg
Area mg-id's:
: mg-id 99    1.1.1.1 :

R2#sh mpls traffic-eng auto-tunnel mesh

Auto-Template1:

 Using mesh-group 99 to clone the following tunnel interfaces:

  Destination         Interface
  -----------         ---------

  1.1.1.1             Tunnel64336

Mesh tunnel interface numbers: min 64336 max 65335


IS-IS does not support IGP distribution of mesh group information.You have to use ACLs in this case.

You can also define manually the min/max tunnel numbers used.


SRLG (Shared Risk Link Groups)

When enabled it allows you to define links that belong to the same group, because they share a risk (i.e two links using the same fiber path).

The idea is to have backup tunnels avoid using links in the same SRLG as the interfaces they are protecting. Otherwise, when the protected link fails the backup tunnel will fail too.


Configuration
  • assign interfaces to SRLGs
  • enable backup auto-tunnels globally (IOS) or per interface (IOS-XR)
  • configure backup auto-tunnels to avoid SRLGs (always or if possible)


IOS
interface X
 mpls traffic-eng srlg 1
 mpls traffic-eng srlg 2
!
interface Y
 mpls traffic-eng srlg 2
 mpls traffic-eng srlg 3
!
mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel backup srlg exclude force



IOS-XR (4.1.0)
srlg
 interface X
  value 1
  value 2
 !
 interface Y
  value 2
  value 3
!
mpls traffic-eng
 interface X
  auto-tunnel backup
   exclude srlg preferred
 

You can have multiple SRLG values per interface.

IOS default is "preferred", while IOS-XR default is "force".

Only backup auto-tunnels can be used.


Links


Inter-Area MPLS TE

Inter-Area MPLS TE Tunnels are not supported by the default configuration.

Two solutions:
  • per domain: ERO loose-hop expansion
  • distributed: Path Computation Element (PCE)

ERO loose-hop expansion

A loosely routed explicit path must be defined for the tunnel LSP that identifies each ABR the LSP should traverse using the "next-address loose" command. The head-end router and the ABRs along the specified explicit path expand automatically the loose hops, each one computing the strict path segment to the next ABR or tunnel destination.

MPLS TE is configured as usually, with the following change:
  • You have to use loose next-hops on the TE Tunnels towards the ABRs

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng path-option 1 explicit name EXPPATH
!
ip explicit-path name EXPPATH enable
 next-address loose 2.2.2.2
 next-address loose 3.3.3.3


IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 4.4.4.4
 path-option 1 explicit name EXPPATH
!
explicit-path name EXPPATH
 index 1 next-address loose ipv4 unicast 2.2.2.2
 index 2 next-address loose ipv4 unicast 3.3.3.3


Specifying the tunnel tail-end in a loosely routed path is optional. You need to define only the ABRs as next-address loose and each ABR will automatically find the strict next-address for the next ABR or for the final destination.

You can use "debug mpls traffic-eng path" and "debug mpls traffic-eng tunnels" debugs on the head-end and the ABRs to troubleshoot any issues.

IOS
R1#debug mpls traffic-eng path ?
  <0-65535>  Show debug output for this tunnel only
  api        Path calculation API events
  dump       Path calculation detail info
  errors     Path calculation errors events
  lookup     Path calculation lookup events
  spf        Path calculation SPF events
  verify     Path calculation verify events

R1#debug mpls traffic-eng tunnels ?
  auto-bw          MPLS Traffic Engineering tunnel auto-bw
  errors           MPLS Traffic Engineering tunnel errors
  events           MPLS Traffic Engineering tunnel system events
  fast-reroute     MPLS Traffic Engineering tunnel fast reroute
  labels           MPLS Traffic Engineering tunnel labels
  path-protection  MPLS Traffic Engineering tunnel path protection
  reoptimize       MPLS Traffic Engineering tunnel reoptimization
  signalling       MPLS Traffic Engineering tunnel signalling
  state            MPLS Traffic Engineering tunnel state machine
  timers           MPLS Traffic Engineering tunnel timers


As an alternative for an inter-area tunnel crossing different areas, you could configure a sequence of intra-area tunnels, each one crossing one of the areas between source and destination routers, in such a way that the traffic arriving on one tunnel is forwarded into the next tunnel and so on.


OSPF

  • An ABR has visibility into the TE topology of all areas where it's attached to.
  • An area 0 router has visibility into the TE topology of area 0 only.
  • An non-transit area router has visibility into the TE topology of that area only.

Always keep in mind that first you have to enable MPLS TE for all interested areas.

You can use the following abbreviations when filtering the output in order to quickly verify the OSPF area & TE topology per router. Just compare the number of nodes and links on the output vs the ones on the diagram.

IOS
R3#sh mpls traffic-eng top | i TE Id
IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node  (ospf 1  area 1)
IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node  (ospf 1  area 1)
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 0)
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 1)
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 0)
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 1)
IGP Id: 5.5.5.5, MPLS TE Id:5.5.5.5 Router Node  (ospf 1  area 0)
IGP Id: 6.6.6.6, MPLS TE Id:6.6.6.6 Router Node  (ospf 1  area 0)

R1#sh mpls traffic-eng top | i TE Id|Address
IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node  (ospf 1  area 1)
          frag_id 1, Intf Address:10.1.2.1
IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node  (ospf 1  area 1)
          frag_id 9, Intf Address:20.2.3.2
          frag_id 10, Intf Address:20.2.4.2
          frag_id 2, Intf Address:10.1.2.2
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 1)
          frag_id 5, Intf Address:20.2.3.3
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 1)
          frag_id 5, Intf Address:20.2.4.4



ISIS

In case of ISIS & MPLS TE, the L1/L2 router is considered as the ABR.
  • A L1 router has visibility into the TE topology of L1 only
  • A L2 router has visibility into the TE topology of L2 only
  • A L1/L2 router has visibility into the TE topology of both L1/L2 

Always keep in mind that first you have to enable MPLS TE for all interested levels.

You can use the following abbreviations when filtering the output in order to quickly verify the ISIS L1/L2 and TE topology per router. Just compare the number of nodes and links on the output vs the ones on the diagram.

IOS
R5#sh mpls traffic-eng top | i TE Id
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-2)
IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router Node  (isis  level-2)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-2)

R5#sh mpls traffic-eng top | i TE Id|Address
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.2
          frag_id 0, Intf Address:10.0.25.2
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.25.5
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.195.5
          frag_id 0, Intf Address:10.0.205.5
IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.195.19
          frag_id 0, Intf Address:10.19.20.19, Nbr Intf Address:10.19.20.20
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.20
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.205.20
          frag_id 0, Intf Address:10.19.20.20, Nbr Intf Address:10.19.20.19


IOS-XR
R2#sh mpls traffic-eng topology | i TE Id
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)

R2#sh mpls traffic-eng topology | i TE Id|Address
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.2
          frag_id 0, Intf Address:10.0.25.2
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.25.5
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.20, Nbr Intf Address:10.0.220.2


Links


Inter-AS MPLS TE

Inter-AS MPLS TE Tunnels are not supported by the default configuration. A loosely routed explicit path must be defined for the tunnel LSP that identifies each ASBR the LSP should traverse using the "next-address loose" command. The head-end router and the ASBRs along the specified explicit path expand automatically the loose hops, each one computing the strict path segment to the next ASBR or tunnel destination.

MPLS TE is configured as usually, with the following two changes:
  • You have to use loose next-hops on the TE Tunnels
  • You have to define some manual TE parameters on the ASBRs for their neighbors
ASBR Forced Link Flooding is the process that allows links to be installed (as point-to-point) into the TE database, although no IGP is running on them. In order to activate that functionality you just need to configure a link as passive for MPLS TE and provide the neighbor's TE-Id and ip address.

  • OSPF
    • uses opaque LSAs (Type 10) containing a single link TLV
    • only information about the link that has changed is flooded
  • IS-IS
    • uses Type 22 TLVs
    • information about all links on a node is flooded

There is no need for full communication (i.e. eBGP, static) to exist between the AS for an Inter-AS LSP to become functional, unless a backup LSP is required too.


Head-end

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 9.9.9.9
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5-EXPPATH
!
ip explicit-path name R4-R5-EXPPATH enable
 next-address loose R4
 next-address loose R5

IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 9.9.9.9
 path-option 1 explicit name R4-R5-EXPPATH
!
explicit-path name R4-R5-EXPPATH
 index 1 next-address loose ipv4 unicast R4
 index 2 next-address loose ipv4 unicast R%



ASBR #1

IOS
interface FastEthernet0/0
 ip address 10.4.5.4 255.255.255.0
 mpls traffic-eng tunnels
 mpls traffic-eng passive-interface nbr-te-id 5.5.5.5 nbr-if-addr 10.4.5.5
 ip rsvp bandwidth

IOS-XR
PCE or verbatim option required


ASBR#2

IOS
interface FastEthernet0/0
 ip address 10.4.5.5 255.255.255.0
 mpls traffic-eng tunnels
 mpls traffic-eng passive-interface nbr-te-id 4.4.4.4 nbr-if-addr 10.4.5.4
 ip rsvp bandwidth

IOS-XR
PCE or verbatim option required


Don't forget to enable "mpls traffic-eng tunnels" and "ip rsvp bandwidth" under the inter-as interfaces, like in intra-as MPLS TE scenarios.

You cannot configure IGP enabled interfaces as MPLS-TE passive interfaces.

You can configure multiple passive neighbors under the same interface. If there are multiple neighbors and the AS use different IGPs, then you need to also use the "nbr-igp-id" keyword.

The TE topology should include all MPLS TE enabled interfaces and for the inter-as links the nbr-te-id should be shown as "Nbr Intf Address", like in all p2p links.

IOS
R1#sh mpls traffic-eng topology | i Address
...
          frag_id 0, Intf Address:10.2.4.4
          frag_id 0, Intf Address:10.3.4.4
          frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5


The IGP metrics are set to max (shown as "invalid" for ISIS and "MaxLinkMetric" for OSPF), because these routes aren't into RIB, but only into MPLS TE.

IOS sets the TE metric the same as the IGP metric, IOS-XR doesn't.

Configure a TE metric if you want to enable reoptimization for this tunnel.

IOS
R9#sh mpls traffic-eng top | i Addr|metric
...
          frag_id 7, Intf Address:10.5.6.6
          TE metric:1, IGP metric:1, attribute flags:0x0
          frag_id 6, Intf Address:10.4.5.5, Nbr Intf Address:4.4.4.4
          TE metric:invalid, IGP metric:invalid, attribute flags:0x0

R1#sh mpls traffic-eng top | i Addr|metric
...
          frag_id 0, Intf Address:10.3.4.4
          TE metric:10, IGP metric:10, attribute flags:0x0
          frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5
          TE metric:MaxLinkMetric, IGP metric:MaxLinkMetric, attribute flags:0x0



Use "sh ip ospf database opaque-area" and "sh isis database verbose" to view the IGP details about the MPLS TE passive links.

You can also use the following commands on the ASBRs to verify the inter-as link.

IOS
R4#show mpls traffic-eng link-management igp-neighbors
...
Link ID::  Fa0/0.45
    Neighbor ID:  5-5-5-5-0-0-0 (force, non-igp IP: 20.4.5.5)
                  up, Sources: Passive
...
Link ID::  Fa0/0.24
    Neighbor ID:  0000.0000.0004.01 (area: isis  level-2, IP: 0.0.0.0)
                  up, Sources: IGP


R4#show mpls traffic-eng link-management advertisements | i Address
    Link IP Address:      20.3.4.4
    Link IP Address:      20.4.5.4
    Link IP Address:      20.4.6.4
    Link IP Address:      20.2.4.4


When viewing the Explicit Route (under the RSVP Path information) of an Inter-AS TE tunnel, loose hops that belong to other AS will be shown with a "*" next to them.

IOS
R1#sh mpls traffic-eng tunnels
...
    RSVP Path Info:
      My Address: 10.1.2.1
      Explicit Route: 10.1.2.2 20.2.3.2 20.2.3.3 3.3.3.3
                      6.6.6.6*


FRR & backup tunnels

Local protection within a domain operates like intra-domain in the Inter-AS LSPs.

When using FRR on the primary Inter-AS tunnel and an Inter-AS backup tunnel for ASBR link/node protection:
  • The explicit path of the backup tunnel must also use loose hops
  • The backup tunnel destination must be included in the RRO of the primary tunnel
  • You need to somehow (i.e. eBGP, static) create a route on the MP router (and all other intra-as routers towards the ASBR) for the backup tunnel's egress ip address, so the RESV messages can be sent from the MP (tail-end of the backup tunnel in one domain) to the PLR (head-end of the backup tunnel in the other domain)

When you're having ip connectivity issues, it might be good practice to enable "debug ip icmp" and watch out for "host unreachable" messages.


Links


MPLS DiffServ-TE

DiffServ-TE allows bandwidth reservations on a per-class basis.

8 Class Types: CT0 - CT7 (CT0 and CT1 are currently used)

These 8 CTs can be combined with the 8 setup/hold priorities creating 64 possible combinations (called TE classes), from where only 8 are actually used (TE0 - TE7). All routers in a network must have a consistent configuration of all the TE classes.


IOS
mpls traffic-eng ds-te te-classes
 te-class 0 class-type 0 priority 0
 te-class 1 class-type 1 priority 7

IOS-XR
mpls traffic-eng
 ds-te te-classes
  te-class 0 class-type 0 priority 0
  te-class 1 class-type 1 priority 7


CT0 is usually used for best effort or pre-DE-TE LSPs and is implicitly signaled
CT1 is usually used for special classes like voice and video and is explicitly signaled

Usually CTs map to scheduler queues for the appropriate QoS actions.

CSPF is enhanced to handle per-CT reservation requirements
IGP is enhanced to carry per-CT available bandwidth at different priorities
RSVP is enhanced to carry a new Class Type Object (CTO) in the PATH message


Bandwidth Constraint Models

BC (Bandwidth Constraint) = the percentage of a link's bandwidth that a CT can use

BC0 = global pool (for best-effort & DiffServ traffic)
BC1 = sub-pool (for strict bandwidth guarantee traffic)

The BC model determines the available bandwidth for each CT at each priority.

Two BC models:
  • MAM (Maximum Allocation Model)
    • RFC 4125
    • the link bandwidth is divided among the different CTs
    • it completely isolates the different CTs
    • different priorities on different CTs do not have any effect
    • bandwidth is wasted due to not being able to share unused bandwidth between CTs
  • RDM (Russian Dolls Model)
    • RFC 4127
    • CTs can share bandwidth on a link
    • no isolation between CTs
    • preemption (using priorities) is required to guarantee bandwidth to a CT
    • bandwidth is utilized more efficiently between CTs

RDM is the default BC model, after enabling IETF DS-TE.

IOS
mpls traffic-eng ds-te mode ietf


IOS-XR
mpls traffic-eng
 ds-te mode ietf

The same mode should be used in all MPLS-TE routers.

IOS
R3#sh mpls traffic-eng top | i BC
BC Model Id: RDM
          BC Model Id: RDM
          BC0 (max_reservable): 75000 (kbps)
          BC0 (max_reservable_bw_global): 0 (kbps)
          BC1 (max_reservable_bw_sub): 0 (kbps)

IOS-XR
GSR#sh mpls traffic top | i BC
My_BC_Model_Type: RDM
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)



Configuration Steps
  • sub-pool (BC1) tunnel
    • choose a specific PHB for classifying the strict guarantee traffic
    • limit the traffic before it enters the tunnel in order to avoid oversubscription
    • mark the traffic with the right EXP while entering the tunnel
    • map the EXP into the appropriate queue at each outgoing interface of every tunnel hop
    • reserve the right percentage of the total sub-pool bandwidth on each outgoing link
  • global pool (BC0) tunnel
    • choose a specific PHB for each class
    • mark each class with the right EXP while entering the tunnel
    • map each EXP into the appropriate queue at each outgoing interface of every tunnel hop
    • reserve the right percentage of the total global pool bandwidth on each outgoing link

IOS
interface Tunnel1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 6.6.6.6
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth sub-pool 444
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5
!
interface FastEthernet0/0
 mpls traffic-eng tunnels
 ip rsvp bandwidth 99999 sub-pool 9999


After switching to IETF DS-TE the above configuration becomes:

IOS
interface Tunnel1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 6.6.6.6
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth 444 class-type 1
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5
!
interface FastEthernet0/0
 mpls traffic-eng tunnels
 ip rsvp bandwidth rdm bc0 99999 bc1 9999


IOS-XR supports either sub-pool or class-type configuration by default.


Links


P2MP LSPs

  • One ingress router
  • Many egress routers
  • Replication (one=>many) happens at branch routers (ingress router can be a branch router too)
  • The path of the P2MP LSP is determined by the branch routers
  • All sub-LSPs of the same P2MP LSP employ the same constraints/policies
  • Traffic is unidirectional, like in P2P LSPs
Two options in control plane:
  • LDP
    • no TE support
    • LSP is initiated by the egress routers
    • Egress routers advertise each one a label for the P2MP FEC towards the branch router
    • Branch routers advertise a single label for the P2MP FEC (for multiple received labels from egress routers) toward the ingress router
    • Ingress routers need to keep state only for the directly connected routers
  • RSVP
    • TE support
    • LSP is initiated by the ingress router
    • Sub-LSPs (like normal LSPs) are created from the ingress router towards each egress router
    • Each sub-LSP has its own PATH/RESV messages, which contain the P2MP Session Object (so that all intermediate routers know the parent LSP where these sub-LSPs belong to)
    • Ingress router sends a PATH message (hop-by-hop) to each egress router (towards the branch router)
    • Branch routers send multiple PATH messages (one for each sub-LSP) towards the multiple egress routers
    • Egress routers receive the PATH messages and each one sends a RESV message towards the branch router
    • Branch routers receive multiple RESV messages (one for each sub-LSP) from each egress router (of a different branch), each one with a different label
    • Branch routers send multiple RESV messages (one for each sub-LSP) towards the ingress router, each one with the same label (since they belong to the same parent P2MP LSP).
    • Ingress router receives multiple RESV messages with the same label from each branch router
    • Ingress routers need to keep state for all egress routers (due to sub-LSPs)


P2MP TE

Limitations
  • Inter-area and inter-as topologies are not supported, only intra-as
  • Node and path protection are not supported, only link protection
  • PIM Sparse is not supported, only SSM
  • Many OAM features are not supported
  • Multiple path-options per destination are not supported, one one path-option per destination
  • PHP is not supported on the tail-end, explicit-null or a normal label must be used
  • Only one backup auto-tunnel is created, to be used for link-protection

Multicast
  • Head-end router and tail-end routers exchange PIM messages with the locally attached CEs
  • MPLS core doesn't need to run PIM
  • PIM doesn't need to be enabled across the MPLS TE tunnel

You can use dynamic paths or explicit paths. If you configure expicit paths that lead to multiple sub-LSPs entering a middle router through different interfaces but exiting through a common interface, then the sub-LSP won't be established (remerge event).

The following apply to all sub-LSPs of the same P2MP LSP:
  • andwidth parameters 
  • hold/setup priorities
  • administrative weight
  • attributes/affinity

Because a sub-LSP cannot be represented as a regular interface on the tail-end router, a special LSP virtual interface (LSPVIF) is automatically created. The LSPVIF represents the originating interface for all IP multicast traffic arriving to the P2MP TE tail-end router. This LSPVIF interface is used for the RPF check.

MPLS-TE should be configured and working between all routers being involved in the P2MP LSPs.


head-end (IOS)
ip multicast-routing
!
ip pim ssm default
!
interface Tunnel0
 ip unnumbered Loopback0
 ip pim passive
 ip igmp static-group 232.20.20.20 source 7.7.7.7
 ip igmp static-group 232.19.19.19 source 7.7.7.7
 ip igmp static-group 232.8.8.8 source 7.7.7.7
 ip igmp static-group 232.2.2.2 source 7.7.7.7
 tunnel mode mpls traffic-eng point-to-multipoint
 tunnel destination list mpls traffic-eng name TAIL-END-ACL
!
mpls traffic-eng destination list name TAIL-END-ACL
 ip 2.2.2.2 path-option 1 dynamic
 ip 19.19.19.19 path-option 1 dynamic
 ip 20.20.20.20 path-option 1 dynamic

For every multicast group you'll need a static igmp under the TE tunnel.

Path-option per sub-LSP can be either dynamic or explicit.


mid-point (IOS)
just normal MPLE-TE config, no multicast required
support of signaling extensions is required 


tail-end (IOS)
ip multicast-routing
ip multicast mpls traffic-eng
!
ip pim ssm default
!
ip mroute 7.7.7.7 255.255.255.255 1.1.1.1

In order to avoid failing on the RPF check on the tail-end router, you must configure a static mroute for the multicast source pointing to the head-end router.


In IOS-XR, the interface "tunnel-mte" is used for P2MP LSPs.

head-end (IOS-XR)
multicast-routing
 address-family ipv4
  interface tunnel-mte0
   enable
!
router igmp
 interface tunnel-mte0
  static-group 232.2.2.2 7.7.7.7
  static-group 232.8.8.8 7.7.7.7
  static-group 232.19.19.19 7.7.7.7
  static-group 232.20.20.20 7.7.7.7
!
interface tunnel-mte0
 ipv4 unnumbered Loopback0
 destination 1.1.1.1
  path-option 1 dynamic
 !
 destination 2.2.2.2
  path-option 1 dynamic
 !
 destination 19.19.19.19
  path-option 1 dynamic


mid-point (IOS-XR)
just normal MPLE-TE config, no multicast required
support of signaling extensions is required


tail-end (IOS-XR)
multicast-routing
 address-family ipv4
  core-tree-protocol rsvp-te
  static-rpf 7.7.7.7 32 mpls 1.1.1.1


IOS-XR 4.2 is required for P2MP LSPs. IOS-XR on C12k doesn't support P2MP LSPs.

IOS-XR doesn't support pings on loopbacks belonging to VRFs under a mVPN topology. Use a physical interface instead.

"multicast-intact" might be required if P2MP and P2P LSPs are created between two nodes.

For P2MP TE FRR protection, the "ip routing protocol purge interface" command is recommended on every penultimate hop router. Otherwise, the traffic can be lost for a few seconds during a FRR cutover event.  
It is assumed that all routers outside the MPLS-TE core are using multicast as usual. So the head-end is having a normal PIM connectivity to the source and the tail-ends are having normal PIM connectivity to the receivers.

Verification

Keep all possible loggings enabled in order to aid in troubleshooting.

IOS
mpls traffic-eng logging lsp path-errors
mpls traffic-eng logging lsp reservation-errors
mpls traffic-eng logging lsp preemption
mpls traffic-eng logging lsp setups
mpls traffic-eng logging lsp teardowns
mpls traffic-eng logging tunnel path change

When the tail-end router creates the LSPVIF interface, you'll get the following log:

%MPLS_TE-5-LSP: Sub-LSP 1.1.1.1[1:3]->2.2.2.2_0: UP
%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up


head-end (IOS)
R1#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

Tunnel0     (p2mp),  Admin: up, Oper: up
  Name: R1_t0

  Tunnel0 Destinations Information:

    Destination     State SLSP UpTime
    2.2.2.2         Up    01:47:12
    19.19.19.19     Up    01:47:28
    20.20.20.20     Up    01:48:35

    Summary: Destinations: 3 [Up: 3, Proceeding: 0, Down: 0 ]
      [destination list name: TAIL-TE-ACL]

  History:
    Tunnel:
      Time since created: 1 hours, 51 minutes
      Time since path change: 1 hours, 48 minutes
      Number of LSP IDs (Tun_Instances) used: 1
    Current LSP: [ID: 1]
      Uptime: 1 hours, 48 minutes

  Tunnel0 LSP Information:
    Configured LSP Parameters:
      Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
      Metric Type: TE (default)

  Session Information
    Source: 1.1.1.1, TunID: 0

    LSPs
      ID: 1 (Current), Path-Set ID: 0xA2000001
        Sub-LSPs: 3, Up: 3, Proceeding: 0, Down: 0

      Total LSPs: 1

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.4.4 12.4.20.20 20.20.20.20
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.6.19.19
                    19.19.19.19
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.2.6.2
                    2.2.2.2
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE


head-end (IOS)
R1#show mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    Passive LSP Listener:           running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3463 seconds
    Periodic FRR Promotion:         Not Running
    Periodic auto-bw collection:    every 300 seconds, next in 163 seconds

P2P TUNNELS/LSPs:
Displayed 0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tails

P2MP TUNNELS:
                         DEST        CURRENT
INTERFACE   STATE/PROT  UP/CFG     TUNID  LSPID
Tunnel0     up/up       3/3        0      1
Displayed 1 (of 1) P2MP heads

P2MP SUB-LSPS:
SOURCE        TUNID  LSPID  DESTINATION   SUBID  STATE UP IF      DOWN IF
1.1.1.1       0      1      20.20.20.20   1      Up    head       Fa0/0.13
1.1.1.1       0      1      19.19.19.19   2      Up    head       Fa0/0.13
1.1.1.1       0      1      2.2.2.2       3      Up    head       Fa0/0.13
Displayed 3 P2MP sub-LSPs:
          3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails



head-end (IOS)
R1#show mpls traffic-eng forwarding path-set brief
Sub-LSP Identifier
src_lspid[subid]->dst_tunid              InLabel Next Hop      I/F    PSID
---------------------------              ------- ------------- ------ ----
1.1.1.1_1[1]->20.20.20.20_0              none    12.1.3.3      Fa0/0. A2000001
1.1.1.1_1[2]->19.19.19.19_0              none    12.1.3.3      Fa0/0. A2000001
1.1.1.1_1[3]->2.2.2.2_0                  none    12.1.3.3      Fa0/0. A2000001


head-end (IOS)
R1#show mpls traffic-eng forwarding path-set detail

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 20.20.20.20, P2MP Subgroup ID: 1
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 19.19.19.19, P2MP Subgroup ID: 2
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 2.2.2.2, P2MP Subgroup ID: 3
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3

The same commands can also be used on all the intermediate routers.


head-end (IOS)
R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.20.20.20), 01:03:22/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:03:22/00:02:59

(7.7.7.7, 232.2.2.2), 01:17:17/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:17/00:02:59

(7.7.7.7, 232.19.19.19), 01:17:11/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:11/00:02:59

(7.7.7.7, 232.8.8.8), 01:17:27/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:27/00:02:59


mid-point (IOS)
R3#sh mpls forwarding-table | i 1.1.1.1|Prefix
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
23         Pop Label  1.1.1.1/32       41241         Fa0/0.13   12.1.3.1
29         29         1.1.1.1 0 [1]    2684          Fa0/0.34   12.3.4.4
           16         1.1.1.1 0 [1]    2684          Fa0/0.35   12.3.5.5

On every mid-point router you should see more than one label for the same TE LSP, each one pointing to a different outgoing interface.

mid-point (IOS)
R3#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.34, 29
    Next Hop : 12.3.4.4
    Explicit Route: 12.3.4.4 12.4.20.20 20.20.20.20
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.35, 16
    Next Hop : 12.3.5.5
    Explicit Route: 12.3.5.5 12.5.6.6 12.6.19.19 19.19.19.19
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.35, 16
    Next Hop : 12.3.5.5
    Explicit Route: 12.3.5.5 12.5.6.6 12.2.6.2 2.2.2.2
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

Sub-LSPs following the same branch (egress interface) will use the same label.


tail-end (IOS)
R2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.2.2.2), 00:28:39/stopped, flags: sLTI
  Incoming interface: Lspvif0, RPF nbr 1.1.1.1, Mroute
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 00:28:39/00:01:20


tail-end (IOS)
R2#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: tail
    Path-Set ID: 0x40000001
    InLabel  : FastEthernet0/0.26, 33
    Prev Hop : 12.2.6.6
    OutLabel :  -
    Explicit Route:  NONE
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE


Links



Posted by at
Labels: , , , , , , , , ,

1 comment:

  1. Mohamed23 August, 2019 21:34

    Which IOS XR Software feature supports establishing point-to-point and point-to-multipoint TE
    tunnels traversing multiple IGP areas and levels allowing headend and tailend routers to reside in
    different areas?

    ReplyDelete

Subscribe to: Post Comments (Atom)