When two attachment circuits (ACs) should be connected by a pseudowire but the attached PE routers are in different autonomous systems, the PE routers cannot exchange IGP routes with each other. In multi-AS networks, autonomous system border routers (ASBRs) establish Border Gateway Protocol (BGP) connections with each other to exchange routes between different autonomous systems.
Figure 9-6 illustrates an example of connecting ACs across the autonomous system boundary. Suppose that the AC of Ethernet VLAN 100 on CE1 in AS100 needs to be connected to the one on CE4 in AS200, and the AC of Ethernet VLAN 200 on CE2 in AS100 needs to be connected to the one on CE3 in AS200. The following case studies present three different solutions to accomplish the goal. Each solution has its own merits and applicable deployment scenarios.
The configuration and routing that are necessary for forwarding IP traffic in a multi-AS environment are complex, and adding pseudowire emulation services does not make network operation much easier. However, the solution discussed in this case study takes a simplistic approach.
Instead of building end-to-end pseudowires across the autonomous system boundary, each ASBR acts as a PE router and provides pseudowire emulation services. Essentially, each ASBR treats the peering ASBR in a different domain as a CE router and the links between the ASBRs as ACs. In the pseudowire emulation architecture, the connectivity between CE and PE devices is at Layer 2. In theory, Layer 3 connectivity is not required between ASBRs if only pseudowire emulation services are required. However, ASBRs typically provide interdomain routing services, too, so Layer 3 connectivity is configured in the example. MPLS forwarding is not required between ASBRs in this deployment model.
As shown in Figure 9-7, a pseudowire with VC ID 100 is provisioned between PE1 and ASBR1 in AS100. A pseudowire with VC ID 100 is also provisioned between PE4 and ASBR2 in AS200. To have end-to-end connectivity between CE1 and CE4, ASBR1 and ASBR2 allocate a dedicated Ethernet VLAN 100 and use it as the common AC for both pseudowires. It is not mandatory for both pseudowires to have the same VC ID, but it is a good self-documenting practice. Similarly, CE2 and CE3 are connected by concatenating a pseudowire to a dedicated Ethernet VLAN 200 and then to another pseudowire. BGP is configured between ASBRs to exchange interdomain routing information, but it is not essential for inter-AS pseudowire emulation in this particular case.
The following configuration examples give you some ideas of how to configure the PE and ASBR routers to use dedicated circuits between autonomous systems to provide inter-AS pseudowire connectivity.
On PE1, configure the pseudowire with VC ID 100 on the AC that connects to CE1, as shown in Example 9-22.
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.3 100 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
On PE2, configure the pseudowire with VC ID 200 on the AC that connects to CE2, as shown in Example 9-23.
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.2 encapsulation dot1Q 200 xconnect 10.1.1.3 200 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
On PE3, configure the pseudowire with VC ID 200 on the AC that connects to CE3, as shown in Example 9-24.
hostname PE3 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 172.16.1.3 200 encapsulation mpls ! interface Serial2/0 ip address 172.16.34.1 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.1 0.0.0.0 area 0 network 172.16.34.0 0.0.0.255 area 0
On PE4, configure the pseudowire with VC ID 100 on the AC that connects to CE4, as shown in Example 9-25.
hostname PE4 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.2 255.255.255.255 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 172.16.1.3 100 encapsulation mpls ! interface Serial2/0 ip address 172.16.44.1 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.2 0.0.0.0 area 0 network 172.16.44.0 0.0.0.255 area 0
When you are using dedicated circuits between ASBRs, ensure that the encapsulation of these circuits matches that of the ACs between CE and PE routers, because the ASBRs effectively act as PE routers. In this example, the connection between ASBR1 and ASBR2 is Ethernet.
On ASBR1, configure the pseudowire with VC ID 100 and the pseudowire with VC ID 200 on the corresponding dedicated circuits, as shown in Example 9-26.
hostname ASBR1 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 10.1.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR2 in AS200 ip address 172.16.100.1 255.255.255.0 ! 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.2 200 encapsulation mpls ! interface Ethernet1/0 ip address 10.43.11.2 255.255.255.0 mpls ip ! router ospf 1 network 10.1.1.3 0.0.0.0 area 0 network 10.43.11.0 0.0.0.255 area 0 ! router bgp 100 no synchronization neighbor 172.16.100.2 remote-as 200 no auto-summary
On ASBR2, configure the pseudowire with VC ID 100 and the pseudowire with VC ID 200 on the corresponding dedicated circuits, as shown in Example 9-27.
hostname ASBR2 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR1 in AS100 ip address 172.16.100.2 255.255.255.0 ! interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 172.16.1.2 100 encapsulation mpls ! interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 172.16.1.1 200 encapsulation mpls ! interface Ethernet1/0 ip address 172.16.24.2 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.3 0.0.0.0 area 0 network 172.16.24.0 0.0.0.255 area 0 ! router bgp 200 no synchronization neighbor 172.16.100.1 remote-as 100 no auto-summary
When considering this deployment model for inter-AS pseudowire emulation services, you need to evaluate the following restrictions that are associated with it:
To be interconnected, the Layer 2 encapsulation of the links between ASBRs must be identical to that of the ACs.
The number of dedicated circuits or virtual circuits between ASBRs can be limited. For example, ASBR1 and ASBR2 are connected through an Ethernet connection that can support up to 4096 802.1q VLANs, which is 4096 dedicated circuits at most.
In the future, when you can replace dedicated circuits with pseudowires for inter-AS pseudowire emulation services, these restrictions should be eliminated.
Note
A new pseudowire emulation solution is being developed at press time to replace the dedicated circuits between ASBRs with pseudowires. In other words, disjointed pseudowires of different autonomous systems can be interconnected through another set of pseudowires that is established between ASBRs. You can imagine that the end-to-end connectivity is provided by "stitching" several pseudowires together. By replacing dedicated circuits with pseudowires, pseudowire emulation in multi-AS networks achieves better flexibility and scalability.
To provide edge-to-edge network connectivity for pseudowires within a single autonomous system, you need to have the /32 host routes of PE routers and the corresponding labels, which you learn through IGP and LDP (or RSVP if you are using MPLS traffic engineering). One solution for obtaining the same level of connectivity in a multi-AS environment is by using external BGP (eBGP) to exchange the /32 host routes of PE devices and the corresponding labels across the autonomous system boundaries and then redistributing the /32 host routes learned through EBGP into IGP. From the point of view of the PE routers, this is similar to the single autonomous system scenario except that the /32 host routes appear to be of IGP external types in the routing tables. Instead of using LDP, ASBRs piggyback IPv4 label information along with the host route advertisements in BGP update messages so that ASBRs can set up LSPs between one another for these host routes. Figure 9-8 illustrates such an example.
To provide the same end-to-end inter-AS pseudowire emulation services, you configure PE1, PE2, PE3, and PE4 identically to "Case Study 9-7: Interconnecting Pseudowires with Dedicated Circuits," except the pseudowire endpoint addresses. On ASBR1 and ASBR2, BGP is configured to announce /32 host routes of PE1, PE2, PE3, and PE4 to the remote autonomous system. To distribute IPv4 labels for these routes, ASBR1 and ASBR2 specify the send-label keyword in the BGP neighbor command.
The following configuration gives you some examples of how to configure the PE and ASBR routers to use BGP IPv4 label distribution with IGP redistribution to provide inter-AS pseudowire connectivity.
On PE1, configure the router ID and the pseudowire with VC ID 100 on the AC that connects to CE1, as shown in Example 9-28.
interface Loopback0 ip address 10.1.1.1 255.255.255.255 interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 172.16.1.2 100 encapsulation mpls
On PE2, configure the router ID and the pseudowire with VC ID 200 on the AC that connects to CE2, as shown in Example 9-29.
interface Loopback0 ip address 10.1.1.2 255.255.255.255 interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 172.16.1.1 200 encapsulation mpls
On PE3, configure the router ID and the pseudowire with VC ID 200 on the AC that connects to CE3, as shown in Example 9-30.
interface Loopback0 ip address 172.16.1.1 255.255.255.255 interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 10.1.1.2 200 encapsulation mpls
On PE4, configure the router ID and the pseudowire with VC ID 100 on the AC that connects to CE4, as shown in Example 9-31.
interface Loopback0 ip address 172.16.1.2 255.255.255.255 interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 10.1.1.1 100 encapsulation mpls
On ASBR1, configure BGP IPv4 label distribution and redistribute BGP routes into OSPF, as shown in Example 9-32.
hostname ASBR1 ! ip cef mpls label protocol ldp ! interface Loopback0 ip address 10.1.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR2 in AS200 ip address 172.16.100.1 255.255.255.0 ! interface Ethernet1/0 ip address 10.43.11.2 255.255.255.0 mpls ip ! router ospf 1 redistribute bgp 100 subnets network 10.1.1.3 0.0.0.0 area 0 network 10.43.11.0 0.0.0.255 area 0 default-metric 20 ! router bgp 100 neighbor 172.16.100.2 remote-as 200 ! address-family ipv4 neighbor 172.16.100.2 activate neighbor 172.16.100.2 send-label no auto-summary no synchronization network 10.1.1.1 mask 255.255.255.255 network 10.1.1.2 mask 255.255.255.255 exit-address-family
On ASBR2, configure BGP IPv4 label distribution and redistribute BGP routes into OSPF, as shown in Example 9-33.
hostname ASBR2 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR1 in AS100 ip address 172.16.100.2 255.255.255.0 ! interface Ethernet1/0 ip address 172.16.24.2 255.255.255.0 mpls ip ! router ospf 1 redistribute bgp 200 subnets network 172.16.1.3 0.0.0.0 area 0 network 172.16.24.0 0.0.0.255 area 0 default-metric 20 ! router bgp 200 neighbor 172.16.100.1 remote-as 100 ! address-family ipv4 neighbor 172.16.100.1 activate neighbor 172.16.100.1 send-label no auto-summary no synchronization network 172.16.1.1 mask 255.255.255.255 network 172.16.1.2 mask 255.255.255.255 exit-address-family
On ASBR1 and ASBR2, the /32 addresses of the PE routers appear as BGP routes, as shown in Example 9-34.
ASBR1#show ip route bgp 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks B 172.16.1.1/32 [20/75] via 172.16.100.2, 03:29:45 B 172.16.1.2/32 [20/75] via 172.16.100.2, 03:29:45 ASBR2#show ip route bgp 10.0.0.0/32 is subnetted, 2 subnets B 10.1.1.2 [20/31] via 172.16.100.1, 03:31:51 B 10.1.1.1 [20/31] via 172.16.100.1, 03:31:51
These routes are redistributed into OSPF and appear as OSPF External type 2 routes in the routing tables of the PE devices. Example 9-35 shows the routing table entries for PE1 in AS100 and PE3 in AS200.
PE1#show ip route ospf 172.16.0.0/32 is subnetted, 2 subnets O E2 172.16.1.1 [110/20] via 10.23.12.2, 03:16:11, Ethernet1/0 O E2 172.16.1.2 [110/20] via 10.23.12.2, 03:16:11, Ethernet1/0 10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks O 10.23.21.0/24 [110/84] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.1.2.1/32 [110/21] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.1.1.2/32 [110/31] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.1.1.3/32 [110/31] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.23.23.0/24 [110/30] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.1.2.3/32 [110/21] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.1.2.2/32 [110/11] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.43.11.0/24 [110/30] via 10.23.12.2, 03:16:11, Ethernet1/0 O 10.33.23.0/24 [110/20] via 10.23.12.2, 03:16:11, Ethernet1/0 PE3#show ip route ospf 172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks O 172.16.44.0/24 [110/128] via 172.16.34.2, 03:16:07, Serial2/0 O 172.16.24.0/24 [110/74] via 172.16.34.2, 03:16:07, Serial2/0 O 172.16.1.3/32 [110/75] via 172.16.34.2, 03:16:07, Serial2/0 O 172.16.1.2/32 [110/129] via 172.16.34.2, 03:16:07, Serial2/0 10.0.0.0/32 is subnetted, 2 subnets O E2 10.1.1.2 [110/20] via 172.16.34.2, 03:16:07, Serial2/0 O E2 10.1.1.1 [110/20] via 172.16.34.2, 03:16:07, Serial2/0
One caveat for this deployment model is that /32 host routes are injected into the IGP routing domain through redistributions; therefore, every transit router in the same IGP routing domain installs these host routes. As shown in Example 9-36, transit routers P1, P2, and P3 all see the host routes for PE3 and PE4 in their routing tables, and P4 has host routes for PE1 and PE2.
P1#show ip route ospf 172.16.0.0/32 is subnetted, 2 subnets O E2 172.16.1.1 [110/20] via 10.43.11.2, 00:01:31, Ethernet1/0 O E2 172.16.1.2 [110/20] via 10.43.11.2, 00:01:31, Ethernet1/0 10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks O 10.1.1.2/32 [110/21] via 10.33.23.3, 08:34:35, Ethernet0/0 O 10.1.1.3/32 [110/11] via 10.43.11.2, 08:34:35, Ethernet1/0 O 10.23.23.0/24 [110/20] via 10.33.23.3, 08:34:35, Ethernet0/0 O 10.1.2.3/32 [110/11] via 10.33.23.3, 08:34:35, Ethernet0/0 O 10.1.2.2/32 [110/11] via 10.33.23.2, 08:34:35, Ethernet0/0 O 10.1.1.1/32 [110/21] via 10.33.23.2, 08:34:35, Ethernet0/0 O 10.23.12.0/24 [110/20] via 10.33.23.2, 08:34:35, Ethernet0/0
Using IGP redistribution of BGP routes, all transit routers in the IGP routing domain install the routes to their routing tables. If the BGP routing database also contains Internet routes, the number of entries that is redistributed into IGP is enormous. Applying route maps that only allow PE host routes to be redistributed at ASBRs can mitigate the IGP routing table explosion. However, when the number of host routes to be filtered increases, the configuration task becomes quite tedious and the routing table size of the transit routers still grows. To solve this problem, PE routers can establish internal BGP (IBGP) sessions with ASBRs within the same autonomous system so that external routes are distributed via IBGP sessions. This confines the external routes within the BGP routing domain, and the transit routers that do not participate in BGP routing never see these external routes.
Figure 9-9 shows an example of inter-AS pseudowire emulation that uses IBGP peering. PE1, PE2, and ASBR1 belong to the same autonomous system. PE1 and PE2 are configured with IBGP peering to ASBR1 to learn host routes for PE3 and PE4. Similarly, PE3 and PE4 are configured with IBGP peering to ASBR2 to learn host routes for PE1 and PE2.
After the IBGP sessions are established, these host routes are still missing in the routing tables on PE devices. For example, the routing table on PE1 does not have the entry for PE4 (see Example 9-37).
PE1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks O 10.23.21.0/24 [110/84] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.1.2.1/32 [110/21] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.1.1.2/32 [110/31] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.1.1.3/32 [110/31] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.23.23.0/24 [110/30] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.1.2.3/32 [110/21] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.1.2.2/32 [110/11] via 10.23.12.2, 02:59:03, Ethernet1/0 C 10.1.1.1/32 is directly connected, Loopback0 C 10.23.12.0/24 is directly connected, Ethernet1/0 C 10.23.11.0/24 is directly connected, Serial3/0 O 10.43.11.0/24 [110/30] via 10.23.12.2, 02:59:03, Ethernet1/0 O 10.33.23.0/24 [110/20] via 10.23.12.2, 02:59:03, Ethernet1/0
A closer examination of the BGP routing table on PE1 reveals the problem. The host route entry 172.16.1.2 for PE4 exists in the BGP routing table, but its next-hop address, 172.16.100.2, is inaccessible from PE1 (see Example 9-38).
PE1#show ip bgp 172.16.1.2
BGP routing table entry for 172.16.1.2/32, version 68
Paths: (1 available, no best path)
Not advertised to any peer
200
172.16.100.2 (inaccessible) from 10.1.1.3 (10.1.1.3)
Origin IGP, metric 75, localpref 100, valid, internal
The address 172.16.100.2 is of the interface Ethernet0/0 on ASBR2, which announces the host route 172.16.1.2 with the next-hop address set to 172.16.100.2. When ASBR1 relays this host route to PE1 through IBGP, the next-hop address is kept intact by default. The interface Ethernet0/0 on ASBR1 is directly connected to the interface Ethernet0/0 on ASBR2. Typically, IGP routing is not enabled on these interfaces, which means the interfaces are not reachable from the PE routers through IGP routing. You can fix this problem in several ways. For example, you can enable IGP routing on these interfaces and set them as passive interfaces, or you can configure the ASBRs as the next hop in the IBGP peering. For the sake of simplicity, the ASBRs are configured with the next-hop-self keyword in the BGP neighbor command for the IBGP peers in this case study.
PE1 sees that the host route of PE4 is reachable through ASBR1 in its routing table, and transit routers such as P2 do not have these host routes in their routing table (see Example 9-39).
PE1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR Gateway of last resort is not set 172.16.0.0/32 is subnetted, 2 subnets B 172.16.1.1 [200/75] via 10.1.1.3, 00:37:57 B 172.16.1.2 [200/75] via 10.1.1.3, 00:37:57 10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks O 10.23.21.0/24 [110/84] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.1.2.1/32 [110/21] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.1.1.2/32 [110/31] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.1.1.3/32 [110/31] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.23.23.0/24 [110/30] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.1.2.3/32 [110/21] via 10.23.12.2, 04:25:50, Ethernet1/0 O 10.1.2.2/32 [110/11] via 10.23.12.2, 04:25:50, Ethernet1/0 C 10.1.1.1/32 is directly connected, Loopback0 C 10.23.12.0/24 is directly connected, Ethernet1/0 C 10.23.11.0/24 is directly connected, Serial3/0 O 10.43.11.0/24 [110/30] via 10.23.12.2, 04:25:51, Ethernet1/0 O 10.33.23.0/24 [110/20] via 10.23.12.2, 04:25:51, Ethernet1/0 P2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks O 10.23.21.0/24 [110/74] via 10.33.23.1, 12:06:10, Ethernet0/0 O 10.1.2.1/32 [110/11] via 10.33.23.1, 12:06:10, Ethernet0/0 O 10.1.1.2/32 [110/21] via 10.33.23.3, 12:06:10, Ethernet0/0 O 10.1.1.3/32 [110/21] via 10.33.23.1, 12:06:10, Ethernet0/0 O 10.23.23.0/24 [110/20] via 10.33.23.3, 12:06:10, Ethernet0/0 O 10.1.2.3/32 [110/11] via 10.33.23.3, 12:06:10, Ethernet0/0 C 10.1.2.2/32 is directly connected, Loopback0 O 10.1.1.1/32 [110/11] via 10.23.12.1, 12:06:10, Ethernet1/0 C 10.23.12.0/24 is directly connected, Ethernet1/0 O 10.23.11.0/24 [110/74] via 10.33.23.1, 12:06:10, Ethernet0/0 [110/74] via 10.23.12.1, 12:06:10, Ethernet1/0 O 10.43.11.0/24 [110/20] via 10.33.23.1, 12:06:10, Ethernet0/0 C 10.33.23.0/24 is directly connected, Ethernet0/0
In previous case studies, in which host routes of PE routers are exchanged through IGP, having /32 host routes and the corresponding labels is sufficient for establishing pseudowires. In this example, PE1 has a /32 route and the corresponding label to PE4. If the AToM pseudowire is configured and its status is up, it gives the impression that the pseudowire functions fully. Based on the output of the show ip cef and show mpls l2transport vc commands in Example 9-40, the pseudowire with VC ID 100 has a label stack of {27 16}. Label 27 is the tunnel label, and label 16 is the VC label.
PE1#show ip cef 172.16.1.2
172.16.1.2/32, version 83, epoch 0, cached adjacency 10.23.12.2
0 packets, 0 bytes
tag information from 10.1.1.3/32, shared, all rewrites owned
local tag: 28
fast tag rewrite with Et1/0, 10.23.12.2, tags imposed {27}
via 10.1.1.3, 0 dependencies, recursive
next hop 10.23.12.2, Ethernet1/0 via 10.1.1.3/32 (Default)
valid cached adjacency
tag rewrite with Et1/0, 10.23.12.2, tags imposed {27}
PE1#show mpls l2transport vc 100 detail
Local interface: Et0/0.1 up, line protocol up, Eth VLAN 100 up
Destination address: 172.16.1.2, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 27, next hop 10.23.12.2
Output interface: Et1/0, imposed label stack {27 16}
Create time: 00:00:35, last status change time: 00:00:30
Signaling protocol: LDP, peer 172.16.1.2:0 up
MPLS VC labels: local 21, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 0, send 6
byte totals: receive 0, send 728
packet drops: receive 0, send 0
When you send packets from CE1 to CE4, CE4 never receives anything even though the counters for packets sent increase on PE1. Apparently, IP connectivity is fine between PE1 and PE4, because the LDP session that is used for pseudowire signaling functions properly. With that in mind, the problem might be related to how the pseudowire packets are forwarded.
Tracking down the pseudowire packet forwarding path from PE1 through the intermediate routers and all the way to ASBR1, use the show mpls forwarding-table command to examine the MPLS label forwarding actions. On Router P2, label 27 gets swapped with label 24, which results in a new label stack {24 16} for the pseudowire packets (see Example 9-41).
P2#show mpls forwarding-table labels 27 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 27 24 10.1.1.3/32 640453 Et0/0 10.33.23.1
On Router P3, the top label 24 is removed, which leaves the label stack at {16} (see Example 9-42). Note that label 16 is the VC label for the pseudowire packets.
P3#show mpls forwarding-table labels 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 24 Pop tag 10.43.11.0/24 0 Et0/0 10.33.23.1
When labeled pseudowire packets arrive at ASBR1, the last label 16 in the label stack is removed according to the MPLS forwarding table, which leaves the pseudowire packets unlabeled (see Example 9-43).
ASBR1#show mpls forwarding-table labels 16 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 10.33.23.0/24 0 Et1/0 10.43.11.1
Under normal operations, PE routers that are provisioned with pseudowires assign the VC labels. Therefore, they should be the label switching routers that remove the VC labels and process the rest of the pseudowire packets. In other words, intermediate label switching routers should not remove VC labels from the label stack. ASBR1 does not act as a PE router in this case study, so removing VC labels on ASBR1 is a mistake.
The cause of the problem lies in the interaction between the routing process and the label distribution process. In all previous case studies, a router that advertises a given route through a routing protocol also advertises the label that is associated with that route through a label distribution protocol, but that is not the case here. PE1 learns the host route 172.16.1.2 from ASBR1 through IBGP with the next-hop address set to ASBR1, but PE1 does not learn the label that is associated with the host route from ASBR1. You can observe this behavior by using the show ip bgp labels command, as shown in Example 9-44.
PE1#show ip bgp labels Network Next Hop In label/Out label 172.16.1.1/32 10.1.1.3 nolabel/nolabel 172.16.1.2/32 10.1.1.3 nolabel/nolabel
The absence of the label for 172.16.1.2 does not impose a problem for IP packets because IP packets can always be forwarded unlabeled in an MPLS network. This fact explains how PE1 and PE4 can establish a targeted LDP session and exchange VC labels for the pseudowire. On the other hand, PE1 does not have an end-to-end contiguous LSP to reach PE4, which means the MPLS packets cannot reach PE4. The partial LSP is between PE1 and ASBR1 because PE1 does have an LSP to reach the next-hop address 10.1.1.3.
To eliminate the MPLS connectivity problem and create an end-to-end contiguous LSP, ASBR1 needs to send the corresponding label and the host route for 172.16.1.2 to PE1. In other words, besides enabling IPv4 label distribution over the EBGP session between ASBR1 and ASBR2, as described in "Case Study 9-8: BGP IPv4 Label Distribution with IGP Redistribution," the IBGP sessions between PE and ASBR also need to distribute IPv4 labels for the host routes that are being advertised. After adding the send-label keyword to the BGP neighbor command for the IBGP peers on PE and ASBR, PE1 obtains label 32 for the host route 172.16.1.2 from IBGP (see Example 9-45).
PE1#show ip bgp label Network Next Hop In label/Out label 172.16.1.1/32 10.1.1.3 nolabel/31 172.16.1.2/32 10.1.1.3 nolabel/32
From the show ip cef and show mpls l2transport vc commands, the pseudowire with VC ID 100 now has a label stack of {27 32 16}. Label 16 is still the VC label, but to reach PE4, it requires two labels: Label 27 is the IGP label to reach ASBR1 that has the address 10.1.1.3, and label 32 is the BGP IPv4 label assigned by ASBR1 to reach PE4 that has the address 172.16.1.2 (see Example 9-46).
PE1#show ip cef 172.16.1.2
172.16.1.2/32, version 85, epoch 0, cached adjacency 10.23.12.2
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: BGP route head
fast tag rewrite with Et1/0, 10.23.12.2, tags imposed {27 32}
via 10.1.1.3, 0 dependencies, recursive
next hop 10.23.12.2, Ethernet1/0 via 10.1.1.3/32 (Default)
valid cached adjacency
tag rewrite with Et1/0, 10.23.12.2, tags imposed {27 32}
PE1#show mpls l2transport vc 100 detail
Local interface: Et0/0.1 up, line protocol up, Eth VLAN 100 up
Destination address: 172.16.1.2, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 32, next hop 10.23.12.2
Output interface: Et1/0, imposed label stack {27 32 16}
Create time: 07:38:14, last status change time: 07:38:09
Signaling protocol: LDP, peer 172.16.1.2:0 up
MPLS VC labels: local 21, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 29, send 465
byte totals: receive 8308, send 176142
packet drops: receive 0, send 8
When sending packets from CE1 to CE4 again, they arrive at ASBR1 with a label stack {32 16} this time. The show mpls forwarding-table command on ASBR1 further confirms that pseudowire packets are properly forwarded to ASBR2 through an LSP, as shown in Example 9-47.
ASBR1#show mpls forwarding-table labels 32 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 32 17 172.16.1.2/32 36750 Et0/0 172.16.100.2
After you complete the configuration on all PEs and ASBRs, you can accomplish the end-to-end inter-AS pseudowire connectivity by using BGP IPv4 label distribution with IBGP peering.
The following configuration gives you some examples of how to configure the PE and ASBR routers to use BGP IPv4 label distribution with IBGP peering to provide inter-AS pseudowire connectivity.
On PE1, configure BGP IPv4 label distribution with IBGP peering and the pseudowire with VC ID 100, as shown in Example 9-48.
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 172.16.1.2 100 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 ! router bgp 100 neighbor 10.1.1.3 remote-as 100 neighbor 10.1.1.3 update-source Loopback0 ! address-family ipv4 neighbor 10.1.1.3 activate neighbor 10.1.1.3 send-label no auto-summary no synchronization exit-address-family
On PE2, configure BGP IPv4 label distribution with IBGP peering and the pseudowire with VC ID 200, as shown in Example 9-49.
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.2 encapsulation dot1Q 200 xconnect 172.16.1.1 200 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 ! router bgp 100 neighbor 10.1.1.3 remote-as 100 neighbor 10.1.1.3 update-source Loopback0 ! address-family ipv4 neighbor 10.1.1.3 activate neighbor 10.1.1.3 send-label no auto-summary no synchronization exit-address-family
On PE3, configure BGP IPv4 label distribution with IBGP peering and the pseudowire with VC ID 200, as shown in Example 9-50.
hostname PE3 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.2 encapsulation dot1Q 200 xconnect 10.1.1.2 200 encapsulation mpls ! interface Serial2/0 ip address 172.16.34.1 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.1 0.0.0.0 area 0 network 172.16.34.0 0.0.0.255 area 0 ! router bgp 200 neighbor 172.16.1.3 remote-as 200 neighbor 172.16.1.3 update-source Loopback0 ! address-family ipv4 neighbor 172.16.1.3 activate neighbor 172.16.1.3 send-label no auto-summary no synchronization exit-address-family
On PE4, configure BGP IPv4 label distribution with IBGP peering and the pseudowire with VC ID 100, as shown in Example 9-51.
hostname PE4 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.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 Serial2/0 ip address 172.16.44.1 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.2 0.0.0.0 area 0 network 172.16.44.0 0.0.0.255 area 0 ! router bgp 200 neighbor 172.16.1.3 remote-as 200 neighbor 172.16.1.3 update-source Loopback0 ! address-family ipv4 neighbor 172.16.1.3 activate neighbor 172.16.1.3 send-label no auto-summary no synchronization exit-address-family
On ASBR1, configure BGP IPv4 label distribution with both EBGP and IBGP peers, as shown in Example 9-52.
hostname ASBR1 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 10.1.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR2 in AS200 ip address 172.16.100.1 255.255.255.0 ! interface Ethernet1/0 ip address 10.43.11.2 255.255.255.0 mpls ip ! router ospf 1 network 10.1.1.3 0.0.0.0 area 0 network 10.43.11.0 0.0.0.255 area 0 ! router bgp 100 neighbor 10.1.1.1 remote-as 100 neighbor 10.1.1.1 update-source Loopback0 neighbor 10.1.1.2 remote-as 100 neighbor 10.1.1.2 update-source Loopback0 neighbor 172.16.100.2 remote-as 200 ! address-family ipv4 neighbor 10.1.1.1 activate neighbor 10.1.1.1 next-hop-self neighbor 10.1.1.1 send-label neighbor 10.1.1.2 activate neighbor 10.1.1.2 next-hop-self neighbor 10.1.1.2 send-label neighbor 172.16.100.2 activate neighbor 172.16.100.2 send-label no auto-summary no synchronization network 10.1.1.1 mask 255.255.255.255 network 10.1.1.2 mask 255.255.255.255 exit-address-family
On ASBR2, configure BGP IPv4 label distribution with both EBGP and IBGP peers, as shown in Example 9-53.
hostname ASBR2 ! ip cef mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 172.16.1.3 255.255.255.255 ! interface Ethernet0/0 description Connect to ASBR1 in AS100 ip address 172.16.100.2 255.255.255.0 ! interface Ethernet1/0 ip address 172.16.24.2 255.255.255.0 mpls ip ! router ospf 1 network 172.16.1.3 0.0.0.0 area 0 network 172.16.24.0 0.0.0.255 area 0 ! router bgp 200 neighbor 172.16.1.1 remote-as 200 neighbor 172.16.1.1 update-source Loopback0 neighbor 172.16.1.2 remote-as 200 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.100.1 remote-as 100 ! address-family ipv4 neighbor 172.16.1.1 activate neighbor 172.16.1.1 next-hop-self neighbor 172.16.1.1 send-label neighbor 172.16.1.2 activate neighbor 172.16.1.2 next-hop-self neighbor 172.16.1.2 send-label neighbor 172.16.100.1 activate neighbor 172.16.100.1 send-label no auto-summary no synchronization network 172.16.1.1 mask 255.255.255.255 network 172.16.1.2 mask 255.255.255.255 exit-address-family