This section covers case studies of Layer 2 VPN IW. Multiple variations of Ethernet and IP IW using both AToM and L2TPv3 are covered using the network shown in Figure 14-3.
Note
The LDP and targeted LDP configuration and sessions apply only to the AToM cases.
All case studies use a common initial configuration, which includes the following:
Create a loopback interface and assign a /32 IP address to it.
Enable IP Cisco Express Forwarding (CEF) globally.
For AToM cases, enable MPLS globally and select Label Distribution Protocol (LDP) as the label distribution protocol. Specify the loopback interface's IP address as the LDP router ID.
By using point-to-point serial interfaces that are running Cisco High-Level Data Link Control (HDLC) between PE and P routers, unnumber those interfaces' IP addresses to the previously defined loopback. This effectively reduces the number of IP addresses to one for all core routers.
For AToM cases, enable LDP in all PE-to-P interfaces.
Enable an Interior Gateway Protocol (IGP) among the core routers. These case studies use Open Shortest Path First (OSPF) with a single area 0.
The initial configuration including MPLS is shown for the SanFran PE router. The Denver and New York configurations are analogous to this one (see Example 14-1).
! hostname SanFran ! ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force ! interface Loopback0 ip address 10.0.0.201 255.255.255.255 ! interface Serial10/0 ip unnumbered Loopback0 mpls ip ! router ospf 1 log-adjacency-changes network 10.0.0.201 0.0.0.0 area 0
The configuration for Layer 2 IW transport requires the use of a pseudowire class and involves the use of the command interworking {ip | ethernet}. In the upcoming sections, you will learn the configuration and verification for the following IW case studies:
Ethernet (Bridged) IW:
Case Study 14-1: Ethernet-to-VLAN Using AToM
Case Study 14-2: Ethernet-to-VLAN Using L2TPv3
Case Study 14-3: ATM AAL5-to-VLAN Using AToM
IP (Routed) IW:
Case Study 14-4: Frame Relay-to-VLAN Using AToM
Case Study 14-5: Frame Relay-to-PPP Using L2TPv3
Case Study 14-6: IP L2-Transport MTU Considerations
Case Study 14-7: Frame Relay-to-ATM Interworking Best Practices
In this section, you learn to configure bridged IW using both AToM and L2TPv3.
The first case study covers Ethernet-to-VLAN bridged IW using AToM. The topology used is shown in Figure 14-4.
In the case of IW, the attachment circuit configuration required in a PE device does not mirror the remote PE device configuration.
Example 14-2 shows the configuration for the Ethernet side in the SanFran PE.
! hostname SanFran ! pseudowire-class atom-iw-eth-vlan encapsulation mpls interworking ethernet ! interface Ethernet0/0 no ip address no cdp enable xconnect 10.0.0.203 1 pw-class atom-iw-eth-vlan !
From Example 14-2, you can see that the specific configuration requires the interworking ethernet command in the pseudowire-class configuration submode. The xconnect directive is applied to the Ethernet interface. Also note that the no cdp enable command was entered to prevent the PE from sending CDP packets to the CE. The PE device does not discover the CE device as a Cisco Discovery Protocol (CDP) neighbor, because the PE device does not inspect CDP packets coming from the CE; instead, these packets are transported over the pseudowire. However, if you did not disable CDP in the attachment circuit, the PE sends CDP packets out the attachment circuit, and the local CE discovers the PE in addition to the remote CE. You disable CDP to prevent the CE from "seeing" the PE device.
Example 14-3 shows the configuration for the 802.1q VLAN side in the NewYork PE.
! hostname NewYork ! pseudowire-class atom-iw-eth-vlan encapsulation mpls interworking ethernet ! interface Ethernet0/0 no ip address no cdp enable ! interface Ethernet0/0.1 encapsulation dot1Q 1 no cdp enable xconnect 10.0.0.201 1 pw-class atom-iw-eth-vlan !
The VLAN PE side is similar to the Ethernet side, except that the xconnect command is applied to the dot1Q subinterface. Also, remember to disable CDP in the Ethernet main interface and subinterface so that you do not send CDP packets to the CE device.
The CE configuration is included in Example 14-4 for both Oakland and Albany CEs for comparison.
! Oakland CE Ethernet attachment circuit configuration ! hostname Oakland ! interface Ethernet0/0 ip address 192.168.27.1 255.255.255.0 ! ! Albany CE VLAN attachment circuit configuration ! hostname Albany ! interface Ethernet0/0 no ip address ! interface Ethernet0/0.1 encapsulation dot1Q 1 ip address 192.168.27.2 255.255.255.0 !
Example 14-5 shows that the AToM L2transport circuit is UP. It also shows other detailed information captured from the NewYork side.
NewYork#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------ --------------------- ------------- --------- ----------
Et0/0.1 Eth VLAN 1 10.0.0.201 1 UP
NewYork#show mpls l2transport vc detail
Local interface: Et0/0.1 up, line protocol up, Eth VLAN 1 up
MPLS VC type is Ethernet, interworking type is Ethernet
Destination address: 10.0.0.201, VC ID: 1, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop point2point
Output interface: Se10/0, imposed label stack {17 18}
Create time: 00:20:51, last status change time: 00:20:06
Signaling protocol: LDP, peer 10.0.0.201:0 up
MPLS VC labels: local 18, remote 18
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Sequence number: receive 0, send 0
VC statistics:
packet totals: receive 151, send 30
byte totals: receive 16854, send 8642
packet drops: receive 0, seq error 0, send 0
NewYork#
The first verification is performed using the command show mpls l2transport vc to check that the L2transport VC is UP. You can note some important points using the detail keyword of that command in the NewYork side (VLAN side). The following list explains the first three lines of the output:
Local interface and state Et0/0.1 up, line protocol up. Note that line protocol cannot be detected in the PE Ethernet interfaces because that would imply generating loop packets out of the attachment circuit toward the CE device and intercepting them. Instead, all Ethernet packets received are transported without inspection.
Attachment circuit type and state Eth VLAN 1 up. Note that this refers only to the local attachment circuit type.
VC type Ethernet (VC type 0x0005). Although the attachment circuit (AC) is Ethernet VLAN, the VC type is always Ethernet for bridged IW. Bridged IW uses this VC type for all AC technologies.
Interworking type Ethernet (bridged) as configured under the pseudowire-class atomiw-eth-vlan template. This triggers the use of the Ethernet VC Type.
10.0.0.201 This is the remote PE's router ID configured in the xconnect command.
VC ID 1 as configured in the xconnect command. The VC ID needs to match in both PEs.
VC status: UP The VC status UP means that the VC can carry data between the two endpoints. (Imposition and disposition are programmed.) Two conditions need to hold true:
Disposition interfaces programmed The VC has been configured and the CE interface is up.
Imposition interfaces programmed The disposition interface is programmed, and there is a remote VC label and an IGP label (label-switched path to the peer). Note that for the imposition interface to be programmed, the disposition interface must have been programmed previously.
Even though the first line of the output shows that the attachment circuit is the Ethernet VLAN with a VLAN ID of 1, the VC type that is signaled is Ethernet because of the IW type Ethernet. You can also see this in Example 14-6.
NewYork#show mpls l2transport binding Destination Address: 10.0.0.201, VC ID: 1 Local Label: 18 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV Capabilities: Type 1, Type 2 Remote Label: 18 Cbit: 1, VC Type: Ethernet, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV Capabilities: Type 1, Type 2 NewYork#
In all the pseudowire endpoints that use Ethernet IW, the VC type is 0x0005 for Ethernet regardless of whether the attachment circuits are 802.1q VLAN, ATM AAL5, or Frame Relay.
Each endpoint does behave differently, however, because the attachment circuits differ:
Chapter 7, "LAN Protocols over MPLS Case Studies." There is no difference in imposition or disposition of Ethernet frames or in CLI command output. In fact, the Ethernet side is completely unaware that a remote IW function exists, so its state is no different.
802.1q VLAN The VLAN attachment circuit performs the IW function by the NSP both at imposition and disposition. For example, at disposition, Ethernet frames that are received from the pseudowire are inserted with the 4-byte 802.1q header after the source MAC address. These extra 4 bytes include the 2-byte Ethertype value of 0x8100, indicating 802.1q/802.1p VLAN, followed by the 2 bytes of tag control information (3 bits of class of service [CoS], 1 bit of Canonical Format Identifier [CFI], and 12 bits of VLAN ID equal to 1 in this example). Following these 4 bytes, the next 2 bytes are the ones that originally came after the source MAC addressthat is, Ethertype for Ethernet II and length in the case of 802.3. This new packet is sent over the attachment circuit to the CE device.
It is also worth noting that ARP is end-to-end, because in Ethernet IW, ARP packets are just Ethernet frames with Ethertype 0x0806.
You can see in Figure 14-5 the way the encapsulation changes as the packet traverses from the Oakland CE through the AToM network to the Albany CE and vice versa.
You can see that the NewYork PE inserts the 802.1q header at imposition and removes it at disposition. The 802.1q header is not carried over the pseudowire. You can also see that the LAN FCS is not transported over the pseudowire. The PE routers need to regenerate it at disposition and remove it at imposition.
This case study presents a similar example to Case Study 14-1 but uses L2TPv3 as the pseudowire technology. The topology is included in Figure 14-6. Note that MPLS is not configured.
You can view the configuration required for this case study as a like-to-like L2TPv3 configuration with the additional pseudowire class command interworking ethernet. You can also view it as the same configuration as Case Study 14-1, using the pseudowire class encapsulation l2tpv3 command plus any additional L2TPv3 settings.
Example 14-7 shows the configuration required for the SanFran PE. To highlight the specific IW commands, this example uses default L2TPv3 dynamic configuration under the l2tpv3-iweth-vlan pseudowire-class. Therefore, it employs the L2TP class l2tp_default_class.
! hostname SanFran ! pseudowire-class l2tpv3-iw-eth-vlan encapsulation l2tpv3 interworking ethernet ip local interface Loopback0 ! interface Ethernet1/0 no ip address no cdp enable xconnect 10.0.0.203 2 pw-class l2tpv3-iw-eth-vlan !
Example 14-8 shows the configuration required for the NewYork PE, where the attachment circuit is configured in an 802.1q subinterface.
! hostname NewYork ! pseudowire-class l2tpv3-iw-eth-vlan encapsulation l2tpv3 interworking ethernet ip local interface Loopback0 ! interface Ethernet1/0 no ip address no cdp enable ! interface Ethernet1/0.1 encapsulation dot1Q 2 no cdp enable xconnect 10.0.0.201 2 pw-class l2tpv3-iw-eth-vlan !
The CE configuration is analogous to the previous case study. You can perform verifications using different permutations of the command show l2tun session (see Example 14-9).
NewYork#show l2tun session Session Information Total tunnels 1 sessions 1 Tunnel control packets dropped due to failed digest 0 LocID RemID TunID Username, Intf/ State Vcid, Circuit 39772 21748 12926 2, Et1/0.1:2 est NewYork# NewYork#show l2tun session all Session Information Total tunnels 1 sessions 1 Tunnel control packets dropped due to failed digest 0 Session id 39772 is up, tunnel id 12926 Call serial number is 1808100000 Remote tunnel name is SanFran Internet address is 10.0.0.201 Session is L2TP signalled Session state is established, time since change 08:33:51 587 Packets sent, 120 received 200195 Bytes sent, 13658 received Receive packets dropped: out-of-order: 0 total: 0 Send packets dropped: exceeded session MTU: 0 total: 0 Session vcid is 2 Session Layer 2 circuit, type is Ethernet Vlan, name is Ethernet1/0.1:2 Circuit state is UP L2TP VC type is Ethernet, interworking type is Ethernet Remote session id is 21748, remote tunnel id 48316 DF bit off, ToS reflect disabled, ToS value 0, TTL value 255 No session cookie information available FS cached header information: encap size = 24 bytes 00000000 00000000 00000000 00000000 00000000 00000000 Sequencing is off NewYork#
Using the command show l2tun session without keywords or arguments displays summary information about the L2TPv3 sessions. You can see that the state for the only session is established. You can use the keyword all to obtain detailed information. This information tells you that the session was established successfully using L2TP signaling, that the Layer 2 circuit type is Ethernet VLAN, and that the VC type is Ethernet. Like Ethernet IW using AToM, the VC type is always 0x0005 for Ethernet despite the attachment circuit technology, which is Ethernet VLAN in this case. This command clearly shows that the IW type is Ethernet.
Another command that uses the interworking keyword presents IW-specific information. Refer to Example 14-10, and compare the differences in output from the two PE routers.
SanFran#show l2tun session interworking Session Information Total tunnels 1 sessions 1 Tunnel control packets dropped due to failed digest 0 LocID TunID Peer-address Type IWrk Username, Intf/ Vcid, Circuit 21750 48316 10.0.0.203 ETH - 2, Et1/0 SanFran# NewYork#show l2tun session interworking Session Information Total tunnels 1 sessions 1 Tunnel control packets dropped due to failed digest 0 LocID TunID Peer-address Type IWrk Username, Intf/ Vcid, Circuit 39772 12926 10.0.0.201 VLAN ETH 2, Et1/0.1:2 NewYork#
From Example 14-10, you can see that in the SanFran end, the type is represented as ETH for Ethernet, because that is the attachment circuit type. The IW type (Iwrk) is dashed out, meaning that an NSP IW function is nonexistent, or to be more precise, a NULL IW function exists between Ethernet and Ethernet.
As you know, the Ethernet side is oblivious about the remote NSP IW function. For all the SanFran side knows, the remote end might also be Ethernet.
In contrast, the NewYork side shows the type as VLAN because that is the attachment circuit type. The NSP IW type is shown as ETH for Ethernet, making explicit the fact that there is an NSP function.
ARP packets are also handled end-to-end just the same way as in the AToM bridged IW Case Study 14-1. As a final note that is applicable to both AToM and L2TPv3 Ethernet VLAN attachment circuits, you can use the command show interface to display xconnect statistics (see Example 14-11).
NewYork#show interfaces ethernet 1/0.1
Ethernet1/0.1 is up, line protocol is up
Hardware is Lance, address is 0000.0c00.cb01 (bia 0000.0c00.cb01)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 2.
ARP type: ARPA, ARP Timeout 04:00:00
Xconnect switched:
Pkts In 556, Chars In 75990, Pkts Out 795, Chars Out 91196
NewYork#
This bridged IW case study shows Ethernet IW between ATM AAL5 and Ethernet VLAN attachment circuits using AToM. The objective is to present a minor difference and to emphasize concepts. See Example 14-12 for the SanFran ATM AAL5-specific configuration.
! hostname SanFran ! pseudowire-class atom-iw-atm-vlan encapsulation mpls interworking ethernet ! interface ATM4/0.500 point-to-point mtu 1500 pvc 0/500 l2transport encapsulation aal5snap xconnect 10.0.0.203 500 pw-class atom-iw-atm-vlan ! !
The highlighted lines outline the configuration that is specific to the AAL5 attachment circuit with bridged IW. ATM IW endpoints are sensible only using ATM AAL5 attachment circuits, not cell relay.
Note the MTU setting in the ATM4/0.500 subinterface to match the FastEthernet subinterface MTU and enable the Layer 2 circuit to come up. Some output refers to the Layer 2 circuit as L2Ckt. The other PE configuration is included in Example 14-13.
! hostname NewYork ! pseudowire-class atom-iw-atm-vlan encapsulation mpls interworking ethernet ! interface FastEthernet0/0.500 encapsulation dot1Q 500 xconnect 10.0.0.201 500 pw-class atom-iw-atm-vlan !
You can use the usual verification commands of show mpls l2transport vc and show mpls l2transport binding to confirm control plane status (see Example 14-14).
SanFran#show mpls l2transport vc 500
Local intf Local circuit Dest address VC ID Status
------------- ----------------------- --------------- ---------- ----------
AT4/0.500 ATM AAL5 0/500 10.0.0.203 500 UP
SanFran#show mpls l2transport vc 500 detail
Local interface: AT4/0.500 up, line protocol up, ATM AAL5 0/500 up
MPLS VC type is Ethernet, interworking type is Ethernet
Destination address: 10.0.0.203, VC ID: 500, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: imp-null, next hop 10.0.1.203
Output interface: Fa0/0, imposed label stack {16 25}
Create time: 00:14:22, last status change time: 00:14:22
Signaling protocol: LDP, peer 10.0.0.203:0 up
MPLS VC labels: local 17, remote 25
Group ID: local 5, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Sequence number: receive 0, send 0
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, seq error 0, send 0
SanFran#show mpls l2transport binding 500
Destination Address: 10.0.0.203, VC ID: 500
Local Label: 17
Cbit: 1, VC Type: Ethernet, GroupID: 5
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: Type 1, Type 2
Remote Label: 25
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: Type 1, Type 2
SanFran#
From the output of the command show mpls l2transport vc 500, you can see that the local circuit is an ATM AAL5 VC and the status is UP. When appending the detail keyword, you can also see that although the attachment circuit is ATM AAL5 0/500, the MPLS VC type (PW Type) is 0x0005 for Ethernet. The IW type is also Ethernet. Finally, using the command show mpls l2transport binding 500, you can further prove that for both the ATM AAL5 VC and Ethernet VLAN attachment circuits, the VC type is Ethernet and the MTU that is advertised is 1500 bytes.
In Figure 14-7, the encapsulation changes as the packet traverses from the Oakland CE as bridged Ethernet/802.3 PDUs over AAL5, through the AToM network as Ethernet over MPLS, to the Albany CE as a tagged Ethernet frame and vice versa.
You can see that the NewYork PE inserts the 802.1q header at imposition and removes it at disposition. The LAN FCS is not transported over the pseudowire. The NewYork PE needs to regenerate the LAN FCS at disposition and remove it at imposition. For a bridged frame over AAL5, the organization code is 0x0080C2 for 802.1. Only the PID of 0x0007 indicating 802.3/Ethernet without preserved FCS is supported. Therefore, no LAN FCS exists in the AAL5 attachment circuit.
You need to take specific considerations into account in a switched environment, as shown in Figure 14-8, that are not present in a router environment.
You can see from Figure 14-8 that you have an IW scenario between Ethernet and VLAN in a LAN switch environment. From Figure 14-8, SP SW 1 and SP SW 2 are service provider switches, and CE SW 1 and CE SW 2 are customer switches. The PSN can be either MPLS with AToM pseudowire or IP with L2TPv3 pseudowire.
In this case, you are using bridged IW between Ethernet and VLAN attachment circuits and allowing per-VLAN spanning tree plus (PVST+). Because of the NSP IW function, the VLAN tag is modified, removed, or added. Spanning Tree Protocol (STP) BPDUs sent from the switch contain the source VLAN that the BPDU is sent on in the 802.1q header, but PVST+ also contains the Port VLAN ID (PVID) TLV (type, length, value) field inside the BPDU that identifies the VLAN number of the source port. The result is that the remote CE switch received a BPDU with an outer 802.1q VLAN tag that is different from the VLAN number in the PVID TLV field in the PVST+ BPDU, or even missing. Because of this inconsistency, the BPDU puts the port into a PVID-inconsistent state, blocking the traffic in that VLAN to prevent forwarding loops. This error condition is a result of violating one of the PVST+ rules, ensuring a consistent native VLAN on all bridges. When the inconsistency is detected, a switch logs error messages such as %SPANTREE-2-RX_1QPVIDERR, % SPANTREE-2-RX_BLKPORTPVID, or others depending on the specific configuration and traffic direction. These errors indicate inconsistency between the PVID and the VLAN tag. This consideration also applies to like-to-like Ethernet VLAN mode pseudowires with VLAN rewrite and Frame Relay or ATM to VLAN bridged IW, where a VLAN tag needs to be inserted or removed.
This section explores configuring routed IW using both AToM and L2TPv3. Routed IW uses a new VC type of 11 (0x000B), which was not used before. The AToM imposition function directly encapsulates a raw IP packet inside AToM. That is why the name of VC type 11 is IP Layer2 Transport.
This case study involves configuring and verifying IP IW between Frame Relay and VLAN attachment circuit endpoints. This topology is included in Figure 14-9.
SanFran and Oakland use Frame Relay Internet Engineering Task Force (IETF) encapsulation. SanFran is the LMI data communication equipment (DCE) (Frame Relay switch behavior), and Oakland is the Local Management Interface (LMI) data terminal equipment (DTE). In the case of IP IW, the configuration command that directs the use of IP VC type and consequent transport of IP only is interworking ip. Example 14-15 shows the configuration for the SanFran PE.
! hostname SanFran ! frame-relay switching ! pseudowire-class atom-iw-fr-vlan encapsulation mpls interworking ip ! interface Serial5/0 no ip address encapsulation frame-relay IETF frame-relay intf-type dce ! connect fr-vlan Serial5/0 100 l2transport xconnect 10.0.0.203 100 pw-class atom-iw-fr-vlan ! !
Example 14-15 shows Frame Relay switching globally enabled, so that you can configure the Serial5/0 in the SanFran PE as LMI DCI. In general terms, the configuration is similar to the like-to-like examples, with the addition of the interworking ip pseudowire-class configuration mode command.
Note
On IP IW with Frame Relay attachment circuits, both NLPID (0xCC) and SNAP with Ethertype (0x0800) encapsulations identifying IP as upper layer are recognized.
Because it is necessary to specify the encapsulation (either MPLS or L2TPv3) and the IW type (either Ethernet or IP) in all Ethernet and IP IW cases, the use of a pseudowire-class is mandatory.
The rest of the configuration uses the global connect command with the l2transport keyword to enter the fr-pw-switching configuration mode and then the actual xconnect. See Example 14-16 for the NewYork side of the configuration.
! hostname NewYork ! pseudowire-class atom-iw-fr-vlan encapsulation mpls interworking ip ! interface Ethernet2/0 no ip address no cdp enable ! interface Ethernet2/0.2 encapsulation dot1Q 2 no cdp enable xconnect 10.0.0.201 100 pw-class atom-iw-fr-vlan !
The configuration is similar to the Ethernet VLAN like-to-like case, with the addition of the interworking ip directive. The CE configuration uses a point-to-point Frame Relay subinterface in the Oakland router and does not need inverse ARP or static mapping (see Example 14-17).
Oakland# ! Oakland CE configuration Oakland#show running-config interface serial 5/0.100 Building configuration... Current configuration : 153 bytes ! interface Serial5/0.100 point-to-point ip address 192.168.29.1 255.255.255.252 frame-relay interface-dlci 100 IETF end Oakland# Albany# ! Albany CE configuration Albany#show running-config interface ethernet 2/0.2 Building configuration... Current configuration : 121 bytes ! interface Ethernet2/0.2 encapsulation dot1Q 2 ip address 192.168.29.2 255.255.255.252 end Albany#
You can issue the usual verification shown in Example 14-18 from the SanFran side. You can use the command debug frame-relay pseudowire to display events and errors that occur, binding a Frame Relay data-link connection identifier (DLCI) to a pseudowire.
SanFran#show mpls l2transport vc 100
Local intf Local circuit Dest address VC ID Status
------------- ----------------------- --------------- ---------- ----------
Se5/0 FR DLCI 100 10.0.0.203 100 UP
SanFran#show mpls l2transport vc 100 detail
Local interface: Se5/0 up, line protocol up, FR DLCI 100 up
MPLS VC type is IP, interworking type is IP
Destination address: 10.0.0.203, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 16, next hop point2point
Output interface: Se10/0, imposed label stack {16 19}
Create time: 22:26:36, last status change time: 22:24:17
Signaling protocol: LDP, peer 10.0.0.203:0 up
MPLS VC labels: local 20, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Sequence number: receive 0, send 0
VC statistics:
packet totals: receive 14, send 19
byte totals: receive 1512, send 2052
packet drops: receive 0, seq error 0, send 0
SanFran#show mpls l2transport binding 100
Destination Address: 10.0.0.203, VC ID: 100
Local Label: 20
Cbit: 1, VC Type: IP, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: Type 1, Type 2
Remote Label: 19
Cbit: 1, VC Type: IP, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: Type 1, Type 2
SanFran#
In the SanFran PE, the command show mpls l2transport vc shows that the VC is UP and the attachment circuit is FR DLCI 100. When you use the detail keyword, the VC type of IP (using 0x000B) and the IW type of IP become explicit. The command show mpls l2transport binding displays the VC type as IP for both the local and remote endpoints.
Note
In routed IW, no attachment circuit natively uses the VC type of IP, unlike bridged IW, where Ethernet interfaces use the VC type of Ethernet. As a consequence, the l2transport VCs in both PEs always perform the IP IW function. This is to say that for routed IW, two NSPs are needed. You can see this with the output of the command show mpls l2transport vc detail, by verifying that the attachment circuit type does not match the VC type in either PE.
To see the VC type being advertised, you can use the debug command debug mpls l2transport signaling message, as shown in Example 14-19.
SanFran#debug mpls l2transport signaling message AToM LDP message debugging is on SanFran# 22:44:46: AToM LDP [10.0.0.203]: Sending label mapping msg vc type 11, cbit 1, vc id 100, group id 0, vc label 20, status 0, mtu 1500 22:45:19: AToM LDP [10.0.0.203]: Received label mapping msg, id 3141, graceful restart instance 0 vc type 11, cbit 1, vc id 100, group id 0, vc label 16, status 0, mtu 1500
The highlighted sections of Example 14-19 show the use of the IP Layer 2 transport VC type with a value of 11, both for the LDP label mapping received and sent.
Because you are using a switched Frame Relay DLCI attachment circuit created by means of the connect command, you can utilize the show connection command to view connection status and information. The show connection command is also a troubleshooting tool (see Example 14-20).
SanFran#show connection ID Name Segment 1 Segment 2 State =========================================================================== 1 fr-vlan Se5/0 100 10.0.0.203 100 UP SanFran#show connection name fr-vlan FR/Pseudo-Wire Connection: 1 - fr-vlan Status - UP Segment 1 - Serial5/0 DLCI 100 Segment status: UP Line status: UP PVC status: ACTIVE NNI PVC status: ACTIVE Segment 2 - 10.0.0.203 100 Segment status: UP Requested AC state: UP PVC status: ACTIVE NNI PVC status: ACTIVE Interworking - ip SanFran#
Without keywords, you can see that show connection command displays a summary of connections with their respective state. You can also see that a connection has two segments: segment 1 and segment 2. Identifying a specific connection by connection name or ID gives the connection details. In particular, it lists the status of each segment, including the segment status, line or attachment circuit status, PVC status, and NNI status. The PVC status refers to the local DLCI status, and the NNI status refers to the status of the DLCI as learned through NNI from the CE device.
The detailed version of the show connection command also shows that the IW type is IP between segment 1, which is the local Frame Relay DLCI, and segment 2, which is the pseudowire plus the remote endpoint attachment circuit of the pseudowire connection identified by the remote peer IP address and VC ID.
In the earlier section titled "Interworking MTU Considerations," you learned that because IW pseudowires use diverse interfaces, they are more prone toward MTU mismatches between attachment circuits. In a FR-VLAN IW case, the Frame Relay attachment circuit might be located in a POS interface with a default MTU of 4470, and the VLAN might reside in an Ethernet subinterface with a default MTU of 1500. To solve this problem, you might be tempted to consider changing the MTU in the POS interface to match the 1500 bytes. However, that would affect every DLCI on that interface, including the IW DLCIs that have a remote attachment circuit in an ATM interface with a default MTU of 4470. Example 14-21 presents the optimal solution for this problem, achieved by modifying the MTU per DLCI under connect mode.
SanFran(config)#connect POS_to_Ethernet POS 8/0 200 l2transport SanFran(config-fr-pw-switching)#mtu 1500 SanFran(config-fr-pw-switching)#xconnect 10.0.0.203 200 encapsulation mpls SanFran(config-fr-pw-switching)#end SanFran#
Note
Specifying the MTU under the connect configuration mode is Frame Relay specific, because the xconnect command is not applied to a subinterface for Frame Relay DLCI attachment circuits. In other attachment circuit types such as Ethernet or ATM, the MTU can be changed under the subinterface where the xconnect command is applied and affect a single pseudowire.
To finalize this case study, capture an IP IW AToM packet in the C-HDLC link between the SanFran PE router and the Denver P router using the debug command debug mpls l2transport packet data. See Example 14-22, including an inline decode.
22:43:38: ATOM imposition: out Se10/0, size 116, EXP 0x0, seq 0, control word 0x0 22:43:38: 0F 00 88 47 00 01 00 FF 00 01 31 02 00 00 00 00 ^^ ^^ ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ | | | top_shim VC_Label Ctrl-word | | | Label=16 Label=19 | | | S=0 S=1 | | | TTL=255 TTL=2 | | +-etype = IPv4 | +-Control +-Address = Unicast Frame 22:43:38: 45 00 00 64 00 13 00 00 FF 01 00 32 C0 A8 1D 01 ^^^ ... Begins IP Packet 22:43:38: C0 A8 1D 02 08 00 0B B7 00 03 00 04 00 00 00 00 22:43:38: 04 E0 6D AC AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD 22:43:38: ATOM disposition: in Se10/0, size 100, seq 0, control word 0x0 22:43:38: 45 00 00 64 00 13 00 00 FF 01 00 32 C0 A8 1D 02 ^^^ ... Begins IP Packet 22:43:38: C0 A8 1D 01 00 00 13 B7 00 03 00 04 00 00 00 00 22:43:38: 04 E0 6D AC AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD 22:43:38: AB CD AB CD
Note
Note that in Example 14-22, the offline hand decoding of the packets is shown in bold font.
From Example 14-22, you can clearly see that after the control word, raw IP is transported. Remember from previous chapters that at disposition, only AToM Payload or SDU is displayed, whereas at imposition, the complete AToM packet is dumped.
You can see in Figure 14-10 how the encapsulation changes as the packet traverses from the Oakland CE as a Frame Relay encapsulated IP datagram (RFC 2427), through the AToM network to the Albany CE as a tagged-Ethernet encapsulated IP datagram and vice versa.
You can see that only the raw IP datagram is transported over the AToM pseudowire. The PE routers remove the complete Layer 2 encapsulation at imposition and re-create it at disposition.
In this case study, you learn the configuration and verification of IP IW between Frame Relay and PPP endpoints using L2TPv3 on the topology included in Figure 14-11.
This case study includes specific details on address resolution in IP IW both in Frame Relay DLCI and PPP port attachment circuits. These details apply to both AToM and L2TPv3 pseudowires. Example 14-23 shows the configuration for the SanFran PE side.
! hostname SanFran ! frame-relay switching ! pseudowire-class fr-ppp-l2tpv3 encapsulation l2tpv3 interworking ip ip local interface Loopback0 ! interface Serial6/0 no ip address encapsulation frame-relay frame-relay intf-type dce ! connect fr-ppp Serial6/0 60 l2transport xconnect 10.0.0.203 60 pw-class fr-ppp-l2tpv3 ! !
The routed IW behavior is configured explicitly with the interworking ip command. As usual with Frame Relay DLCI attachment circuits, this configuration uses the connect command and the cross-connect inside the fr-pw-switching configuration mode.
Example 14-24 shows the configuration in the NewYork side.
! hostname NewYork ! pseudowire-class fr-ppp-l2tpv3 encapsulation l2tpv3 interworking ip ip local interface Loopback0 ! interface Serial6/0 no ip address encapsulation ppp ppp ipcp address proxy 192.168.30.1 xconnect 10.0.0.201 60 pw-class fr-ppp-l2tpv3 !
The configuration in Example 14-24 is similar to a normal L2TPv3 session configuration, with the addition of the interworking ip directive. However, an additional command exists under the PPP interface. The command ppp ipcp address proxy specifies the remote CE's IP address, which is the IP address of the Oakland CE. This is necessary because ARP mediation does not take place.
In the like-to-like scenario with PPP pseudowires, PPP negotiations including IPCP are between the two CE devices. In IP IW, Layer 2 from the CE is terminated in the PE. Therefore, in the case of a PPP attachment circuit, IPCP as specified in RFC 1332 needs to be negotiated between the PE and CE because PPP is terminated at the PE. IPCP negotiation includes the exchange of IP addresses, but the NewYork PE has no knowledge of Oakland's IP address. The Oakland CE is the IP peer to the Albany CE. You need to manually assign Oakland's IP address in the NewYork PE so that it can be included in IPCP packets in the IPCP IP-Address Configuration option (type number 3). In this case, the PE device acts as an IPCP address proxy for the remote CE.
IPCP has a PPP DLL protocol number of 0x8021 and terminates on the PE. Only IP packets that have a PPP DLL protocol number of 0x0021 are transported over the pseudowire.
When the PE performs address resolution with the local CE, you can achieve the same result without configuring the PE device by using the command peer default ip address in the local CE, indicating the remote CE's IP address.
The next two examples show the CE router configuration. Example 14-25 starts with the Oakland configuration.
! hostname Oakland ! interface Serial6/0 no ip address encapsulation frame-relay ! interface Serial6/0.60 multipoint ip address 192.168.30.1 255.255.255.252 no ip directed-broadcast frame-relay map ip 192.168.30.2 60 broadcast !
You can see from Example 14-25 that you are now using a multipoint subinterface. This is to show the difference in configuration between using point-to-point versus multipoint subinterfaces. You do not need the frame-relay map configuration in a point-to-point subinterface, because the IP address and mask already define the connected prefix. The main interface has multipoint behavior, and you need to configure a frame-relay map (or inverse ARP when possible) for DLCIs in the main interface.
Example 14-25 shows the usage of the command frame-relay map instead of frame-relay interface-dlci. The frame-relay map command creates a DLCI but also maps it to a next-hop network protocol address. The example shows DLCI 60 mapped to the IP address 192.168.30.2 (the remote CE's IP on the PPP side) and specifies that broadcast packets such as routing protocol updates are to be sent over the DLCI.
Example 14-26 shows the configuration at the PPP-speaking Albany CE.
! hostname Albany ! interface Serial6/0 ip address 192.168.30.2 255.255.255.252 encapsulation ppp !
This configuration is the same as previous PPP-CE configurations.
Next, verify functionality and connectivity. Start the checks in the SanFran PE, as shown in Example 14-27.
SanFran#show l2tun session interworking vcid 60 Session Information Total tunnels 1 sessions 2 Tunnel control packets dropped due to failed digest 0 LocID TunID Peer-address Type IWrk Username, Intf/ Vcid, Circuit 11756 51283 10.0.0.203 FR IP 60, Se6/0:60 SanFran# SanFran#show l2tun session all ip-addr 10.0.0.203 vcid 60 L2TP Session Session id 11756 is up, tunnel id 51283 Call serial number is 3043600001 Remote tunnel name is NewYork Internet address is 10.0.0.203 Session is L2TP signalled Session state is established, time since change 21:54:06 5 Packets sent, 5 received 500 Bytes sent, 500 received Receive packets dropped: out-of-order: 0 total: 0 Send packets dropped: exceeded session MTU: 0 total: 0 Session vcid is 60 Session Layer 2 circuit, type is Frame Relay, name is Serial6/0:60 Circuit state is UP L2TP VC type is IP, interworking type is IP Remote session id is 9875, remote tunnel id 15753 DF bit off, ToS reflect disabled, ToS value 0, TTL value 255 No session cookie information available FS cached header information: encap size = 24 bytes 00000000 00000000 00000000 00000000 00000000 00000000 Sequencing is off SanFran#
The command show l2tun session with the interworking keyword displays the fact that although the attachment circuit type is Frame Relay (and PPP on the NewYork end), the IW type is IP. The same command with the all keyword displays the details of the dynamic L2TPv3 pseudowire, including the following:
The dynamic session is L2TP signaled.
The session state is established.
The circuit state is UP.
The VC type is IP (0x000B), as is the IW type.
You can use the show connection command in the Frame Relay end (see Example 14-28).
SanFran#show connection name fr-ppp FR/Pseudo-Wire Connection: 4 - fr-ppp Status - UP Segment 1 - Serial6/0 DLCI 60 Segment status: UP Line status: UP PVC status: ACTIVE NNI PVC status: ACTIVE Segment 2 - 10.0.0.203 60 Segment status: UP Requested AC state: UP PVC status: ACTIVE NNI PVC status: ACTIVE Interworking - ip SanFran#
After you check the PE devices, do not forget that the goal is to provide CE-CE IP connectivity using disparate Layer 2 access technologies; therefore, check the CE devices. Example 14-29 shows some captures from the Oakland CE.
Oakland#ping 192.168.30.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/36 ms
Oakland#show frame-relay map
Serial5/0.100 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast, IETF
status defined, active
Serial6/0.60 (up): ip 192.168.30.2 dlci 60(0x3C,0xCC0), static,
broadcast,
CISCO, status defined, active
Oakland#
Example 14-29 shows that IP connectivity exists between CE devices using ping. It also shows the output of the show frame-relay map command. You can see that DLCI 60 in interface Serial 6/0.60, which uses Frame Relay Cisco encapsulation, has a static map to 192.168.30.2 as configured, is active, and allows broadcasts. You can compare it to the map created in Case Study 14-4 using Frame Relay. In that case, a map is defined automatically for point-to-point subinterfaces, because the router can infer the mapping given the IP address and the subnet mask.
Note
The command show frame-relay map includes two hexadecimal numbers between parentheses beside the DLCI. The first number is the DLCI in hexadecimal representation. The second number is the 2-byte Q.922 header with the BECN, FECN, and DE bits zeroed out.
Next, analyze the PPP interface at the Oakland CE (see Example 14-30).
Albany#show interfaces s6/0 Serial6/0 is up, line protocol is up Hardware is M4T Internet address is 192.168.30.2/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open Open: IPCP Last input 00:00:02, output 00:00:02, 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: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) !Output omitted for brevity Albany# Albany#show ip route connected | include Serial6/0 C 192.168.30.0/24 is directly connected, Serial6/0 C 192.168.30.1/32 is directly connected, Serial6/0 Albany#
You can use the command show interfaces to see that Link Control Protocol (LCP) and IPCP are in an open state, which means they have been negotiated successfully, and that the /32 connected route to Oakland's IP address was installed through IPCP.
In the routed IW case, only IPv4 is transported, and Layer 2 terminates in the PE device. From Chapters 8, "WAN Protocols over MPLS Case Studies," and 12, "WAN Protocols over L2TPv3 Case Studies," you learned that in the like-to-like cases, PPP does not run in the PE device. It goes into a closed state when the xconnect command is entered. That is to say, in the like-to-like case, PE devices do not participate in PPP negotiation.
You can verify whether PPP runs in the PE by enabling debug ppp negotiation in the NewYork PE (see Example 14-31).
NewYork# *Jun 10 01:42:41.394: %LINK-3-UPDOWN: Interface Serial6/0, changed state to up *Jun 10 01:42:41.394: Se6/0 PPP: Treating connection as a dedicated line *Jun 10 01:42:41.394: Se6/0 PPP: Phase is ESTABLISHING, Active Open *Jun 10 01:42:41.394: Se6/0 LCP: O CONFREQ [Closed] id 226 len 10 *Jun 10 01:42:41.394: Se6/0 LCP: MagicNumber 0xC0A64078 (0x0506C0A *Jun 10 01:42:41.418: Se6/0 LCP: I CONFREQ [REQsent] id 6 len 10 *Jun 10 01:42:41.418: Se6/0 LCP: MagicNumber 0xC0A60E24 (0x0506C0A60E24) *Jun 10 01:42:41.418: Se6/0 LCP: O CONFACK [REQsent] id 6 len 10 *Jun 10 01:42:41.418: Se6/0 LCP: MagicNumber 0xC0A60E24 (0x0506C0A60E24) *Jun 10 01:42:41.418: Se6/0 LCP: I CONFACK [ACKsent] id 226 len 10 *Jun 10 01:42:41.418: Se6/0 LCP: MagicNumber 0xC0A64078 (0x0506C0A64078) *Jun 10 01:42:41.418: Se6/0 LCP: State is Open *Jun 10 01:42:41.418: Se6/0 PPP: XCONNECT has gated NCP starts *Jun 10 01:42:41.418: Se6/0 PPP: Phase is UP *Jun 10 01:42:41.418: Se6/0 PPP: XCONNECT is preventing NCP starts *Jun 10 01:42:41.438: Se6/0 PPP XCONNECT request to START IPCP using 0.0.0.0 *Jun 10 01:42:41.438: Se6/0 IPCP: O CONFREQ [Closed] id 8 len 10 *Jun 10 01:42:41.438: Se6/0 IPCP: Address 192.168.30.1 (0x0306C0A81E01) *Jun 10 01:42:41.470: Se6/0 IPCP: I CONFACK [REQsent] id 8 len 10 *Jun 10 01:42:41.470: Se6/0 IPCP: Address 192.168.30.1 (0x0306C0A81E01) *Jun 10 01:42:42.454: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/0, changed state to up *Jun 10 01:42:43.454: Se6/0 IPCP: TIMEout: State ACKrcvd *Jun 10 01:42:43.454: Se6/0 IPCP: O CONFREQ [ACKrcvd] id 9 len 10 *Jun 10 01:42:43.454: Se6/0 IPCP: Address 192.168.30.1 (0x0306C0A81E01) *Jun 10 01:42:43.454: Se6/0 IPCP: I CONFREQ [REQsent] id 7 len 10 *Jun 10 01:42:43.454: Se6/0 IPCP: Address 192.168.30.2 (0x0306C0A81E02) *Jun 10 01:42:43.454: Se6/0 IPCP: O CONFACK [REQsent] id 7 len 10 *Jun 10 01:42:43.454: Se6/0 IPCP: Address 192.168.30.2 (0x0306C0A81E02) *Jun 10 01:42:43.470: Se6/0 IPCP: I CONFACK [ACKsent] id 9 len 10 *Jun 10 01:42:43.470: Se6/0 IPCP: Address 192.168.30.1 (0x0306C0A81E01) *Jun 10 01:42:43.470: Se6/0 IPCP: State is Open NewYork# NewYork#show interfaces serial 6/0 Serial6/0 is up, line protocol is up Hardware is M4T MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open Open: IPCP Last input 00:00:00, output 00:00:00, output hang never !Output omitted for brevity NewYork#
You can see that LCP and IPCP are terminated at the PE router, IPv4 is transported, and everything else is dropped. Example 14-31 shows that all the debug information before and including the timestamp of Jun 10 01:42:41.418 is LCP negotiation that succeeds with the LCP state being open. The debug information after and including the timestamp of Jun 10 01:42:41.438 pertains to the only NCP that is IPCP negotiation and concludes with the open state for IPCP. You can also use the command show interface in the PE device and see that in contrast to the like-to-like case, LCP and IPCP are now open at the PE attachment circuit.
Regarding the data plane encapsulation details, you can see in Figure 14-12 how the encapsulation changes as the packet traverses from the Oakland CE as a Frame Relayencapsulated IP datagram (RFC 2427), through the IP service provider network over L2TPv3, to the Albany CE as a PPP-encapsulated IP datagram (RFC 1661) and vice versa.
You can see that only the raw IP datagram is transported over the L2TPv3 pseudowire, and the PE routers remove the complete Layer 2 encapsulation at imposition and re-create it at disposition. Non-IP datagrams coming from the CE device are dropped at the PE.
This section presents the important and recurring topic of MTU as it pertains to IP IW, both in the AToM and L2TPv3 cases. IP IW is the most efficient from an overhead perspective. It holds the best-case scenario in regards to MTU adjustments because only raw IP is transported, and Layer 2 overhead does not exist. For IP IW, the Layer 2 from the CE is terminated at the PE and not transported; therefore, no additional overhead is present.
Table 14-2 summarizes the different overheads added in the PE router to an IP packet received from the CE device. Table 14-2 lists the overheads for both AToM and L2TPv3, including the overhead definition and the actual overhead value from Case Studies 14-4 and 14-5, respectively.
AToM
| MPLS Tunnel header
| MPLS VC header
| Control word
| 12 bytes
|
4 bytes
| 4 bytes
| 4 bytes
| ||
L2TPv3
| IP header without options
| Session ID + cookie
| L2-Specific Sublayer
| 24 bytes
|
20 bytes
| 4 bytes + 0 bytes
| 0 bytes
|
From Table 14-2, you can see that the IP IW AToM Case Study 14-4 has 12 bytes of overhead, whereas the IP IW L2TPv3 Case Study 14-5 has 24 bytes of overhead (because of the cookie absence and because sequencing is disabled).
Knowing these overheads, you can calculate the largest IP packet that can be sent from the CE and make it unfragmented, where all interfaces have a default MTU of 1500 bytes:
AToM 1500 bytes 12 bytes = 1488 bytes
L2TPv3 1500 bytes 24 bytes = 1476 bytes
To prove the preceding calculations, perform the following experiment:
For AToM, send extended ping from the Oakland CE while setting the don't fragment (DF) bit in the IP header and using "Sweep range of sizes" and verbose output.
For L2TPv3, configure the L2TPv3 session to set the DF bit in the IP header, adding ip dfbit set in the fr-ppp-l2tpv3 pseudowire class, as explained in Chapter 13, "Advanced L2TPv3 Case Studies." In this case, the extended ping from the Oakland CE does not need to set the DF bit, because the DF bit that will be used in the cloud is the one in the L2TPv3 IPv4 delivery header.
See Example 14-32 for the results of these tests.
Oakland# ! Now test the AToM IP interworking case study 14-4 Oakland#ping Protocol [ip]: Target IP address: 192.168.29.2 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: 1 Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: y Sweep min size [36]: 1480 Sweep max size [18024]: 1490 Sweep interval [1]: Type escape sequence to abort. Sending 11, [1480..1490]-byte ICMP Echos to 192.168.29.2, timeout is 1 seconds: Reply to request 0 (96 ms) (size 1480) Reply to request 1 (24 ms) (size 1481) Reply to request 2 (32 ms) (size 1482) Reply to request 3 (20 ms) (size 1483) Reply to request 4 (28 ms) (size 1484) Reply to request 5 (36 ms) (size 1485) Reply to request 6 (28 ms) (size 1486) Reply to request 7 (48 ms) (size 1487) Reply to request 8 (32 ms) (size 1488) Request 9 timed out (size 1489) Request 10 timed out (size 1490) Success rate is 81 percent (9/11), round-trip min/avg/max = 20/38/96 ms Oakland# Oakland# Oakland# Oakland# ! Now test the L2TPv3 IP interworking case study 14-5 Oakland#ping Protocol [ip]: Target IP address: 192.168.30.2 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: y Sweep min size [36]: 1470 Sweep max size [18024]: 1480 Sweep interval [1]: Type escape sequence to abort. Sending 11, [1470..1480]-byte ICMP Echos to 192.168.30.2, timeout is 2 seconds: Reply to request 0 (20 ms) (size 1470) Reply to request 1 (20 ms) (size 1471) Reply to request 2 (32 ms) (size 1472) Reply to request 3 (20 ms) (size 1473) Reply to request 4 (24 ms) (size 1474) Reply to request 5 (28 ms) (size 1475) Reply to request 6 (36 ms) (size 1476) Request 7 timed out (size 1477) Request 8 timed out (size 1478) Request 9 timed out (size 1479) Request 10 timed out (size 1480) Success rate is 63 percent (7/11), round-trip min/avg/max = 20/25/36 ms Oakland#
You can conclude that the calculation is correct. From Example 14-32, you learn that in the AToM case, the largest IP packet that makes it through is 1488 bytes because of the 12-byte overhead. In contrast, in the L2TPv3 case, the largest IP packet that makes it through is 1476 bytes because of the 24-byte overhead.
By knowing the IP MTU limitation and calculation with IP IW, you can tune the core MTU based on the largest expected IP datagram from the CE device.
In this last IW case study, you will learn some best practices about routed IW between Frame Relay and ATM. First, understand that IP IW pseudowire between Frame Relay and ATM VCs is not FRF.8, "Frame Relay/ATM PVC Service Interworking Implementation Agreement," (SIW) in which an IW function (IWF) translates between RFC 2427 encapsulated Frame Relay and RFC 2684 encapsulated AAL5 with a null SSCP. Only IP packets are transported over the IP IW pseudowire.
In contrast to FRF.8 SIW, which supports address resolution translation, inverse ARP is not supported in IP IW pseudowires; therefore, the ATM and Frame Relay CEs need to be configured on point-to-point subinterfaces or use static maps if they are on multipoint subinterfaces.
In the ATM attachment circuit, only AAL5 SDU VC mode is supported, and the ATM PVC encapsulation can either be AAL5SNAP or AAL5MUX (in which no translation is required because LLC/SNAP is nonexistent, and only one protocol is carried). Either AAL5SNAP or AAL5MUX needs to be configured in both the CE and PE devices under the PVC configuration mode. The encapsulations of AAL0 or AAL5 are not valid for IP IW, because AAL5 terminates at the PE device, and the PE device needs to know the AAL5 encapsulation type. However, in contrast to the CE configuration, when using AAL5MUX encapsulation in the PE Layer 2 PVC, you do not need to specify ip as the protocol carried.
A typical configuration for a CE that has multipoint subinterfaces is included in Example 14-33.
! hostname Oakland ! interface ATM3/0.27 multipoint ip address 192.168.31.1 255.255.255.0 pvc 0/270 protocol ip 192.168.31.2 broadcast encapsulation aal5snap ! ! interface ATM3/0.28 multipoint ip address 192.168.32.1 255.255.255.0 pvc 0/271 protocol ip 192.168.32.2 broadcast encapsulation aal5mux ip ! !
Note that both AAL5SNAP and AAL5MUX IP PVC encapsulations are supported. The protocol to VC mapping is achieved with the PVC mode command protocol. Example 14-34 shows how to verify ATM protocol to VC mappings.
Oakland#show atm map Map list ATM3/0.27pvc10E : PERMANENT ip 192.168.31.2 maps to VC 4, VPI 0, VCI 270, ATM3/0.27 , broadcast Map list ATM3/0.28pvc10F : PERMANENT ip 192.168.32.2 maps to VC 9, VPI 0, VCI 271, ATM3/0.28 , broadcast, aal5mux Oakland #
You can see that IP addresses map to ATM VCs in a permanent way, meaning manually or statically configured. The broadcast keyword indicates pseudobroadcasting.