لطفا منتظر باشید ...
Preferred Path
When a given destination has multiple equal-cost paths, the load-sharing algorithm used in AToM distributes pseudowires to all available paths by default, and users do not have the option of choosing which pseudowire goes through which output path.
If network operators want to choose a particular output path for a given pseudowire, they can configure a preferred path and associate it with the pseudowire. AToM provides two options to configure preferred paths for pseudowires: IP routing and MPLS traffic engineering.
Before starting the discussion on preferred path options, it is worthwhile to reiterate that the IP address configured in the xconnect ip_address vc_id command must always be the router ID that the remote PE router uses for Label Distribution Protocol (LDP) signaling. The router ID is the first four bytes in the LDP ID. The show mpls ldp neighbor and show mpls ldp discovery commands display the LDP IDs of the local PE router and its neighbors (see Example 9-12).
Example 9-12. LDP Neighbors and Their LDP IDs
PE1#show mpls ldp neighbor
Peer LDP Ident: 10.33.23.1:0; Local LDP Ident 10.1.1.1:0
TCP connection: 10.33.23.1.11000 - 10.1.1.1.646
State: Oper; Msgs sent/rcvd: 5548/5548; Downstream
Up time: 3d08h
LDP discovery sources:
Ethernet1/0, Src IP addr: 10.23.12.2
Addresses bound to peer LDP Ident:
10.33.23.1 10.23.12.2
Peer LDP Ident: 10.23.11.2:0; Local LDP Ident 10.1.1.1:0
TCP connection: 10.23.11.2.11142 - 10.1.1.1.646
State: Oper; Msgs sent/rcvd: 125/126; Downstream
Up time: 01:30:57
LDP discovery sources:
Serial3/0, Src IP addr: 10.23.11.2
Addresses bound to peer LDP Ident:
10.23.11.2 10.23.21.1 10.43.11.2
Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
TCP connection: 10.1.1.2.11003 - 10.1.1.1.646
State: Oper; Msgs sent/rcvd: 136/137; Downstream
Up time: 01:30:53
LDP discovery sources:
Targeted Hello 10.1.1.1 -> 10.1.1.2, active, passive
Addresses bound to peer LDP Ident:
10.1.1.2 10.23.21.2 10.23.23.1 10.1.1.200
10.1.1.201
PE1#show mpls ldp discovery
Local LDP Identifier:
10.1.1.1:0
Discovery Sources:
Interfaces:
Ethernet1/0 (ldp): xmit/recv
LDP Id: 10.33.23.1:0
Serial3/0 (ldp): xmit/recv
LDP Id: 10.23.11.2:0
Targeted Hellos:
10.1.1.1 -> 10.1.1.2 (ldp): active/passive, xmit/recv
LDP Id: 10.1.1.2:0
Three LDP signaling sessions are available, as shown in the show mpls ldp neighbor command output. PE1 establishes two nontargeted LDP sessions with P1 and P2 to exchange IGP labels, which serve as tunnel labels for pseudowire packets. The targeted LDP session between PE1 and PE2 is for pseudowire signaling. The first four bytes of the LDP ID for PE2 are 10.1.1.2, its router ID. The targeted LDP session for pseudowire signaling uses the local and remote router IDs as the source and destination addresses. When no preferred path is configured for a pseudowire, an output path is selected based on the remote router ID in the forwarding table for pseudowire packets.
The preferred path option not only allows pseudowire data packets to flow through a different path from pseudowire control packets, but it also makes it possible to provide differentiated services to pseudowires with different forwarding requirements. For example, you can place pseudowires that carry voice traffic to a special traffic-engineered path with low latency and jitter; you can place pseudowires that remotely back up a large amount of data for file servers to a best-effort path that allows high bursts.
To configure a preferred path, you first need to configure a pseudowire class and associate it with the pseudowire. A pseudowire class configures common attributes for a group of pseudowires. For AToM pseudowires, the encapsulation for the pseudowire class is MPLS, as shown in Example 9-13.
Example 9-13. Configuring a Pseudowire Class
PE1(config)#pseudowire-class PE1-P1-PE2
PE1(config-pw-class)#encapsulation mpls
To associate a pseudowire with a pseudowire class, use the pw-class keyword in the xconnect command, as shown in Example 9-14.
Example 9-14. Configuring an xconnect Command with a Pseudowire Class
PE1(config)#interface Ethernet0/0.2
PE1(config-subif)#xconnect 10.1.1.2 200 pw-class PE1-P1-PE2
The following case studies discuss how to use IP routing and MPLS traffic engineering to select preferred paths for pseudowires.
Case Study 9-3: Configuring Preferred Path Using IP Routing
Whichever method is chosen to configure a preferred path, the basic and usually overlooked prerequisite for a PE to establish network connectivity to a remote PE is a host route entry of the remote PE and its corresponding label in its forwarding tables. The host route, also known as the /32 route, and its label ensure that the local PE has an end-to-end contiguous label-switched path (LSP) to the remote PE. Any non-host route, such as a subnet route or summary route, does not guarantee the connectivity requirement even if a subnet or summary route network covers the range to which the host route belongs.
Case Study 9-9: BGP IPv4 Label Distribution with IBGP Peering," explains this topic in more detail.
Host routes such as router IDs are typically configured on loopback interfaces. A relatively simple way to specify a preferred path for AToM pseudowires is to configure multiple loopback interfaces with different host addresses.
The preferred-path peer host_address command configures a preferred path using a host address. For example, 10.1.1.200 is a host route configured in a loopback interface on PE2, and PE1 configures a pseudowire class that takes the preferred path to reach 10.1.1.200. When forwarding pseudowire packets to PE2, PE1 uses 10.1.1.200 instead of PE2's router ID 10.1.1.2 to look up the output interface in the forwarding tables (see Example 9-15).
Example 9-15. Configuring Preferred Path Using IP Routing
PE1(config)#pseudowire-class PE1-P1-PE2
PE1(config-pw-class)#encapsulation mpls
PE1(config-pw-class)#preferred-path peer 10.1.1.200 ?
disable-fallback disable fall back to alternative route
Besides the preferred path, each pseudowire also computes a default path using the remote router ID that is configured in the xconnect command. If a preferred path is not found or active, pseudowires that are configured with the preferred path automatically fall back to the default path. The disable-fallback option turns off this default behavior so that pseudowires remain down until the preferred path becomes available.
In Case Study 9-2, the default load-sharing hash algorithm assigns pseudowires to different output interfaces. The pseudowire with VC ID 100 takes Interface Serial3/0, pseudowire 200 takes Interface Ethernet1/0, and pseudowire 300 takes Interface Serial3/0. Figure 9-2 shows two available paths between PE1 and PE2. In this case study, you will learn how to configure a pseudowire to associate with a particular output path.
Figure 9-2. Preferred Path with IP Routing
Load Sharing" section. In the following configuration steps, the pseudowire with VC ID 100 still takes the default path assigned by the load-sharing algorithm, but pseudowire 200 takes the preferred path through P1, and pseudowire 300 takes the path through P2 and P3, as shown in Figure 9-2.
At the end of Step 8, the pseudowire with VC ID 100 is going through the default path, and pseudowire 200 is going through the preferred path toward 10.1.1.200, with the output interface Serial3/0 connected to P1. Pseudowire 300 is going through the preferred path toward 10.1.1.201, with the output interface Ethernet1/0 connected to P2.
Example 9-16 is the complete configuration on PE1 for sending pseudowire traffic toward PE2 over preferred paths:
Example 9-16. Configuration for Preferred Path Using IP Routing
hostname PE1
!
ip cef
mpls label protocol ldp
mpls ldp router-id Loopback0
pseudowire-class PE1-P1-PE2
encapsulation mpls
preferred-path peer 10.1.1.200
!
pseudowire-class PE1-P2-P3-PE2
encapsulation mpls
preferred-path peer 10.1.1.201
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.1
encapsulation dot1Q 100
xconnect 10.1.1.2 100 encapsulation mpls
!
interface Ethernet0/0.2
encapsulation dot1Q 200
xconnect 10.1.1.2 200 pw-class PE1-P1-PE2
!
interface Ethernet0/0.3
encapsulation dot1Q 300
xconnect 10.1.1.2 300 pw-class PE1-P2-P3-PE2
!
interface Ethernet1/0
ip address 10.23.12.1 255.255.255.0
mpls ip
!
interface Serial3/0
ip address 10.23.11.1 255.255.255.0
mpls ip
!
router ospf 1
network 10.1.1.1 0.0.0.0 area 0
network 10.23.11.0 0.0.0.255 area 0
network 10.23.12.0 0.0.0.255 area 0
!
ip route 10.1.1.200 255.255.255.255 10.23.11.2
ip route 10.1.1.201 255.255.255.255 10.23.12.2
If PE2 needs to send pseudowire traffic to PE1 over the same preferred path, repeat Steps 1 through 8 with appropriate parameters on PE2.
Case Study 9-4: Configuring a Preferred Path Using MPLS Traffic Engineering Tunnels
In "Case Study 9-3: Configuring Preferred Path Using IP Routing," PE1 can select an output interface for a pseudowire using IP routing, but it cannot control how P1, P2, and P3 route the pseudowire traffic. For example, if P1 also has a link connecting to P2 and P3, as illustrated in Figure 9-3, using IP routing to select the preferred path on PE1 cannot guarantee the pseudowire traffic always flows from P1 to PE2. It is entirely possible that the traffic goes through P1 and P3 and then finally arrives at PE2.
Figure 9-3. Preferred Path with MPLS Traffic Engineering
[View full size image]
The dynamic nature of IGP routing protocols makes it difficult to engineer explicit paths in a meshed network, and it is not always feasible to configure static routes on all the routers along the path. Explicit paths are useful when network operators know the traffic pattern of their networks and want to direct certain traffic through predetermined paths. It takes the guesswork out of predicting how the traffic traverses across the network. An MPLS traffic engineering tunnel with an explicit path option fulfills this objective precisely.
When real-time traffic is encapsulated inside pseudowires, pseudowire traffic must be able to reserve and maintain the bandwidth needed to guarantee the service quality at a reasonable level. When network operators care more about reducing jitter and congestion for real-time traffic than directing traffic through a predetermined path, an MPLS traffic engineering tunnel with dynamic path option is more appropriate; this means that as long as a path satisfies the specified bandwidth requirement, it is considered a feasible path.
The preferred-path interface tunnel command configures a preferred path using the MPLS traffic engineering tunnel interface, as shown in Example 9-17.
Example 9-17. Configuring Preferred Path Using Traffic Engineering Tunnel
PE1(config)#pseudowire-class PE1-P1-PE2
PE1(config-pw-class)#encapsulation mpls
PE1(config-pw-class)#preferred-path interface Tunnel1 ?
disable-fallback disable fall back to alternative route
Case Study 9-6: Configuring AToM Pseudowire over GRE Tunnel," describes how to configure AToM pseudowires over GRE tunnels.
The disable-fallback option works the same way as in the previous case study, which disables the use of the default forwarding path when the preferred path is unavailable.
Assume that the initial configuration is identical to Example 9-1. In the following configuration steps, two pseudowires take the preferred paths set up by MPLS traffic engineering tunnels on PE1. Pseudowire with VC ID 200 goes through the traffic engineering tunnel with an explicit path through P1 and PE2, and pseudowire 300 goes through the traffic engineering tunnel with 5-Mbps guaranteed bandwidth:
Step 1. | Enable MPLS traffic engineering globally on PE1.
|
Step 2. | Configure MPLS-enabled interfaces to support RSVP traffic engineering signaling. For interface Ethernet1/0, reserve 8000-Kbps bandwidth. For interface Serial3/0, reserve 1200-Kbps bandwidth.
|
Step 3. | Configure OSPF for MPLS traffic engineering.
|
Step 4. | Repeat Steps 1 through 3 on P1, P2, P3, and PE2, and in Step 2, substitute the interface and bandwidth parameters accordingly. Configure RSVP bandwidth reservation on all MPLS interfaces that the traffic engineering tunnels might traverse. |
Step 5. | On PE1, configure an MPLS traffic engineering tunnel with an explicit path through P1 and PE2, of which the addresses are 10.23.11.2 and 10.23.21.2, respectively. The bandwidth requirement for this traffic engineering tunnel is 1000 Kbps.
|
Step 6. | Verify the status of the MPLS traffic engineering tunnel with the explicit path using the show mpls traffic-eng tunnels command.
From the output of the show mpls traffic-eng tunnels command, the MPLS traffic tunnel uses the interface Serial3/0 as the output interface and takes the explicit path to P1 and PE2. The tunnel takes the shortest path through P2 and P3 if no path constraint is imposed on the tunnel. |
Step 7. | Verify that the intermediate router P1 sets up the traffic engineering tunnel properly.
Notice that the incoming label for the tunnel is 16 on Serial2/0. This should be the tunnel imposition label that PE1 uses for the pseudowires that are going through this traffic engineering tunnel. The outgoing label is implicit-null on Serial3/0, which means that the interface is connected directly to the tunnel tailend PE2. |
Step 8. | On PE1, configure an MPLS traffic engineering tunnel with 5-Mbps guaranteed bandwidth.
|
Step 9. | Verify the status of the MPLS traffic engineering tunnel by using the show mpls traffic-eng tunnels command.
|
Step 10. | Verify that the intermediate routers P2 and P3 set up the traffic engineering tunnel properly.
Notice that on P2, the incoming label for the tunnel is 22 on Ethernet1/0. This should be the tunnel imposition label that PE1 uses for the pseudowires that are going through this traffic engineering tunnel. On P3, the outgoing label is implicit-null on Ethernet1/0, which means that the interface is connected directly to the tunnel tailend PE2. |
Step 11. | Verify that the PE2 sets up both traffic engineering tunnels correctly as the tailend.
|
Step 12. | Configure a pseudowire class with a preferred path going through the explicit path.
Notice that the disable-fallback option is enabled to prevent the traffic from taking the default route when the traffic engineering tunnel becomes unavailable. |
Step 13. | Configure a pseudowire class that prefers a high-bandwidth path.
Because the disable-fallback option is not present, the traffic takes the default route when the high-bandwidth traffic engineering tunnel becomes unavailable. |
Step 14. | Provision the pseudowire of VC ID 200 with the explicit path and pseudowire 300 with the high-bandwidth path.
|
Step 15. | Verify that pseudowires are active and taking the specified path by using the show mpls l2transport vc detail command.
Note that the default path for pseudowires 100 and 300 is established through LDP, not Resource Reservation Protocol (RSVP) Traffic Engineering. The default path is disabled for pseudowire 200 by using the disable-fallback option. The traffic engineering tunnel labels for pseudowires 200 and 300 are 16 and 22, respectively, which match the traffic engineering labels that P1 and P2 assign. Because the traffic engineering tunnels are from PE1 to PE2, the forwarding process on PE1 perceives PE2 as if it were directly connected through the tunnel interfaces. Therefore, the tunnel label fields have a label value of 3, which is the implicit-null label. |
Upon completion of these steps, the network has two MPLS traffic engineering tunnels established from PE1 to PE2. Traffic engineering tunnels are always unidirectional. If you want the same forwarding properties for pseudowire traffic from PE2 to PE1, PE2 needs to configure its own traffic engineering tunnels toward PE1 by repeating Steps 5 through 15 with appropriate parameters.
Caution
When you are using an MPLS traffic engineering tunnel as a preferred path for pseudowires, you need to make sure that the tunnel endpoints (headend and tailend) are on the PE routers that provision these pseudowires.
After you complete these steps, the configuration on PE1 is shown in Example 9-18.
Example 9-18. Configuration for Preferred Path Using MPLS Traffic Engineering Tunnel
hostname PE1
!
ip cef
mpls label protocol ldp
mpls ldp router-id Loopback0
mpls traffic-eng tunnels
pseudowire-class PE1-P1-PE2
encapsulation mpls
preferred-path interface Tunnel1 disable-fallback
!
pseudowire-class High_Bandwidth
encapsulation mpls
preferred-path interface Tunnel2
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 10.1.1.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng path-option 1 explicit name P1-PE2
!
interface Tunnel2
ip unnumbered Loopback0
tunnel destination 10.1.1.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 5000
tunnel mpls traffic-eng path-option 1 dynamic
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.1
encapsulation dot1Q 100
xconnect 10.1.1.2 100 encapsulation mpls
!
interface Ethernet0/0.2
encapsulation dot1Q 200
xconnect 10.1.1.2 200 pw-class PE1-P1-PE2
!
interface Ethernet0/0.3
encapsulation dot1Q 300
xconnect 10.1.1.2 300 pw-class High_Bandwidth
!
interface Ethernet1/0
ip address 10.23.12.1 255.255.255.0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 8000
!
interface Serial3/0
ip address 10.23.11.1 255.255.255.0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 1200
!
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
network 10.1.1.1 0.0.0.0 area 0
network 10.23.11.0 0.0.0.255 area 0
network 10.23.12.0 0.0.0.255 area 0
!
ip explicit-path name P1-PE2 enable
next-address 10.23.11.2
next-address 10.23.21.2
Besides using the preferred-path interface command, you can also direct pseudowire traffic to an MPLS traffic engineering tunnel by using the preferred-path peer command. The net effect is similar to using IP routing for the preferred path. The only difference is that the specified /32 host route has a traffic engineering tunnel interface as the output interface instead of a physical interface in the forwarding table.
When the traffic engineering tunnel is configured with the autoroute option, IGP can learn the host route through the traffic engineering tunnel interface. As a result, IGP forwards both IP and pseudowire packets through the traffic engineering tunnel for the routing prefixes it learns through the tunnel. To enable the autoroute option, configure the tunnel mpls traffic-eng autoroute announce command under the tunnel interface configuration mode.
