NTS: RSVP/MPLS-TE

RSVP/MPLS-TE

MPLS-TE (MPLS Traffic Engineering) Requirements are described in RFC 2702.
RSVP (Resource Reservation Protocol) is defined in RFC 2205.
RSVP-TE (RSVP Traffic Engineering extension) is defined in RFC 3209.
OSPFv2 extensions for TE are defined in RFC 3630.
OSPFv3 extensions for TE are defined in RFC 5329.
ISIS extensions for TE are defined in RFC 5305.

RSVP

RSVP messages are sent hop-by-hop between RSVP-enabled routers as "raw" IP packets with protocol number 46.

Two main messages:

PATH

sent with the same source and destination addresses as the actual data (i.e. tunnel src/dst), in order to be routed correctly even through non-RSVP routers
objects

Label Request Object
Explicit Route Object (ERO)
Record Route Object (RRO)
Session Attribute Object (SAO)
Sender TSpec

RESV

sent hop-by-hop by having each RSVP router forward a RESV message to the previous RSVP hop (learned by the PATH message)
objects

Label Object
Record Route Object (RRO)

Each RESV message follows the exact reverse path of the initial PATH message

As a general case (but not applicable to MPLS-TE), if the PATH message arrives at a router that does not understand RSVP, that router should forward the message as a normal packet without interpreting the contents of the message and will not reserve resources for the flow.

Assume the following network:

R1-R2-R3-R4

where an MPLS-TE tunnel is going to be built from R1 to R4.

Then the following actions will happen when an RSVP reservation is asked:

checks reservation attributes
sends PATH message with src/dst R1/R4 to next-hop (R2)

receives PATH message with src/dst R1/R4 from previous-hop (R1)
checks reservation attributes
sends PATH message with src/dst R1/R4 to next-hop (R3)

receives PATH message with src/dst R1/R4 from previous-hop (R2)
checks reservation attributes
sends PATH message with src/dst R1/R4 to next-hop (R4)

receives PATH message with src/dst R1/R4 from previous-hop (R3)
checks reservation attributes
makes the reservation
sends RESV message with src/dst R4/R3 to previous-hop (R3)

receives RESV message with src/dst R4/R3 from R4
sends RESV message with src/dst R3/R2 to previous-hop (R2)

receives RESV message with src/dst R3/R2 from R3
sends RESV message with src/dst R2/R1 to previous-hop (R1)

receives RESV message with src/dst R2/R1 from R2
creates the tunnel (up/up)

In case of MPLS-TE, one reservation attribute could be the transport label required in order to build the LSP tunnel.

Labels are allocated downstream (R1=>R4) using PATH messages and propagated upstream (R4=>R1) using RESV messages.

tunnel head-end = RSVP sender
tunnel tail-end = RSVP receiver

The request to bind labels to a specific LSP tunnel is initiated by the tunnel ingress node (known as RSVP sender) using a PATH message.

The reply to this label allocation PATH message is sent from the egress node (known as RSVP receiver) back upstream towards the sender using a RESV message, following the path state across all nodes created by the initial PATH message in reverse order.

Each intermediate node that receives a RESV message containing a label, uses that label for outgoing traffic associated with this specific LSP tunnel. If the node is not the sender, it allocates a new label and places that new label into a new RESV message which it sends upstream to the previous-hop, until it reaches the sender and a complete LSP is built.

When using "sh ip rsvp int" to verify the rsvp bandwidth on an interface, all rsvp enabled interfaces are shown, even the ones that are shut down.

RSVP hellos are not enabled by default, since they are not needed for normal MPLS TE operation.

RSVP & Fast Failure Detection

When RSVP signals a TE LSP and there is a failure somewhere along the path, the failure can remain undetected for as long as two minutes (timeout of RSVP session).

Two solutions can be used for triggering fast detection in case of a failure:

RSVP hellos
BFD

RSVP hellos

IOS
ip rsvp signalling hello
!
interface X
ip rsvp signalling hello

IOS-XR
not supported

IOS-XR supports only BFD for fast detection (< 1sec). RSVP hellos can be used for simple reroute (detection > 10sec) or GR.

The same type of "rsvp signalling hello" must be configured on the other side too for fast detection to take place.

IOS
R4#sh ip rsvp hello
Hello:
RSVP Hello for Fast-Reroute/Reroute: Enabled
    Statistics: Disabled
BFD for Fast-Reroute/Reroute: Disabled
RSVP Hello for Graceful Restart: Disabled

R4#sh ip rsvp hello client lsp sum
Local           Remote          tun_id lsp_id subgrp_orig     subgrp_id FLAGS
2.2.2.2         19.19.19.19     0      46     0.0.0.0         0         0x24

R4#sh ip rsvp hello client lsp det
Hello Client LSPs (all lsp tree)

Tun Dest:   19.19.19.19 Tun ID: 0 Ext Tun ID: 2.2.2.2
Tun Sender: 2.2.2.2 LSP ID: 46
    Lsp flags: 0x24
    Lsp RR DN nbr: 20.4.5.5 FRR

R4#sh ip rsvp hello client nbr
Local           Remote          Type    NBR_STATE    HI_STATE    LSPs
20.4.5.4        20.4.5.5        RR      Normal       Up             1

R4#sh ip rsvp hello client nbr det
Hello Client Neighbors

        Remote addr 20.4.5.5,    Local addr 20.4.5.4
    Nbr State: Normal    Type: Reroute
    Nbr Hello State: Up
    LSPs protecting: 1
    I/F: Fa0/0.45

In IOS, there are 3 different commands to set the hello refresh interval:

ip rsvp signalling hello refresh interval xxx

refresh interval: 10-30000 ms

ip rsvp signalling hello fast-reroute refresh interval xxx

refresh interval: 10-30000 ms

ip rsvp signalling hello reroute refresh interval xxx

refresh interval: 1000-30000 ms

The first two ones are the same and are the ones that actually enable/configure FRR. The number of refresh misses is configured likewise.

BFD

Check "BFD" for more information.

In both cases in IOS, RSVP hellos must be configured both globally on the router and on the specific interface in order to be operational.

MPLS-TE Configuration

enable MPLS-TE globally
enable MPLS-TE & RSVP under each interested interface
enable MPLS-TE extensions under the IGP
create the MPLS-TE tunnel

Minimum configuration includes the following:

IOS
! global
mpls traffic-eng tunnels

! per interface
interface X
mpls traffic-eng tunnels
ip rsvp bandwidth

! per IGP
router isis X
metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level x
!
router ospf X
mpls traffic-eng router-id Loopback0
mpls traffic-eng area x

! per tunnel
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination x.x.x.x
tunnel mpls traffic-eng path-option 1 dynamic

IOS-XR
! global
mpls ldp

! per interface
rsvp
interface X
!
mpls traffic-eng
interface X

! per IGP
router ospf X
area 0
mpls traffic-eng
mpls traffic-eng router-id Loopback0
!
router isis X
address-family ipv4 unicast
metric-style wide
mpls traffic-eng level x
mpls traffic-eng router-id Loopback0

! per tunnel
interface tunnel-te0
ipv4 unnumbered Loopback0
destination x.x.x.x
path-option 1 dynamic

Is IOS-XR you must also enable MPLS LDP (even when LDP is not going to be used), otherwise data-plane won't work and you'll see unresolved CEF entries.

If you don't set the router-id under the IGP, you won't be able to create any TE paths for the tunnels.

You have to configure "ip rsvp bandwidth" in order to set the reserved bandwidth per interface (tunnels can work without setting it, as long as their required bandwidth is 0).

Default bandwidth is 75% in IOS and 0 in IOS-XR (IOS-XR doesn't support the setting of bandwidth as a percentage).

You won't see the RSVP bandwidth of an interface as allocated, unless the tunnel that passes through it is fully operational.

RSVP bandwidth is reserved only on the egress interface of a router (based on the direction of the tunnel).

Don't forget to enable wide metrics if using IS-IS (IOS gives you a warning).

In IOS-XR every tunnel type has a specific interface name. For MPLS-TE tunnels, the name "tunne-te" is used.

Each TE tunnel is unidirectional, so if you want to make it behave like bidirectional, then you need to configure a reverse tunnel from the tail-end to the head-end too. Only "ip unnumbered" should be used in TE tunnels due to their unidirectional nature.

Most tunnel changes require to shut/no shut the tunnel interface in order to have immediate effect.

Setting the (signaled) bandwidth on the tunnel is not necessary for normal operation, but it might help to verify the TE path when checking the RSVP interface bandwidth on the path.

MPLS TE in Cisco software supports only a single IGP process/instance.

For extra logging information, you can configure the following:

IOS
R1(config)#mpls traffic-eng logging lsp ?
path-errors         Log LSP Path Error traps
preemption          Log LSP Preemption traps
reservation-errors Log LSP Reservation Error traps
setups              Log LSP Establishment Traps
teardowns           Log LSP Teardown Traps

R1(config)#mpls traffic-eng logging tunnel ?
lsp-selection Log Tunnel LSP Selection traps
path           Log Tunnel Path-related traps

IOS-XR
C12k(config-if)#logging events ?
link-status Enable interface and line-protocol state change alarms
lsp-status   Enable interface LSP state change alarms

C12k(config-if)#logging events lsp-status ?
insufficient-bandwidth Enable Syslog for setup/reopt failure due to bandwidth
reoptimize              Enable interface LSP REOPT change alarms
reroute                 Enable interface LSP REROUTE change alarms
state                   Enable interface LSP UP/DOWN change alarms
switchover              Enable interface LSP SWITCHOVER change alarms

MPLS-TE Verification

When using MPLS-TE in place of LDP for a L3VPN connection, then the transport label is provided by RSVP.

IOS
R2#sh mpls traffic-eng tunnels tunnel 0 | i Label
InLabel : -
OutLabel : FastEthernet0/0.24, 16

R2#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       16         19.19.19.19/32   0             Tu0        point2point
        MAC/Encaps=18/22, MRU=1500, Label Stack{16}, via Fa0/0.24
        CA0611400000CA0509F00000810000188847 00010000
        No output feature configured

Don't forget to use the complete prefix when checking the LFIB in the PE, otherwise "sh mpls forwarding-table" won't show you anything about it.

The VPN label is still provided by BGP VPNv4.

IOS
R2#sh bgp vpnv4 unicast all 20.20.20.20/32 | i label
      mpls labels in/out nolabel/17

You can also check the labels assigned by RSVP in the intermediate routers and follow the path like in LDP labels.

IOS
R4#sh mpls traffic-eng tunnels | i Label
InLabel : FastEthernet0/0.24, 16
OutLabel : FastEthernet0/0.45, 26

R5#sh mpls traffic-eng tunnels | i Label
InLabel : FastEthernet0/0.45, 26
OutLabel : FastEthernet0/0.519, implicit-null

Keep in mind that "sh mpls forwarding-table" will show you the tunnel source prefix (which originated the RSVP messages) when referring to TE tunnels.

IOS
R4#sh mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         26         2.2.2.2 0 [1]    7658          Fa0/0.45   20.4.5.5

R5#sh mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
26         Pop Label 2.2.2.2 0 [1]    7540          Fa0/0.519 20.5.19.19

The number "0 [1]" after the prefix are the "Tun_Id" and "Tun_instance" found in "sh mpls traffic-eng tunnels" output.

R5#sh mpls traffic-eng tunnels | i Tun
LSP Tunnel R2_t0 is signalled, connection is up
       Src 2.2.2.2, Dst 19.19.19.19, Tun_Id 0, Tun_Instance 1

You can use "clear ip rsvp reservation *" if you want to clear the RSVP label bindings (i.e. after you change the mpls label range).

You can use the following command in order to find the optimal path for a tunnel, based on current resources:

IOS
R2#sh mpls traffic-eng tunnels suboptimal constraints current | b Short
Shortest Availability-Constrained Path Info:
    Path Weight: 30 (TE)
    Explicit Route: 20.2.4.2 20.2.4.4 20.4.5.4 20.4.5.5
                    20.5.19.5 20.5.19.19 19.19.19.19

Other options include:

R2#sh mpls traffic-eng tunnels suboptimal constraints ?
current path lookup constrained by available resources
max      path lookup constrained by network's maximum potential resources
none     path lookup without any constraints

The same info is available if you use the "sh mpls traffic-eng tunnels tunnel X" command, explicitly specifying the tunnel.

An easy way to find the address (and label when using FRR) of each hop, is to enable record-route.

IOS
interface Tunnel0
tunnel mpls traffic-eng record-route

IOS-XR
interface tunnel-te0
record-route

IOS
R2#sh mpls traffic-eng tunnels | b Resv
    RSVP Resv Info:
      Record   Route: 20.3.4.3 20.4.5.4 20.5.19.5 20.5.19.19

Besides various show commands, you can use "debug mpls traffic-eng tunnels" in order to check for any error messages while setting up the tunnel path. Other possible debugs are the following:

R2#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

Some of these debugs are replicated in the RSVP debug commands.

If you enable "debug mpls traffic-eng tunnels signalling detail" and there is an error in RSVP communication somewhere in the path, you'll get the following message, which will guide you to the hop with the problem:

TE-SIG-HE: Tunnel0 [71]->1.1.1.1: received Path Error from 20.2.4.2: Routing Problem: No route available toward destination

Traffic steering & LSP attributes

You can use the following methods in order to steer the tunnel traffic through a specific TE path:

use explicit path-option with specific addresses included/excluded
use dynamic path option and change the interface IGP metric
use dynamic path option and change the interface TE metric (administrative-weight)
use dynamic path option and change the interface RSVP bandwidth or the tunnel bandwidth
use dynamic path option and change the interface/tunnel affinity/attributes
use a combination of explicit path-option and the above attributes

explicit-path

When using explit-paths in order to define the TE path, you can use either loopbacks or next-hop addresses as next-address. Also there is no need to define the last-hop, which is the tail-end. However, it's good practice to define next-hop addresses (plus the last-hop) if you want to be as strict as possible about the path.

i.e. for a path R2-R3-R4-R5-R6-R7 you can simply create the following explicit path on R2:

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

IOS-XR
interface tunnel-te0
ipv4 unnumbered Loopback0
destination 2.2.2.2
path-option 1 explicit name R3-R4-R5-R6
!
explicit-path name R3-R4-R5-R6
index 1 next-address strict ipv4 unicast R3
index 2 next-address strict ipv4 unicast R4
index 3 next-address strict ipv4 unicast R5
index 4 next-address strict ipv4 unicast R6

While editing the explicit-path, you can use "index x" in order to change a specific entry, or "list" to view all current entries.

When checking the output of "sh mpls traffic-eng topology" you can find the exact path (ip addresses from all ingress/egress interfaces) followed under the "Explicit Route" object (ERO).

When using the "exclude-address" option, the path is considered semi-dynamic. It works like a dynamic path (based on IGP), but specific hops are avoided.

bandwidth

You can define the tunnel required/signaled bandwidth and the interface available bandwidth in order to steer the traffic through a path that has enough bandwidth to accommodate the tunnel's need.

This is purely a control-plane reservation, in order to allow the TE tunnels to be established. In order to actually reserve that amount of bandwidth for the TE tunnel traffic, you have to configure the appropriate QoS too.

IOS
interface FastEthernet0/0
mpls traffic-eng tunnels
ip rsvp bandwidth 100000
!
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng bandwidth 99000
tunnel mpls traffic-eng path-option 1 dynamic

IOS-XR
rsvp
interface X
bandwidth 100000
!
interface tunnel-te0
ipv4 unnumbered Loopback0
signalled-bandwidth 99000
destination 2.2.2.2
path-option 1 dynamic

You can use the Path Option for Bandwidth Override in order to provide a fallback path option that allows overriding the bandwidth configured on the TE tunnel (i.e a path option with bandwidth set to 0 removes the bandwidth constraint imposed by the constraint-based routing calculation).

When an LSP is signaled using a path option with a configured bandwidth, the bandwidth associated with the path option is signaled instead of the signaled bandwidth configured directly on the tunnel. You can have multiple path-options with different bandwidth requirements. All path-options should use the same type of bandwidth (global pool or sub-pool), otherwise reoptimization might not occur.

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 19.19.19.19
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 50000
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R6-R5
tunnel mpls traffic-eng path-option 2 dynamic bandwidth 25000
tunnel mpls traffic-eng path-option 3 dynamic bandwidth 0

In the above example, 3 path-options are using 3 different bandwidth requirements:

path-option 1 (explicit) requires 50000 kbps (default)
path-option 2 (dynamic) requires 25000 kbps
path-option 3 (dynamic) requires 0 kbps

With bandwidth override configured on a path option, the traffic engineering software attempts to reoptimize the bandwidth every 30 seconds.

TE metric

You can influence the path that the tunnel will follow by changing the TE metric (administrative-weight) on the physical interfaces along the path.

IOS
interface Χ
mpls traffic-eng tunnels
mpls traffic-eng administrative-weight 2

IOS-XR
mpls traffic-eng
interface Χ
admin-weight 2

Usually it's easier to increase the TE metric on the path that should not be preferred, instead of decreasing the metric on the path that should be preferred.

If TE metric is set to its max under a specific interface, then tunnel will never pass through that interface.

All TE metric changes require to shut/no shut the tunnel interface in order to have immediate effect.

Default TE metric is the IGP metric for that specific path. Whenever IGP metric changes, TE metric follows, unless it's explicitly configured, so it gets priority.

IOS
R1#sh mpls traffic-eng tunnel

P2P TUNNELS/LSPs:

Name: R1_t0                              (Tunnel0) Destination: 2.2.2.2
Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type dynamic (Basis for Setup, path weight 23)

You can change this default path-selection policy (where TE metric is used) using the following command, either globally or under the specific tunnel:

IOS
mpls traffic-eng path-selection metric igp
!
interface Tunnel0
tunnel mpls traffic-eng path-selection metric igp

IOS-XR
mpls traffic-eng
path-selection metric igp
!
interface tunnel-te0
path-selection metric igp

Use the following commands to verify the current metric type:

IOS
R1#sh mpls traffic-eng tunnels | i Metric
    Metric Type: TE (default)
R1#sh mpls traffic-eng tunnels | i Metric
    Metric Type: IGP (interface)

IOS-XR
GSR#sh mpls traffic-eng tunnels | i Metric
    Metric Type: TE (default)

path-options

You can define multiple path-options (as fall-back methods), with preference 1 having the highest priority. The currently active TE path can be found by checking the "sh mpls traffic-eng tunnels" command output.

IOS
interface Tunnel0
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R5-R6
tunnel mpls traffic-eng path-option 2 dynamic

IOS-XR
interface tunnel-te0
path-option 1 explicit name R3-R4-R5-R6
path-option 2 dynamic

IOS
R2#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

Name: R2_t0                               (Tunnel0) Destination: 7.7.7.7
Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 2, type dynamic (Basis for Setup, path weight 40)
    path option 1, type explicit R3-R4-R5-R6
...

You can also use "traceroute mpls traffic-eng" on a PE in order to verify the TE path unidirectionally:

IOS
R2#traceroute mpls traffic-eng tunnel 0
Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
0 26.2.4.2 MRU 1500 [Labels: 22 Exp: 0]
L 1 26.2.4.4 MRU 1500 [Labels: 22 Exp: 0] 76 ms
L 2 26.4.5.5 MRU 1500 [Labels: 21 Exp: 0] 80 ms
L 3 26.5.6.6 MRU 1500 [Labels: 22 Exp: 0] 104 ms
L 4 26.3.6.3 MRU 1504 [Labels: implicit-null Exp: 0] 112 ms
! 5 26.3.19.19 140 ms

IOS-XR
GSR#traceroute mpls traffic-eng tunnel 0

Tracing MPLS TE Label Switched Path on tunnel-te0, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 2.2.78.8 MRU 1500 [Labels: 22 Exp: 0]
L 1 2.2.78.7 MRU 1500 [Labels: 23 Exp: 0] 41 ms
L 2 2.2.27.2 MRU 1504 [Labels: implicit-null Exp: 0] 126 ms
! 3 2.2.29.9 9 ms

MPLS traceroute in IOS-XR requires "mpls oam" to be enabled.

setup/hold priorities

Every LSP/tunnel has a setup and a hold priority, each one having values from 0 (best) to 7 (worst).

setup priority

used when the LSP is being established

hold priority

used when the LSP is already established

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng path-option 1 dynamic

IOS-XR
interface tunnel-te0
ipv4 unnumbered Loopback0
priority 4 4
destination 2.2.2.2
path-option 1 dynamic

Preemption
When an LSP is set up across a path where resources have been exhausted, its setup priority is compared to the hold priority of all the LSPs already using the resources, in order to determine if the new LSP can preempt an existing LSP and use its resources.

Do not use a hold priority that is worse than the setup priority, otherwise you might end up with continuous preemption (the software will probably prohibit you from doing so).

Using a high hold priority is recommended for stable environments.

When having primary and backup tunnels, it's good practice to assign better priorities to primary tunnels.

IOS-XR supports soft-preemption, which tries to preempt tunnels with the least possible disruption. You have to enable it under the tunnel and on every node.

LSP attributes

It provides the ability to configure values for several LSP-specific path-options for TE tunnels. One or more TE tunnels can specify specific path-options by referencing an LSP attribute list. You can configure LSP attributes lists with different sets of attributes for each path-option

Attributes that can be used:

affinity (IOS, IOS-XR)
auto-bw (IOS)
bandwidth (IOS, IOS-XR)
lockdown (IOS)
priority (IOS)
protection (IOS)
record-route (IOS)

LSP attribute list values referenced by the path-option take precedence over the values configured on the tunnel interface.

IOS
mpls traffic-eng lsp attributes LSP-ATTR-1
bandwidth 22222
priority 6 6
!
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 19.19.19.19
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 50000
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R6-R5 attributes LSP-ATTR-1

IOS-XR
mpls traffic-eng
attribute-set path-option LSP-ATTR-1
signalled-bandwidth 22222
!
interface tunnel-te0
ipv4 unnumbered Loopback0
signalled-bandwidth 50000
destination 2.2.2.2
path-option 1 dynamic attribute-set LSP-ATTR-1

IOS
R2#sh mpls traffic-eng lsp attributes
LIST LSP-ATTR-1
    bandwidth 22222
    priority 6 6

R2#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

Name: R2_t0                               (Tunnel0) Destination: 19.19.19.19
Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type explicit R3-R4-R6-R5 (Basis for Setup, path weight 50)

Config Parameters:
    Bandwidth: 22222    kbps (Global) Priority: 6 6   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute announce: enabled LockDown: disabled Loadshare: 22222    bw-based
    auto-bw: disabled
...

If when applying the LSP attributes to a path-option you get a warning like "% Setup priority is inconsistent with popt x", then you have to check the x path-option for a possible inconsistency.

TE LSP reoptimization

Tunnel reoptimization is the signaling of an new LSP that is more optimal (i.e. with a lower metric) than the current LSP a TE tunnel is using and the switching over of the tunnel's data to use this new LSP.

The new more optimal TE LSP is always established and the data moved onto it before the original LSP is torn down (using RSVP shared explicit reservation style), in order to ensure that no data packets are lost during the transition to the new LSP.

The TE LSPs reoptimization process is triggered under the following circumstances:

periodically (based on a timer)
manually (using the command "mpls traffic-eng reoptimize")
after a network event (i.e. link-up)

Regardless of how reoptimization is triggered, the head-end router reoptimizes a tunnel only if it can find a better path than the one the tunnel currently uses. If there is no better path in the TE database (topology), then no new LSP is signaled and reoptimization does not occur.

You can use the "lockdown" keyword with any tunnel path-option if you want to disable reoptimization for a specific path-option of a tunnel.

Links

IETF - RFC 4736

TE Tunnels for VPN

There is no need to have a single end-to-end LSP tunnel between two PEs. You can have:

multiple TE tunnels (one after the other) between the PEs, using "stitching" on the intermediate P routers
a combination of TE tunnels plus LDP sessions

When doing PE-to-P TE tunnels you must be careful of the PHP happening one hop before the P, exposing the bottom VPN label to it. One solution is to create an extra layer of labels between the PE and the P (using a tLDP session across the tunnel) in order to avoid exposing the VPN label and expose a transport label instead. Then, traffic can be forwarded from the P to the end PE and have the VPN label popped there without any issue.

Generally, for VPN traffic the following types of TE tunnels be used:

PE-to-PE tunnels

high number of LSPs
no extra LDP required

P-to-P tunnels

low number of LSPs
LDP over IP Tunnel or LDP over TE Tunnel is required

PE-to-P tunnels

medium number of LSPs
tLDP over TE Tunnel is required

TE Routing & Traffic Selection

You can route through the TE tunnel using one of the following:

static route (for the tunnel destination)

supported on inter-area tunnels

static route (for a loopback on the tail-end)

supported on inter-area tunnels

autoroute announce

the tunnel destination is announced automatically into the IGP of the head-end only

not supported on inter-area tunnels

autoroute destination

the tunnel destination is announced automatically as a static route

supported on inter-area tunnels

forwarding adjacency

the TE link is advertised like a normal link into the IGP of all routers

policy-based routing (PBR)

traffic is forwarded across a TE tunnel based on a route-map criteria
supported on inter-area tunnels

policy-based tunnel selection (PBTS)

traffic is forwarded across TE tunnels based on a single EXP value per tunnel
supported on inter-area tunnels

class-based tunnel selection (CBTS)

traffic is forwarded across TE tunnels based on one or more EXP values per tunnel
supported on inter-area tunnels

MPLS L3VPN through MPLS TE Tunnel
If the BGP next-hop (for MPLS-VPN) is different from the MPLS-TE router-ID of the tail-end (i.e. if this is not a PE-PE TE tunnel), then you need to enable LDP over the tunnel (i.e. enable "mpls ip" on the TE tunnel interface).

static route

IOS
interface Tunnel0
tunnel destination x.x.x.x
!
ip route x.x.x.x 255.255.255.255 Tunnel0

IOS-XR
interface tunnel-te0
destination y.y.y.y
!
router static
address-family ipv4 unicast
y.y.y.y/32 tunnel-te0

You can also use a static route for a loopback on the tail-end, and then use that loopback for BGP next-hop under a specific VRF.

IOS

PE-1
vrf definition VPN
address-family ipv4
bgp next-hop Loopback100
exit-address-family
!
interface Loopback100
ip address 100.100.100.1 255.255.255.255
!
ip route 100.100.100.2 255.255.255.255 Tunnel0

PE-2
vrf definition VPN
address-family ipv4
bgp next-hop Loopback100
exit-address-family
!
interface Loopback100
ip address 100.100.100.2 255.255.255.255
!
ip route 100.100.100.1 255.255.255.255 Tunnel0

autoroute announce

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 1 dynamic

R1#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 2.2.2.2on Tunnel0, 00:03:39 ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 00:03:39 ago, via Tunnel0
      Route metric is 4, traffic share count is 1

IOS-XR
interface tunnel-te0
ipv4 unnumbered Loopback0
autoroute announce
destination 2.2.2.2
path-option 1 dynamic

GSR#sh route 2.2.2.2
Routing entry for 2.2.0.9/32
Known via "isis 1", distance 115, metric 30, type level-1
Installed Jan 16 13:29:24.723 for 01:11:17
Routing Descriptor Blocks
    2.2.2.2, from 2.2.2.2, via tunnel-te0
      Route metric is 30
No advertising protos.

autoroute destination

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute destination
tunnel mpls traffic-eng path-option 1 dynamic

R1#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
      Route metric is 0, traffic share count is 1

IOS-XR
not supported

If there is another static route manually configured, then traffic is load-balanced (unless a different metric is used).

If both "autoroute announce" and "autoroute destination" are configured, then "autoroute destination" becomes active, due to the static route having precedence over IGP in the RIB.

It's obvious that if you want to route other than the tunnel destination traffic through the tunnel, the autoroute options won't help you.

forwarding adjacency

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 10.0.0.1
tunnel mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng path-option 1 dynamic

IOS-XR
interface tunnel-te0
ipv4 unnumbered Loopback0
destination 10.0.0.2
forwarding-adjacency
path-option 1 dynamic

LSP tunnel must be bidirectional.

If you don't set the IGP metric under the tunnel interface, the default IGP metric will be used (which might not provide the expected results). In any case you have to be very careful of loops.

Autoroute announce should not be used together with forwarding-adjacency.

Although a bidirectional tunnel is required, there is no actual IGP adjacency established over the TE tunnel.

An easy way to verify the existence of the tunnel in the ISIS topology is to use the following command:

IOS
R2#sh isis topology | i System|TE
System Id            Metric     Next-Hop             Interface   SNPA
R5                   19         XR1                  Tu0         *MPLS TE-Tunnel
R6                   19         XR1                  Tu0         *MPLS TE-Tunnel
XR1                  9          XR1                  Tu0         *MPLS TE-Tunnel

Policy-Based Routing (PBR)

IOS
interface FastEthernet1/0
ip policy route-map TO-TUNNEL-ROUTEMAP
!
route-map TO-TUNNEL-ROUTEMAP permit 10
set interface Tunnel0

PBR for VRF traffic is not supported. You can use static route + vrf bgp next-hop in order to forward each VRF to a different TE tunnel.

CBTS (Class-Based Tunnel Selection)

It's EXP-based tunnel selection between multiple tunnels to same destination.

CBTS does not allow load-balancing of a given EXP value in multiple tunnels.

CBTS is not supported with AToM and MPLS TE Automesh.

If the input QoS policy modifies the EXP value, CBTS uses the modified EXP value for its tunnel selection.
If the output QoS policy modifies the EXP value, CBTS uses the original EXP value for its tunnel selection.

Tunnel Selection

All comparisons are made per tunnel prefix (static route, autoroute).
Only tunnels with the best metric are used for CBTS.

specific EXP is configured on a single tunnel and there is a single default EXP tunnel

traffic with that EXP is forwarded into the specific EXP tunnel
traffic with other EXPs is forwarded into the default EXP tunnel

specific EXP is configured on multiple tunnels and there is a single default EXP tunnel

traffic with that EXP is forwarded into one of the specific EXP tunnels (based on lowest EXP and lowest tunnel ID)
traffic with other EXPs is forwarded into the default EXP tunnel

specific EXPs are configured on multiple tunnels and there is no default EXP tunnel

traffic with a specific EXP is forwarded into the specific EXP tunnel
traffic with other EXPs is forwarded into the EXP tunnel with the lowest EXP value

specific EXP is not configured on any tunnel and there is a single default EXP tunnel

traffic with any EXP is forwarded into the default EXP tunnel

specific EXP is not configured on any tunnel and there are multiple default EXP tunnels

traffic with any EXP is forwarded (arbitrarily) into one of the default EXP tunnels

specific EXP is not configured on any tunnel and there is no default EXP tunnel

traffic with any EXP is load-balanced across all tunnels

Since static route has precedence over (dynamic) autoroute, if two tunnels for the same prefix use static route and autoroute accordingly, then only the one with the static route is chosen for the CBTS, regardless of the EXP values configured in them. This is also applicable and on same-type tunnels (i.e. autoroute ones) with different metrics, where only the one with the best metric is used by CBTS.

Configuration

Tunnel master bundles tunnel members
Tunnel selection (autoroute, etc.) configured on tunnel master
Bundle members configured with EXP values to carry

IOS
interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng exp 3 5
!
interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng exp default
!
interface Tunnel1000
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member Tunnel0
tunnel mpls traffic-eng exp-bundle member Tunnel1

IOS
R1#sh mpls traffic-eng exp

Destination: 2.2.2.2

   Master: Tunnel1000        Status: up

   Members       Status               Conf Exp                  Actual Exp

   Tunnel0       up (Active)         3 5                       3 5
   Tunnel1       up (Active)         Default                   0 1 2 4 6 7

(D) : Destination is different
(NE): Exp values not configured on tunnel

IOS-XR
not supported

Policy-Based Tunnel Selection (PBTS)

It's EXP-based tunnel selection between multiple tunnels to same destination.

Similar to CBTS, but only one class per tunnel is supported and no tunnel-bundle is required.

PBTS has precedence over CBTS.

Configuration

Tunnels configured via policy-class with one EXP value to carry
Tunnel without policy-class acts as default

IOS
not supported

IOS-XR
interface tunnel-te0
ipv4 unnumbered Loopback0
destination 2.2.2.2
policy-class 5
path-option 1 dynamic
!
interface tunnel-te1
ipv4 unnumbered Loopback0
destination 2.2.2.2
policy-class default
path-option 1 dynamic

Pages

Thursday, February 6, 2014

NTS: RSVP/MPLS-TE

RSVP/MPLS-TE

1 comment: