This section provides an overview of the association signaling methods for the bidirectional LSPs. Two unidirectional LSPs can be bound to form an associated bidirectional LSP in the following scenarios:

• No unidirectional LSP exists, and both must be established.
• Both unidirectional LSPs exist, but the association must be established.
• One unidirectional LSP exists, but the reverse associated LSP must be established.

This section provides an overview of associated bidirectional non co-routed and co-routed LSPs. Establishment of MPLS TE-LSP involves computation of a path between a head-end node to a tail-end node, signaling along the path, and modification of intermediate nodes along the path. The signaling process ensures bandwidth reservation (if signaled bandwidth is lesser than 0 and programming of forwarding entries).

Path computation is performed by the head-end nodes of both the participating LSPs using Constrained Shortest Path First (CSPF). CSPF is the 'shortest path (measured in terms of cost) that satisfies all relevant LSP TE constraints or attributes, such as required bandwidth, priority and so on.

Associated Bidirectional Non Co-routed LSPs: A non co-routed bidirectional TE LSP follows two different paths, that is, the forward direction LSP path is different than the reverse direction LSP path. Here is an illustration.

In the above topology:

• The outer paths (in green) are working LSP pairs.
• The inner paths (in red) are protecting LSP pairs.
• Router 1 sets up working LSP to Router 3 and protecting LSP to Router 3 independently.
• Router 3 sets up working LSP to Router 1 and protecting LSP to Router 1 independently.

Non co-routed bidirectional TE LSP is available by default, and no configuration is required.

Note	In case of non co-routed LSPs, the head-end nodes relax the constraint on having identical forward and reverse paths. Hence, depending on network state you can have identical forward and reverse paths, though the bidirectional LSP is co-routed.

Associated Bidirectional Co-routed LSPs: A co-routed bidirectional TE LSP denotes a bidirectional tunnel where the forward direction LSP and reverse direction LSP must follow the same path, for example, the same nodes and paths. Here is an illustration.

• Exp-null over Flex-LSP is not supported.

• Flex-LSP does not support tunnel statistics.

• VC (layer 2 VPN ckts) statistics are not supported.

• It is recommended to configure for the following timers for Flex-LSP deployments:

  mpls traffic-eng reoptimize timers frequency 120

  mpls traffic-eng reoptimize timers delay installation 30

  mpls traffic-eng reoptimize timers delay cleanup 90

• The no mpls ip propagate-tcl command is not recommended with Flex-LSP. The PREC value of BFD control packet is set to “0”. Therefore, packet prioritization cannot be done at midpoints and BFD flap can occur with traffic congestions.

• It is recommended to configure BFD timers as 10x3 during cable pull testing or in Flex LSP feature deployments.

• 50-msec convergence is not guaranteed for local shut.

• 50-msec convergence is not guaranteed without WRAP protection. WRAP protection is mandatory to achieve 50-msec convergence for remote failures.

• 50-msec convergence is expected with a maximum of 30 Flex-LSP tunnels that use the same egress interface.

• With scale and multiple other feature mix-ups, it is possible to see higher convergence.

• TE NSR and IGP NSR are mandatory for RSP switchover.

• Flex LSP is supported with the IPv4 template.

• The ip rsvp signalling hello command is not mandatory and it can cause a large punt during the cutover and can lead to unexpected results like BFD flapping.

• VPLS over Flex-LSP is not supported.

• Both IGP and FRR must be configured as clients for single-hop BFD when the WRAP protection is enabled; only FRR cannot be the only client that is configured at midpoint.

• Layer 3 VPN over Flex-LSP is not supported.

• It is recommended to configure 10x3 BFD timers for cable failures, to achieve 50 msec of convergence.

• It is recommended to configure 10x3 BFD timers for cable failures, to achieve 50 msec of convergence.

• Dynamic diverse paths are not supported for Flex LSP Tunnel.

• The Diverse node SRLG path option is not supported.

• The protect dynamic SRLG path is diverse from the primary path and thus the shortest path is not always chosen.

• When the constraint for the protect path of Flex-LSP tunnel does not meet, it will wait in the REQUESTED state.

A co-routed bidirectional packet LSP is a combination of two LSPs (one in the forward direction and the other in reverse direction) sharing the same path between a pair of ingress and egress nodes. It is established using the extensions to RSVP-TE. This type of LSP can be used to carry any of the standard types of MPLS-based traffic, including Layer 2 VPNs and Layer 2 circuits. You can configure a single BFD session for the bidirectional LSP (that is, you do not need to configure a BFD session for each LSP in each direction). You can also configure a single standby bidirectional LSP to provide a backup for the primary bidirectional LSP.

The configuration includes the following steps:

1. Enable basic MPLS Traffic Engineering on hostname PE1.

2. Map L2VPN pseudowire to a specific FLEX LSP tunnel.

3. Configure Flex LSP.

4. Enable BFD.

5. Enable Wrap and Fault OAM.

6. Enable BDIs on a core-facing interface.

Note	The working and protect LSPs for PE1 (head-end) is different from PE2 (tail-end).

At PE1 (head-end):

interface Tunnel1001
 ip unnumbered Loopback0
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination 10.1.1.1
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 200
 tunnel mpls traffic-eng path-option 1 explicit name ThruHunG verbatim
 tunnel mpls traffic-eng path-option protect 1 explicit name PROT1 verbatim
 tunnel mpls traffic-eng bidirectional association id 1001 source-address 10.1.1.1 global-id 1001
!
interface Tunnel1002
 ip unnumbered Loopback0
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination 10.1.1.1
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 200
 tunnel mpls traffic-eng path-option 1 explicit name ThruHunG verbatim
 tunnel mpls traffic-eng path-option protect 1 explicit name PROT1 verbatim
 tunnel mpls traffic-eng bidirectional association id 1002 source-address 10.1.1.1 global-id 1002

ip explicit-path name ThruTenG enable
 next-address loose 22.1.1.2
 next-address loose 10.1.1.1
 next-address loose 10.1.1.1
!
ip explicit-path name ThruHunG enable
 next-address loose 23.1.1.2
 next-address loose 10.1.1.1
 next-address loose 10.1.1.1

ip explicit-path name PROT1 enable
 next-address loose 30.1.1.2
 next-address loose 40.1.1.1
 next-address loose 10.1.1.1

At PE2 (tail-end):

interface Tunnel1001
 ip unnumbered Loopback0
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 200
 tunnel mpls traffic-eng path-option 1 explicit name ThruTenG verbatim
 tunnel mpls traffic-eng path-option protect 1 explicit name PROT2 verbatim
 tunnel mpls traffic-eng bidirectional association id 1001 source-address 10.1.1.1 global-id 1001
!
interface Tunnel1002
 ip unnumbered Loopback0
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 200
 tunnel mpls traffic-eng path-option 1 explicit name ThruTenG verbatim
 tunnel mpls traffic-eng path-option protect 1 explicit name PROT2 verbatim
 tunnel mpls traffic-eng bidirectional association id 1002 source-address 10.1.1.1 global-id 1002

ip explicit-path name ThruTenG enable
 next-address loose 10.1.1.2
 next-address loose 22.1.1.1
 next-address loose 4.4.4.4
!
ip explicit-path name ThruHunG enable
 next-address loose 10.1.1.2
 next-address loose 23.1.1.1
 next-address loose 4.4.4.4

ip explicit-path name PROT2 enable
 next-address loose 41.1.1.2
 next-address loose 31.1.1.1
 next-address loose 4.4.4.4

Router# show mpls traffic-eng tunnels bidirectional-associated association id 1 

P2P TUNNELS/LSPs: 
Name: RP1_t3                              (Tunnel3) Destination: 10.5.0.1 
  Status: 
    Admin: up         Oper: up     Path: valid       Signalling: connected 
    path option 2, type explicit expl_route_m2_tail (Basis for Setup, path weight 40) 
    path option 3, type explicit expl_route_m3_tail 
    Path Protection: 0 Common Link(s), 0 Common Node(s) 
    path protect option 2, type explicit expl_route_m3_tail (Basis for Protect, path weight 40) 
    path protect option 3, type list name xtd 
    Lockout Info: 
      Locked Out: No 
  Config Parameters: 
    Bandwidth: 500      kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF 
    Metric Type: TE (default) 
    AutoRoute: disabled LockDown: disabled Loadshare: 500 [4000000] bw-based 
    auto-bw: disabled 
    Association Type: Single Sided Bidirectional LSPs, Co-routed: YES 
    Association ID: 1, Source: 2.3.4.5, Global ID: 6 
    Fault-OAM: disabled 
  Active Path Option Parameters: 
    State: explicit path option 2 is active 
    BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled 
  InLabel  :  - 
  OutLabel : Ethernet0/0, 16 
  Next Hop : 10.1.2.2 
-------~Full Output not provided ~-------
    

Step 2: Verifying RSVP Signaling

Router# show ip rsvp sender detail  
PATH: 
  Tun Dest:   10.255.255.1  Tun ID: 15  Ext Tun ID: 10.255.255.8 
  Tun Sender: 10.255.255.8  LSP ID: 40 
  Path refreshes: 
    arriving: from PHOP 10.5.2.1 on Et0/1 every 30000 msecs. Timeout in 136 sec 
    sent:     to   NHOP 10.1.4.1 on Ethernet0/0 
  Session Attr:  
    Setup Prio: 7, Holding Prio: 7 
    Flags: (0x4) SE Style 
    Session Name: R3_t15  
  ERO: (incoming) 
    10.5.2.2 (Strict IPv4 Prefix, 8 bytes, /32) 
    10.1.4.2 (Strict IPv4 Prefix, 8 bytes, /32) 
    10.1.4.1 (Strict IPv4 Prefix, 8 bytes, /32) 
    10.255.255.1 (Strict IPv4 Prefix, 8 bytes, /32) 
  ERO: (outgoing) 
    10.1.4.1 (Strict IPv4 Prefix, 8 bytes, /32) 
    10.255.255.1 (Strict IPv4 Prefix, 8 bytes, /32) 
  ASSOCIATION: 
    Extended Association type: Single sided provisioned bidirectional LSPs IPv4 
    Association ID: 1, Source: 10.1.1.1 
    Global source: 0 
    ExtID[0]: 0xAFFFF08 
    ExtID[1]: 0x28 
-------~Full Output not provided ~-------

Step 3: Verifying RSVP Reservation

Router# show ip rsvp reservation detail 
Reservation: 
  Tun Dest:   10.255.255.1  Tun ID: 15  Ext Tun ID: 10.255.255.8 
  Tun Sender: 10.255.255.8  LSP ID: 327 
  Resv refreshes: 
    arriving: from NHOP 10.1.4.1 on Et0/0 every 30000 msecs. Timeout in 382 sec 
  Next Hop: 10.1.4.1 on Ethernet0/0 
  Label: 23 (outgoing) 
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load 
  Resv ID handle: 1200040C. 
  Created: 11:08:07 EST Fri Aug 28 2015 
  Average Bitrate is 0 bits/sec, Maximum Burst is 1K bytes 
  Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes 
  Status: 
  Policy: Accepted. Policy source(s): MPLS/TE 
Reservation: 
  Tun Dest:   10.255.255.8  Tun ID: 15  Ext Tun ID: 10.255.255.1 
  Tun Sender: 10.255.255.1  LSP ID: 338 
  Resv refreshes: 
    arriving: from NHOP 10.5.2.1 on Et0/1 every 30000 msecs. Timeout in 382 sec 
  Next Hop: 10.5.2.1 on Ethernet0/1 
  Label: 17 (outgoing) 
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load 
  Resv ID handle: 05000410. 
  Created: 11:08:07 EST Fri Aug 28 2015 
  Average Bitrate is 0 bits/sec, Maximum Burst is 1K bytes 
  Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes 
  RRO: 
    10.3.2.2/32, Flags:0x0 (No Local Protection) 
    10.3.2.1/32, Flags:0x0 (No Local Protection) 
  Status: 
  Policy: Accepted. Policy source(s): MPLS/TE

Step 4: Verifying Wrap Functionality

Router# show mpls traffic-eng tunnels  
P2P TUNNELS/LSPs: 
Name: R1_t15                              (Tunnel15) Destination: 10.255.255.8 
  Status: 
    Admin: up         Oper: up     Path: valid       Signalling: connected 
    path option 1, type explicit Primary (Basis for Setup, path weight 60) 
    path option 2, type dynamic 
    Path Protection: 0 Common Link(s), 0 Common Node(s) 
    path protect option 1, type explicit Secondary (Basis for Protect, path weight 40) 
    Lockout Info: 
      Locked Out: No 
  Config Parameters: 
    Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF 
    Metric Type: TE (default) 
    AutoRoute: enabled  LockDown: disabled Loadshare: 0 [0] bw-based 
    auto-bw: disabled 
    Association Type: Single Sided Bidirectional LSPs, Co-routed: YES 
    Association ID: 1, Source: 10.1.1.1 
    Fault-OAM: enabled, Path-Protection: ready, Wrap-Protection: enabled, Wrap-Capable: Yes 
    FlexLSP Event History: 
  Active Path Option Parameters: 
    State: explicit path option 1 is active 
    BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled

Router# show mpls traffic-eng tunnels protection  
P2P TUNNELS: 
R1_t15 
  LSP Head, Tunnel15, Admin: up, Oper: up 
  Src 10.255.255.1, Dest 10.255.255.8, Instance 34 
  Fast Reroute Protection: None 
  Lockout Info: 
    Locked Out: No 
  Path Protection: Backup lsp in use. 
  Prior Working LSP details: 
    LSP ID: 33 (Delayed Clean) 
    Deactivates In: (2796) ms 
    InLabel  :  - 
    OutLabel : Ethernet0/1, 16 
    Next Hop : 10.1.4.2 
    Reverse Associated LSP Information:  
        Signaled Name: 10.255.255.8 15 
        Tunnel: 15, Source: 10.255.255.8, Dest: 10.255.255.1, LSP: 29 State: Up 
    Lockout Info:  
        Locked out: No 
        Lockout Originated By: None 
    Association:  
        Association Type: Single Sided Bidirectional LSPs 
        Association ID: 1 Source: 10.1.1.1 
-------~Full Output not provided ~-------

Step 5: Verifying BFD and OAM Operations

Router# show mpls traffic-eng tunnels detail | sec Fault
    Fault-OAM: enabled, Path-Protection: no protection, Wrap-Protection: disabled, Wrap-Capable: No
    Fault-OAM Events:
      LSP 4638 (deleted) bfd-delete, 
          at 07:32:08 IST Fri Jun 3 2016 (1 days, 8 hours, 35 mins, 30 secs ago)
      LSP 4638 (deleted) fault-delete, 
          at 07:32:08 IST Fri Jun 3 2016 (1 days, 8 hours, 35 mins, 30 secs ago)
      LSP 4638 (working) bfd-up, 
          at 10:15:31 IST Thu Jun 2 2016 (2 days, 5 hours, 52 mins, 7 secs ago)
      LSP 4637 (working) bfd-delete, 
          at 10:15:20 IST Thu Jun 2 2016 (2 days, 5 hours, 52 mins, 18 secs ago)
      LSP 4637 (working) fault-delete, 
          at 10:15:20 IST Thu Jun 2 2016 (2 days, 5 hours, 52 mins, 18 secs ago)
      LSP 4636 (working) bfd-delete, 
          at 10:15:17 IST Thu Jun 2 2016 (2 days, 5 hours, 52 mins, 21 secs ago)
      LSP 4636 (working) fault-delete, 
          at 10:15:17 IST Thu Jun 2 2016 (2 days, 5 hours, 52 mins, 21 secs ago)
-------~Full Output not provided ~-------

Router# show mpls fault-oam session end-point detail  
  MPLS Fault-OAM End-point Sessions 
===================================== 
    Session handle : 0x6 
    Client handle : 0x2B9FAE02B750 
    Local label : 18 
    Tunnel interface : Tunnel3 (0x15) 
    Tunnel number : 3 
    LSP number : 49 
    Global ID : 0 
    Node ID : 10.1.0.1 
    Local event : Fault Clear 
    Sender Information 
        Fault source : End-point 
        Refresh seconds : 20 
        Initial count : 0 
        Fault type : CLR 
        Tx Fault-CLR count : 0 
        Tx Fault-AIS count : 0 
        Tx Fault-LDI count : 0 
        Tx Fault-LKR count : 0 
        Tx Lockout-CLR count : 0 
        Tx Lockout count : 0 
        Tx Error count : 0 
    Receiver Information 
        Source global ID : 0 
        Source node ID : 0 
        Source intf number : 0 
        Fault type : CLR 
        Rx Fault-CLR count : 0 
        Rx Fault-AIS count : 0 
        Rx Fault-LDI count : 0 
        Rx Fault-LKR count : 0 
        Rx Lockout-CLR count : 0 
        Rx Lockout count : 0 
        Rx Error count : 0 
    -------~Full Output not provided ~-------

Step 6: Verifying that Pseudowire is in UP State

Router# show mpls l2transport vc vcid 1            (HEAD router)
 
Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Gi6            Eth VLAN 30                53.0.0.1        1          UP        
 #show mpls l2transport vc vcid 1 detail 
Local interface: Gi6 up, line protocol up, Eth VLAN 30 up
  Interworking type is Ethernet
  Destination address: 53.0.0.1, VC ID: 1, VC status: up
    Output interface: Tu10, imposed label stack {29 29780}
    Preferred path: Tunnel10,  active
    Required BW = 15000, Admitted BW = 15000
    Default path: ready
    Next hop: point2point
  Create time: 00:01:13, last status change time: 00:01:13
    Last label FSM state change time: 00:01:13
  Signaling protocol: LDP, peer 53.0.0.1:0 up
    Targeted Hello: 52.0.0.1(LDP Id) -> 53.0.0.1, LDP is UP
    Graceful restart: configured and enabled
    Non stop routing: configured and not enabled

    -------~Full Output not provided ~-------

Use the show adjacency tunnel internal command to view the software forwarding of the tunnel:

Router# show adjacency tunnel1 internal | i lsp-num

          GigabitEthernet0/5/2 55.0.0.1 label 21 lsp-num 20
          Path protected by GigabitEthernet0/5/3 label 22 lsp-num 21
          Reopt of working: Null0 0.0.0.0 label none lsp-num 0
          Reopt of protect: Null0 label none lsp-num 0

Flex LSP phase 2 is supported from Cisco IOS XE Everest 16.5.1. Flex LSP, also known as Associated Bidirectional Label Switched Paths (LSPs), are LSP instances where the forward and the reverse direction paths are set up, monitored, protected independently, and associated together during signaling. The RSVP Association aims to bind the forward and reverse LSPs together to form either a co-routed or a non co-routed associated bidirectional traffic engineering (TE) tunnel.

The Cisco IOS XE Everest 16.5.1 supports only co-routed Flex LSP tunnels. Flex LSP Phase 2 supports the following features:

• Shared Risk Link Groups (SRLGs) Protection – SRLGs indicate situations where links in a network share a common fiber (or a common physical attribute). If one link fails, the other links in the group may also fail. Links in this group have a shared risk.

  The MPLS-TE SRLG Protection feature enhances backup tunnel path selection so that a backup tunnel avoids using links that are in the same SRLG as interfaces the backup tunnel is protecting.

• Non-revertive

• Sticky

• Hop count and Cost max limit – Each path from the tunnel source node (head-end) to destination node (tail-end) has a number of characteristics, including node hop count and accumulated path cost. Node hop count is the number of nodes along a path excluding the source node.

  To ensure that the selected path does not exceed the specified hop count, configure a maximum node hop count.

  Each link segment along the path has an associated path cost. Accumulated path cost is the sum of the path cost of all link segments. In the co-routed tunnel case, the accumulated path cost includes both, the forward and reverse link cost. To ensure that the selected path does not exceed the specified cost value, configure a cost max limit.

• ECMP min-fill, max-fill – Path calculation selects a path with the lowest accumulated path cost. Sometimes there are multiple paths from the tunnel source node to the destination node, and all these paths may have the same accumulated (and lowest) path cost. These paths are referred to as “Equal Cost Multi Path” (ECMP). In this scenario, path calculation must use other tiebreakers (such as, node hop count and path minimum bandwidth) to select one path. Max-fill is a tiebreaker method that selects, from all ECMPs, a path with the least head room, but can still accommodate the path request. This method has the effect of packing the links. Min-fill is a tiebreaker method that selects, from all ECMPs, a path with the most head room, and which has a load balance effect over time.

• Restore path option – The restore path option signals a restore LSP after a double failure of both, primary and protect LSPs.

Prior to Cisco IOS XE Bengaluru Release 17.4.1, when a MPLS Flex LSP tunnel used to run on the protect LSP (when the working LSP would go down) and the tunnel bandwidth was modified, the existing LSP was replaced by a new LSP. The new LSP reflected the tunnel bandwidth, but there was a traffic loss of two seconds. This happened because Make Before Break (MBB) functionality was only supported on the working LSP and not on the protect LSP.

Starting with Cisco IOS XE Bengaluru Release 17.4.1, the MBB functionality is supported on the protect LSP. Thus, when a working LSP goes down, the tunnel does not break and continues with the old bandwidth. You need to manually bring up the working LSP to experience the new bandwidth. When the working LSP comes up, use the following command to manually switch from the working to the protect LSP:

mpls traffic-eng switch tunnel tunnel-ID .

This configuration switches the traffic from protect to working. Thus, both the working and protect LSP reflect the new bandwidth. This in turn ensures no traffic loss.