Chapter 19. Transit Fast Restoration Based on RSVP-TE

Until now, the discussion has been about various IP Fast ReRoute (FRR) protection techniques. Let’s focus now on protection in RSVP-TE. As in the previous cases, there are a variety of options to provide protection with RSVP transport, just not as many:

  • Path protection

  • Facility protection (RFC 4090, Section 3.2)

  • One-to-one protection (RFC 4090, Section 3.1)

These options are discussed in the three sections of this chapter.

RSVP-TE Path Protection

The concept of path protection is very simple: for each RSVP LSP that requires path protection, an operator defines two (or more) paths. During normal conditions, the primary path is used to forward the traffic for any given LSP. If some failure on the primary path happens, the head-end router can switch the traffic to the secondary path, as illustrated in Figure 19-1.

You can see that the LSP from PE3 to PE1 is configured with two path options. The primary path uses the PE3→P1→PE1 route, whereas the secondary path uses the PE3→PE4→P5→P3→P1→PE1 route. A simple configuration to achieve these desired results is presented Example 19-1.

RSVP path protection concepts
Figure 19-1. RSVP path protection concepts
Example 19-1. RSVP multiple path configuration on PE3 (Junos)
protocols {
    mpls {
        label-switched-path PE3--->PE1 {
            to 172.16.0.11;
            primary PE3-P1-PE1;
            secondary PE3-PE4-P5-P3-P1-PE1;
        }
        path PE3-P1-PE1 {
            10.0.0.34 strict;
            10.0.0.2 strict;
        }
        path PE3-PE4-P5-P3-P1-PE1 {
            10.0.0.33 strict;
            10.0.0.28 strict;
            10.0.0.14 strict;
            10.0.0.8 strict;
            10.0.0.2 strict;
}}}

The appropriate RIB entries are installed and traffic uses the primary path.

Example 19-2. Primary path forwarding verification on PE3 (Junos)
juniper@PE3> show mpls lsp name PE3--->PE1 detail | match <pattern>
  From: 172.16.0.33, State: Up, ActiveRoute: 0, LSPname: PE3--->PE1
  ActivePath: PE3-P1-PE1 (primary)
 *Primary   PE3-P1-PE1       State: Up
  Secondary PE3-PE4-P5-P3-P1-PE1 State: Dn

juniper@PE3> show route table inet.3 172.16.0.11/32
(...)
172.16.0.11/32     *[RSVP/7/1] 00:07:24, metric 1050
                    > to 10.0.0.34 via ge-2/0/6.0,
                                   label-switched-path PE3--->PE1

juniper@PE3> traceroute mpls rsvp PE3--->PE1 | match RSVP-TE
  ttl    Label  Protocol   Address     Previous Hop   Probe Status
    1   303440  RSVP-TE    10.0.0.34   (null)         Success
    2        3  RSVP-TE    10.0.0.2    10.0.0.34      Egress

Now, as Example 19-3 shows, when a failure occurs (e.g., the link between P1 and PE3 fails), the secondary path is signaled by RSVP, and the new next hop is subsequently used.

Example 19-3. Secondary path forwarding verification on PE3 (Junos)
juniper@PE3> show mpls lsp name PE3--->PE1 detail | match <pattern>
  From: 172.16.0.33, State: Up, ActiveRoute: 0, LSPname: PE3--->PE1
  ActivePath: PE3-PE4-P5-P3-P1-PE1 (secondary)
  Primary   PE3-P1-PE1       State: Dn
 *Secondary PE3-PE4-P5-P3-P1-PE1 State: Up

juniper@PE3> show route table inet.3 172.16.0.11/32
(...)
172.16.0.11/32     *[RSVP/7/1] 00:02:22, metric 1150
                    > to 10.0.0.33 via ge-2/0/4.0,
                                   label-switched-path PE3--->PE1

juniper@PE3> traceroute mpls rsvp PE3--->PE1 | except "FEC|Hop"

ttl    Label  Protocol  Address      Previous Hop   Probe Status
  1    24032  RSVP-TE   10.0.0.33    (null)         Success
  2   301168  Unknown   10.0.0.28    10.0.0.33      Non-compliant
  3                     172.16.0.3   10.0.0.28      Non-compliant
  4                     172.16.0.1   172.16.0.3     Non-compliant
  5                     172.16.0.11  172.16.0.1     Egress

As of this writing, some level of interoperability inconsistency between Junos and IOS XR could be observed in MPLS RSVP-TE LSP Ping (RFC 4379 and RFC 6424). You can see the manifestation of this problem in Label (missing), Protocol (missing or Unknown) and Probe Status (Non-compliant) output fields. Because this issue didn’t cause any disturbance to the traffic itself, we didn’t dwell on it for a detailed analysis of the problem.

For the sake of completeness, let’s configure multiple paths for a RSVP-TE tunnel initiated on an IOS XR device. In this example, we configure an RVSP-TE LSP from PE4 to PE2.

Example 19-4. RSVP multiple path configuration on PE4 (IOS XR)
explicit-path name PE4-P6-P4-P2-PE2
 index 10 next-address strict ipv4 unicast 10.0.0.26
 index 20 next-address strict ipv4 unicast 10.0.0.16
 index 30 next-address strict ipv4 unicast 10.0.0.10
 index 40 next-address strict ipv4 unicast 10.0.0.4
!
explicit-path name PE4-P5-P3-P4-P2-PE2
 index 10 next-address strict ipv4 unicast 10.0.0.28
 index 20 next-address strict ipv4 unicast 10.0.0.14
 index 30 next-address strict ipv4 unicast 10.0.0.13
 index 40 next-address strict ipv4 unicast 10.0.0.10
 index 50 next-address strict ipv4 unicast 10.0.0.4
!
interface tunnel-te22
 apply-group GR-LSP
 signalled-name PE4--->PE2
 destination 172.16.0.22
 path-option 1 explicit name PE4-P5-P3-P4-P2-PE2
 path-option 2 explicit name PE4-P6-P4-P2-PE2

Based on this configuration, an LSP using the primary path is established and appropriate entries are populated. As is discussed in Chapter 2, the IGP metric for destinations reachable via RSVP-TE tunnels equals the cost of the shortest hop-by-hop path to the destination (in this example, PE4→P5→P3→P1→PE1→PE2; cost: 800). Because this shortest path is not always equal to the path taken by LSP, the reported metric values (line 7, versus 13 and 15 in Example 19-5) might differ. This is true for both Junos and IOS XR devices (with nuances described in the final sections of Chapter 3).

Example 19-5. Primary path forwarding verification on PE4 (IOS XR)
1     RP/0/0/CPU0:PE4#show mpls traffic-eng tunnels destination 172.16.0.22
2                     role head detail | include <pattern>
3     Name: tunnel-te22  Destination: 172.16.0.22  Ifhandle:0x1080
4       Signalled-Name: PE4--->PE2
5         Admin:    up Oper:   up   Path:  valid   Signalling: connected
6         path option 1,  type explicit PE4-P5-P3-P4-P2-PE2
7                                       (Basis for Setup, path weight 950)
8         path option 2,  type explicit PE4-P6-P4-P2-PE2
9         Outgoing Interface: Gi0/0/0/3, Outgoing Label: 301360
10
11    RP/0/0/CPU0:PE4#show route 172.16.0.22/32
12    (...)
13      Known via "isis core", distance 115, metric 800, type level-2
14        172.16.0.22, from 172.16.0.22, via tunnel-te22
15          Route metric is 800
16
17    RP/0/0/CPU0:PE4#traceroute mpls traffic-eng tunnel-te 22
18    (...)
19      0 10.0.0.29 MRU 1500 [Labels: 301584 Exp: 0]
20    L 1 172.16.0.5 MRU 1514 [Labels: 302448 Exp: 7] 30 ms
21    L 2 172.16.0.3 MRU 1514 [Labels: 24010 Exp: 7] 220 ms
22    L 3 10.0.0.13 MRU 1500 [Labels: 24011 Exp: 0] 10 ms
23    L 4 10.0.0.10 MRU 1500 [Labels: implicit-null Exp: 0] 10 ms
24    ! 5 10.0.0.4 10 ms

The trace output is as expected. There are some differences, however, in the reported addresses (loopbacks versus link addresses) or Maximum Receive Unit (MRU) sizes (including or excluding the Layer 2 header) depending on whether the reporting node is Junos or IOS XR.

After a network failure occurs (e.g., on the P3-P5 link) traffic shifts to the secondary path, as demonstrated in Example 19-6. This time, the LSP metric (line 7) and the IGP metric (lines 13 and 15) are equal, because after failure of the P3-P5 link, the shortest path to the destination equals the secondary path.

Example 19-6. Secondary path forwarding verification on PE4 (IOS XR)
1     RP/0/0/CPU0:PE4#show mpls traffic-eng tunnels destination 172.16.0.22
2                     role head detail | include <pattern>
3     Name: tunnel-te22  Destination: 172.16.0.22  Ifhandle:0x480
4       Signalled-Name: PE4--->PE2
5         Admin:    up Oper:   up   Path:  valid   Signalling: connected
6         path option 2,  type explicit PE4-P6-P4-P2-PE2 (Basis for Setup,
7                         path weight 1250)
8         path option 1,  type explicit PE4-P5-P3-P4-P2-PE2
9         Outgoing Interface: Gi0/0/0/2, Outgoing Label: 24012
10
11    RP/0/0/CPU0:PE4#show route 172.16.0.22/32
12    (...)
13      Known via "isis core", distance 115, metric 1250, type level-2
14        172.16.0.22, from 172.16.0.22, via tunnel-te22
15          Route metric is 1250
16
17    RP/0/0/CPU0:PE4#traceroute mpls traffic-eng tunnel-te 22
18    (...)
19      0 10.0.0.27 MRU 1500 [Labels: 24012 Exp: 0]
20    L 1 10.0.0.26 MRU 1500 [Labels: 24010 Exp: 0] 10 ms
21    L 2 10.0.0.16 MRU 1500 [Labels: 24011 Exp: 0] 10 ms
22    L 3 10.0.0.10 MRU 1500 [Labels: implicit-null Exp: 0] 0 ms
23    ! 4 10.0.0.4 10 ms

So far, so good. But what traffic restoration times could you imagine in your design? When a failure happens, the following sequence of events are executed:

  1. Failure detection

  2. The secondary path is signaled via RSVP-TE

  3. Installation of a new next hop in the RIB/FIB structures

If the failure occurs close to the head-end router (e.g., the PE3-P1 link fails on the primary path used by LSP from PE3 to PE1), failure detection can be rather quick. Failure of directly connected links or neighbors can be discovered rapidly.

If the failure is farther away from the head-end router (e.g., the P3-P4 link fails on the primary path used by LSP from PE4 to PE2), information about the failure can be propagated to the head-end or tail-end routers (PE4 or PE2) via RSVP-TE signaling messages (PathErr, ResvTear) generated by the router that detects the failure. Alternatively, after IGP global convergence, all the routers in the domain (including head-end and tail-end routers) gain knowledge about the failed link or node. This failure detection can be quite long (several hundred milliseconds), and for certain applications, too long. This problem is discussed a little later in this chapter.

For now, let’s check the second and third element of the overall time required for traffic restoration. When a network failure affects the primary path, a secondary path must be signaled and a new next hop installed in RIB/FIB. This certainly takes time, especially in scaled environments with large numbers of LSPs. Therefore you can use the same trick as discussed in the Loop-Free Alternates (LFA) scenarios: preinstalling backup next hops.

Obviously, to preinstall a backup next hop, the secondary path must be presignaled. So, let’s do that. You simply designate the secondary path as a standby path, as shown in Example 19-7. A standby path is presignaled and corresponds to the next hop preinstalled in the RIB/FIB. But it is only a backup next hop—just like in the LFA case.

Example 19-7. RSVP-TE secondary standby path configuration—PE3 (Junos)
protocols{
    mpls {
        label-switched-path PE3--->PE1 {
            secondary PE3-PE4-P5-P3-P1-PE1 {
                standby;
}}}

Now let’s check what’s the difference in the various states related to the PE3--->PE1 LSP.

Example 19-8. Primary/standby path states on PE3 (Junos)
juniper@PE3> show mpls lsp name PE3--->PE1 detail | match <pattern>
  From: 172.16.0.33, State: Up, ActiveRoute: 0, LSPname: PE3--->PE1
  ActivePath: PE3-P1-PE1 (primary)
 *Primary   PE3-P1-PE1       State: Up
  Standby   PE3-PE4-P5-P3-P1-PE1 State: Up

juniper@PE3> show route table inet.3 172.16.0.11/32 detail | match ...
    *RSVP   Preference: 7/1
            Next hop: 10.0.0.34 via ge-2/0/6.0 weight 0x1, selected
            Label-switched-path PE3--->PE1
            Next hop: 10.0.0.33 via ge-2/0/4.0 weight 0x2001
            Label-switched-path PE3--->PE1
            Age: 23:15      Metric: 1050

You can see the secondary path is presignaled (state is up) and the backup next hop is preinstalled. This time, though, the weight for the backup next hop is 0x2001 (in the LFA case, it was 0xf000, 0x100, or 0x8000, depending on the LFA style used). As long as it is greater than 0x1, it is a backup next hop.

Let’s also do the same on the IOS XR device, as shown in Example 19-9. Enabling the path-protection feature and designating one of the path options (e.g., path option 2) to protect the primary path (path option 1) causes the protecting path (path option 2) to be presignaled.

Example 19-9. Primary/standby path configuration and states—PE4 (IOS XR)
interface tunnel-te22
 path-protection
 path-option 1 explicit name PE4-P5-P3-P4-P2-PE2 protected-by 2
 path-option 2 explicit name PE4-P6-P4-P2-PE2

RP/0/0/CPU0:PE4#show mpls traffic-eng tunnels destination 172.16.0.22
                role head detail | include <pattern>
Name: tunnel-te22  Destination: 172.16.0.22  Ifhandle:0x480
  Signalled-Name: PE4--->PE2
    Admin:    up Oper:   up   Path:  valid   Signalling: connected
    path option 1,  type explicit PE4-P5-P3-P4-P2-PE2
                    (Basis for Setup, path weight 950)
    path option 2,  type explicit PE4-P6-P4-P2-PE2
                    (Basis for Standby, path weight 1250)
    Standby Path: User defined [explicit path option: 2],
    Outgoing Interface: Gi0/0/0/3, Outgoing Label: 301360
    Outgoing Interface: Gi0/0/0/2, Outgoing Label: 24012

Manually designing and explicitly configuring primary and secondary path options might be a challenging task, especially in large networks. Furthermore, as your network changes during its lifetime (typically networks grow and sometimes network topologies are modified), keeping track of the most optimal primary and secondary paths could become an operational nightmare. To cope, you can establish primary and secondary paths dynamically.

In typical designs, the primary path is restricted to use only certain links (e.g., links with the smallest delay)—the required techniques for this are discussed in Chapters Chapter 13 and Chapter 15, so they are not covered here.

Let’s simply configure two dynamic paths—primary and secondary—without any explicit constraints.

Example 19-10. Dynamic primary/secondary standby path—PE3 (Junos)
1     protocols {
2         mpls {
3             label-switched-path PE3--->PE2 {
4                 to 172.16.0.22;
5                 primary PRIMARY;
6                 secondary SECONDARY {
7                     standby;
8                 }
9             }
10            path PRIMARY;
11            path SECONDARY;
12    }}

Lines 10 and 11 demonstrate how you can define path options without specifying any next hops. They are basically empty path options. These path options become populated with explicit lists of next hops by a constrained SPF algorithm during the LSP creation time. (This is discussed in Chapter 2.) But what is new here is the way in which these paths are calculated by CSPF.

First, the path options that are designated as primary, named PRIMARY in the example, follow standard CSPF rules, which in the end produce paths based on the lowest total cost to the destination (because no constraints are imposed on the primary path in the example). This cost is 1100, as shown in Figure 19-2 and in Example 19-11, line 5.

Example 19-11. States for primary/standby paths on PE3 (Junos)
1     juniper@PE3> show mpls lsp name PE3--->PE2 detail | match <pattern>
2      From: 172.16.0.33, State: Up, ActiveRoute: 0, LSPname: PE3--->PE2
3      ActivePath: PRIMARY (primary)
4     *Primary   PRIMARY          State: Up
5       Computed ERO (S [L] denotes strict [loose]): (CSPF metric: 1100)
6      10.0.0.34 S 10.0.0.2 S 10.0.0.1 S
7      Standby   SECONDARY        State: Up
8       Computed ERO (S [L] denotes strict [loose]): (CSPF metric: 1350)
9      10.0.0.33 S 10.0.0.28 S 10.0.0.14 S 10.0.0.13 S 10.0.0.10 S
10     10.0.0.4 S
RSVP path protection—dynamic PE3--->PE2 LSPs
Figure 19-2. RSVP path protection—dynamic PE3--->PE2 LSPs

Conversely, the path option designated as secondary standby (called SECONDARY in the example) is calculated using different rules. You can discover those rules by enabling and monitoring logs for CSPF events, as shown in Example 19-12, and Example 19-13, respectively.

Example 19-12. Enabling logs for CSPF events on PE3 (Junos)
protocols {
    mpls {
        traceoptions {
            file cspf size 100m;
            flag cspf;
            flag cspf-link;
            flag cspf-node;
}}}
Example 19-13. Monitoring logs for CSPF events on PE3 (Junos)
1     juniper@PE3> monitor start cspf
2     (...)
3     <timestamp> CSPF for path PE3--->PE2(secondary SECONDARY)
4     <timestamp> CSPF final destination 172.16.0.22
5     <timestamp> CSPF starting from PE3.00 (172.16.0.33) to 172.16.0.22
6     <timestamp> constraint avoid primary path
7     <timestamp> Node PE3.00 (172.16.0.33) metric 0, hops 0,
8                 avail 32000 32000 32000 32000
9     <timestamp>   Link 10.0.0.35->10.0.0.34(P1.00/172.16.0.1,
10          Link IDs 338->335) metric 1000 color 0x0 bw 900Mbps
11    <timestamp> link passes constraints
12    <timestamp> Link overlap with primary path, adding cost 8000000
13    (...)

When checking the logs, you can spot an entry that indicates the start of CSPF for the secondary path (line 3). CSPF for the secondary path tries to avoid the primary path (line 6), so that the primary and secondary paths are distinct to the highest possible degree. Recall from the discussion about MRTs in Chapter 18, the logic was similar: MRT-red and MRT-blue forwarding topologies should be distinct, whenever possible. Now, the primary and secondary paths should be diverse, to the highest possible degree. Whereas MRT uses a sophisticated algorithm to find dissimilar paths for MRT-red and MRT-blue forwarding, Junos CSPF for the secondary path uses a more basic approach, as visible in line 12. Put simply, the cost of links used by the primary path is temporarily increased by 8 million. Thus, in this particular example, link PE3→P1 (line 9) is considered by CSPF with a total cost of 8001000: IGP metric 1000 (line 10) + extra cost 8 million (line 12). In this way, CSPF temporarily increases the cost for all the links used by the primary path.

You can see the results of the primary and secondary path computation in Figure 19-2, and in Example 19-11 (line 6 for primary, lines 9 and 10 for secondary). The primary is a path with the smallest total cost (PE3→P1→PE1→PE2; total cost: 1100), whereas the secondary is a completely distinct path (PE4→P5→P3→P4→P2→PE2; total cost: 1350). There are no common links between primary and secondary paths. Also note that the secondary path is not the second shortest path after the primary. The second shortest path in the example topology is PE3→PE4→P5→P3→P1→PE1→PE2, with a total cost of 1200. This path is not chosen for a secondary path option, though, because it shares some links (P1→PE1→PE2) with the primary path. As you can see, the default algorithm to calculate paths for dynamic primary and secondary options provides very good results.

The results with IOS XR are similar. If path-protection is configured, you can simply define one dynamic path option. The second dynamic path (to protect the first one) will be automatically presignaled.

Example 19-14. Dynamic primary/secondary standby path—PE4 (IOS XR)
interface tunnel-te11
 path-protection
 path-option 1 dynamic

Figure 19-3 and Example 19-15 show the path computations. There is, however, a slight difference between Junos and IOS XR behavior when it comes to calculating paths for secondary path options. Junos tries to avoid the links used by the primary path by increasing, temporarily, metrics for these links. It might happen, however, that the secondary path shares some links with the primary path. IOS XR, on the other hand, completely avoids such links (and nodes) by temporarily removing these links (nodes) from the database used as the input for CSPF calculations (see line 7 in Example 19-15). Thus, in IOS XR, the secondary path must be completely distinct from the primary path. If such a path cannot be found, the secondary path is not presignaled.

Example 19-15. States for primary/standby paths on PE4 (IOS XR)
1     RP/0/0/CPU0:PE4#show mpls traffic-eng tunnels 11 detail
2     Name: tunnel-te11  Destination: 172.16.0.11  Ifhandle:0x680
3      Signalled-Name: PE4--->PE1
4       Admin:    up Oper:   up   Path:  valid   Signalling: connected
5       path option 1,  type dynamic  (Basis for Setup, path weight 750)
6       path option 2,  type dynamic  (Basis for Standby, path weight 1300)
7       Standby Path: Node and Link Diverse [explicit path option: 2]
8       Outgoing Interface: Gi0/0/0/3, Outgoing Label: 301365
9       Outgoing Interface: Gi0/0/0/2, Outgoing Label: 24018
10    (...)
11      Path info (IS-IS core level-2):
12      Node hop count: 4
13      Hop0: 10.0.0.28               ## P5
14      Hop1: 10.0.0.14               ## P3
15      Hop2: 10.0.0.8                ## P1
16      Hop3: 10.0.0.2                ## PE1
17      Hop4: 172.16.0.11             ## PE1
18
19      Standby LSP Path info (IS-IS core level-2), Oper State: Up :
20      Node hop count: 5
21      Hop0: 10.0.0.26               ## P6
22      Hop1: 10.0.0.16               ## P4
23      Hop2: 10.0.0.10               ## P2
24      Hop3: 10.0.0.4                ## PE2
25      Hop4: 10.0.0.0                ## PE1
26      Hop5: 172.16.0.11             ## PE1
RSVP path protection—dynamic PE4--->PE1 LSPs
Figure 19-3. RSVP path protection—dynamic PE4--->PE1 LSPs

The last thing you should know about path protection is how RSVP-TE signals different paths belonging to same RSVP-TE tunnel. If you carefully study Chapter 2 and RFC 3209 (RSVP-TE: Extensions to RSVP for LSP Tunnels), RSVP-TE maintains a couple of IDs used for identification of tunnels and paths:

Tunnel ID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.

In Junos, you can easily monitor RSVP-TE packet exchange by capturing packets with IP protocol 46 (this is the IP protocol ID assigned to RSVP). If you sniff packets on different interfaces (with Junos command monitor traffic interface <int> size 2000 no-resolve detail), you can catch RSVP packets handling primary as well as secondary paths of PE3--->PE2, as shown in Example 19-16.

Example 19-16. RVSP packets monitoring on PE3 (Junos)
1     /* Interface ge-2/0/6.0 */
2     RSVPv1 Path Message (1), Flags: [Refresh reduction capable]
3       Session Object (1) Flags: [reject if unknown], Class-Type:
4         Tunnel IPv4 (7), length: 16, IPv4 Tunnel EndPoint: 172.16.0.22,
5         Tunnel ID: 0xb14d, Extended Tunnel ID: 172.16.0.33
6       Session Attribute Object (207) Flags: [ignore and forward if
7         unknown], Class-Type: Tunnel IPv4 (7), length: 20, Session
8         Name: PE3--->PE2, Setup Priority: 7, Holding Priority: 0,
9         Flags: [SE Style desired]
10      Sender Template Object (11) Flags: [reject if unknown],
11        Class-Type: Tunnel IPv4 (7), length: 12, IPv4 Tunnel Sender
12        Address: 172.16.0.33, LSP-ID: 0x0037
13
14    /* Interface ge-2/0/4.0 */
15    RSVPv1 Path Message (1), Flags: [Refresh reduction capable]
16      Session Object (1) Flags: [reject if unknown], Class-Type:
17        Tunnel IPv4 (7), length: 16, IPv4 Tunnel EndPoint: 172.16.0.22,
18        Tunnel ID: 0xb14d, Extended Tunnel ID: 172.16.0.33
19      Session Attribute Object (207) Flags: [ignore and forward if
20        unknown], Class-Type: Tunnel IPv4 (7), length: 20, Session
21        Name: PE3--->PE2, Setup Priority: 7, Holding Priority: 0,
22        Flags: [SE Style desired]
23      Sender Template Object (11) Flags: [reject if unknown],
24        Class-Type: Tunnel IPv4 (7), length: 12,  IPv4 Tunnel Sender
25        Address: 172.16.0.33, LSP-ID: 0x0038

The tunnel ID is the same for all paths of the same RSVP-TE tunnel. It is manually assigned in IOS XR (the same as the configured interface tunnel ID) and automatically assigned in Junos. You can see that Tunnel ID 0xb14d (45389 in decimal) is used in the RSVP-TE signaling messages by both the primary (line 5) and the secondary (line 18) paths. The LSP ID, however, is different on both paths. The primary uses 0x0037 (line 12), whereas the secondary uses 0x0038 (line 25). Each time the path is changed (e.g., due to reoptimization) or a new path added, the new LSP ID is automatically generated, maintaining multiple paths belonging to the same RSVP-TE tunnel.

RSVP-TE Facility (Node-Link) Protection

Path protection is based on switchover between the primary and secondary standby paths. The head-end router performs this switchover, so failure information must first be propagated to the head-end router before any repair action can be executed. If the failure happens close to the head-end router (failure of a directly connected link or a directly connected node), failure detection is quite quick. If, however, failure happens farther away from the head-end router, the following failure detection methods can trigger path switchover:

  • Notification from the IGP that the topology has changed (e.g., some of the transit routers are no longer available)

  • RSVP PathErr or ResvTear messages

  • Notification from the Bidirectional Forwarding Detection (BFD) protocol running as the LSP’s OAM, which indicates that forwarding over the LSP is broken

Any of these events can result in a relatively slow failure detection, and thus path switchover might by triggered relatively late after failure occurs. For certain loss-sensitive applications this is undesirable.

Thus, RFC 4090 (Fast Reroute Extensions to RSVP-TE for LSP Tunnels) introduces two options for protecting traffic flowing via RSVP-TE tunnels using the local-repair paradigm. Similar to the protection cases available for LDP and SPRING (different variants of LFA), traffic is repaired locally; thus, the failure propagation time to head-end router no longer plays a significant role.

Because the terminology used for these two options across vendors can become a bit confusing, Table 19-1 summarizes the terms used by Junos and IOS XR as well as by the RFC (this book uses the RFC terms in all further discussions.)

Table 19-1. RSVP-TE protection terminology
RFC 4090 One-to-one backup Facility backup
Junos Fast ReRoute Link Protection
Node-Link Protection
IOS XR n/a Fast ReRoute Protection Any
Fast ReRoute Protection Node

One of the two options described in RFC 4090 is facility backup, whereby “facility” is defined as a link or node. This option shows some similarities to per-link LFA discussed earlier in this chapter. Namely, with facility backup, all eligible traffic flowing through the protected facility (link or node) is rerouted by the means of local repair over the same backup next hop when the facility (link or node) fails.

The problem with per-link LFA is its high dependency on topology, which results in no loop-free backup next hop in many situations. This limitation does not affect RSVP-TE protection. Because RSVP-TE has the capability to signal explicit paths, after the path is signaled and states are created on all transit routers, packets do not necessarily use the shortest-path for forwarding any longer. Explicit path specification creates the opportunity to presignal any bypass path, which is completely independent from the network topology or IGP metrics. You used this capability of RSVP-TE in Chapter 18, when you extended LFA backup coverage with manual or dynamic RSVP-TE tunnels. This chapter focuses on pure RSVP-TE scenarios.

So, let’s do it. But before getting under way with this section, you must set all RSVP-TE tunnels (full mesh between PE routers) back to their basic state (single, dynamic path option per tunnel.) Then, taking this book’s topology as a reference, this is the path followed by each right-to-left tunnels:

  • PE3--->PE1 tunnel: PE3→P1→PE1

  • PE3--->PE2 tunnel: PE3→PE4→P5→P3→P4→P2→PE2

  • PE4--->PE1 tunnel: PE4→P5→P3→P1→PE1

  • PE4--->PE2 tunnel: PE4→P5→P3→P4→P2→PE2

Remember that in the IGP and TE worlds, links are seen as two half-links. Let’s focus on P5→P3, whose reverse half-link is P3→P5. According to the previous list, the following three LSPs transit the (half-)link P5→P3: PE3--->PE2, PE4--->PE1, and PE4--->PE2.

Facility Protection in Action

Most of the verifications thus far have been based on operational show commands in the prefailure state. Let’s now simulate link failure events.

When a link or node fails, the traffic is locally repaired (redirected over the bypass LSP), and the head-end router of the regular LSP is notified about the failure. While traffic is locally repaired, the head-end router performs CSPF for the regular LSP in order to eventually calculate and signal a new path that avoids the failed facility (link or node). So, seeing a backup path on a traceroute output might be challenging, given that the path might already be resignaled.

If, however, the regular LSP uses an explicit (not dynamic) path, which includes the failed link or node, CSPF fails and it is not possible to resignal the tunnel. In this situation, local repair is in action forever. Even the RSVP-TE Path and Resv messages of the protected LSPs are tunneled through the bypass LSP, which is seen as one hop.

Automatic Protection Bypass

Creating bypass LSPs manually, as done so far in this chapter, might be a very challenging task. Fortunately, both IOS XR and Junos offer the possibility of automatic bypass LSP creation, as configured in Example 19-38 and Example 19-39. This is similar to the automatic bypass tunnels for extending LFA coverage discussed in Chapter 18.

Example 19-38. Automatic bypass tunnel configuration (IOS XR)
group GR-MPLS-TE
 mpls traffic-eng
  interface 'GigabitEthernet.*'
   auto-tunnel backup
end-group
!
ipv4 unnumbered mpls traffic-eng Loopback0
!
mpls traffic-eng
 apply-group GR-MPLS-TE
 auto-tunnel backup
  tunnel-id min 101 max 199
Example 19-39. Automatic bypass tunnel configuration (Junos)
groups {
    GR-RSVP {
        protocols {
            rsvp {
                interface "<*[es]*>" {
                    link-protection;
}}}}}
protocols {
    rsvp {
        apply-groups GR-RSVP;
}}

In both IOS XR and Junos, you enable automatic bypass tunnel creation on an interface basis, using the auto-tunnel backup or link-protection keywords, respectively. RSVP-TE auto tunneling has been already discussed in Chapter 2 and Chapter 5. Using groups simplifies the configuration of multiple interfaces, and the regular expression in Example 19-39 matches both Ethernet and SONET interfaces.

Note

In IOS XR, manual and automatic bypass tunnel configuration cannot coexist on the same interface. In Junos, they can, and manual bypass tunnel is preferred. If a manual bypass tunnel is not operational (not configured or configured but in down state), Junos establishes an automatic bypass tunnel.

Additionally, let’s request node-link protection (refer to Example 19-31 and Example 19-33) for all regular tunnels and verify the state of the network, as demonstrated in Example 19-40.

Example 19-40. Bypass LSPs on PE1 (Junos)
juniper@PE1> show rsvp session | match <pattern>
Ingress RSVP: 7 sessions
To              From            LSPname
172.16.0.1      172.16.0.11     Bypass->10.0.0.3
172.16.0.3      172.16.0.11     Bypass->10.0.0.3->10.0.0.9
172.16.0.22     172.16.0.11     Bypass->10.0.0.1
172.16.0.33     172.16.0.11     Bypass->10.0.0.3->10.0.0.35
Egress RSVP: 6 sessions
To              From            LSPname
172.16.0.11     172.16.0.22     autob_PE2_t101_Gi0_0_0_3
172.16.0.11     172.16.0.33     Bypass->10.0.0.34->10.0.0.2
172.16.0.11     172.16.0.1      Bypass->10.0.0.2
Transit RSVP: 4 sessions
To              From            LSPname
172.16.0.2      172.16.0.22     autob_PE2_t103_Gi0_0_0_2
172.16.0.4      172.16.0.22     autob_PE2_t102_Gi0_0_0_2_172.16.0.2
172.16.0.22     172.16.0.2      autob_P2_t102_Gi0_0_0_2

As you can see, IOS XR and Junos (look at the column labeled From) follow different naming conventions for automatic bypass tunnels. Let’s review the terminology:

NHOP (link protection) bypass tunnel
Junos: Bypass-><NHOP-LINK-IP>
For example, the NHOP bypass tunnel started on PE1 to protect traffic forwarded via PE1→P1 (ge-2/0/2.0, NHOP-LINK-IP = 10.0.0.3) link:
Bypass->10.0.0.3
IOS XR: autob_<S-NODE>_t<ID>_<S-INTF>
For example, the NHOP bypass tunnel started on PE2 to protect traffic forwarded via PE2→P2 (Gi0/0/0/2, NHOP-LINK-IP = 10.0.0.5) link:
autob_PE2_t103_Gi0_0_0_2
NNHOP (node and link protection) bypass tunnel
Junos: Bypass-><NHOP-LINK-IP>-><NNHOP-LINK-IP>
For example, the NNHOP bypass tunnel started on PE1 to protect traffic forwarded through P1 node (NHOP-LOOPBACK-IP=172.16.0.1) via PE1→P1→P3 path (ge-2//0/2.0, NHOP-LINK-IP = 10.0.0.3, NNHOP-LINK-IP = 10.0.0.9):
Bypass->10.0.0.3->10.0.0.9
IOS XR: autob_<S-NODE>_t<ID>_<S-INTF>_<NHOP-LOOPBACK-IP>
For example, the NNHOP bypass tunnel started on PE2 to protect traffic forwarded through P2 node (NHOP-LOOPBACK-IP=172.16.0.2) via PE2→P2→P4 path (Gi0/0/0/2, NHOP-LINK-IP = 10.0.0.5, NNHOP-LINK-IP = 10.0.0.11):
autob_PE2_t102_Gi0_0_0_2_172.16.0.2

It’s noteworthy that the automatic bypass feature generates a single NHOP bypass tunnel per protected link. However, multiple NNHOP tunnels might be created, depending on the regular LSPs transiting the NHOP node. If in Figure 19-8 you temporarily change the metric of the P1-P2 to 200, regular tunnels from PE1 and PE2 will take following paths:

  • PE1--->PE2 tunnel: PE1→P1→P2→PE2

  • PE1--->PE3 tunnel: PE1→P1→PE3

  • PE1--->PE4 tunnel: PE1→P1→P3→P5→PE4

  • PE2--->PE1 tunnel: PE2→P2→P1→PE1

  • PE2--->PE3 tunnel: PE2→P2→P1→PE3

  • PE2--->PE4 tunnel: PE2→P2→P4→P3→P5→PE4

For all three regular tunnels starting from PE1, the NHOP is the same node (P1). Similarly, for all three regular tunnels starting from PE2, the NHOP is P2. However, three NNHOP automatic bypass tunnels are created on PE1, because NNHOPs are different for each regular LSP started from PE1 (NNHOPs are P2, PE3, and P3, respectively). On PE2, two NNHOP bypass tunnels are required, as two different NNHOPs are used (P1 and P4). Let’s verify that in the following two examples:

Example 19-41. NNHOP tunnel status on PE1 (Junos)
juniper@PE1> show rsvp interface ge-2/0/2.0 extensive | match ...
Protection: On, Bypass: 3, LSP: 3, Protected LSP: 3,
                                   Unprotected LSP: 0
  Bypass: Bypass->10.0.0.3->10.0.0.7, State: Up, Type: NP, LSP: 1
  Bypass: Bypass->10.0.0.3->10.0.0.9, State: Up, Type: NP, LSP: 1
  Bypass: Bypass->10.0.0.3->10.0.0.35, State: Up, Type: NP, LSP: 1

juniper@PE1> show route table inet.3 protocol rsvp
(...)
172.16.0.22/32 *[RSVP/7/1] 00:53:08, metric 300
      > to 10.0.0.3 via ge-2/0/2.0, LSP PE1--->PE2
        to 10.0.0.1 via ge-2/0/3.0, LSP Bypass->10.0.0.3->10.0.0.7
172.16.0.33/32 *[RSVP/7/1] 03:16:55, metric 1050
      > to 10.0.0.3 via ge-2/0/2.0, LSP PE1--->PE3
        to 10.0.0.1 via ge-2/0/3.0, LSP Bypass->10.0.0.3->10.0.0.35
172.16.0.44/32 *[RSVP/7/1] 03:16:54, metric 750
      > to 10.0.0.3 via ge-2/0/2.0, LSP PE1--->PE4
        to 10.0.0.1 via ge-2/0/3.0, LSP Bypass->10.0.0.3->10.0.0.9
Example 19-42. NNHOP tunnel status on PE2 (IOS XR)
RP/0/0/CPU0:PE2#show mpls traffic-eng tunnels auto-tunnel
                | include Name
Name: tunnel-te102  Destination: 172.16.0.4   (auto-tunnel backup)
  Signalled-Name: autob_PE2_t102_Gi0_0_0_2_172.16.0.2
Name: tunnel-te104  Destination: 172.16.0.1   (auto-tunnel backup)
  Signalled-Name: autob_PE2_t104_Gi0_0_0_2_172.16.0.2

RP/0/0/CPU0:PE2#show mpls traffic-eng fast-reroute database
Tunnel  Out Intf/        FRR Intf/        Status
        Label            Label
------- ---------------- ---------------- -------
tt11    Gi0/0/0/2:24041  tt104:307984     Ready
tt33    Gi0/0/0/2:24015  tt104:307968     Ready
tt44    Gi0/0/0/2:24014  tt102:24025      Ready

In Junos, you can easily determine for which NNHOP the bypass is established, because NHOP and NNHOP link addresses are encoded in the bypass tunnel name. In IOS XR, you need to execute more commands to find that out.

The RSVP-TE facility protection design is now final. All regular tunnels are protected against transit node and link failures, and appropriate states (primary and backup next hops) are created on all routers. There is 100% backup coverage for both node and link failures. Compared to the much more extensive efforts required to achieve 100% backup coverage with LFA, you can see that RSVP-TE is much simpler. You simply need to enable automatic bypass tunnels, and request node and link protection for regular tunnels, and you are done.

Note

The semantics of the Junos node-link-protection keyword used in LFA and RSVP-TE facility protection configurations is slightly different. In LFA, backup next hop is selected only if it fulfills both node and link-protection criteria. In RSVP-TE facility protection, the backup next hop that fulfills node-protection criterion is preferred, but if not found, the backup next hop that fulfills link protection criterion is used. To achieve similar behavior in LFA, you must additionally use the node-link-degradation keyword.

RSVP-TE One-to-One Protection

Whereas you can consider facility protection a rough equivalent of per-link LFA, you can view one-to-one protection as a rough equivalent of per-prefix LFA (in the analogy, replace prefixes with protected RSVP-TE LSPs). In one-to-one protection, each eligible regular tunnel is protected independently with separate detour LSPs.

Note

Facility backup uses bypass LSPs, whereas one-to-one backup uses detour LSPs for protection.

With facility backup, during a failure event, traffic belonging to multiple regular tunnels might be forwarded (tunneled) over a single bypass LSP. In one-to-one backup, detour LSPs are associated with a single regular tunnel only; thus, traffic on that single tunnel might use its associated detour LSPs during a failure event. The native merging feature, which will be explained soon, reduces the impact of these detours in terms of scalability.

You can view one-to-one protection as an extension of the RSVP-TE path protection concept discussed earlier in this chapter. In path protection, the head-end router creates the primary and secondary (standby) LSP and performs switchover to the secondary LSP upon failure of the primary LSP. The head-end can detect a failure of the directly connected neighbor relatively fast. However, detecting a failure of transit nodes used by the primary path farther away from the head-end might take some time. Thus, switchover to the secondary standby LSP might be delayed, which is a clear limitation of the path protection scheme.

The one-to-one backup concept overcomes this limitation through automatic creation of secondary standby LSPs at each transit node along the primary path. These secondary standby LSPs are called detour LSPs in one-to-one backup architecture. Apart from the name itself, another difference is that detour LSPs don’t need to be completely disjointed from the primary path. It is enough if they are disjointed until the NNHOP only, because protection against failure of the NNHOP is handled by the detour LSP initiated at the next hop. This concept is illustrated in Figure 19-9.

Note

As of this writing, support for one-to-one backup was available in Junos but not in IOS XR.

One-to-one backup with detour LSPs
Figure 19-9. One-to-one backup with detour LSPs

From a configuration perspective, you simply need to enable one-to-one protection for each LSP that you want to protect, as demonstrated in Example 19-43.

Before starting this section, all RSVP-TE tunnels (full mesh between PE routers) are set back to their basic state (single, dynamic path option per tunnel) and all the facility protection specific configurations removed.

Example 19-43. One-to-one protection configuration (Junos)
protocols {
    mpls {
        label-switched-path PE1--->PE4 {
            fast-reroute;
}}}
Note

The fast-reroute keyword used in RSVP-TE tunnel configurations in IOS XR and Junos has completely different meanings. In IOS XR, it designates specific RSVP-TE tunnels as eligible for facility (link or node) protection. Exactly the same keyword in Junos results in enabling one-to-one protection for a specific RSVP-TE tunnel. Consult Table 19-1 for the terminology used by RFC 4090. Also check the documentation for both vendors.

The primary LSP for PE1--->PE4 tunnel is established via the shortest path, which is PE1→P1→P3→P5→PE4. Additionally, the head-end router as well as each transit (mid-point) router presignal the detour LSPs. Let’s verify, at least on three first nodes from regular LSP, what paths are selected for these detour LSPs (see Example 19-44).

Example 19-44. Detour LSPs for PE1→PE4 LSP
1     juniper@PE1> show rsvp session name PE1--->PE4 extensive | match ...
2       Detour is Up
3       Detour Explct route: 10.0.0.1 10.0.0.5 10.0.0.11 10.0.0.12
4                            10.0.0.15 10.0.0.29
5       Detour Record route: <self> 10.0.0.1 10.0.0.5 10.0.0.11 10.0.0.12
6                            10.0.0.15 10.0.0.29
7       Detour Label out: 299952
8
9     juniper@P1> show rsvp session name PE1--->PE4 extensive | match ...
10      Detour is Up
11      Detour Explct route: 10.0.0.35 10.0.0.33
12      Detour Record route: 10.0.0.2 <self> 10.0.0.35 10.0.0.33
13      Detour Label out: 299952
14
15    juniper@P3> show rsvp session name PE1--->PE4 extensive | match ...
16      Detour is Up
17      Detour Explct route: 10.0.0.13 10.0.0.17 10.0.0.27
18      Detour Record route: 10.0.0.2 10.0.0.8 <self> 10.0.0.13 10.0.0.17
19                           10.0.0.27
20      Detour Label out: 300224
21    Detour branch from 10.0.0.0, to skip 172.16.0.1, Up
22      Explct route: 10.0.0.15 10.0.0.29
23      Record route: 10.0.0.0 10.0.0.4 10.0.0.10 10.0.0.13 <self>
24                    10.0.0.15 10.0.0.29
25      Label in: 300192, Label out: 300016
26    Detour branch from 10.0.0.15, to skip 172.16.0.44, Up
27      Explct route: 10.0.0.13 10.0.0.17 10.0.0.27
28      Record route: 10.0.0.2 10.0.0.8 10.0.0.14 10.0.0.15 <self>
29                    10.0.0.13 10.0.0.17 10.0.0.27
30      Label in: 300176, Label out: 300224

The path for the detour LSP is by default the shortest path to the destination (PE4), which avoids the primary next-hop node (or link to primary next-hop in case of the penultimate node: P5). That is:

Detour from PE1:
PE1→PE2→P2→P4→P3→P5→PE4 (avoid P1 node, lines 3 through 6 and 21 through 24)
Detour from P1
P1→PE3→PE4 (avoid P3 node, lines 11 and 12)
Detour from P3
P3→P4→P6→PE4 (avoid P5 node, lines 17 and 18)
Detour from P5
P5→P3→P4→P6→PE4 (avoid P5→PE4 link, lines 26 through 29)

As you can see, the detour LSP to skip the NHOP node doesn’t necessarily traverse the NNHOP node (in case of facility backup with node protection, automatic bypass LSP always terminates on the NNHOP node). For example, the detour from P1 to skip node P3 does not traverse P5 (which is the NNHOP node). Put simply, the shortest path from P1 to PE4 that avoids P3 is not via P5.

Another observation is the fact that some detour LSPs use (partially) overlapping paths with another detour LSP or with a primary LSP. For example, the detour LSP from P3 and the detour LSP from P5 have a common P3→P4→P6→PE4 segment (lines 18, 19, 28, and 29). Similarly the detour LSP from PE1 shares the P3→P5→PE4 segment with the primary path.

One-to-one backup architecture is clever enough to realize this and merge LSPs (multiple detour LSPs or the detour LSP with the primary LSP) to avoid wasting resources. When the detour LSP from P3 and the detour LSP from P5 are merged together in one LSP at P3 (the merge node), P3 uses one single RSVP Path message in the downstream segment. Indeed, downstream from the merge node, there is only one label allocated for the two merged LSPs (lines 20 and 30).

To signal detour LSPs and keep track of merged detour LSPs, RFC 4090 introduces an additional RVSP-TE object: DETOUR object. The DETOUR object is basically a list of [PLR_ID, Avoid_Node_ID] pairs. Each pair represents a single detour LSP. For example, [10.0.0.12, 172.16.0.5] represents a detour LSP started at P3 (10.0.0.12) to avoid P5 (172.16.0.5) node. Let’s see how a single RSVP-TE Path message, captured on the P4→P6 link, is used for multiple (merged) detour LSPs (from P3, and from P5).

Example 19-45. RSVP-TE Path message with DETOUR object
[linux:~/Downloads] juniper% tshark -r rsvp-path-merge.pcap -V
(...)
 Resource ReserVation Protocol (RSVP): PATH Message. SESSION:
   IPv4-LSP, Destination 172.16.0.44, Short Call ID 0,
   Tunnel ID 54692, Ext ID ac10000b. SENDER TEMPLATE: IPv4-LSP,
   Tunnel Source: 172.16.0.11, Short Call ID: 0, LSP ID: 1.
(...)
     DETOUR:
         Length: 20
         Object class: DETOUR object (63)
         C-type: 7
         PLR ID 1: 10.0.0.12
         Avoid Node ID 1: 172.16.0.5
         PLR ID 2: 10.0.0.15
         Avoid Node ID 2: 172.16.0.44

Another way to verify the LSP merging operation is to check the MPLS routing entries for incoming labels of different LSPs that are eligible for merging (in this case, the primary path, and the detour from PE1).

Example 19-46. Merging operation at merge node P3
1     juniper@P3> show route label 300160 detail | match <pattern>
2     300160 (1 entry, 1 announced)
3            Next hop: 10.0.0.15 via ge-0/0/4.0 weight 0x1, selected
4              Label-switched-path PE1--->PE4
5              Label operation: Swap 300016
6            Next hop: 10.0.0.13 via ge-0/0/2.0 weight 0x4001
7              Label-switched-path PE1--->PE4
8              Label operation: Swap 300224
9
10    juniper@P3> show route label 300192 detail | match <pattern>
11    300192 (1 entry, 1 announced)
12           Next hop: 10.0.0.15 via ge-0/0/4.0 weight 0x1, selected
13             Label-switched-path PE1--->PE4
14             Label-operation: Swap 300016

In Example 19-46, the incoming label 300160 (primary LSP) is swapped to label 300016 (line 5) when sent via ge-0/0/4.0 (primary next hop). At the same time, label 300192 (detour LSP from PE1 to avoid P1) is swapped to label 300016 (line 14), too, effectively merging two LSPs (primary + detour from PE1) downstream of the P3 node.

Example 19-47 simulates the P3→P5 link failure and performs traceroute to a PE4’s VPN prefix for verification (again, during this verification the primary path was statically fixed using an explicit path option). The VPN label is 16 and remains constant.

Example 19-47. One-to-one protection in action (Junos)
juniper@PE1> traceroute 192.168.1.44 routing-instance VRF-A
 1  P1 (10.0.0.3)  13.831 ms  7.650 ms  6.315 ms
     MPLS Label=300288 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=1 S=1
 2  P3 (10.0.0.9)  6.668 ms  5.828 ms  6.962 ms
     MPLS Label=300160 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=2 S=1
 3  P4 (10.0.0.13)  8.084 ms  5.744 ms  7.895 ms
     MPLS Label=300224 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=3 S=1
 4  P6 (10.0.0.17)  5.673 ms  6.361 ms  7.924 ms
     MPLS Label=300048 CoS=0 TTL=1 S=0
     MPLS Label=16 CoS=0 TTL=4 S=1
 5 PE4-VRF-A (192.168.1.44) 6.075 ms 6.625 ms 6.421 ms

From traceroute, it is obvious that P3 realizes the link failure and uses a backup next hop (lines 6 and 8 in Example 19-46) to forward the traffic via the P3→P4→P6→PE4 detour LSP. If you compare typical traceroute when facility protection is active (Example 19-35 and Example 19-37) with traceroute when one-to-one protection is active, you can spot two major differences:

  • Facility protection results in an additional label (bypass LSP) being pushed on the label stack; thus, the resulting label stack is bigger (increased from two to three labels in the examples). One-to-one backup, on the other hand, doesn’t cause label stack increase, because the label action on the backup next hop is swap (line 8 in Example 19-46) and not swap/push (line 8 in Example 19-24). In the PHP case, the label action in one-to-one is pop, as compared to swap in facility protection.

  • The path taken by traffic during active protection is typically more optimal with one-to-one backup, because one-to-one detour LSPs are established over the shortest post-convergence path to the final destination (avoiding protected node). In facility backup, on the other hand, the bypass LSPs are established only to the NHOP or NNHOP node, resulting typically in suboptimal traffic forwarding during failures.

So, which is better: facility backup or one-to-one backup? The answer is: it depends! One-to-one backup provides more optimal backup paths. Additionally, it has the ability to spread backup paths of multiple regular LSPs using the same resource (link and node), because detour LSPs are separate for each regular LSP. Thus, during failure, traffic originally flowing along the same (failed) link might be forwarded over different paths, minimizing the possible likelihood of intermittent congestion. In facility protection, traffic is forwarded over the same bypass LSP; consequently, intermittent congestion might occur. Conversely, one-to-one protection results in more RSVP-TE states that need to be maintained in the network, because detours are specific to each regular LSP. Table 19-2 provides a comparison between the total number of RSVP sessions (first row: regular + bypass LSPs, second row: regular + detour LSPs) that need to be maintained at each node using the example topology from this section. The table assumes full mesh of regular LSPs between PE routers, and the desire for both node and link protection.

Table 19-2. Comparison of facility protection and one-to-one protection
Type P1 P2 P3 P4 P5 P6 PE1 PE2 PE3 PE4
Facility 13 16 15 16 13 5 13 16 12 18
One to One 19 16 20 19 16 8 16 16 15 23

As more and more regular LSPs are added to the network, the differences might be greater.

Note

One-to-one protection is especially advantageous in ring topologies, for which the suboptimal characteristic of facility backup is quite remarkable, causing a two-stage U-turn effect. Grab a piece of paper and a pencil and do the simulation yourself!

Transit Fast-Restoration Summary

A variety of local protection options to minimize traffic loss during transit link or node failures were discussed in this chapter. Which is the best? Again, the answer is: it depends. Each of the options has some advantages and disadvantages, and depending on the focus in the particular deployment, you might choose one or the other. In typical deployments, a mixture of protection technologies is used. For example, RSVP-TE based in the core network, and LFA based in the edge.

Chapter 20 and Chapter 21 discuss additional protection features, this time related to the failure of the egress PE node or egress PE-CE link.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.237.164