Thursday, February 6, 2014

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:

  1. R1
    1. checks reservation attributes
    2. sends PATH message with src/dst R1/R4 to next-hop (R2)
  2. R2
    1. receives PATH message with src/dst R1/R4 from previous-hop (R1)
    2. checks reservation attributes
    3. sends PATH message with src/dst R1/R4 to next-hop (R3)
  3. R3
    1. receives PATH message with src/dst R1/R4 from previous-hop (R2)
    2. checks reservation attributes 
    3. sends PATH message with src/dst R1/R4 to next-hop (R4)
  4. R4
    1. receives PATH message with src/dst R1/R4 from previous-hop (R3)
    2. checks reservation attributes 
    3. makes the reservation
    4. sends RESV message with src/dst R4/R3 to previous-hop (R3)
  5. R3
    1. receives RESV message with src/dst R4/R3 from R4
    2. sends RESV message with src/dst R3/R2 to previous-hop (R2)
  6. R2
    1. receives RESV message with src/dst R3/R2 from R3
    2. sends RESV message with src/dst R2/R1 to previous-hop (R1)
  7. R1
    1. receives RESV message with src/dst R2/R1 from R2
    2. 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



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





No comments:

Post a Comment