|
|
< Free Open Study > |
|
Advanced Protection IssuesThe previous sections described how link and node protection work. This section covers some advanced FRR features that you can configure to make the protection you are using more effective. Here are the topics covered:
Multiple Backup TunnelsThere are two types of multiple backup tunnels:
Multiple Backup Tunnels to the Same MPFigure 7-17 shows a link that is protected by backup tunnel1 and backup tunnel2. This link carries two primary tunnels—tunnel1 and tunnel2. Figure 7-17. Multiple Backup Tunnels to the Same MP
Suppose that the protected link—12008a You can configure two backup tunnels from 12008a to 12008c—backup tunnel1 and backup tunnel3—such that each backup tunnel goes over diverse paths that have OC-3 worth of bandwidth. This protects the two primary tunnels without dropping traffic, as shown in Figure 7-17. With multiple backup tunnels to the same MP, when the protected link or node fails, the traffic from primary tunnel1 and primary tunnel2 is assigned to these backup tunnels. This can be observed using the show mpls traffic-eng fast-reroute database command, as demonstrated in Example 7-31, which shows the FRR status on 12008a. Example 7-31 FRR Status Information with Multiple Backup Tunnels12008a#show mpls traffic-eng fast-reroute database Tunnel head fast reroute information: Prefix Tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status 4.4.4.4 1 [1520] 16 PO1/0:33 Tu1:33 ready 3.3.3.3 1 [902] 28 PO1/0:12319 Tu3: 19 ready The first line of output in Example 7-31 corresponds to Primary Tunnel1 (7200a), and the second one corresponds to primary tunnel2 (7500a). The out interface is POS1/0—the protected link/interface in both cases. Figure 7-18 illustrates the actual forwarding of the primary LSPs after failure. Figure 7-18. Load Balancing of Two Primary LSPs
NOTE Parallel backup tunnels are meaningful only when they are destined for the same MP. Traffic belonging to a single primary tunnel is always carried on the same backup tunnel during failure. It is not split over multiple backup tunnels, even if they are configured. This is not CEF's load balancing, but instead merely a distribution of protected tunnels among protection tunnels. The later section "Backup Tunnel Selection Summary" covers this assignment in more detail. NHop Versus NNHop Backup TunnelsAn NHop backup tunnel protects against failure of the link from the PLR to the NHop node, whereas an NNHop backup tunnel protects against both NHop node failure and the link connecting the PLR to the NHop. Hence, if both are configured, the PLR chooses the NNHop backup tunnel over the NHop backup tunnel when assigning protected LSPs to backup tunnels. Figure 7-19 depicts two backup tunnels configured on PLR 12008a—one going to NHop and the other going to NNHop. Figure 7-19. NHop Versus NNHop Backup Tunnels
Example 7-32 shows that both primary LSPs are backed up using NNHop tunnel2, even though two backup tunnels are available—one to the NHop and the second to the NNHop. This can be observed by executing the show mpls traffic-eng fast-reroute database command. Example 7-32 NNHop Tunnel2 Being Used for Protection12008a#show mpls traffic-eng fast-reroute database Tunnel head fast reroute information: Prefix Tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status 4.4.4.4 1 [1520] 16 PO1/0:Pop tag Tu2:tag-implicit ready 3.3.3.3 1 [902] 28 PO1/0:19 Tu2:tag-implicit ready Backup Bandwidth ReservationThe preceding section discussed the motivation for having multiple backup tunnels. This section discusses another FRR feature—bandwidth protection rather than just link (or node) protection. The idea is that, rather than placing all protected tunnels down a protection tunnel that might end up traversing a link that could be congested during failure, you can build bandwidth-aware protection tunnels. This is a fairly complex mechanism to employ on a large scale, but it gives you the best possible protection for your network. Two new terms are introduced:
Limited backup bandwidth, as you might suspect, puts a limit on how much bandwidth can be allocated from a backup tunnel. It is a number that you need to configure, as shown in Example 7-33. Example 7-33 Backup Bandwidth Configuration for Global Pools and Subpools
12008a(config-if)#tunnel mpls traffic-eng backup-bw ?
<1-4294967295> Amount of allocatable backup bw, any lsp may use
global-pool Enter Allocatable amount for Global-Pool bw
sub-pool Enter Allocatable amount for Sub-Pool bw
The limit can be a number between 1 and 4,294,967,295 specified in terms of kbps. The keywords Global-Pool and Sub-Pool refer to the dual pools created for DiffServ-Aware Traffic Engineering (DS-TE) (if you recall from Chapter 6, "Quality of Service with MPLS TE"). Again, for each of the pools, you can either limit the backup bandwidth using the configuration shown in Example 7-34, or you can use the keyword unlimited. If you enter a backup bandwidth without specifying the pool, the bandwidth protection offered by this backup tunnel is available to both types of primary LSPs. If you specify the pool type on the backup tunnel, only primary LSPs of that pool type can use the backup tunnel. Example 7-34 Configuring Limited Versus Unlimited Backup Bandwidth for the DS-TE Global Pool
12008a(config-if)#tunnel mpls traffic-eng backup-bw global-pool ?
<1-4294967295> Amount of allocatable backup bw, only global-pool may use
Unlimited Unlimited amount for Global-Pool bw
Unlimited backup bandwidth, as the name suggests, has no limits on how much backup bandwidth can be allocated from the backup tunnel. The same terms apply to subpools as well. Example 7-35 shows the configuration for unlimited backup bandwidth. Example 7-35 Configuring Limited Versus Unlimited Backup Bandwidth for the DS-TE Subpool
12008a(config-if)#tunnel mpls traffic-eng backup-bw sub-pool ?
<1-4294967295> Amount of allocatable backup bw, only sub-pool may use
Unlimited Unlimited amount for Sub-Pool bw
If you refer to Table 7-3 (in the next section), you can see that, if multiple backup tunnels are configured at a PLR, the backup tunnel selection process chooses a backup tunnel with limited backup bandwidth over one that has unlimited bandwidth configured. Among the tunnels that have limited bandwidth configured, the ones that terminate at NNHop are preferred over ones that terminate on NHop. It also prefers tunnels with subpool reservation over ones that have global pool reservation. NOTE It is important to understand that backup bandwidth is only an associated bandwidth. It is not actually signalled. In other words, this scheme does not require the backup tunnels to successfully reserve the amount of bandwidth they offer (by configuring the backup-bw on the backup tunnels). You can configure the backup tunnel to reserve bandwidth if you want (using the tunnel mpls traffic-eng bandwidth command), but reserving bandwidth is a separate issue from protecting bandwidth. Consider the example shown in Figure 7-20. The primary LSP has 100 Mbps of bandwidth reserved (from either pool), and four backup tunnels terminate at the same destination (12008c—PLR). Backup tunnel T1 has been configured with unlimited backup bandwidth and three tunnels (T2, T3, and T4) with limited backup bandwidth—80 Mbps, 120 Mbps, and 150 Mbps, respectively. Figure 7-20. Backup Tunnel Selection
During the backup selection process, tunnel T1 is eliminated because other limited backup tunnels are going to the same destination that fit the demand. Tunnel T2 is eliminated because it has 80 Mbps and does not fulfill the bandwidth requirement of the primary LSP (100 Mbps). Both tunnel T3 and T4 meet the bandwidth requirement of the primary LSP. Backup tunnel T3 is selected because it has the least leftover bandwidth. After the primary LSP is assigned to backup tunnel T3, the backup bandwidth on tunnel T3 is reduced by 100 Mbps, so it now has a remaining protection capacity of 20 Mbps. If backup tunnel T4 were selected, 50 Mbps of bandwidth would be wasted because it is not required by the primary LSP. If tunnel T3 is selected, only 20 Mbps is wasted, thus making it the best fit. Assignment is done this way in an attempt to limit backup bandwidth fragmentation. NOTE In the case of limited backup bandwidth, if more than one tunnel meets the bandwidth requirement, you choose the one that has the least leftover bandwidth. For unlimited, if you have more than one unlimited tunnel to choose from, you choose the one that has the least assigned. Each primary LSP can reserve either global (best-effort) or subpool (premium/low-latency) bandwidth. As mentioned earlier, you can designate the pool type for the backup bandwidth—subpool to backup subpool primary LSPs, global-pool to backup global-pool primary LSPs and any pool (if you don't select either global or subpool). This means that the PLR tries to find a subpool backup tunnel for a subpool primary LSP with sufficient subpool bandwidth to cover the needs of that primary LSP. If such a subpool backup tunnel is not available, it tries to use the any pool (but not the global-pool tunnels). The same applies for global-pool backup tunnel selection. If a global-pool LSP needs backup, the PLR looks for a global-pool backup tunnel that meets its need. If it cannot find one, the PLR looks for an any pool tunnel but not subpool backup tunnels. Figure 7-21 shows two backup tunnels from the PLR (12008a) to the MP (7200c). One is a subpool backup tunnel and the other is a global-pool backup tunnel. Which one is used to backup the primary tunnel depends on the type of bandwidth being reserved by the primary tunnel. Figure 7-21. Global Versus Subpool NNHop Backup Tunnels
Backup Tunnel Selection SummaryWhen multiple backup tunnels are configured, keeping track of which backup the PLR chooses can be confusing. The process of backup tunnel selection is covered in Table 7-3 and Table 7-4. The first column shows, from best to worst, what the PLR prefers. For example, an NNHop subpool tunnel with limited bandwidth is the best, and the NHop backup tunnel with unlimited bandwidth configuration is the worst.
NOTE Complete details on configuration and the enhancements that were implemented for node protection are available at the Cisco web site at www.cisco.com. You can obtain information relevant to node protection enhancement by searching for "Fast Reroute enhancement." PromotionBecause multiple backup tunnels can now be configured, a backup LSP that was chosen as a result of the selection process described earlier might no longer be the best due to a change in the environment, such as the configuration of a new backup tunnel or a primary LSP's resource requirement changing. To address this issue, the PLR performs reoptimiza-tion periodically. This periodic reoptimization is called promotion. It is done every five minutes on the PLRs by default. You can change this default using the mpls traffic-eng fast-reroute timers command. Setting the value of this timer to 0 disables promotion. You can observe when the next promotion is due by using show mpls traffic-eng tunnels summary, as demonstrated in Example 7-36. Example 7-36 Observing LSP Promotion Periods12008a#show mpls traffic-eng tunnels summary Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Head: 3 interfaces, 2 active signalling attempts, 2 established 10 activations, 8 deactivations Midpoints: 2, Tails: 0 Periodic reoptimization: every 3600 seconds, next in 3367 seconds Periodic fastreroute: every 300 seconds, next in 67 seconds Periodic auto-bw collection: every 300 seconds, next in 67 seconds Configuring Multiple Backup Tunnels to Multiple NNHopsWhen doing link protection, there is, of course, only one MP because there's only one neighbor—at least on point-to-point links. However, in the case of node protection (or link protection of a multipoint subnet, such as an Ethernet subnet), you might need to configure multiple backup tunnels to different nodes. Because multipoint Ethernet segments are rare in a network core, let's consider node protection. If you want to configure node protection on a PLR, and the NHop across that link has three neighbors of its own, the PLR needs at least three NNHop tunnels—one to each of the NNHops. Of course, you can use more than one backup tunnel to the same NNHop if you want. Figure 7-22 illustrates multiple backup tunnels to different NNHops. Three primary tunnels go from 7200a and 7500a to 7200c, 7500c, and 7500d. These are labeled primary tunnel 1, primary tunnel 2, and primary tunnel 3. The PLR is 12008a. The NHops that the PLR is trying to protect are 12008c, 12008b, and 12008d. Three backup tunnels—backup tunnel 1, backup tunnel 2, and backup tunnel 3—start at 12008a. Backup tunnel 1 terminates on 7200c, backup tunnel 2 terminates on 12008d, and backup tunnel 3 terminates on 12008d also. The rule you have to keep in mind when building these backup tunnels is that they need to Figure 7-22. Multiple Backup Tunnels to Multiple NNHops
Notice that all the backup tunnels meet these criteria. Multiple backup tunnels can be configured as shown in Example 7-37. Example 7-37 Multiple Backup Tunnel Configuration12008a#show running-config interface pos 1/0 interface POS1/0 ip address 10.0.5.5 255.255.255.0 no ip directed-broadcast mpls label protocol ldp mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel1 mpls traffic-eng backup-path Tunnel2 mpls traffic-eng backup-path Tunnel3 crc 32 clock source internal pos ais-shut ip rsvp bandwidth 155000 155000 end Adding the second and third backup paths is no different from adding the first one. Example 7-38 shows the configuration for all the backup tunnels on 12008a. Example 7-38 Configuration for All the Backup Tunnels on 12008a12008a#show running-config interface tunnel1 interface Tunnel1 description Link Protection Tunnel (Backup) ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 12.12.12.12 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw global-pool unlimited tunnel mpls traffic-eng path-option 5 explicit name backup1 end 12008a#show running-config interface tunnel2 interface Tunnel2 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 13.13.13.13 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw global-pool unlimited tunnel mpls traffic-eng path-option 5 explicit name backup2 end 12008a#show running-config interface tunnel3 interface Tunnel3 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 14.14.14.14 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw global-pool unlimited tunnel mpls traffic-eng path-option 5 explicit name backup3 end 12008a#show ip explicit paths ip explicit-path name backup1 enable next-address 10.0.13.16 next-address 10.0.87.13 next-address 10.0.86.12 next-address 12.12.12.12 ip explicit-path name backup2 enable next-address 10.0.13.16 next-address 16.16.16.16 ip explicit-path name backup3 enable next-address 10.0.5.7 next-address 10.0.7.16 next-address 16.16.16.16 As you can see, node protection configuration is similar to link protection. The only difference is in the protection tunnel (or tunnels) on the protected interface—how many there are and where they terminate. |
|
|
< Free Open Study > |
|
12008c in 
