Load SharingWhen more than one path exists between the source and destination, load sharing often becomes an important factor for better bandwidth utilization. You can deploy load sharing in many different ways. Load sharing is sometimes completely transparent to pseudowire traffic if it only involves core routers in the network. The case studies in this section focus on the load-sharing scenarios that involve provider edge (PE) routers performing pseudogwire emulation over MPLS. More precisely, an ingress PE router sees more than one path to reach the egress PE router for pseudowire traffic. Service providers normally deploy standard-based routing protocols in the core networks, such as Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS), which support Equal-Cost Multipath (ECMP) load sharing. With these routing protocols, only routes that have the least cost to a given destination are shown in the forwarding table. If multiple equal-cost routes go to the same destination, all of them are installed in the forwarding table. Depending on the traffic type and forwarding configuration, packets with the same destination are distributed across these paths. Note The total number of equal-cost routes available depends on with Cisco IOS releases and hardware platform specifications. The load-sharing scheme used in AToM ensures that packets being transmitted over a given pseudowire follow the same path, and packets of different pseudowires are spread across all available equal-cost paths. The first aspect of this scheme is to minimize the possibility of out-of-order packets because of load sharing. Some Layer 2 protocols or higher layer protocols do not function or their performance is drastically penalized when packets are delivered out of order. Packets that are transmitted over a single pseudowire are generally considered part of the same data flow, which is likely of the same protocol or application. Putting packets of the same flow through the same path reduces the likelihood that they will be misordered in the core network. The second aspect of this scheme mandates that the load-sharing scheme used in AToM utilizes a hashing algorithm to assign pseudowires to equal-cost paths. By default, the remote virtual circuit (VC) label of a pseudowire acts as the hash key to calculate the outgoing path. Because of this, pseudowire packets that have the same remote VC label are sent through the same path. Again, the rationale behind this is to keep these packets in the same data flow and to minimize out-of-order packets. Figure 9-1 shows a network topology with multiple paths between PE1 and PE2. Suppose that the core network is configured with OSPF as the Interior Gateway Protocol (IGP). Figure 9-1. Multipath Network TopologyPE1 has an initial configuration, shown in Example 9-1. Example 9-1. Initial Pseudowire Configuration
hostname PE1 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! 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 encapsulation mpls ! interface Ethernet0/0.3 encapsulation dot1Q 300 xconnect 10.1.1.2 300 encapsulation mpls ! 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 The initial configuration on PE2 is shown in Example 9-2. Example 9-2. PE2 Initial Pseudowire Configuration
hostname PE2 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 10.1.1.2 255.255.255.255 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 10.1.1.1 100 encapsulation mpls ! interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 10.1.1.1 200 encapsulation mpls ! interface Ethernet0/0.3 encapsulation dot1Q 300 xconnect 10.1.1.1 300 encapsulation mpls ! interface Ethernet1/0 ip address 10.23.23.1 255.255.255.0 mpls ip ! interface Serial3/0 ip address 10.23.21.2 255.255.255.0 mpls ip ! router ospf 1 network 10.1.1.2 0.0.0.0 area 0 network 10.23.21.0 0.0.0.255 area 0 network 10.23.23.0 0.0.0.255 area 0 The following case study sections discuss how PE routers make path selection decisions for pseudowire traffic when these types of forwarding paths are present: Case Study 9-1: Unequal-Cost Multipath Case Study 9-2: Equal-Cost Multipath Case Study 9-1: Unequal-Cost MultipathWith open standard IGP routing protocols such as OSPF and IS-IS, only routes that have the lowest cost are installed in the forwarding table. Therefore, for cases in which multiple paths point to the same destinations but each has a different cost, only one path is selected for packet forwarding. In Example 9-3, PE1 and PE2 are connected through P1 using T1 links and through P2 and P3 using Ethernet links. By default, the OSPF cost is 64 for T1 links and 10 for Ethernet links. Example 9-3. SPF Costs on PE1 Interfaces
PE1#show ip ospf interface serial3/0 Serial3/0 is up, line protocol is up Internet Address 10.23.11.1/24, Area 0 Process ID 1, Router ID 10.1.1.1, Network Type POINT_TO_POINT, Cost: 64 PE1#show ip ospf interface ethernet1/0 Ethernet1/0 is up, line protocol is up Internet Address 10.23.12.1/24, Area 0 Process ID 1, Router ID 10.1.1.1, Network Type BROADCAST, Cost: 10 To reach the loopback interface on PE1 and PE2, you must take the cost of the loopback interface into account, as shown in Example 9-4. Example 9-4. SPF Cost on PE1 Loopback Interface
PE1#show ip ospf interface loopback0 Loopback0 is up, line protocol is up Internet Address 10.1.1.1/32, Area 0 Process ID 1, Router ID 10.1.1.1, Network Type LOOPBACK, Cost: 1 The cost for PE1 to go through P1 to reach PE2 is 64 + 64 + 1 = 129, whereas the cost to go through P2 and P3 is 10 + 10 + 10 + 1 = 31. The least-cost path to the destination 10.1.1.2 is through P2 and P3, thus chosen by the routing protocol to forward data packets. You can observe this through the show command in Example 9-5. Example 9-5. SPF Cost to PE2 Loopback Interface
PE1#show ip route 10.1.1.2 Routing entry for 10.1.1.2/32 Known via "ospf 1", distance 110, metric 31, type intra area Last update from 10.23.12.2 on Ethernet1/0, 00:52:57 ago Routing Descriptor Blocks: * 10.23.12.2, from 10.1.1.2, 00:52:57 ago, via Ethernet1/0 Route metric is 31, traffic share count is 1 Because Ethernet1/0 is the only outgoing interface that the routing protocol chooses to reach the destination, all AToM pseudowires on PE1 take that interface (see Example 9-6). Example 9-6. A Single Lowest-Cost Path Selected on PE1
PE1#show mpls l2transport summary Destination address: 10.1.1.2, total number of vc: 3 0 unknown, 3 up, 0 down, 0 admin down 3 active vc on MPLS interface Et1/0 PE2 has a similar result to PE1, as shown in Example 9-7. Example 9-7. A Single Lowest-Cost Path Selected on PE2PE2#show mpls l2transport summary Destination address: 10.1.1.1, total number of vc: 3 0 unknown, 3 up, 0 down, 0 admin down 3 active vc on MPLS interface Et1/0 Case Study 9-2: Equal-Cost MultipathIn the previous case study, all AToM pseudowires took a single outgoing path when all feasible outgoing paths had different costs. Example 9-8 uses the same topology and configuration, but the cost of the link between P2 and P3 is increased so that the overall cost for the path going through P2 and P3 becomes equal to the one through P1. As a result, the routing table on PE1 now shows it has two equal-cost paths to the destination. Example 9-8. Two Equal-Cost Paths to PE2 Loopback InterfacePE1#show ip route 10.1.1.2 Routing entry for 10.1.1.2/32 Known via "ospf 1", distance 110, metric 129, type intra area Last update from 10.23.12.2 on Ethernet1/0, 00:00:14 ago Routing Descriptor Blocks: * 10.23.11.2, from 10.1.1.2, 00:00:14 ago, via Serial3/0 Route metric is 129, traffic share count is 1 10.23.12.2, from 10.1.1.2, 00:00:14 ago, via Ethernet1/0 Route metric is 129, traffic share count is 1 In Example 9-9, you see that PE2 has a similar result to PE1. Example 9-9. Two Equal-Cost Paths to PE1 Loopback InterfacePE2#show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "ospf 1", distance 110, metric 129, type intra area Last update from 10.23.23.2 on Ethernet1/0, 00:00:41 ago Routing Descriptor Blocks: * 10.23.21.1, from 10.1.1.1, 00:00:41 ago, via Serial3/0 Route metric is 129, traffic share count is 1 10.23.23.2, from 10.1.1.1, 00:00:41 ago, via Ethernet1/0 Route metric is 129, traffic share count is 1 When equal-cost paths are available, AToM attempts to distribute pseudowires among them. On PE1 and PE2, the show mpls l2transport summary command demonstrates that AToM pseudowires are assigned to different output interfaces, as shown in Example 9-10. Example 9-10. Pseudowires Load Share Across Equal-Cost Paths
PE1#show mpls l2transport summary Destination address: 10.1.1.2, total number of vc: 3 0 unknown, 3 up, 0 down, 0 admin down 2 active vc on MPLS interface Se3/0 1 active vc on MPLS interface Et1/0 PE2#show mpls l2transport summary Destination address: 10.1.1.1, total number of vc: 3 0 unknown, 3 up, 0 down, 0 admin down 2 active vc on MPLS interface Et1/0 1 active vc on MPLS interface Se3/0 Notice that PE1 and PE2 come up with different ideas for how to load share the pseudowires. For all three provisioned pseudowires, PE1 distributes two of them to the serial interface, which takes P1 as the next-hop router towards PE2; PE2 distributes two of the pseudowires to the Ethernet interface, which takes P3 as the next-hop router toward PE1. This means that one of the pseudowires selects the path through P1 in the direction from PE1 to PE2, but it takes the path through P3 and P2 in the return direction from PE2 to PE1. For this particular pseudowire, PE1 transmits its packets to PE2 through P1, and PE2 transmits its packets to PE1 through P3 and P2. This is not really a problem or mistake. Packets of this pseudowire being transmitted in each direction still follow the same path. IP/MPLS traffic is generally considered unidirectional, and the routing protocol is free to choose different equal-cost paths for packets sent in different directions. It is normal for the core network to route packets under the default hop-by-hop and best-effort forwarding scheme. On the other hand, if the core network engages in traffic engineering techniques and prefers explicit paths for pseudowire traffic, you need to associate AToM pseudowires with these explicit paths. The next section discusses preferred paths in more detail. Under the default forwarding scheme, the show mpls l2transport vc detail command reveals how the underlying load-sharing algorithm works when equal-cost paths are present (see Example 9-11). Example 9-11. Load Sharing Selects Different Output Interfaces for Pseudowires
PE1#show mpls l2transport vc detail
Local interface: Et0/0.1 up, line protocol up, Eth VLAN 100 up
Destination address: 10.1.1.2, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop point2point
Output interface: Se3/0, imposed label stack {17 22}
Create time: 2d10h, last status change time: 2d10h
Signaling protocol: LDP, peer 10.1.1.2:0 up
MPLS VC labels: local 21, remote 22
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
!Output omitted for brevity
Local interface: Et0/0.2 up, line protocol up, Eth VLAN 200 up
Destination address: 10.1.1.2, VC ID: 200, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop 10.23.12.2
Output interface: Et1/0, imposed label stack {17 25}
Create time: 2d10h, last status change time: 2d10h
Signaling protocol: LDP, peer 10.1.1.2:0 up
MPLS VC labels: local 22, remote 25
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
!Output omitted for brevity
Local interface: Et0/0.3 up, line protocol up, Eth VLAN 300 up
Destination address: 10.1.1.2, VC ID: 300, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop point2point
Output interface: Se3/0, imposed label stack {17 26}
Create time: 2d10h, last status change time: 2d10h
Signaling protocol: LDP, peer 10.1.1.2:0 up
MPLS VC labels: local 23, remote 26
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
!Output omitted for brevity
On PE1, AToM pseudowires of VC ID 100, 200, and 300 have a remote VC label of 22, 25, and 26 respectively. Because two equal-cost paths are available, the algorithm uses the remote VC labels, such as the hash key, to calculate an index value for each pseudowire. Then the index value maps to a hash bucket that corresponds to one of the two output paths. The hash buckets for pseudowires of VC ID 100 and 300 map to the same output interface; therefore, they take the same output path. |