Node Protection

The earlier section "Node Protection Overview" provided you with a basic understanding of how node protection works. This section focuses on the details of node protection, particularly the areas in which node protection deviates from link protection.

Similarities Between Link Protection and Node Protection

Node protection and link protection share a few common characteristics and differ on a few others. The similarities are as follows:

• Enabling FRR at the primary tunnel headend

• Tying the protected link to the backup tunnel

• Failure detection

• Connectivity restoration

• Post-failure signalling

In node protection, although you are trying to protect against the failure of an NHop, the way you detect the failure is configured on the link connecting the PLR to the NHop, just as you would in case of link protection.

Differences Between Link Protection and Node Protection

This section examines the areas in which node protection differs from link protection:

• NNHop backup tunnel is configured at the PLR.

• Label recording is required for the NNHop backup tunnel.

• NNHop tunnel handles link and node failures.

NNHop Backup Tunnel Is Configured at the PLR

Creating a backup tunnel to the NNHop is similar to creating a backup tunnel to the NHop, except that an NNHop tunnel terminates on the NNHop instead of on the NHop. You have to build the backup tunnel to the NNHop instead of the NHop to protect against the failure of the NHop node. Example 7-29 shows the configuration of the NNHop backup tunnel on 12008a. This is depicted in Figure 7-16.

Example 7-29 NNHop Backup Tunnel for Node Protection

12008a#show running-config interface tunnel2

interface Tunnel2

 ip unnumbered Loopback0

 no ip directed-broadcast

 tunnel destination 12.12.12.12

 tunnel mode mpls traffic-eng

 tunnel mpls traffic-eng path-option 5 explicit name nnhop

 ip rsvp signalling dscp 0

end



12008a#show ip explicit-paths name nnhop

ip explicit-path name nnhop enable

 next-address 10.0.11.10

 next-address 10.0.9.16

 next-address 10.0.86.13

 next-address 10.0.87.12

 next-address 12.12.12.12

The hops specified in the explicit path list nnhop are as follows:

• 10.0.11.10— The IP address of 12008b on link 12008a12008b

• 10.0.9.16— The IP address of 12008d on link 12008b12008d

• 10.0.86.13— The IP address of 7500c on link 12008d7500c

• 10.0.87.12— The IP address of 7200c on link 7500c7200c

As you can see from Example 7-29, the destination of the tunnel is 12.12.12.12, which is the RID of 7200c, the NNHop node.

Label Recording Is Required for the NNHop Backup Tunnel

The output in Example 7-30 shows the Label Recording flag turned on. This flag is turned on whenever the headend configures tunnel mpls traffic-eng fast-reroute.

Example 7-30 debug ip path resv detail Output on 7200a Showing Label Recording

7200a#debug ip path resv detail

*Oct 16 14:40:57.124:  SESSION_ATTRIBUTE    type 7 length 24:

*Oct 16 14:40:57.124:   Setup Prio: 7, Holding Prio: 7

*Oct 16 14:40:57.124:   Flags: Local Prot desired, Label Recording, SE Style

*Oct 16 14:40:57.124:   Session Name: 7200a_t1

When you build a tunnel to the NHop because you are this node's upstream neighbor, you know what label the downstream neighbor expects because you received the label from the RSVP Resv message along the reservation. However, if you want to build a backup tunnel to the NNHop node, you do not know what label this node expects for a given LSP.

This is what the Label Recording flag is for. It records the incoming label used at each hop for an LSP so that a PLR doing node protection knows what label to use on a protected LSP when it's switched down the backup tunnel. Here is a quote from RFC 3902:

The recording of the Label subobject in the ROUTE_RECORD object is controlled by the label- recording-desired flag in the SESSION_ATTRIBUTE object. Since the Label subobject is not needed for all applications, it is not automatically recorded. The flag allows applications to request this only when needed.

Also, if you examine the output of show mpls traffic-eng tunnel tunnel1 on 7200a, you'll see this:

Record   Route:  10.0.5.5(16) 10.0.17.11(33)

                 10.0.17.12(0)

The numbers 16, 33, and 0 in parentheses refer to the label values from the record label object.

Having this information available is also useful during troubleshooting.

Note that requesting label recording is controlled by the tunnel headend. Because the headend doesn't know whether the network has link protection or node protection, label recording is turned on but is not used if the network has no node protection.

NNHop Tunnel Handles Link and Node Failures

If you consider Figure 7-16 again, the backup tunnel bypasses both the NHop and the link that connects the PLR to the NHop. Even though the tunnel is primarily in place to protect against the failure of 12008c, the protected node, if the link 12008a12008c fails, there is no way for the PLR (12008a) to tell whether the link went down because link itself went down or the link went down because the entire NHop node went down.

If you used an NHop backup tunnel, it would only guard against link failures. With NNHop backup tunnels, the moment a failure is detected on the POS 1/0 interface on 12008a, protection kicks in, sending all the packets of the primary tunnel over the backup tunnel. As you can see, node protection is both link and node protection rolled into one.