Chapter 4: Cisco MPLS Traffic Engineering

Cisco Press

1 2 3 4 5 6 7 8 Page 7
Page 7 of 8

Link and Node Protection

You need to pre-establish a backup TE LSP to implement link and node protection. You can configure this backup with an MPLS TE tunnel interface using the same commands that you use to configure the primary tunnel. The headend of the backup tunnel will always reside on the PLR. Conversely, the tailend will always be the merge point (MP). The backup tunnel can rely on a dynamically computed path or an explicit path. The only obvious restriction is that the path options for the backup tunnel must not use the facility (link, node, or shared-risk link group [SRLG]) whose failure you are trying to protect against. Backup tunnels commonly do not use an explicit bandwidth reservation. Remember that backup tunnels remain unused most of the time, and an explicit reservation limits your ability to share bandwidth.

The tunnel destination determines the type of protection a backup tunnel provides. An NHOP (adjacent neighbor) destination defines a backup tunnel that can protect against the failure of the link that connects to that neighbor. An NNHOP (a neighbor's neighbor) destination protects against the adjacent neighbor failure for those TE LSPs also traversing that second neighbor. Depending on your topology, you may need multiple backup tunnels to fully protect against the failure of an adjacent neighbor. A PLR may also have multiple backup tunnels to the same destination and protect against the same failure. This allows you to provide redundancy in case a backup tunnel fails and to distribute the primary TE LSPs across several backup tunnels.

You need to associate the backup tunnel with a physical interface that will detect the failure. Cisco IOS uses the mpls traffic-eng backup-path interface command for that purpose. Cisco IOS XR uses the backup-path command under a particular interface in the mpls traffic-eng configuration mode. You use the same command regardless of the type of protection you are trying to implement. To accelerate the detection of some node failures, you might need to enable RSVP hello messages or Bidirectional Forwarding Detection (BFD) between the PLR and the adjacent neighbor. In many cases, the PLR will detect the node failure as a link failure.

Examples 4-39 and 4-40 illustrate the configuration of backup tunnels in Cisco IOS and Cisco IOS XR, respectively. In both examples, one of the tunnels provides link protection; the other tunnel provides node protection. All tunnels use dynamic path computation that excludes the appropriate node or link. Figure 4-3 shows the details of the network topology and the tunnel paths.

In Example 4-46, node A has an NHOP tunnel, Tunnel1, and NNHOP tunnel, Tunnel2. Tunnel1 provides link protection, with interface POS0/1/1 acting as the failure-detection point. Tunnel2 provides node protection, with interface POS1/0/0 as failure-detection point. Similarly, Example 4-47 shows an NHOP tunnel, tunnel-te1, and an NNHOP tunnel, tunnel-te2, on node B. In this example, tunnel-te1 provides link protection and uses interface POS0/3/0/1 as the failure-detection point. Similarly, tunnel-te2 provides node protection and uses interface POS0/3/0/2 for the same purpose.

figure 4.3

Figure 4-3

Sample Network Topology with Link and Node Protection

Example 4-46  Backup Tunnels for Link and Node Protection in Cisco IOS

interface Tunnel1
 description NHOP-BACKUP
 ip unnumbered Loopback0
 tunnel destination 172.16.255.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 10 explicit name PATH1
!
interface Tunnel2
 description NNHOP-BACKUP
 ip unnumbered Loopback0
 tunnel destination 172.16.255.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 10 explicit name PATH2
!
interface POS0/1/1
 ip address 172.16.4.3 255.255.255.254
 mpls traffic-eng tunnels
 mpls traffic-eng backup-path Tunnel1
 ip rsvp bandwidth 155000
!
interface POS1/0/0
 ip address 172.16.192.5 255.255.255.254
 mpls traffic-eng tunnels
 mpls traffic-eng backup-path Tunnel2
 ip rsvp bandwidth 155000
!
ip explicit-path name PATH1 enable
 exclude-address 172.16.4.2
!
ip explicit-path name PATH2 enable
 exclude-address 172.16.255.130
!

Example 4-47  Backup Tunnels for Link and Node Protection in Cisco IOS XR

explicit-path name PATH1
 index 1 exclude-address ipv4 unicast 172.16.192.1
!
explicit-path name PATH2
 index 1 exclude-address ipv4 unicast 172.16.255.131
!
interface tunnel-te1
 description NHOP-BACKUP
 ipv4 unnumbered Loopback0
 destination 172.16.255.130
 path-option 10 explicit name PATH1
!
interface tunnel-te2
 description NNHOP-BACKUP
 ipv4 unnumbered Loopback0
 destination 172.16.255.130
 path-option 10 explicit name PATH2
!
mpls traffic-eng
 interface POS0/3/0/1
  backup-path tunnel-te 1
 !
 interface POS0/3/0/2
  backup-path tunnel-te 2
 !
!

Note - Cisco IOS provides the automatic creation of backup TE LSPs. You enable this behavior with the mpls traffic-eng auto-tunnel backup command. A detailed discussion of this functionality is beyond the scope of this book. Consult the Cisco IOS documentation for further details.


Bandwidth Protection

The PLR can manage the capacity of backup tunnels to provide bandwidth protection. You can use the tunnel mpls traffic-eng backup-bw command and the backup-bw command to explicitly configure the backup tunnel capacity in Cisco IOS and Cisco IOS XR, respectively. They provide local knowledge of the capacity of the backup tunnels and do not instruct the PLR to signal a bandwidth reservation. With proper design, a PLR can provide bandwidth protection even if the backup tunnel does not reserve bandwidth. A PLR provides bandwidth protection for any primary TE LSP that requests protection if possible. However, it gives precedence to TE LSPs with nonzero bandwidth that request bandwidth protection.

You configure the capacity of a backup tunnel in terms of a bandwidth amount and the Class-Types they can protect. With respect to the bandwidth amount, you can configure the backup with an explicit (limited) bandwidth amount or as a backup with unlimited bandwidth. With respect to Class-Types, you can configure a backup tunnel to protect TE LSPs using the global pool (CT0), the subpool (CT1), or any bandwidth pool (CT0 or CT1). Bandwidth protection enables you to define multiple backup tunnels with different capacity configuration to protect against the same failure. When the PLR detects a TE LSP that requires protection, it evaluates which backup tunnel can provide the best level of bandwidth protection.

Table 4-3 shows the criteria that the PLR uses to select from among multiple backup tunnels to protect a primary TE LSP. In general, the PLR prefers NNHOP over NHOP tunnels because they can protect against both a node and a link failure. It prefers backup tunnels with an explicit (limited) bandwidth amount. Finally, it prefers an exact Class-Type match over backup tunnels that protect any Class-Type. The most preferable backup tunnel will be an NNHOP tunnel with a limited bandwidth amount and an exact class match. In contrast, the least desirable backup tunnel will be an NHOP tunnel with unlimited bandwidth for any Class-Type. This tunnel provides the lowest certain of bandwidth guarantee.

Table 4-3 Priorities for Backup Tunnel Selection in Cisco IOS and Cisco IOS XR

Preference

Backup Tunnel Destination

Bandwidth Amount

Bandwidth Pool

0 (best)

NNHOP

Limited

Exact match

1

NNHOP

Limited

Any

2

NNHOP

Unlimited

Exact match

3

NNHOP

Unlimited

Any

4

NHOP

Limited

Exact match

5

NHOP

Limited

Any

6

NHOP

Unlimited

Exact match

7 (worst)

NHOP

Unlimited

Any

Example 4-48 shows the bandwidth protection configuration on a PLR in Cisco IOS and Cisco IOS XR, respectively. Examine Figure 4-4.

figure 4.4

Figure 4-4

Sample Network Topology with Cisco IOS PLR Providing Bandwidth Protection

In Example 4-48, interface POS1/0/0 can trigger three backup tunnels:

  • Tunnel1 is an NNHOP backup tunnel protecting 40,000 kbps for CT TE LSPs.

  • Tunnel2 is an NNHOP tunnel that can protect 90,000 kbps for CT0 LSPs.

Tunnel3 is an NHOP tunnel that can protect 90,000 kbps for TE LSPs of any CT.

Example 4-48 Backup Tunnels for Bandwidth Protection in Cisco IOS

interface Tunnel1
 description NNHOP-BACKUP-40M-CT1
 ip unnumbered Loopback0
 tunnel destination 172.16.255.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng backup-bw 40000 class-type 1
 tunnel mpls traffic-eng path-option 10 explicit name PATH1
!
interface Tunnel2
 description NNHOP-BACKUP-90M-CT0
 ip unnumbered Loopback0
 tunnel destination 172.16.255.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng backup-bw 90000 class-type 0
 tunnel mpls traffic-eng path-option 10 explicit name PATH2
!
interface Tunnel3
 description NHOP-BACKUP-90M-ANY-CT
 ip unnumbered Loopback0
 tunnel destination 172.16.255.130
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng backup-bw 90000
 tunnel mpls traffic-eng path-option 10 explicit name PATH3
!
interface POS1/0/0
 ip address 172.16.192.5 255.255.255.254
 mpls traffic-eng tunnels
 mpls traffic-eng backup-path Tunnel1
 mpls traffic-eng backup-path Tunnel2
 mpls traffic-eng backup-path Tunnel3
 ip rsvp bandwidth rdm 155000 sub-pool 55000
!
ip explicit-path name PATH1 enable
 exclude-address 172.16.255.130
!
ip explicit-path name PATH3 enable
 next-address 172.16.192.2
 next-address 172.16.192.1
!
ip explicit-path name PATH2 enable
 next-address 172.16.4.2
!

Examine Figure 4-5.

Example 4-49 shows three backup tunnels that could re-reroute traffic in case of a failure on interface POS0/3/0/1:

  • tunnel-te1 is an NHOP tunnel protecting 55,000 kbps for CT0 TE LSPs.

  • tunnel-te2 is an NNHOP tunnel that supports a protection capacity of 20,000 for CT0 TE LSPs.

tunnel-te3 is an NHOP tunnel that protects 25,000 kbps for CT1 TE LSPs.

Figure 4.5

Figure 4-5

Sample Network Topology with Cisco IOS XR PLR Providing Bandwidth Protection

Example 4-49  Bandwidth Protection in Cisco IOS XR

interface tunnel-te1
 description NHOP-BACKUP-55M-CTO
 ipv4 unnumbered Loopback0
 backup-bw 55000 class-type 0
 destination 172.16.255.130
 path-option 10 explicit name PATH1
!
interface tunnel-te2
 description NNHOP-BACKUP-20M-CTO
 ipv4 unnumbered Loopback0
 backup-bw 20000 class-type 0
 destination 172.16.255.2
 path-option 10 explicit name PATH2
!
interface tunnel-te3
 description NHOP-BACKUP-25M-ANY-CT
 ipv4 unnumbered Loopback0
 backup-bw 25000 class-type 1
 destination 172.16.255.130
 path-option 10 explicit name PATH1
!
mpls traffic-eng
 interface POS0/3/0/1
 backup-path tunnel-te 1
 backup-path tunnel-te 2
 backup-path tunnel-te 3
 !
!

Verifying FRR on the Headend

In Cisco IOS, you can verify the operation of FRR on a headend by examining the Path and Resv state of the primary TE LSP. The show ip rsvp sender detail command provides the most detail about the Path state of a TE LSP. This command enables you to verify whether the node is signaling the TE LSP with any of the FRR flags (local protection desired, node protection desired, or bandwidth protection desired). Similarly, the show ip rsvp reservation detail command provides the details of the Resv state. This command displays the hop-by-hop route information that the signaling packets collected. In Example 4-50, you see that the first node in the path is providing bandwidth protection for an LSP with an NNHOP backup tunnel.

Example 4-50 Examining Primary TE LSP Protection at the Headend in Cisco IOS

Router#show ip rsvp reservation detail 
Reservation:
 Tun Dest:  172.16.255.2 Tun ID: 1 Ext Tun ID: 172.16.255.1
 Tun Sender: 172.16.255.1 LSP ID: 6
 Next Hop: 172.16.0.3 on POS1/0/0
 Label: 30 (outgoing)
 Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
 Resv ID handle: 06000410.
 Created: 16:25:39 UTC Tue Jul 29 2003
 Average Bitrate is 20M bits/sec, Maximum Burst is 1K bytes
 Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
 RRO:
  172.16.255.131/32, Flags:0x2D (Local Prot Avail/Has BW/to NNHOP, Node-id)
   Label subobject: Flags 0x1, C-Type 1, Label 30
  172.16.255.130/32, Flags:0x20 (No Local Protection, Node-id)
   Label subobject: Flags 0x1, C-Type 1, Label 33
  172.16.255.2/32, Flags:0x20 (No Local Protection, Node-id)
   Label subobject: Flags 0x1, C-Type 1, Label 0
 Status:
 Policy: Accepted. Policy source(s): MPLS/TE
Router#

Example 4-51 shows how to verify the operation of FRR on a headend in Cisco IOS XR. In this case, the show mpls traffic-eng tunnels command provides enough detail about the RSVP state of the TE LSP. In particular, the decoded route record object (RRO) will show you, for every hop in the path, whether the TE LSP has local protection, whether protection is active (the node is rerouting the TE LSP through a backup), and whether bandwidth or node protection is available. The flags in the IPv4/IPv6 subobject contain that information. In this example, the first hop (node ID 172.16.255.131) provides local protection with node and bandwidth protection (flags 0x2d).

Example 4-51 Examining Primary TE LSP Protection at the Headend in Cisco IOS XR

Related:
1 2 3 4 5 6 7 8 Page 7
Page 7 of 8
SD-WAN buyers guide: Key questions to ask vendors (and yourself)