Case Study 9-6: Configuring AToM Pseudowire over GRE Tunnel Chapter 3, "Layer 2 VPN Architectures," each label represents an LSP. The top label is responsible for delivering pseudowire packets from one PE router to another through a tunnel LSP; therefore, it is known as the tunnel label. The tunnel label serves as an encapsulation header for the rest of the packet, which has little dependency on the tunnel label. Analogically, the relationship is somewhat like the IP header of an IP packet to the payload it carries. When an IP header or GRE/IP header replaces the tunnel label, the tunnel label has little impact on the pseudowire emulation functionality.This case study explores the deployment model of transporting AToM pseudowire packets over GRE tunnels. Although this model enables you to deploy AToM pseudowires in any IP or MPLS network, they are most advantageous and efficient in networks that do not have MPLS forwarding. For example, the pseudowire endpoints are located in MPLS edge routers with a plain IP core network or two separate MPLS networks connected by a transit network with plain IP forwarding. With pseudowire emulation in MPLS networks, you should choose the native MPLS tunnel label to reduce encapsulation overhead and leverage advanced features, such as MPLS traffic engineering and fast reroute.Forwarding pseudowire traffic over a GRE tunnel is quite similar to that over an MPLS traffic engineering tunnel with the autoroute option, where both IP and pseudowire packets can go through the same tunnel. You cannot use the preferred-path interface command with a GRE tunnel interface.As illustrated in Figure 9-5, the PE routers are enabled with MPLS services, but the core network runs plain IP forwarding only.
Figure 9-5. AToM Pseudowire over GRE Tunnel [View full size image] The following steps configure an AToM pseudowire to traverse the IP network through a GRE tunnel:
Step 1. | Enable MPLS forwarding and set the MPLS label protocol to LDP in the global configuration mode on PE3. PE3(config)#ip cef PE3(config)#mpls ip PE3(config)#mpls label protocol ldp
| Step 2. | Create a loopback interface with a host IP address. PE3(config)#interface Loopback0 PE3(config-if)#ip address 172.16.1.1 255.255.255.255
| Step 3. | Configure a GRE tunnel interface on PE3, and set the tunnel source and destination addresses to be a routable address on PE3 and PE4, respectively. PE3(config-if)#interface Tunnel1 PE3(config-if)#ip unnumbered Loopback0 PE3(config-if)#tunnel source Serial2/0 PE3(config-if)#tunnel destination 172.16.44.1
| Step 4. | To avoid recursive routing loops, make sure the tunnel destination address does not use the tunnel interface as the outgoing interface. It can accomplish this by using static route or dynamic routing protocols. Here, OSPF runs on the core facing network interface. PE3(config)#router ospf 1 PE3(config-router)#network 172.16.34.0 0.0.0.255 area 0
| Step 5. | Enable MPLS forwarding on the GRE tunnel interface. This step is necessary so that MPLS applications see the tunnel interface as a feasible outgoing interface for MPLS traffic. PE3(config-if)#interface Tunnel1 PE3(config-if)#mpls ip
| Step 6. | Add a static route to redirect pseudowire traffic into the tunnel interface. PE3(config)#ip route 172.16.1.2 255.255.255.255 Tunnel1
| Step 7. | Provision an AToM pseudowire on the CE-facing interface. PE3(config)#interface Ethernet0/0.1 PE3(config-subif)#encapsulation dot1Q 100 PE3(config-subif)#xconnect 172.16.1.2 100 encapsulation mpls
| Step 8. | Repeat Steps 1 through 7 on PE4 with appropriate parameters. | Step 9. | Verify the tunnel interface status and encapsulation using the show interface and show adjacency commands. PE3#show interface Tunnel1 Tunnel1 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Loopback0 (172.16.1.1) MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 172.16.34.1 (Serial2/0), destination 172.16.44.1 Tunnel protocol/transport GRE/IP, sequencing disabled Tunnel TTL 255 Key disabled Checksumming of packets disabled, fast tunneling enabled Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 25314 packets input, 2578630 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 26389 packets output, 2905870 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out PE3#show adjacency Tunnel1 detail Protocol Interface Address TAG Tunnel1 point2point(5) 2148 packets, 856752 bytes 4500000000000000FF2F15ACAC102201 AC102C0100008847 TFIB never Epoch: 0 IP Tunnel1 point2point(7) 0 packets, 0 bytes 4500000000000000FF2F15ACAC102201 AC102C0100000800 CEF expires: 00:02:16 refresh: 00:00:16 Epoch: 0
The output of the show adjacency command contains two adjacency entries. The tag adjacency is for MPLS traffic, such as the AToM pseudowire traffic, and the IP adjacency is for IP traffic. Notice that the GRE tunnel encapsulation for switching MPLS traffic consists of an IP header and a GRE header. The IP header contains an IP protocol type 47 (0x2F) indicating a payload GRE packet, and the tunnel source and destination addresses are in hex format (0xAC102201, 0xAC102C01). The GRE header has a protocol type 0x8847 for MPLS unicast traffic. |
Step 1. | Verify the pseudowire status by using the show mpls l2transport vc detail command. PE3#show mpls l2transport vc 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: imp-null, next hop point2point Output interface: Tu1, imposed label stack {16} Create time: 17:47:08, last status change time: 17:46:36 Signaling protocol: LDP, peer 172.16.1.2:0 up MPLS VC labels: local 16, 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 1070, send 1070 byte totals: receive 398956, send 398956 packet drops: receive 0, send 0
Notice that the output interface of the pseudowire is the GRE tunnel interface. The tunnel label is the implicit null label, as if the two PE routers are connected directly. |
After you complete these steps, view the configuration on PE3, as shown in Example 9-20.Example 9-20. PE3 Configuration for AToM Pseudowire over GRE Tunnel
hostname PE3 ! ip cef mpls label protocol ldp ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! interface Tunnel1 ip unnumbered Loopback0 mpls ip tunnel source Serial2/0 tunnel destination 172.16.44.1 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 172.16.1.2 100 encapsulation mpls ! interface Serial2/0 ip address 172.16.34.1 255.255.255.0 ! router ospf 1 network 172.16.34.0 0.0.0.255 area 0 ! ip route 172.16.1.2 255.255.255.255 Tunnel1
The PE4 configuration is shown in Example 9-21.Example 9-21. PE4 Configuration for AToM Pseudowire over GRE Tunnel
hostname PE4 ! ip cef mpls label protocol ldp ! interface Loopback0 ip address 172.16.1.2 255.255.255.255 ! interface Tunnel1 ip unnumbered Loopback0 mpls ip tunnel source Serial2/0 tunnel destination 172.16.34.1 ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.1 encapsulation dot1Q 100 xconnect 172.16.1.1 100 encapsulation mpls ! interface Serial2/0 ip address 172.16.44.1 255.255.255.0 ! router ospf 1 network 172.16.44.0 0.0.0.255 area 0 ! ip route 172.16.1.1 255.255.255.255 Tunnel1
|