Case Study 9-6: Configuring AToM Pseudowire over GRE Tunnel
Typically, when AToM pseudowire packets traverse an MPLS network, they carry label stacks that have more than one label. As described in 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.
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
 |
