|
Table Of Contents
Restrictions for L2VPN Interworking
Cisco 7200 and 7500 Series Routers Supported Port Adapters
Cisco 7200 Series Routers Supported Interface Processors
Cisco 7500 Series Routers Supported Interface Processors
Cisco 10720 Internet Router Supported Line Cards
Cisco 12000 Series Router Restrictions
Cisco 12000 Series Routers Supported Line Cards
Cisco 12000 Series Routers Supported Shared Port Adapters
Cisco 7600 Series Router Supported Line Cards
Cisco 7600 Series Routers Restrictions
ATM AAL5 Interworking Restrictions
Ethernet/VLAN Interworking Restrictions
Frame Relay Interworking Restrictions
Information About L2VPN Interworking
Overview of L2VPN Interworking
How to Configure L2VPN Interworking
Configuring L2VPN Interworking
Configuring Static IP Addresses for PPP
Configuration Examples for L2VPN Interworking
Ethernet to VLAN over L2TPV3 (Bridged): Example
Ethernet to VLAN over AToM (Bridged): Example
Frame Relay to VLAN over L2TPV3 (Routed): Example
Frame Relay to VLAN over AToM (Routed): Example
Frame Relay to ATM AAL5 over AToM (Routed): Example
VLAN to ATM AAL5 over AToM (Bridged): Example
Frame Relay to PPP over L2TPv3 (Routed): Example
Frame Relay to PPP over AToM (Routed): Example
Ethernet/VLAN to PPP over AToM (Routed): Example
Feature Information for L2VPN Interworking
L2VPN Interworking
First Published: August 26, 2003Last Updated: May 15, 2006This feature module explains how to configure the following Layer 2 Virtual Private Network (L2VPN) Interworking features:
•Ethernet/VLAN to ATM AAL5 Interworking
•Ethernet/VLAN to Frame Relay Interworking
•Ethernet/VLAN to PPP Interworking
•Ethernet to VLAN Interworking
•Frame Relay to ATM AAL5 Interworking
•Frame Relay to PPP Interworking
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for L2VPN Interworking" section.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
• Restrictions for L2VPN Interworking
• Information About L2VPN Interworking
• How to Configure L2VPN Interworking
• Feature Information for L2VPN Interworking
Restrictions for L2VPN Interworking
The following sections list the L2VPN Interworking restrictions:
• Cisco 7200 and 7500 Series Routers Supported Port Adapters
• Cisco 7200 Series Routers Supported Interface Processors
• Cisco 7500 Series Routers Supported Interface Processors
• Cisco 10720 Internet Router Supported Line Cards
• Cisco 12000 Series Router Restrictions
• Cisco 12000 Series Routers Supported Line Cards
• Cisco 12000 Series Routers Supported Shared Port Adapters
• Cisco 7600 Series Router Supported Line Cards
• Cisco 7600 Series Routers Restrictions
• ATM AAL5 Interworking Restrictions
• Ethernet/VLAN Interworking Restrictions
• Frame Relay Interworking Restrictions
• PPP Interworking Restrictions
General Restrictions
This section lists general restrictions that apply to L2VPN Interworking. Other restrictions that are platform- or device-specific are listed in the following sections.
•The interworking type on one PE router must match the interworking type on the peer PE router.
•You must enable Cisco Express Forwarding.
•Distributed Cisco Express Forwarding switching is supported on the Cisco 7500.
•Although Layer 2 Quality of Service (QoS) is supported extensively on Cisco 12000 series routers (details are given in Any Transport over MPLS (AToM): Layer 2 QoS (Quality of Service) for the Cisco 12000 Series Router), on other platforms only the following QoS features are supported with L2VPN Interworking:
–Static IP Type of Service (ToS) or MPLS Experimental Bit (EXP) setting in tunnel header
–IP ToS reflection in tunnel header (Layer 2 Tunnel Protocol Version 3 (L2TPv3) only)
–Frame Relay policing
–Frame Relay data-link connection identifier (DLCI)-based congestion management (7500/VIP)
–One-to-one mapping of VLAN priority bits to MPLS EXP bits
Cisco 7200 and 7500 Series Routers Supported Port Adapters
L2VPN Interworking is supported only on the following port adapters in the Cisco 7200 and 7500 series routers:
•PA-FE-TX (Single-port Fast Ethernet 100BASE-TX)
•PA-FE-FX (Single-port Fast Ethernet 100BASE-FX)
•PA-2FE-TX (Dual-port Fast Ethernet 100BASE-TX)
•PA-2FE-FX (Dual-port Fast Ethernet 100BASE-FX)
•PA-8E (8-port Ethernet Adapter) [7200 only, L2TPv3 only]
•PA-4E (4-port Ethernet Adapter) [7200 only, L2TPv3 only]
•PA-12E/2FE (12-port Ethernet/2-port FE Adapter) [7200 only, L2TPv3 only]
•PA-GE (Gigabit Ethernet Port Adapter) [7200 only]
•PA-4T (4-port synchronous serial port adapter)
•PA-4T+ (Enhanced 4-port synchronous serial port adapter)
•PA-8T (8-port synchronous serial port adapter)
•PA-H—Single-port High-Speed Serial Interface (HSSI) adapter
•PA-2H (Dual-port HSSI adapter)
•PA-MC-8E1 (8-port multichannel E1 G.703/G.704 120-ohm interfaces)
•PA-MC-2EI (2-port multichannel E1 G.703/G.704 120-ohm interfaces)
•PA-MC-8T1—8-port multichannel T1 with integrated Channel Service Unit (CSU) and Data Service Unit (DSUs)
•PA-MC-4T1 (4-port multichannel T1 with integrated CSUs and DSUs)
•PA-MC-2T1 (2-port multichannel T1 with integrated CSUs and DSUs)
•PA-MC-8TE1+ (8-port multichannel T1/E1)
•PA-MC-T3 (1-port multichannel T3 interface)
•PA-MC-E3 (1-port multichannel E3 interface)
•PA-MC-2T3+ (2-port enhanced multichannel T3 port adapter)
•PA-MC-STM1 (1-port multichannel STM1 port adapter)
•PA-T3 (Single-port T3 port adapter)
•PA-E3 (Single-port E3 port adapter)
•PA-2E3 (2-port T3 port adapter)
•PA-2T3 (2-port T3 port adapter)
•PA-POS-OC3SML- (Single-port Packet over SONET (POS), Single-mode, long reach)
•PA-POS-OC3SMI- (Single-port POS, Single-mode, intermediate reach)
•PA-POS-OC3MM- (Single-port POS, Multimode)
•PA-A3-OC3 (1-port ATM OC3/STM1 port adapter, enhanced)
•PA-A3-OC12 (1-port ATM OC12/STM4 port adapter, enhanced)
•PA-A3-T3 (DS3 high-speed interface)
•PA-A3-E3 (E3 medium-speed interface)
•PA-A3-8T1IMA (ATM inverse multiplexer over ATM port adapter with 8 T1 ports)
•PA-A3-8E1IMA (ATM inverse multiplexer over ATM port adapter with 8 E1 ports)
Cisco 7200 Series Routers Supported Interface Processors
L2VPN Interworking is supported only on the following Cisco 7200 series router interface processors:
•C7200-I/O-2FE
•C7200-I/O-GE+E (Only the Gigabit Ethernet port of this port adapter is supported.)
•C7200-I/O-FE
•PA-GE
Cisco 7500 Series Routers Supported Interface Processors
L2VPN Interworking is supported only on the following Cisco 7500 series router interface processors:
•GEIP (Gigabit Ethernet interface processor)
•GEIP+ (Enhanced Gigabit Ethernet interface processor)
Cisco 10720 Internet Router Supported Line Cards
L2VPN Interworking is supported only on the following Cisco 10720 Internet router line cards:
•10720-FE-TX
•10720-FE-FX-SM
•10720-FE-FX-MM
•10720-GE-FE-TX
•10720-GE-SFP-SX
•10720-GE-SFP-LH
Cisco 12000 Series Router Restrictions
Cisco 12000 series routers do not support the following:
•Frame Relay to PPP interworking.
•L2VPN Interworking over L2TPv3 on Engine 5 line cards. Engine 5 line cards do not support 802.1Q tunneling (QinQ).
Cisco 12000 Series Routers Supported Line Cards
L2VPN Interworking is supported only on the following Cisco 12000 series router line cards:
•4GE-SFP-LC
•4OC12X/ATM-MM-SC
•4OC12X/ATM-IR-SC
•4OC3X/ATM-IR-SC
•4OC3X/POS-MM-MJ-B
•4OC3X/POS-IR-LC-B
•4OC3X/POS-LR-LC-B
•8OC3X/POS-MM-MJ-B
•8OC3X/POS-IR-LC-B
•16OC3X/POS-M-MJ-B
•16OC3X/POS-I-LC-B
•4OC12X/POS-M-SC-B
•4OC12X/POS-I-SC-B
•OC48X/POS-SR-SC
•OC48X/POS-LR-SC
•12000-SIP-401: modular 2.5 Gbps IP Services Engine (ISE), which holds four Half-Height (HH) shared port adapters (SPAs)
•12000-SIP-501: modular 5 Gbps ISE, which holds four HH SPAs
•12000-SIP-600: modular 10 Gbps ISE, which holds two FH/HH SPAs
•12000-SIP-601: modular 10 Gbps ISE, which holds four HH SPAs
Cisco 12000 Series Routers Supported Shared Port Adapters
This section lists the SPAs used with the Engine 5 line cards on Cisco 12000 series routers. This section also lists the supported transport types on the POS, channelized, and Gigabit Ethernet SPAs of the Engine 5 line card (see Table 1).
•T3/E3 with 2xT3/E3 SPA HH (SPA-2XT3/E3)
•T3/E3 with 4xT3/E3 SPA HH (SPA-4XT3/E3)
The following supported Ethernet SPAs also support the Remote Ethernet Port Shutdown feature (which minimizes potential data loss after a remote link failure):
•8xFE SPA HH (SPA-8XFE)
•5xGE SPA HH (SPA-5XGE)
•10xGE SPA HH (SPA-10XGE)
•2xGE SPA HH (SPA-2XGE)
•1p 10GE (1-port 10-Gigabit Ethernet)
Note For detailed information on the Remote Ethernet Port Shutdown feature, refer to Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown.
The following supported POS and channelized SPAs also support Frame Relay over
Multiprotocol Label Switching (MPLS), and PPP/High-Level Data Link control (HDLC) over MPLS:•2xOC48c/STM16c POS SPA HH (SPA-2XOC48POS/RPR)
•1xOC192c/STM64c POS SPA FH, fixed optics (SPA-OC192POS-LR)
•1xOC192c/STM64c POS SPA HH, pluggable optics (SPA-OC192RPR-XFP)
•1xCHOC3/ChSTM1 DSx SPA HH (SPA-1XCHSTM1/OC3)
•8xChT1/E1 SPA HH (SPA-CH8TE1)
•2xCT3->DS0 SPA HH (SPA-2XCT3/DS0
•4xCT3->DS0 SPA HH (SPA-4XCT3/DS0)
Table 1 shows the supported transport types on the POS, channelized, and Gigabit Ethernet SPAs of the Engine 5 line card.
Cisco 7600 Series Router Supported Line Cards
The following line cards are supported on the Cisco 7600 series router. Table 2 shows the line cards that are supported on the WAN (ATM, Frame Relay, or PPP) side of the interworking link. Table 3 shows the line cards that are supported on the Ethernet side of the interworking link.
Cisco 7600 Series Routers Restrictions
•The Cisco 7600 series routers do not support L2VPN Interworking over L2TPv3.
•Cisco 7600 series routers support only the following interworking types:
–Ethernet/VLAN to Frame Relay (IP and Ethernet modes)
–Ethernet/VLAN to ATM AAL5SNAP (IP and Ethernet modes)
–Ethernet/VLAN to PPP (IP only)
–Ethernet to VLAN Interworking
•Cisco 7600 series routers do not support the following interworking types:
–Ethernet/VLAN to ATM AAL5MUX
–Frame Relay to PPP Interworking
–Frame Relay to ATM AAL5 Interworking
•Both ends of the interworking link must be configured with the same encapsulation and interworking type:
–If you use Ethernet encapsulation, you must use the Ethernet (bridged) interworking type. If you are not using Ethernet encapsulation, you can use a bridging mechanism, such as routed bridge encapsulation (RBE).
–If you use an IP encapsulation (such as ATM or Frame Relay), you must use the IP (routed) interworking type. The provider edge (PE) routers negotiate the process for learning and resolving addresses.
Unsupported Hardware
The following hardware is not supported:
•Cisco 7200—non-VXR chassis
•Cisco 7500—RSP1 and RSP2
•Cisco 7500—Cisco Versatile Interface Processor 2, Model 40 (VIP2-40) and earlier
•Cisco 10720—OC-48c/STM-16c Spatial Reuse Protocol/Packet Over SONET (SRP/POS) uplink modules
ATM AAL5 Interworking Restrictions
The following restrictions apply to ATM AAL5 Interworking:
•Cisco 12000 series Engine 5 line cards do not support L2VPN interworking on ATM. On other line cards and platforms, only ATM AAL5 VC mode is supported; ATM VP and port mode are not supported.
•Switched Virtual Circuits (SVCs) are not supported.
•Inverse ARP is not supported with IP interworking.
•Customer Edge (CE) routers must use point-to-point subinterfaces or static maps.
•Both AAL5MUX and AAL5SNAP encapsulation are supported. In the case of AAL5MUX, no translation is needed.
•On the Cisco 12000 series Engine 3 line card, Network Layer Protocol ID (NLPID) encapsulation is not supported in routed mode; and neither NLPID nor AAL5MUX is supported in bridged mode.
•In the Ethernet end-to-end over ATM scenario, the following translations are supported:
–Ethernet without LAN Frame Check Sequence (FCS) (AAAA030080C200070000)
–Spanning tree (AAAA030080c2000E)
Everything else is dropped.
•In the IP over ATM scenario, the IPv4 (AAAA030000000800) translation is supported. Everything else is dropped.
•Orthogonal Amplitude Modulation (OAM) emulation for L2VPN Interworking is the same as like-to-like. The end-to-end F5 loopback cells are looped back on the PE router. When the pseudowire is down, an F5 end-to-end segment Alarm Indication Signal (AIS)/Remote Defect Identification (RDI) is sent from the PE router to the CE router.
•Interim Local Management Interface (ILMI) can manage Virtual Circuits (VCs) and Permanent Virtual Circuits (PVCs). To enable ILMI management, configure ILMI PVC 0/16 on the PE router's ATM interface. If a PVC is provisioned or deleted, an ilmiVCCChange trap is sent to the CE router. Only the user side of the User Network Interface (UNI) is supported; the network side of the UNI is not supported.
Ethernet/VLAN Interworking Restrictions
The following restrictions apply to Ethernet/VLAN interworking:
•The Cisco 10720 Internet router supports Ethernet to VLAN Interworking Ethernet only, over L2TPv3.
•Ethernet interworking for a raw Ethernet port or a VLAN trunk is not supported. Traffic streams are not kept separate when traffic is sent between transport types.
•In routed mode, only one CE router can be attached to an Ethernet PE router.
•There must be a one-to-one relationship between an attachment circuit and the pseudowire. Point-to-multipoint or multipoint-to-point configurations are not supported.
•Configure routing protocols for point-to-point operation on the CE routers when configuring an Ethernet to non-Ethernet setup.
•In the IP interworking mode, the IPv4 (0800) translation is supported. The PE router captures ARP (0806) packets and responds with its own MAC address (proxy ARP). Everything else is dropped.
•The Ethernet or VLAN must contain only two IP devices: PE router and CE router. The PE router performs proxy ARP and responds to all Address Resolution Protocol (ARP) requests it receives. Therefore, only one CE and one PE router should be on the Ethernet or VLAN segment.
•If the CE routers are doing static routing, you can optionally perform the following:
–The PE router needs to learn the MAC address of the CE router to correctly forward traffic to it. The Ethernet PE router sends an Internet Control Message Protocol (ICMP) Router discovery protocol (RDP) solicitation message with the source IP address as zero. The Ethernet CE router responds to this solicitation message. To configure the Cisco CE router's Ethernet or VLAN interface to respond to the ICMP RDP solicitation message, issue the ip irdp command in interface configuration mode. If you do not configure the CE router, traffic is dropped until the CE router sends traffic toward the PE router.
–To disable the CE routers from running the router discovery protocol, issue the
ip irdp maxadvertinterval 0 command in interface mode.•When the PE router on the Ethernet side receives a VLAN tagged packet from the CE router, the PE router removes the VLAN tag from the Ethernet frame from the CE router. In the reverse direction, the PE router adds the VLAN tag to the frames before sending the frame to the CE router. The VLAN tag needs to be inserted or removed in this way when you configure VLAN to Ethernet interworking, VLAN to Frame Relay, or ATM using Ethernet (bridged) interworking.
This restriction applies if you configure interworking between Ethernet and VLAN with Catalyst switches as the CE routers. The spanning tree protocol is supported for Ethernet interworking. Ethernet interworking between an Ethernet port and a VLAN supports spanning tree protocol only on VLAN 1. Configure VLAN 1 as a nonnative VLAN.
•In bridged interworking from VLAN to Frame Relay (FR), the Frame Relay PE router does not strip off VLAN tags from the Ethernet traffic it receives.
•When you change the interworking configuration on an Ethernet PE router, clear the ARP entry on the adjacent CE router so that it can learn the new MAC address. Otherwise, you might encounter traffic drops.
Frame Relay Interworking Restrictions
The following restrictions apply to Frame Relay interworking:
•The attachment circuit maximum transmission unit (MTU) sizes must match when you connect them over MPLS. By default, the MTU size associated with a Frame Relay DLCI is the interface MTU. This may cause problems, for example, when connecting some DLCIs on a POS interface (with a default MTU of 4470 bytes) to Ethernet or VLAN (with a default MTU of 1500 bytes) and other DLCIs on the same POS interface to ATM (with a default MTU of 4470 bytes). To avoid reducing all the interface MTUs to the lowest common denominator (1500 bytes in this case), you can specify the MTU for individual DLCIs using the mtu command.
•Only DLCI mode is supported. Port mode is not supported.
•Configure Frame Relay switching to use data communications equipment (DCE) or Network-to-Network Interface (NNI). data terminal equipment (DTE) mode does not report status in the Local Management Interface (LMI) process. If a Frame Relay over MPLS circuit goes down and the PE router is in DTE mode, the CE router is never informed of the disabled circuit. You must configure the frame-relay switching command in global configuration mode in order to configure DCE or NNI.
•Frame Relay policing is nondistributed on the Cisco 7500 series routers. If you enable Frame Relay policing, traffic is sent to the route switch processor (RSP) for processing.
•Inverse ARP is not supported with IP interworking. CE routers must use point-to-point subinterfaces or static maps.
•The PE router automatically supports translation of both the Cisco encapsulations and the
Internet Engineering Task Force (IETF) encapsulations that come from the CE, but translates only to IETF when sending to the CE router. This is not a problem for the Cisco CE router, because it can handle IETF encapsulation on receipt even if it is configured to send Cisco encapsulation.•With Ethernet interworking, the following translations are supported:
–Ethernet without LAN FCS (0300800080C20007 or 6558)
–Spanning tree (0300800080C2000E or 4242)
Everything else is dropped.
•With IP interworking, the IPv4 (03CC or 0800) translation is supported. Everything else is dropped.
•PVC status signaling works the same way as in like-to-like case. The PE router reports the PVC status to the CE router, based on the availability of the pseudo wire. PVC status detected by the PE router will also be reflected into the pseudo wire. LMI to OAM interworking is supported when you connect Frame Relay to ATM.
PPP Interworking Restrictions
The following restrictions apply to PPP interworking:
•There must be a one-to-one relationship between a PPP session and the pseudowire. Multiple PPP sessions multiplexing over the pseudowire is not supported.
•There must be a one-to-one relationship between a PPP session and a Frame Relay DLCI. Each Frame Relay PVC must have only one PPP session.
•Only IP (IPv4 (0021) interworking is supported. Link Control Protocol (LCP) packets and Internet Protocol Control Protocol (IPCP) packets are terminated at the PE router. Everything else is dropped.
•Proxy IPCP is automatically enabled on the PE router when IP interworking is configured on the pseudowire.
•By default, the PE router assumes that the CE router knows the remote CE router's IP address.
•Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP) authentication are supported.
Information About L2VPN Interworking
The following sections provide an introduction to L2VPN interworking.
• Overview of L2VPN Interworking
Overview of L2VPN Interworking
Layer 2 transport over MPLS and IP already exists for like-to-like attachment circuits, such as Ethernet-to-Ethernet or PPP-to-PPP. L2VPN Interworking builds on this functionality by allowing disparate attachment circuits to be connected. An interworking function facilitates the translation between the different Layer 2 encapsulations. Figure 1 is an example of Layer 2 interworking, where ATM and Frame Relay packets travel over the MPLS cloud.
Figure 1 ATM to Frame Relay Interworking Example
The L2VPN Interworking feature supports Ethernet, 802.1Q (VLAN), Frame Relay, ATM (Asynchronous Transfer Mode) Adaptation Layer 5 (AAL5), and PPP attachment circuits over MPLS and L2TPv3. The features and restrictions for like-to-like functionality also apply to L2VPN Interworking.
L2VPN Interworking Modes
L2VPN Interworking works in either Ethernet ("bridged") mode or IP ("routed") mode. You specify the mode by issuing the following command in pseudowire-class configuration mode:
interworking {ethernet | ip}
The interworking command causes the attachment circuits to be terminated locally. The two keywords perform the following functions:
•The ethernet keyword causes Ethernet frames to be extracted from the attachment circuit and sent over the pseudowire. Ethernet end-to-end transmission is assumed. Attachment circuit frames that are not Ethernet are dropped. In the case of VLAN, the VLAN tag is removed, leaving an untagged Ethernet frame.
•The ip keyword causes IP packets to be extracted from the attachment circuit and sent over the pseudowire. Attachment circuit frames that do not contain IPv4 packets are dropped.
The supported L2VPN Interworking features are listed in Table 4.
Note The Cisco 7600 series routers do not support L2VPN Interworking over L2TPv3.
The following sections explain more about Ethernet and IP interworking modes.
Ethernet Interworking
As mentioned earlier, Ethernet Interworking is also called bridged interworking. Ethernet frames are bridged across the pseudowire. The customer edge (CE) routers could be natively bridging Ethernet or could be routing using a bridged encapsulation model, such as Bridge Virtual Interface (BVI) or RBE. The PE routers operate in Ethernet like-to-like mode.
This model is used to offer the following services:
•LAN services—An example is an enterprise that has several sites, where some sites have Ethernet connectivity to the service provider (SP) network and others have ATM connectivity. The enterprise wants LAN connectivity to all its sites. In this case, traffic from the Ethernet or VLAN of one site can be sent through the IP/MPLS network and encapsulated as bridged traffic over an ATM virtual circuit (VC) of another site.
•Connectivity services—An example is an enterprise that has different sites that are running an Internal Gateway Protocol (IGP) routing protocol, which has incompatible procedures on broadcast and non-broadcast links. The enterprise has several sites that are running an IGP, such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS), between the sites. In this scenario, some of the procedures (such as route advertisement or designated router) depend on the underlying Layer 2 protocol and are different for a point-to-point ATM connection versus a broadcast Ethernet connection. Therefore, the bridged encapsulation over ATM can be used to achieve homogenous Ethernet connectivity between the CE routers running the IGP.
IP Interworking
IP Interworking is also called routed interworking. The CE routers encapsulate IP on the link between the CE and PE routers. A new VC type is used to signal the IP pseudowire in MPLS and L2TPv3. Translation between the Layer 2 and IP encapsulations across the pseudowire is required. Special consideration needs to be given to address resolution and routing protocol operation, because these are handled differently on different Layer 2 encapsulations.
This model is used to provide IP connectivity between sites, regardless of the Layer 2 connectivity to these sites. It is different from a layer 3 VPN because it is point-to-point in nature and the service provider does not maintain any customer routing information.
Address resolution is encapsulation dependent:
•Ethernet uses ARP
•Frame Relay and ATM use Inverse ARP
•PPP uses IPCP
Therefore, address resolution must be terminated on the PE router. End-to-end address resolution is not supported.
Routing protocols operate differently over broadcast and point-to-point media. For Ethernet, the CE routers must either use static routing or configure the routing protocols to treat the Ethernet side as a point-to-point network.
How to Configure L2VPN Interworking
The following sections explain the tasks you can perform to set up L2VPN Interworking:
• Configuring L2VPN Interworking (required)
• Configuring Static IP Addresses for PPP (optional)
• Verifying the Configuration (optional)
Configuring L2VPN Interworking
Enabling L2VPN Interworking requires that you add the interworking command to the list of commands that comprise the pseudowire. The steps for configuring the pseudowire for L2VPN Interworking are included in this section. You use the interworking command as part of the overall AToM or L2TPv3 configuration. For specific instructions on configuring AToM or L2TPv3, see the following documents:
•Layer 2 Tunnel Protocol Version 3
•Any Transport over MPLS
SUMMARY STEPS
1. enable
2. configure terminal
3. pseudowire-class name
4. encapsulation {mpls | l2tpv3}
5. interworking {ethernet | ip}
DETAILED STEPS
Configuring Static IP Addresses for PPP
If the PE router needs to perform address resolution with the local CE router for PPP, you can configure the remote CE router's IP address on the PE router. Issue the ppp ipcp address proxy command with the remote CE router's IP address on the PE router's xconnect PPP interface. The following example shows a sample configuration:
pseudowire-class ip-interworking
encapsulation mpls
interworking ip
interface Serial2/0
encapsulation ppp
xconnect 10.0.0.2 200 pw-class ip-interworking
ppp ipcp address proxy 10.65.32.14
You can also configure the remote CE router's IP address on the local CE router with the peer default ip address command if the local CE router performs address resolution.
Verifying the Configuration
l2tpv3
You can verify the L2VPN Interworking configuration using show l2tunnel session all command on the PE routers. In the following example, the interworking type is shown in bold.
You can issue arp and ping commands between the CE routers to ensure that data is being sent:
Router# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.5 134 0005.0032.0854 ARPA FastEthernet0/0
Internet 10.1.1.7 - 0005.0032.0000 ARPA FastEthernet0/0
Router# ping 10.1.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
You can verify that the interworking type is correctly set by using show l2tunnel session interworking command. Issue the command on the PE routers that are doing the interworking translation. If the PE router does the raw Ethernet translation, the command output displays the interworking type with a hyphen (-). On the PE router that does the Ethernet VLAN translation, the command output displays the interworking type as ETH as shown in the following examples:
Command Output for Raw Ethernet Translation: Example
Router# show l2tunnel session interworking
Session Information Total tunnels 1 sessions 1
LocID TunID Peer-address Type IWrk Username, Intf/Vcid, Circuit
15736 35411 10.9.9.9 ETH - 123, Fa1/1/0
Command Output for Ethernet VLAN Translation: Example
Router# show l2tunnel session interworking
Session Information Total tunnels 1 sessions 1
LocID TunID Peer-address Type IWrk Username, Intf/Vcid, Circuit
26570 46882 10.8.8.8 VLAN ETH 123, Fa2/0.1:10
AToM
You can verify the AToM configuration by using the show mpls l2transport vc detail command. In the following example, the interworking type is shown in bold.
Configuration Examples for L2VPN Interworking
The following sections show examples of L2VPN Interworking:
• Ethernet to VLAN over L2TPV3 (Bridged): Example
• Ethernet to VLAN over AToM (Bridged): Example
• Frame Relay to VLAN over L2TPV3 (Routed): Example
• Frame Relay to VLAN over AToM (Routed): Example
• Frame Relay to ATM AAL5 over AToM (Routed): Example
• VLAN to ATM AAL5 over AToM (Bridged): Example
• Frame Relay to PPP over L2TPv3 (Routed): Example
• Frame Relay to PPP over AToM (Routed): Example
• Ethernet/VLAN to PPP over AToM (Routed): Example
Ethernet to VLAN over L2TPV3 (Bridged): Example
Ethernet to VLAN over AToM (Bridged): Example
Frame Relay to VLAN over L2TPV3 (Routed): Example
Frame Relay to VLAN over AToM (Routed): Example
Frame Relay to ATM AAL5 over AToM (Routed): Example
Frame Relay to ATM AAL5 is available only with AToM in IP mode.
VLAN to ATM AAL5 over AToM (Bridged): Example
Frame Relay to PPP over L2TPv3 (Routed): Example
Frame Relay to PPP over AToM (Routed): Example
Ethernet/VLAN to PPP over AToM (Routed): Example
Additional References
The following sections provide references related to the L2VPN Interworking feature.
Related Documents
Standards
Standards1 Titledraft-ietf-l2tpext-l2tp-base-03.txt
Layer Two Tunneling Protocol (Version 3) 'L2TPv3'
draft-martini-l2circuit-trans-mpls-09.txt
Transport of Layer 2 Frames Over MPLS
draft-ietf-pwe3-frame-relay-03.txt.
Encapsulation Methods for Transport of Frame Relay over MPLS Networks
draft-martini-l2circuit-encap-mpls-04.txt.
Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks
draft-ietf-pwe3-ethernet-encap-08.txt.
Encapsulation Methods for Transport of Ethernet over MPLS Networks
draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt.
Encapsulation Methods for Transport of PPP/HDLC over MPLS Networks
draft-ietf-ppvpn-l2vpn-00.txt.
An Architecture for L2VPNs
1 Not all supported standards are listed.
MIBs
RFCs
RFCs TitleNo new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents new and modified commands.
• debug frame-relay pseudowire
• mtu
debug frame-relay pseudowire
To display events and error conditions that occur when binding a Frame Relay data-link connection identifier (DLCI) to a pseudowire, use the debug frame-relay pseudowire command in privileged EXEC mode. To disable the display of these events and error conditions, use the no form of this command.
debug frame-relay pseudowire
no debug frame-relay pseudowire
Syntax Description
This command contains no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Examples of Frame-Relay pseudowire events include:
•Command-line interface (CLI) provisioning events
•Pseudowire circuit status updates
•Failures occurring during the management of these events
Examples
The following example enables the display of Frame-Relay pseudowire events. In this example, the interface has been shut down and then enabled.
Router# debug frame-relay pseudowire
Router(config)# interface hssi1/0/0
Router(config-if)# shutdown
09:18:33.303: FRoPW [10.15.15.15, 100]: acmgr_circuit_down
09:18:33.303: FRoPW [10.15.15.15, 100]: SW AC update circuit state to down
09:18:33.303: FRoPW [10.15.15.15, 100]: Setting connection DOWN
09:18:35.299: %LINK-5-CHANGED: Interface Hssi1/0/0, changed state to administratively down
09:18:36.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi1/0/0, changed state to down
Router(config-if)# no shutdown
09:18:41.919: %LINK-3-UPDOWN: Interface Hssi1/0/0, changed state to up
09:18:41.919: FRoPW [10.15.15.15, 100]: Local up, sending acmgr_circuit_up
09:18:41.919: FRoPW [10.15.15.15, 100]: Setting pw segment UP
09:18:41.919: FRoPW [10.15.15.15, 100]: PW nni_pvc_status set ACTIVE
09:18:41.919: label_oce_get_label_bundle: flags 14 label 28
09:18:42.919: %LINEPROTO-5-UPDOWN: Line protocol on Interface Hssi1/0/0, changed state to up
Table 5 describes the significant fields shown in the display.
debug ssm
To display diagnostic information about the Segment Switching Manager (SSM) for switched Layer 2 segments, use the debug ssm command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug ssm {cm errors | cm events | fhm errors | fhm events | sm errors | sm events | sm counters | xdr}
no debug ssm {cm errors | cm events | fhm errors | fhm events | sm errors | sm events | sm counters | xdr}
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The SSM manages the data-plane component of the Layer 2 Virtual Private Network (L2VPN) configuration. The CM tracks the connection-level errors and events that occur on an xconnect. The SM tracks the per-segment events and errors on the xconnect.
Use the debug ssm command to troubleshoot problems in bringing up the data plane.
This command is generally used only by Cisco engineers for internal debugging of SSM processes.
Examples
The following example shows sample output for the debug ssm xdr command:
Router# debug ssm xdr
SSM xdr debugging is on
2w5d: SSM XDR: [4096] deallocate segment, len 16
2w5d: SSM XDR: [8193] deallocate segment, len 16
2w5d: %LINK-3-UPDOWN: Interface FastEthernet2/1, changed state to down
2w5d: %LINK-3-UPDOWN: Interface FastEthernet2/1, changed state to up
2w5d: SSM XDR: [4102] provision segment, switch 4101, len 106
2w5d: SSM XDR: [4102] update segment status, len 17
2w5d: SSM XDR: [8199] provision segment, switch 4101, len 206
2w5d: SSM XDR: [4102] update segment status, len 17
2w5d: %SYS-5-CONFIG_I: Configured from console by console
2w5d: %LINK-3-UPDOWN: Interface FastEthernet2/1, changed state to down
2w5d: SSM XDR: [4102] update segment status, len 17
2w5d: %LINK-3-UPDOWN: Interface FastEthernet2/1, changed state to up
2w5d: SSM XDR: [4102] deallocate segment, len 16
2w5d: SSM XDR: [8199] deallocate segment, len 16
2w5d: SSM XDR: [4104] provision segment, switch 4102, len 106
2w5d: SSM XDR: [4104] update segment status, len 17
2w5d: SSM XDR: [8201] provision segment, switch 4102, len 206
2w5d: SSM XDR: [4104] update segment status, len 17
2w5d: SSM XDR: [4104] update segment status, len 17
2w5d: %SYS-5-CONFIG_I: Configured from console by console
The following example shows the events that occur on the segment manager when an Any Transport over MPLS (AToM) virtual circuit (VC) configured for Ethernet over MPLS is shut down and then enabled:
Router# debug ssm sm events
SSM Connection Manager events debugging is on
Router(config)# interface fastethernet 0/1/0.1
Router(config-subif)# shutdown
09:13:38.159: SSM SM: [SSS:AToM:36928] event Unprovison segment
09:13:38.159: SSM SM: [SSS:Ethernet Vlan:4146] event Unbind segment
09:13:38.159: SSM SM: [SSS:AToM:36928] free segment class
09:13:38.159: SSM SM: [SSS:AToM:36928] free segment
09:13:38.159: SSM SM: [SSS:AToM:36928] event Free segment
09:13:38.159: SSM SM: last segment class freed
09:13:38.159: SSM SM: [SSS:Ethernet Vlan:4146] segment ready
09:13:38.159: SSM SM: [SSS:Ethernet Vlan:4146] event Found segment data
Router(config-subif)# no shutdown
09:13:45.815: SSM SM: [SSS:AToM:36929] event Provison segment
09:13:45.815: label_oce_get_label_bundle: flags 14 label 16
09:13:45.815: SSM SM: [SSS:AToM:36929] segment ready
09:13:45.815: SSM SM: [SSS:AToM:36929] event Found segment data
09:13:45.815: SSM SM: [SSS:AToM:36929] event Bind segment
09:13:45.815: SSM SM: [SSS:Ethernet Vlan:4146] event Bind segment
The following example shows the events that occur on the CM when an AToM VC configured for Ethernet over MPLS is shut down and then enabled:
Router(config)# interface fastethernet 0/1/0.1
Router(config-subif)# shutdown
09:17:20.179: SSM CM: [AToM] unprovision segment, id 36929
09:17:20.179: SSM CM: CM FSM: state Open - event Free segment
09:17:20.179: SSM CM: [SSS:AToM:36929] unprovision segment 1
09:17:20.179: SSM CM: [SSS:AToM] shQ request send unprovision complete event
09:17:20.179: SSM CM: [SSS:Ethernet Vlan:4146] unbind segment 2
09:17:20.179: SSM CM: [SSS:Ethernet Vlan] shQ request send ready event
09:17:20.179: SSM CM: SM msg event send unprovision complete event
09:17:20.179: SSM CM: SM msg event send ready event
Router(config-subif)# no shutdown
09:17:35.879: SSM CM: Query AToM to Ethernet Vlan switching, enabled
09:17:35.879: SSM CM: [AToM] provision second segment, id 36930
09:17:35.879: SSM CM: CM FSM: state Down - event Provision segment
09:17:35.879: SSM CM: [SSS:AToM:36930] provision segment 2
09:17:35.879: SSM CM: [AToM] send client event 6, id 36930
09:17:35.879: SSM CM: [SSS:AToM] shQ request send ready event
09:17:35.883: SSM CM: SM msg event send ready event
09:17:35.883: SSM CM: [AToM] send client event 3, id 36930
The following example shows the events that occur on the CM and SM when an AToM VC is provisioned and then unprovisioned:
Router# debug ssm cm events
SSM Connection Manager events debugging is on
Router# debug ssm sm events
SSM Segment Manager events debugging is on
Router# configure terminal
Router(config)# interface ethernet1/0
Router(config-if)# xconnect 10.55.55.2 101 pw-class mpls
16:57:34: SSM CM: provision switch event, switch id 86040
16:57:34: SSM CM: [Ethernet] provision first segment, id 12313
16:57:34: SSM CM: CM FSM: state Idle - event Provision segment
16:57:34: SSM CM: [SSS:Ethernet:12313] provision segment 1
16:57:34: SSM SM: [SSS:Ethernet:12313] event Provison segment
16:57:34: SSM CM: [SSS:Ethernet] shQ request send ready event
16:57:34: SSM CM: SM msg event send ready event
16:57:34: SSM SM: [SSS:Ethernet:12313] segment ready
16:57:34: SSM SM: [SSS:Ethernet:12313] event Found segment data
16:57:34: SSM CM: Query AToM to Ethernet switching, enabled
16:57:34: SSM CM: [AToM] provision second segment, id 16410
16:57:34: SSM CM: CM FSM: state Down - event Provision segment
16:57:34: SSM CM: [SSS:AToM:16410] provision segment 2
16:57:34: SSM SM: [SSS:AToM:16410] event Provison segment
16:57:34: SSM CM: [AToM] send client event 6, id 16410
16:57:34: label_oce_get_label_bundle: flags 14 label 19
16:57:34: SSM CM: [SSS:AToM] shQ request send ready event
16:57:34: SSM CM: SM msg event send ready event
16:57:34: SSM SM: [SSS:AToM:16410] segment ready
16:57:34: SSM SM: [SSS:AToM:16410] event Found segment data
16:57:34: SSM SM: [SSS:AToM:16410] event Bind segment
16:57:34: SSM SM: [SSS:Ethernet:12313] event Bind segment
16:57:34: SSM CM: [AToM] send client event 3, id 16410
Router# configure terminal
Router(config)# interface e1/0
Router(config-if)# no xconnect
16:57:26: SSM CM: [Ethernet] unprovision segment, id 16387
16:57:26: SSM CM: CM FSM: state Open - event Free segment
16:57:26: SSM CM: [SSS:Ethernet:16387] unprovision segment 1
16:57:26: SSM SM: [SSS:Ethernet:16387] event Unprovison segment
16:57:26: SSM CM: [SSS:Ethernet] shQ request send unprovision complete event
16:57:26: SSM CM: [SSS:AToM:86036] unbind segment 2
16:57:26: SSM SM: [SSS:AToM:86036] event Unbind segment
16:57:26: SSM CM: SM msg event send unprovision complete event
16:57:26: SSM SM: [SSS:Ethernet:16387] free segment class
16:57:26: SSM SM: [SSS:Ethernet:16387] free segment
16:57:26: SSM SM: [SSS:Ethernet:16387] event Free segment
16:57:26: SSM SM: last segment class freed
16:57:26: SSM CM: unprovision switch event, switch id 12290
16:57:26: SSM CM: [SSS:AToM] shQ request send unready event
16:57:26: SSM CM: SM msg event send unready event
16:57:26: SSM SM: [SSS:AToM:86036] event Unbind segment
16:57:26: SSM CM: [AToM] unprovision segment, id 86036
16:57:26: SSM CM: CM FSM: state Down - event Free segment
16:57:26: SSM CM: [SSS:AToM:86036] unprovision segment 2
16:57:26: SSM SM: [SSS:AToM:86036] event Unprovison segment
16:57:26: SSM CM: [SSS:AToM] shQ request send unprovision complete event
16:57:26: SSM CM: SM msg event send unprovision complete event
16:57:26: SSM SM: [SSS:AToM:86036] free segment class
16:57:26: SSM SM: [SSS:AToM:86036] free segment
16:57:26: SSM SM: [SSS:AToM:86036] event Free segment
16:57:26: SSM SM: last segment class freed
Related Commands
interworking
To enable L2VPN Interworking, use the interworking command in pseudowire class configuration mode. To disable L2VPN Interworking, use the no form of this command.
interworking {ethernet | ip}
no interworking {ethernet | ip}
Syntax Description
Defaults
L2VPN Interworking is not enabled.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Table 6 shows which L2VPN Interworking features support Ethernet, IP, or both types of interworking.
The following example shows a pseudowire class configuration that enables L2VPN Interworking:
pseudowire-class ip-interworking
encapsulation mpls
interworking ip
Related Commands
mtu
To adjust the maximum packet size or maximum transmission unit (MTU) size, use the mtu command in interface configuration mode or connect submode. To restore the MTU value to its original default value, use the no form of this command.
mtu bytes
no mtu
Syntax Description
Defaults
Table 7 lists default MTU values according to media type.
Table 7 Default Media MTU Values
Media Type Default MTU (Bytes)Ethernet
1500
Serial
1500
Token Ring
4464
ATM
4470
FDDI
4470
HSSI (HSA)
4470
Command Modes
Interface configuration
Connect submode (for Frame Relay Layer 2 Interworking)Command History
Usage Guidelines
Each interface has a default maximum packet size or MTU size. This number generally defaults to the largest size possible for that interface type. On serial interfaces, the MTU size varies, but cannot be set smaller than 64 bytes.
Note Changing an MTU size on a Cisco 7500 series router results in the recarving of buffers and
resetting of all interfaces. The following message is displayed:.
%RSP-3-Restart:cbus complexProtocol-Specific Versions of the mtu Command
Changing the MTU value with the mtu interface configuration command can affect values for the protocol-specific versions of the command (the ip mtu command, for example). If the value specified with the ip mtu interface configuration command is the same as the value specified with the mtu interface configuration command, and you change the value for the mtu interface configuration command, the ip mtu value automatically matches the new mtu interface configuration command value. However, changing the values for the ip mtu configuration commands has no effect on the value for the mtu interface configuration command.
ATM and LANE Interfaces
ATM interfaces are not bound by what is configured on the major interface. By default, MTU on a subinterface is equal to the default MTU (4490); if a client is configured the default is 1500. MTU can be changed on subinterfaces, but it may result in recarving of buffers to accommodate the new maximum MTU on the interface.
Examples
The following example specifies an MTU of 1000 bytes:
Router(config)# interface serial 1
Router(config-if)# mtu 1000
Related Commands
Command Descriptionencapsulation smds
Enables SMDS service on the desired interface.
ip mtu
Sets the MTU size of IP packets sent on an interface.
show l2tun session
To display the current state of Layer 2 sessions and protocol information about Layer 2 Tunnel Protocol (L2TP) control channels, use the show l2tun session command in privileged EXEC mode.
show l2tun session [all [filter] | brief [filter] [hostname] | circuit [filter] [hostname] | interworking [filter] [hostname] | packets [filter] | sequence [filter] | state [filter]]
Syntax Description
all
(Optional) Displays information about all current L2TP sessions on the router.
filter
(Optional) One of the filter parameters defined in Table 8.
brief
(Optional) Displays information about all current L2TP sessions, including peer ID address and circuit status of the L2TP sessions.
hostname
(Optional) Specifies that the peer hostname will be displayed in the output.
circuit
(Optional) Displays information about all current L2TP sessions, including circuit status (up or down).
interworking
(Optional) Displays information about Layer 2 Virtual Private Network (L2VPN) interworking.
packets
(Optional) Displays information about the packet counters (in and out) associated with current L2TP sessions.
sequence
(Optional) Displays sequencing information about each L2TP session, including number of out-of-order and returned packets.
state
(Optional) Displays information about all current L2TP sessions and their protocol state, including remote Virtual Connection Identifier (VCIDs).
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the show l2tun session command to display information about current L2TP sessions on the router.
Table 8 defines the filter parameters available to refine the output of the show l2tun session command.
Examples
The following example shows how to display detailed information about all current L2TP sessions:
Router# show l2tun session all
Session Information Total tunnels 0 sessions 1
Session id 42438 is down, tunnel id 45795
Remote session id is 0, remote tunnel id 43092
Session Layer 2 circuit, type is Ethernet, name is FastEthernet4/1/1
Session vcid is 123456789
Circuit state is DOWN
Local circuit state is DOWN
Remote circuit state is DOWN
Call serial number is 1463700128
Remote tunnel name is PE1
Internet address is 10.1.1.1
Local tunnel name is PE1
Internet address is 10.1.1.2
IP protocol 115
Session is L2TP signalled
Session state is idle, time since change 00:00:26
0 Packets sent, 0 received
0 Bytes sent, 0 received
Last clearing of "show vpdn" counters never
Receive packets dropped:
out-of-order: 0
total: 0
Send packets dropped:
exceeded session MTU: 0
total: 0
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
No session cookie information available
UDP checksums are disabled
L2-L2 switching enabled
No FS cached header information available
Sequencing is off
Unique ID is 1
The following example shows how to display information only about the L2TP session set up on a peer router with an IP address of 172.16.184.142 and a VCID of 300:
Router# show l2tun session all ip-addr 172.16.184.142 vcid 300
L2TP Session
Session id 32518 is up, tunnel id 35217
Call serial number is 2074900020
Remote tunnel name is tun1
Internet address is 172.16.184.142
Session is L2TP signalled
Session state is established, time since change 03:06:39
9932 Packets sent, 9932 received
1171954 Bytes sent, 1171918 received
Session vcid is 300
Session Layer 2 circuit, type is Ethernet Vlan, name is FastEthernet0/1/0.3:3
Circuit state is UP
Remote session id is 18819, remote tunnel id 37340
Set DF bit to 0
Session cookie information:
local cookie, size 4 bytes, value CF DC 5B F3
remote cookie, size 4 bytes, value FE 33 56 C4
SSS switching enabled
Sequencing is on
Ns 9932, Nr 10001, 0 out of order packets discarded
Table 9 describes the significant fields shown in the displays.
The following example shows how to display information about the circuit status of L2TP sessions on a router:
Router# show l2tun session circuit
Session Information Total tunnels 3 sessions 3
LocID TunID Peer-address Type Stat Username, Intf/
Vcid, Circuit
32517 26515 172.16.184.142 VLAN UP 100, Fa0/1/0.1:1
32519 30866 172.16.184.142 VLAN UP 200, Fa0/1/0.2:2
32518 35217 172.16.184.142 VLAN UP 300, Fa0/1/0.3:3
The following example shows how to display information about the circuit status of L2TP sessions and the hostnames of remote peers:
Router# show l2tun session circuit hostname
Session Information Total tunnels 3 sessions 3
LocID TunID Peer-hostname Type Stat Username, Intf/
Vcid, Circuit
32517 26515 <unknown> VLAN UP 100, Fa0/1/0.1:1
32519 30866 router32 VLAN UP 200, Fa0/1/0.2:2
32518 35217 access3 VLAN UP 300, Fa0/1/0.3:3
Table 10 describes the significant fields shown in the displays.
Related Commands
show l2tun tunnel
To display the current state of Layer 2 Tunneling Protocol (L2TP) tunnels and information about configured tunnels, including local and remote hostnames, aggregate packet counts, and control channel information, use the show l2tun tunnel command in privileged EXEC mode.
Cisco IOS Release 12.0(30)S and Earlier Releases, Cisco IOS Release 12.3(2)T and Later Releases, Cisco IOS Release 12.2(25)S, Cisco IOS Release 12.2(28)SB
show l2tun tunnel [all [filter] | packets [filter] | state [filter] | summary [filter] | transport [filter]]
Cisco IOS Release 12.0(31)S and Later Releases, Cisco IOS Release 12.2(27)SBC, Cisco IOS Release 12.2(33)SRA
show l2tun tunnel [all [filter] | packets [filter] | state [filter] | summary [filter] | transport [filter] | authentication]
Syntax Description
all
(Optional) Displays information about all current L2TP sessions configured on the router.
filter
(Optional) One of the filter parameters defined in Table 11.
packets
(Optional) Displays aggregate packet counts for all negotiated L2TP sessions.
state
(Optional) Displays information about the current state of L2TP sessions, including the local and remote hostnames for each control channel.
summary
(Optional) Displays a summary of L2TP sessions on the router and their current state, including the number of virtual private dialup network (VPDN) sessions associated with each control channel.
transport
(Optional) Displays information about the L2TP control channels used in each session and the local and remote IP addresses at each end of the control channel.
authentication
(Optional) Displays global information about L2TP control channel authentication attribute-value pairs (AV pairs).
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the show l2tun tunnel command to display information about configured L2TP sessions on the router.
Table 11 defines the filter parameters available to refine the output of the show l2tun tunnel command.
Examples
The following example shows how to display detailed information about all L2TP tunnels:
Router# show l2tun tunnel all
Tunnel Information Total tunnels 1 sessions 1
Tunnel id 26515 is up, remote id is 41814, 1 active sessions
Tunnel state is established, time since change 03:11:50
Tunnel transport is IP (115)
Remote tunnel name is tun1
Internet Address 172.16.184.142, port 0
Local tunnel name is Router
Internet Address 172.16.184.116, port 0
Tunnel domain is
VPDN group for tunnel is
L2TP class for tunnel is
0 packets sent, 0 received
0 bytes sent, 0 received
Control Ns 11507, Nr 11506
Local RWS 2048 (default), Remote RWS 800
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 1, max 1
Total resends 0, ZLB ACKs sent 11505
Total peer authentication failures 8
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
The following example shows the display of pseudowire control channel password information:
Router# show l2tun tunnel all
!
Control message authentication is on, 2 secrets configured
Last message authenticated with first digest secret
!
Table 12 describes the significant fields shown in the displays.
The following example shows how to filter information to display L2TP control channel details only for the sessions configured with the local name Router and the remote name tun1:
Router# show l2tun tunnel transport local-name Router tun1
Tunnel Information Total tunnels 3 sessions 3
LocID Type Prot Local Address Port Remote Address Port
26515 IP 115 172.16.184.116 0 172.16.184.142 0
30866 IP 115 172.16.184.116 0 172.16.184.142 0
35217 IP 115 172.16.184.116 0 172.16.184.142 0
Table 13 describes the significant fields shown in the display.
The following example shows how to display information about the current state of L2TP sessions with the local and remote hostnames of each session:
Router# show l2tun tunnel state
LocID RemID Local Name Remote Name State Last-Chg
26515 41814 Router tun1 est 03:13:15
30866 6809 Router tun1 est 03:13:15
35217 37340 Router tun1 est 03:13:15
Table 14 describes the significant fields shown in the display.
The following example shows the display of all possible L2TP control channel authentication AV pair statistics. AV pair statistic fields are displayed only if they are nonzero. For the purposes of this example, all possible output fields are displayed in the sample output.
This example is valid for Cisco IOS Release 12.0(31)S and later releases or Cisco IOS Release 12.2(27)SBC. To display authentication statistics in Cisco IOS Release 12.2(28)SB or a later release, use the monitor l2tun counters tunnel l2tp and show l2tun counters tunnel l2tp commands instead.
Router# show l2tun tunnel authentication
L2TPv3 Tunnel Authentication Statistics:
Nonce AVP Statistics:
Ignored 0
Missing 0
All Digests Statistics:
Unexpected 0
Unexpected ZLB 0
Primary Digest AVP Statistics:
Validate fail 0
Hash invalid 0
Length invalid 0
Missing 0
Ignored 0
Passed 0
Failed 0
Secondary Digest AVP Statistics:
Validate fail 0
Hash invalid 0
Length invalid 0
Missing 0
Ignored 0
Passed 0
Failed 0
Integrity Check Statistics:
Validate fail 0
Length invalid 0
Passed 0
Failed 0
Local Secret Statistics:
Missing 0
Challenge AVP Statistics:
Generate response fail 0
Ignored 0
Challenge/Response AVP Statistics:
Generate response fail 0
Missing 0
Ignored 0
Passed 0
Failed 0
Overall Statistics:
Passed 0
Skipped 0
Ignored 0
Failed 0
Table 15 describes the significant fields shown in the display.
Related Commands
show mpls l2transport vc
To display information about Any Transport over MPLS (AToM) virtual circuits (VCs) that have been enabled to route Layer 2 packets on a router, use the show mpls l2transport vc command in privileged EXEC mode.
show mpls l2transport vc [vcid vc-id] | [vcid vc-id-min vc-id-max] [interface name [local-circuit-id]] [destination ip-address | name] [detail]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
If you do not specify any keywords or arguments, the command displays a summary of all the VCs.
Examples
The output of the commands varies, depending on the type of Layer 2 packets being transported over the AToM VCs.
The following sample output shows information about the interfaces and VCs that have been configured to transport various Layer 2 packets on the router:
Router# show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- ------------------ --------------- ---------- ----------
Se5/0 FR DLCI 55 10.0.0.1 55 UP
AT4/0 ATM AAL5 0/100 10.0.0.1 100 UP
AT4/0 ATM AAL5 0/200 10.0.0.1 200 UP
AT4/0.300 ATM AAL5 0/300 10.0.0.1 300 UP
Table 16 describes the significant fields shown in the display.
The following example shows information about the NSF/SSO and GR capability. The SSO portion indicates when checkpointing data has either been sent (on active) or received (on standby). When SSO data has not been successfully sent or has been released, the SSO information is not shown.
Router# show mpls l2transport vc detail
Local interface: Fa5/1/1.2 down, line protocol down, Eth VLAN 2 up
Destination address: 10.55.55.2, VC ID: 1002, VC status: down
Output interface: Se4/0/3, imposed label stack {16}
Preferred path: not configured
Default path: active
Tunnel label: imp-null, next hop point2point
Create time: 02:03:29, last status change time: 02:03:26
Signaling protocol: LDP, peer 10.55.55.2:0 down
MPLS VC labels: local 16, remote unassigned
Group ID: local 0, remote unknown
MTU: local 1500, remote unknown
Remote interface description:
Sequencing: receive disabled, send disabled
SSO Descriptor: 10.55.55.2/1002, local label: 16
SSM segment/switch IDs: 12290/8193, PWID: 8193
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, send 0
Table 17 describes the significant fields shown in the display.
Related Commands
Command Descriptionshow mpls l2transport summary
Displays summary information about VCs that have been enabled to route AToM Layer 2 packets on a router.
Feature Information for L2VPN Interworking
Table 18 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note Table 18 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2006 Cisco Systems, Inc. All rights reserved.
Posted: Mon Jun 19 19:11:16 PDT 2006
All contents are Copyright © 1992--2006 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.