Downloads |
 Feedback
|
Table Of Contents
Layer 2 Tunnel Protocol Version 3
Prerequisites for Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Supported Port Adapters for the Cisco 7200 and 7500 Series Routers
Supported Line Cards for the Cisco 10720 Internet Router
Supported Line Cards for the Cisco 12000 Series Internet Routers
Cisco 7500-Specific Restrictions
Cisco 10720-Specific Restrictions
Cisco 12000 Series-Specific Restrictions
Frame Relay-Specific Restrictions
ATM VP Mode Single Cell Relay over L2TPv3 Restrictions
Information About Layer 2 Tunnel Protocol Version 3
Pseudowire Control Encapsulation
L2TPv3 Type of Service Marking
L2TPv3 and UTI Feature Comparison
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring L2TP Control Channel Parameters
Configuring L2TP Control Channel Timing Parameters
Configuring L2TP Control Channel Authentication Parameters
Configuring L2TP Control Channel Maintenance Parameters
Configuring the L2TPv3 Pseudowire
Configuring the Xconnect Attachment Circuit
Manually Configuring L2TPv3 Session Parameters
Configuring the Xconnect Attachment Circuit for ATM VP Mode Single Cell Relay over L2TPv3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring Frame Relay DLCI-to-DLCI Switching Example
Configuring Frame Relay Trunking Example
Configuring QoS for L2TPv3 on the Cisco 7500 Series Example
Configuring QoS for L2TPv3 on the Cisco 12000 Series Example
Configuring MLFR for L2TPv3 on the Cisco 12000 Series Example
Configuring a Static L2TPv3 Session for an Xconnect Ethernet Interface Example
Configuring a Negotiated L2TPv3 Session for an Xconnect VLAN Subinterface Example
Configuring a Negotiated L2TPv3 Session for Local HDLC Switching Example
Configuring a Pseudowire Class for Fragmentation of IP Packets Example
Configuring the Xconnect Attachment Circuit for ATM VP Mode Single Cell Relay over L2TPv3 Example
Verifying an L2TPv3 Session Example
Verifying an L2TP Control Channel Example
Verifying ATM VP Mode Single Cell Relay over L2TPv3 Configuration
snmp-server enable traps l2tun session
Layer 2 Tunnel Protocol Version 3
The Layer 2 Tunnel Protocol Version 3 feature expands on Cisco support of the Layer 2 Tunnel Protocol Version 3 (L2TPv3). L2TPv3 is an Internet Engineering Task Force (IETF) l2tpext working group draft that provides several enhancements to L2TP for the capability to tunnel any Layer 2 payload over L2TP. Specifically, L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network using Layer 2 virtual private networks (VPNs). Benefits of this feature include the following:
•
L2TPv3 simplifies deployment of VPNs
•
•
Feature Specifications for Layer 2 Tunneling Protocol Version 3
Note
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
•
•
•
•
•
Prerequisites for Layer 2 Tunnel Protocol Version 3
•
•
•
Restrictions for Layer 2 Tunnel Protocol Version 3
The following subsections contain information on restrictions:
•
•
•
•
•
•
•
•
Supported Port Adapters for the Cisco 7200 and 7500 Series Routers
L2TPv3 is supported on the following port adapters in the Cisco 7200 and 7500 series routers:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
L2TPv3 is supported on the following port adapters for the Cisco 7200 series routers only:
•
•
Supported Line Cards for the Cisco 10720 Internet Router
L2TPv3 is supported on the following uplink and access cards in the Cisco 10720 Internet router:
•
•
•
•
•
Supported Line Cards for the Cisco 12000 Series Internet Routers
Table 1 shows the line cards that support L2TPv3 for the Cisco 12000 series Internet routers.
Table 1
Supported Line Cards for the Cisco 12000 Series Internet Routers
General L2TPv3 Restrictions
•
•
•
When L2TPv3 is used to tunnel Frame Relay DLCIs, an IDB is not required for each circuit. As a result, the memory requirements are much lower. The scalability targets for the Engineering Field Test (EFT) program are 4000 L2TP sessions, which exceeds the IDB limitations for any Cisco platform in Release 12.0(24)S.
•
•
•
•
•
•
Cisco 7500-Specific Restrictions
•
Cisco 10720-Specific Restrictions
•
•
•
•
You can also configure a LAN interface as the IP local interface so that the tunnel control session is tied to an operational LAN (Gigabit Ethernet or Fast Ethernet) interface or subinterface. However, in this case, the tunnel control plane is used only as long as the Gigabit Ethernet or Fast Ethernet interface is operational.
Cisco 12000 Series-Specific Restrictions
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
•
•
Frame Relay-Specific Restrictions
•
•
•
•
•
•
–
–
The police command is supported as follows:
- Only the transmit keyword is supported with the conform-action action parameter.
- Only the set-frde-transmit value is supported with the exceed-action action parameter.
- Only the drop value is supported with the violate-action action parameter.
Backward explicit congestion notification (BECN) and forward explicit congestion notification (FECN) configuration are not supported.
The ToS byte must be configured in IP headers of tunneled Frame Relay packets when you configure the L2TPv3 pseudowire (see Configuring the L2TPv3 Pseudowire).
All standard restrictions for configuring QoS on Cisco 12000 Series line cards apply to configuring QoS for L2TPv3 on Cisco 12000 Series 2-port Ch OC-3/STM-1 (DS1/E1) or 6-port Ch T3 line cards.
On the ingress side of a Cisco 12000 Series Frame Relay interface:
- Weighted random early detection (WRED) and modified deficit round robin (MDRR) configurations are not supported.
On the egress side of a Cisco 12000 Series Frame Relay interface:
- Modified Deficit Round Robin (MDRR) is the only queuing strategy supported.
- Weighted Random Early Detection (WRED) is the only packet drop strategy supported.
- MDRR is supported only in the following modes:
With both a low latency (priority) queue and class-default queue configured. (The low latency queue is only supported in combination with the class-default queue, and cannot be configured with normal distributed round robin (DRR) queues.)
Without a low latency queue configured. (In this case, only 6 queues are supported, including the class-default queue.)
- Egress queuing is determined according to the IP Precedence value(s) configured for classes of L2TPv3 Frame Relay traffic using the match ip precedence command, instead of on a per-DLCI basis.
•
•
•
•
•
•
VLAN-Specific Restrictions
•
•
•
ATM VP Mode Single Cell Relay over L2TPv3 Restrictions
•
•
Information About Layer 2 Tunnel Protocol Version 3
To configure the Layer 2 Tunnel Protocol Version 3 feature, you must understand the following concepts:
•
Migration from UTI to L2TPv3
UTI is a Cisco proprietary protocol that offers a simple high-speed transparent Layer 2-to-Layer 2 service over an IP backbone. The UTI protocol lacks the signaling capability and standards support necessary for large-scale commercial service. To begin to answer the need for a standard way to provide large-scale VPN connectivity over an IP core network, limited migration from UTI to L2TPv3 was introduced in Cisco IOS Release 12.0(21)S. The L2TPv3 feature in Cisco IOS Release 12.0(23)S introduced a more robust version of L2TPv3 to replace UTI.
As described in the section "L2TPv3 Header Description," the UTI data header is identical to the L2TPv3 header but with no sequence numbers and an 8-byte cookie. By manually configuring an L2TPv3 session using an 8-byte cookie (see the section "Manually Configuring L2TPv3 Session Parameters") and by setting the IP protocol number of outgoing data packets to 120 (as described in the section "Configuring the L2TPv3 Pseudowire"), you can ensure that a PE running L2TPv3 may interoperate with a peer PE running UTI. However, because UTI does not define a signaling plane, dynamically established L2TPv3 sessions cannot interoperate with UTI.
When a customer upgrades from a pre-L2TPv3 Cisco IOS release to a post-L2TPv3 release, an internal UTI-to-Xconnect command-line interface (CLI) migration utility will automatically convert the UTI commands to Xconnect and pseudowire class configuration commands without the need for any user intervention. After the CLI migration, the UTI commands that were replaced will not be available. The old-style UTI CLI will be hidden from the user.
Note
L2TPv3 Operation
L2TPv3 provides similar and enhanced services to replace the current UTI implementation, including the following features:
•
•
The initial Cisco IOS Release 12.0(23)S features supported only the following features:
•
•
•
•
The attachment circuit is the physical interface or subinterface attached to the pseudowire.
Figure 1 shows an example of how the L2TPv3 feature is used for setting up VPNs using Layer 2 tunneling over an IP network. All traffic between two customer network sites is encapsulated in IP packets carrying L2TP data messages and sent across an IP network. The backbone routers of the IP network treat the traffic as any other IP traffic and need not know anything about the customer networks.
Figure 1 L2TPv3 Operation
In Figure 1, the PE routers R1 and R2 provide L2TPv3 services. The R1 and R2 routers communicate with each other using a pseudowire over the IP backbone network through a path comprising the interfaces int1 and int2, the IP network, and interfaces int3 and int4.
In this example, the CE routers R3 and R4 communicate through a pair of Xconnect Ethernet or 802.1q VLAN interfaces using an L2TPv3 session. The L2TPv3 session tu1 is a pseudowire configured between interface int1 on R1 and interface int4 on R2. Any packet arriving on interface int1 on R1 is encapsulated and sent via the pseudowire control channel (tu1) to R2. R2 decapsulates the packet and sends it on interface int4 to R4. When R4 needs to send a packet to R3, the packet follows the same path in reverse.
Please note the following features regarding L2TPv3 operation:
•
•
•
•
Benefits of Using L2TPv3
L2TPv3 Simplifies Deployment of VPNs
L2TPv3 is an industry-standard Layer 2 tunneling protocol that ensures interoperability among vendors, increasing customer flexibility and service availability.
L2TPv3 Does Not Require MPLS
With L2TPv3 service providers need not deploy MPLS in the core IP backbone to set up VPNs using L2TPv3 over the IP backbone, resulting in operational savings and increased revenue.
L2TPv3 Supports Layer 2 Tunneling over IP for Any Payload
L2TPv3 provides enhancements to L2TP to support Layer 2 tunneling of any payload over an IP core network. L2TPv3 defines the base L2TP protocol as being separate from the Layer 2 payload that is tunneled.
L2TPv3 Header Description
The migration from UTI to L2TPv3 also requires the standardization of the UTI header. As a result, the L2TPv3 header has the new format shown in Figure 2.
Each L2TPv3 packet contains an L2TPv3 header that includes a unique session ID representing one session and a variable cookie length. The L2TPv3 session ID and the Tunnel Cookie field length are assigned via the CLI. See the section "How to Configure Layer 2 Tunnel Protocol Version 3" for more information on the CLI commands for L2TPv3.
Figure 2 L2TPv3 Header Format
IP Delivery Header (20 bytes)
Protocol ID: 115L2TPV3 Header consisting of:
Session ID (4 bytes)
Cookie (0, 4, or 8 bytes)
Pseudowire Control Encapsulation
(4 bytes by default)Layer 2 Payload
Session ID
The L2TPv3 session ID is similar to the UTI session ID, and identifies the session context on the decapsulating system. For dynamic sessions, the value of the session ID is selected to optimize the context identification efficiency of the decapsulating system. A decapsulation implementation may therefore elect to support a smaller session ID bit field. In this L2TPv3 implementation, an upper value for the L2TPv3 session ID was set at 023. The L2TPv3 session ID value 0 is reserved for use by the protocol. For static sessions, the session ID is manually configured.
Note
Session Cookie
The L2TPv3 header contains a control channel cookie field that is similar to the UTI control channel key field. The control channel cookie field, however, has a variable length of 0, 4, or 8 bytes according to the cookie length supported by a given platform for packet decapsulation. The control channel cookie length can be manually configured for static sessions, or dynamically determined for dynamic sessions.
The variable cookie length does not present a problem when the same platform is at both ends of an L2TPv3 control channel. However, when different platforms interoperate across an L2TPv3 control channel, both platforms need to encapsulate packets with a 4-byte cookie length.
Pseudowire Control Encapsulation
The L2TPv3 pseudowire control encapsulation consists of 32 bits (4 bytes) and contains information used to sequence L2TP packets (see the section "Sequencing"). For the purposes of sequencing, only the first bit and bits 8 to 31 are relevant.
Bit 1 indicates whether the Sequence Number field, bits 8 to 31, contains a valid sequence number and is to be updated.
L2TPv3 Features
L2TPv3 provides Xconnect support for Ethernet, 802.1q (VLAN), Frame Relay, HDLC, and PPP, using the sessions described in the following sections:
•
•
L2TPv3 also includes support for the features described in the following sections:
•
Static L2TPv3 Sessions
Typically, the L2TP control plane is responsible for negotiating session parameters, such as the session ID or the cookie, in order to set up the session. However, some IP networks require sessions to be configured so that no signaling is required for session establishment. You can, therefore, set up static L2TPv3 sessions for a PE router by configuring fixed values for the fields in the L2TP data header. A static L2TPv3 session allows the PE to tunnel Layer 2 traffic as soon as the attachment circuit to which the session is bound comes up.
Note
When you use a static L2TPv3 session, you cannot perform circuit interworking, such as LMI, because there is no facility to exchange control messages. To perform circuit interworking, you must use a dynamic session.
Dynamic L2TPv3 Sessions
A dynamic L2TP session is established through the exchange of control messages containing attribute-value pairs (AVPs). Each AVP contains information about the nature of the Layer 2 link being forwarded: the payload type, virtual circuit (VC) ID, and so on.
Multiple L2TP sessions (one for each forwarded Layer 2 circuit) can exist between a pair of PEs, and can be maintained by a single control channel. Session IDs and cookies are dynamically generated and exchanged as part of a dynamic session setup. Information such as sequencing configuration is also exchanged. Circuit state changes (UP/DOWN) are conveyed using the SLI message.
Sequencing
Although the correct sequence of received Layer 2 frames is guaranteed by some Layer 2 technologies (by the nature of the link, such as a serial line) or the protocol itself, forwarded Layer 2 frames may be lost, duplicated, or reordered when they traverse a network as IP packets. If the Layer 2 protocol does not provide an explicit sequencing mechanism, you can configure L2TP to sequence its data packets according to the data channel sequencing mechanism described in the L2TPv3 IETF l2tpext working group draft.
A receiver of L2TP data packets mandates sequencing through the Sequencing Required AVP when the session is being negotiated. A sender that receives this AVP (or that is manually configured to send sequenced packets) uses the Layer 2-specific pseudowire control encapsulation defined in L2TPv3.
Currently, you can configure L2TP only to drop out-of-order packets; you cannot configure L2TP to deliver the packets out-of-order. No reordering mechanism is available.
Local Switching
Local switching (from one port to another port in the same router) is supported for both static and dynamic sessions. You must configure separate IP addresses for each Xconnect statement.
See the section "Configuration Examples for Layer 2 Tunnel Protocol Version 3" for an example of how to configure local port switching.
Distributed Switching
Distributed Cisco Express Forwarding (dCEF) switching is supported for L2TP on the Cisco 7500 series and Cisco 12000 series Internet routers.
Note
IP Packet Fragmentation
It is desirable to avoid fragmentation issues in the service provider network because reassembly is computationally expensive. The easiest way to avoid fragmentation issues is to configure the CE routers with an MTU value that is smaller than the pseudowire path MTU. However, in scenarios where this is not an option, fragmentation issues must be considered. Previously, L2TP supported only the following options for packet fragmentation when a packet is determined to exceed the L2TP path MTU:
•
•
•
Cisco IOS Release 12.0(24)S introduces the ability to allow IP traffic from the CE router to be fragmented before the data enters the pseudowire, forcing the computationally expensive reassembly to occur in the CE network rather than in the service provider network. The number of fragments that must be generated is determined based on the discovered pseudowire path MTU. The original L2 header is then copied to each of the generated fragments, the L2TP/IP encapsulation is added, and the frames are then forwarded. This feature will be implicitly enabled whenever the ip pmtu command is enabled in the pseudowire class. It will be applied to any packets received from the CE network that have a Don't Fragment (DF) bit set to 0 and that exceed the L2TP path MTU in size.
Fragmentation of IP packets before the data enters the pseudowire is supported on the Cisco 7200 series, Cisco 7500 series, and Cisco 12000 Internet Routers in Cisco IOS Release 12.0(24)S.
L2TPv3 Type of Service Marking
When Layer 2 traffic is tunneled across an IP network, information contained in the ToS bits may be transferred to the L2TP-encapsulated IP packets in one of the following ways:
•
•
•
See the section "Configuring a Negotiated L2TPv3 Session for Local HDLC Switching Example" for more information about how to configure ToS information.
Keepalive
The keepalive mechanism for L2TPv3 extends only to the endpoints of the tunneling protocol. L2TP has a reliable control message delivery mechanism that serves as the basis for the keepalive mechanism. The keepalive mechanism consists of an exchange of L2TP hello messages.
If a keepalive mechanism is required, the control plane is used, although it may not be used to bring up sessions. You can manually configure sessions.
In the case of static L2TPv3 sessions, a control channel between the two L2TP peers is negotiated through the exchange of start control channel request (SCCRQ), start control channel replay (SCCRP), and start control channel connected (SCCCN) control messages. The control channel is responsible only for maintaining the keepalive mechanism through the exchange of hello messages.
The interval between hello messages is configurable per control channel. If one peer detects that the other has gone down through the keepalive mechanism, it sends a StopCCN control message and then notifies all of the pseudowires to the peer about the event. This notification results in the teardown of both manually configured and dynamic sessions.
MTU Handling
It is important that you configure an MTU appropriate for a each L2TPv3 tunneled link. The configured MTU size ensures the following:
•
•
L2TPv3 handles the MTU as follows:
•
•
•
–
–
L2TPv3 and UTI Feature Comparison
Table 1 compares L2TPv3 and UTI support.
Supported L2TPv3 Payloads
L2TPv3 supports the following Layer 2 payloads that can be included in L2TPv3 packets tunneled over the pseudowire:
•
•
•
Note
Frame Relay
L2TPv3 supports the Frame Relay functionality described in the following sections:
•
Port-to-Port Trunking
Port-to-port trunking is where two CE Frame Relay interfaces are connected as by a leased line (UTI "raw" mode). All traffic arriving on one interface is forwarded transparently across the pseudowire to the other interface.
For example, in Figure 1, if the two CE routers are connected by a virtual leased line, the PE routers transparently transport all packets between CE R3 and CE R4 over a pseudowire. PE R1 and PE R2 do not examine or change the DLCIs, and do not participate in the LMI protocol. The two CE routers are LMI peers. There is nothing Frame Relay-specific about this service as far as the PE routers are concerned. The CE routers should be able to use any encapsulation based on HDLC framing without needing to change the provider configuration.
DLCI-to-DLCI Switching
Frame Relay DLCI-to-DLCI switching is where individual Frame Relay DLCIs are connected to create an end-to-end Frame Relay PVC. Traffic arriving on a DLCI on one interface is forwarded across the pseudowire to another DLCI on the other interface.
For example, in Figure 1, CE R3 and PE R1 are Frame Relay LMI peers; CE R4 and PE R2 are also LMI peers. You can use a different type of LMI between CE R3 and PE R1 compared to what you use between CE R4 and PE R2.
The CE devices may be a Frame Relay switch or end-user device. Each Frame Relay PVC is composed of multiple segments. The DLCI value is local to each segment and is changed as traffic is switched from segment to segment. Note that, in Figure 1, two Frame Relay PVC segments are connected by a pseudowire. Frame Relay header flags (FECN, BECN, C/R, DE) are preserved across the pseudowire.
PVC Status Signaling
PVC status signaling is propagated toward Frame Relay end users by the LMI protocol. You can configure the LMI to operate in any of the following modes:
•
•
•
L2TPv3 supports all three modes.
The PVC status should be reported as ACTIVE only if the PVC is available from the reporting device to the Frame Relay end-user device. All interfaces, line protocols, and pseudowires must be operational between the reporting device and the Frame Relay end-user device.
Note that any keepalive functions on the session are independent of Frame Relay, but any state changes that are detected are fed into the PVC status reporting. For example, the L2TP control channel uses hello packets as a keepalive function. If the L2TPv3 keepalive fails, all L2TPv3 sessions are torn down. Loss of the session is notified to Frame Relay, which can then report PVCs INACTIVE to the CE devices.
For example, in Figure 1, CE R3 reports ACTIVE to PE R1 only if the PVC is available within CE R3. When CE R3 is a switch, it reports all the way to the user device in the customer network.
PE R1 reports ACTIVE to CE R3 only if the PVC is available within PE R1 and all the way to the end-user device (via PE R2 and CE R3) in the other customer VPN site.
The ACTIVE state is propagated hop-by-hop, independently in each direction, from one end of the Frame Relay network to the other end.
Sequencing
Frame Relay provides an ordered service in which packets sent to the Frame Relay network by one end-user device are delivered in order to the other end-user device. When switching is occurring over the pseudowire, packet ordering must be able to be preserved with a very high probability to closely emulate a traditional Frame Relay service. If the CE router is not using a protocol that can detect misordering itself, configuring sequence number processing may be important. For example, if the Layer 3 protocol is IP and Frame Relay is therefore used only for encapsulation, sequencing is not required. To detect misordering, you can configure sequence number processing separately for transmission or reception. For more information about how to configure sequencing, see the section "Configuring a Negotiated L2TPv3 Session for Local HDLC Switching Example."
ToS Marking
The ToS bytes in the IP header can be statically configured or reflected from the internal IP header. The Frame Relay DE bit does not influence the ToS bytes.
CIR Guarantees
In order to provide committed information rate (CIR) guarantees, you can configure a queueing policy that provides bandwidth to each DLCI to the interface facing the customer network on the egress PE.
Note
Binding L2TPv3 Sessions to Multilink Frame Relay Interfaces
The configuration of an L2TPv3 session on a Multilink Frame Relay (MLFR) bundle interface is supported only on Cisco 12000 Series Two-Port Channelized OC-3/STM-1 (DS1/E1) and Six-Port Channelized T3 (T1) line cards.
The Multilink Frame Relay feature introduces functionality based on the Frame Relay Forum Multilink Frame Relay UNI/NNI Implementation Agreement (FRF.16). This feature provides a cost-effective way to increase bandwidth for particular applications by enabling multiple serial links to be aggregated into a single bundle of bandwidth.
For an example of how to configure L2TPv3 tunneling on a multilink Frame Relay bundle interface, see Configuring MLFR for L2TPv3 on the Cisco 12000 Series Example.
For information about how configure and use the MLFR feature, refer to the Multilink Frame Relay (FRF.16) publication.
Ethernet
An Ethernet frame arriving at a PE router is simply encapsulated in its entirety with an L2TP data header. At the other end, a received L2TP data packet is stripped of its L2TP data header. The payload, an Ethernet frame, is then forwarded to the appropriate attachment circuit.
Because the L2TPv3 tunneling protocol serves essentially as a bridge, it need not examine any part of an Ethernet frame. Any Ethernet frame received on an interface is tunneled, and any L2TP-tunneled Ethernet frame is forwarded out the interface.
Note
802.1q (VLAN)
L2TPv3 supports VLAN membership in the following ways:
•
•
In L2TPv3, Ethernet Xconnect supports port-based VLAN membership and the reception of tagged Ethernet frames. A tagged Ethernet frame contains a tag header (defined in 802.1Q), which is 4-bytes long and consists of a 2-byte tag protocol identifier (TPID) field and a 2-byte tag control information (TCI) field. The TPID indicates that a TCI follows. The TCI is further broken down into the following three fields:
•
•
•
For L2TPv3, an Ethernet subinterface configured to support VLAN switching may be bound to an Xconnect service so that all Ethernet traffic, tagged with a VID specified on the subinterface, is tunneled to another PE. The VLAN Ethernet frames are forwarded in their entirety. The receiving PE may rewrite the VID of the tunneled traffic to another value before forwarding the traffic onto an attachment circuit.
To successfully rewrite VLANs, it may be necessary to disable the Spanning Tree Protocol (STP). This can be done on a per-VLAN basis by using the no spanning-tree vlan command.
Note
HDLC
L2TPv3 encapsulates an HDLC frame arriving at a PE in its entirety (including the Address, Control, and Protocol fields, but not the Flag fields and the frame check sequence) with an L2TP data header.
PPP
PEs that support L2TPv3 forward PPP traffic using a "transparent pass-through" model, in which the PEs play no role in the negotiation and maintenance of the PPP link. L2TPv3 encapsulates a PPP frame arriving at a PE in its entirety (including the HDLC Address and Control fields) with an L2TP data header.
ATM
L2TPv3 can connect two isolated ATM clouds over a packet-switched network while maintaining an end-to-end ATM Service Level Agreement (SLA). Cisco IOS Release 12.0(25)S supports virtual path (VP) single cell relay, with one ATM cell being forwarded per packet. All packets are transparently forwarded over the L2TPv3 pseudowire.
How to Configure Layer 2 Tunnel Protocol Version 3
This section contains the following procedures:
•
•
•
•
•
Configuring L2TP Control Channel Parameters
The L2TP class configuration procedure creates a template of L2TP control channel parameters that can be inherited by different pseudowire classes. L2TP control channel parameters are used in control channel authentication, keepalive messages, and control channel negotiation. In an L2TPv3 session, the same L2TP class must be specified in the pseudowire configured on the PE router at each end of the control channel. Configuring L2TP control channel parameters is optional. However, the L2TP class must be configured before it is with associated a pseudowire class (see the section "Configuring the L2TPv3 Pseudowire").
The three main groups of L2TP control channel parameters that you can configure in an L2TP class are described in the following sections:
•
•
•
After you enter L2TP class configuration mode, you can configure L2TP control channel parameters in any order. If you have multiple authentication requirements you can configure multiple sets of L2TP class control channel parameters with different L2TP class names. However, only one set of L2TP class control channel parameters can be applied to a connection between any pair of IP addresses.
Configuring L2TP Control Channel Timing Parameters
The following L2TP control channel timing parameters can be configured in L2TP class configuration mode:
•
•
•
This task configures a set of timing control channel parameters in an L2TP class. All of the timing control channel parameter configurations are optional and may be configured in any order. If these parameters are not configured, the default values are applied.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring L2TP Control Channel Authentication Parameters
The following L2TP control channel authentication parameters can be configured in L2TP class configuration mode:
•
•
•
•
This task configures a set of authentication control channel parameters in an L2TP class. All of the authentication control channel parameter configurations are optional and may be configured in any order. If these parameters are not configured, the default values will be applied.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring L2TP Control Channel Maintenance Parameters
The L2TP hello packet keepalive interval control channel maintenance parameter can be configured in L2TP class configuration mode.
This task configures the interval used for hello messages in an L2TP class. This control channel parameter configuration is optional. If this parameter is not configured, the default value will be applied.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring the L2TPv3 Pseudowire
The pseudowire class configuration procedure creates a configuration template for the pseudowire. You use this template, or class, to configure session-level parameters for L2TPv3 sessions that will be used to transport attachment circuit traffic over the pseudowire.
The pseudowire configuration specifies the characteristics of the L2TPv3 signaling mechanism, including the data encapsulation type, the control protocol, sequencing, fragmentation, payload-specific options, and IP properties. The setting that determines if signaling is used to set up the pseudowire is also included.
For simple L2TPv3 signaling configurations on most platforms, pseudowire class configuration is optional. However, specifying a source IP address to configure a loopback interface is highly recommended. If you do not configure a loopback interface, the router will choose the best available local address, which could be any IP address configured on a core-facing interface. This configuration could prevent a control channel from being established. On the Cisco 12000 series Internet routers, specifying a source IP address is mandatory, and you should configure a loopback interface that is dedicated for the use of L2TPv3 sessions exclusively. If you do not configure other pseudowire class configuration commands, the default values are used.
Once you specify the encapsulation l2tpv3 command, you cannot remove it using the no encapsulation l2tpv3 command. Nor can you change the command's setting using the encapsulation mpls command. Those methods result in the following error message:
Encapsulation changes are not allowed on an existing pw-class.To remove the command, you must delete the pseudowire with the no pseudowire-class command. To change the type of encapsulation, remove the pseudowire with the no pseudowire-class command and re-establish the pseudowire and specify the new encapsulation type.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
pseudowire-class [pw-class-name]
Example:Router(config)# pseudowire-class etherpw
Enters pseudowire class configuration mode and optionally specifies the name of the L2TP pseudowire class.
Step 4
encapsulation l2tpv3
Example:Router(config-pw)# encapsulation l2tpv3
Specifies that L2TPv3 is used as the data encapsulation method to tunnel IP traffic.
Step 5
protocol {l2tpv3 | none}[l2tp-class-name]
Example:Router(config-pw)# protocol l2tpv3 class1
(Optional) Specifies the L2TPv3 signaling protocol to be used to manage the pseudowires created with the control channel parameters in the specified L2TP class (see the section "Configuring L2TP Control Channel Parameters").
•
•
Step 6
ip local interface interface-name
Example:Router(config-pw)# ip local interface e0/0
Specifies the PE router interface whose IP address is to be used as the source IP address for sending tunneled packets.
•
Note
Step 7
ip pmtu
Example:Router(config-pw)# ip pmtu
(Optional) Enables the discovery of the path MTU for tunneled traffic.
•
Note
•
Note
Step 8
ip tos {value value | reflect}
Example:Router(config-pw)# ip tos reflect
(Optional) Configures the value of the ToS byte in IP headers of tunneled packets, or reflects the ToS byte value from the inner IP header.
•
Step 9
ip dfbit set
Example:Router(config-pw)# ip dfbit set
(Optional) Configures the value of the DF bit in the outer headers of tunneled packets.
•
Step 10
ip ttl value
Example:Router(config-pw)# ip ttl 100
(Optional) Configures the value of the time to live (TTL) byte in the IP headers of tunneled packets.
•
Step 11
ip protocol {l2tp | uti | protocol-number}
Example:Router(config-pw)# ip protocol uti
(Optional) Configures the IP protocol to be used for tunneling packets.
•
Step 12
sequencing {transmit | receive | both}
Example:Router(config-pw)# sequencing both
(Optional) Specifies the direction in which sequencing of data packets in a pseudowire is enabled:
•
•
•
Configuring the Xconnect Attachment Circuit
This configuration procedure binds an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to an L2TPv3 pseudowire for Xconnect service. The virtual circuit identifier that you configure creates the binding between a pseudowire configured on a PE router and an attachment circuit in a CE device. The virtual circuit identifier configured on the PE router at one end of the L2TPv3 control channel must also be configured on the peer PE router at the other end.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface type slot/port
Example:Router(config)# interface ethernet 0/0
Specifies the interface by type (for example, Ethernet) and slot and port number, and enters interface configuration mode.
Step 4
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
Example:Router(config-if)# xconnect 10.0.3.201 123 pw-class vlan-xconnect
Specifies the IP address of the peer PE router and the 32-bit virtual circuit identifier shared between the PE at each end of the control channel.
•
•
–
•
•
•
–
•
•
Note
Note
•
Manually Configuring L2TPv3 Session Parameters
When you bind an attachment circuit to an L2TPv3 pseudowire for Xconnect service using the xconnect l2tpv3 manual command (see the section "Configuring the Xconnect Attachment Circuit") because you do not want signaling, you must then configure L2TP-specific parameters to complete the L2TPv3 control channel configuration.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface type slot/port
Example:Router(config)# interface ethernet 0/0
Specifies the interface by type (for example, Ethernet) and slot and port number, and enters interface configuration mode.
Step 4
xconnect peer-ip-address vc-id encapsulation l2tpv3 manual pw-class pw-class-name
Example:Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class vlan-xconnect
Specifies the IP address of the peer PE router and the 32-bit virtual circuit identifier shared between the PE at each end of the control channel.
•
•
•
Step 5
l2tp id local-session-id remote-session-id
Example:Router(config-if-xconn)# l2tp id 222 111
Configures the identifiers for the local L2TPv3 session and for the remote L2TPv3 session on the peer PE router.
•
Step 6
l2tp cookie local size low-value [high-value]
Example:Router(config-l2tp-class)# l2tp cookie local 4 54321
(Optional) Specifies the value that the peer PE must include in the cookie field of incoming (received) L2TP packets.
•
•
Note
Step 7
l2tp cookie remote size low-value [high-value]
Example:Router(config-l2tp-class)# l2tp cookie remote 4 12345
(Optional) Specifies the value that the router includes in the cookie field of outgoing (sent) L2TP packets.
•
•
Note
Step 8
l2tp hello l2tp-class-name
Example:Router(config-l2tp-class)# l2tp hello l2tp-defaults
(Optional) Specifies the L2TP class name to use (see the section "Configuring L2TP Control Channel Parameters") for control channel configuration parameters, including the interval to use between hello keepalive messages.
Note
Configuring the Xconnect Attachment Circuit for ATM VP Mode Single Cell Relay over L2TPv3
The ATM VP Mode Single Cell Relay over L2TPv3 feature allows cells coming into a predefined permanent virtual path (PVP) on the ATM interface to be transported over an L2TPv3 pseudowire to a predefined PVP on the egress ATM interface. This task binds a permanent virtual path (PVP) to an L2TPv3 pseudowire for Xconnect service.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuration Examples for Layer 2 Tunnel Protocol Version 3
This section provides the following configuration examples:
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring Frame Relay DLCI-to-DLCI Switching Example
The following is a sample configuration for switching a Frame Relay DLCI over a pseudowire:
pseudowire-class fr-xconnectencapsulation l2tpv3protocol l2tpv3ip local interface Loopback0sequencing bothinterface Serial0/0encapsulation frame-relayframe-relay intf-type dceconnect one Serial0/0 100 l2transportxconnect 10.0.3.201 555 pw-class fr-xconnectconnect two Serial0/0 200 l2transportxconnect 10.0.3.201 666 pw-class fr-xconnectConfiguring Frame Relay Trunking Example
The following is a sample configuration for setting up a trunk connection for an entire serial interface over a pseudowire. All incoming packets are switched to the pseudowire regardless of content.
Note that when you configure trunking for a serial interface, the trunk connection does not require an encapsulation method. You do not, therefore, need to enter the encapsulation frame-relay command. Reconfiguring the default encapsulation removes all Xconnect configuration settings from the interface.
interface Serial0/0xconnect 10.0.3.201 555 pw-class serial-xconnectConfiguring QoS for L2TPv3 on the Cisco 7500 Series Example
The following example shows the MQC commands used on a Cisco 7500 Series router to configure a CIR guarantee of 256 kbps on DLCI 100 and 512 kbps for DLCI 200 on the egress side of a Frame Relay interface that is also configured for L2TPv3 tunneling:
ip cef distributedclass-map dlci100match fr-dlci 100class-map dlci200match fr-dlci 200policy-map dlciclass dlci100bandwidth 256class dlci200bandwidth 512interface Serial0/0encapsulation frame-relayframe-relay interface-type dceservice-policy output dlciconnect one Serial0/0 100 l2transportxconnect 10.0.3.201 555 encapsulation l2tpv3 pw-class mqcconnect two Serial0/0 200 l2transportxconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class mqcConfiguring QoS for L2TPv3 on the Cisco 12000 Series Example
To apply a QoS policy for L2TPv3 to a Frame Relay interface on a Cisco 12000 Series 2-port Ch OC-3/STM-1 (DS1/E1) or 6-port Ch T3 line card, you must:
•
•
As shown in the following example, when you configure QoS for L2TPv3 on the ingress side of a Cisco 12000 Series Frame Relay interface, you must also configure the value of the ToS byte used in IP headers of tunneled packets when you configure the L2TPv3 pseudowire (see Configuring the L2TPv3 Pseudowire).
The following example shows the MQC commands and ToS byte configuration used on a Cisco 12000 Series router to apply a QoS policy for DLCI 100 on the ingress side of a Frame Relay interface configured for L2TPv3 tunneling:
policy-map frtp-policyclass class-defaultpolice cir 8000 bc 6000 pir 32000 be 4000 conform-action transmit exceed-action set-frde-transmit violate-action dropmap-class frame-relay fr-mapservice-policy input frtp-policyinterface Serial0/1/1:0encapsulation frame-relayframe-relay interface-dlci 100 switchedclass fr-mapconnect frol2tp1 Serial0/1/1:0 100 l2transportxconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class aaapseudowire-class aaaencapsulation l2tpv3ip tos value 96To apply a QoS policy for L2TPv3 to the egress side of a Frame Relay interface on a Cisco 12000 Series 2-port Ch OC-3/STM-1 (DS1/E1) or 6-port Ch T3 line card, you must:
•
•
The next example shows the MQC commands used on a Cisco 12000 Series Internet Router to apply a QoS policy with WRED/MDRR settings for specified IP Precedence values to DLCI 100 on the egress side of a Frame Relay interface configured for L2TPv3:
class-map match-all d2match ip precedence 2class-map match-all d3match ip precedence 3policy-map oclass d2bandwidth percent 10random-detectrandom-detect precedence 1 200 packets 500 packets 1class d3bandwidth percent 10random-detectrandom-detect precedence 1 1 packets 2 packets 1map-class frame-relay fr-mapservice-policy output ointerface Serial0/1/1:0encapsulation frame-relayframe-relay interface-dlci 100 switchedclass fr-mapconnect frol2tp1 Serial0/1/1:0 100 l2transportxconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class aaaConfiguring MLFR for L2TPv3 on the Cisco 12000 Series Example
The following example shows how to configure L2TPv3 tunneling on a multilink Frame Relay bundle interface on a Cisco 12000 Series 2-port Ch OC-3/STM-1 (DS1/E1) or 6-port Ch T3 line card:
frame-relay switchingpseudowire-class mfrencapsulation l2tpv3ip local interface Loopback0interface mfr0frame-relay intf-type dceinterface Serial0/0.1/1:11encapsulation frame-relay MFR0interface Serial0/0.1/1:12encapsulation frame-relay MFR0connect L2TPoMFR MFR0 100 l2transportxconnect 10.10.10.10 3 pw-class mfrConfiguring a Static L2TPv3 Session for an Xconnect Ethernet Interface Example
L2TPv3 is the only encapsulation method that supports a manually provisioned session setup. This example shows how to configure a static session configuration in which all control channel parameters are set up in advance. There is no control plane used and no negotiation phase to set up the control channel. The PE router starts sending tunneled traffic as soon as the Ethernet interface (int e0/0) comes up. The virtual circuit identifier, 123, is not used. The PE sends L2TP data packets with session ID 111 and cookie 12345. In turn, the PE expects to receive L2TP data packets with session ID 222 and cookie 54321.
l2tp-class l2tp-defaultsretransmit initial retries 30cookie-size 8pseudowire-class ether-pwencapsulation l2tpv3protocol noneip local interface Loopback0interface Ethernet 0/0xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pwl2tp id 222 111l2tp cookie local 4 54321l2tp cookie remote 4 12345l2tp hello l2tp-defaultsConfiguring a Negotiated L2TPv3 Session for an Xconnect VLAN Subinterface Example
The following is a sample configuration of a dynamic L2TPv3 session for a VLAN Xconnect interface. In this example, only VLAN traffic with a VLAN ID of 5 is tunneled. In the other direction, the L2TPv3 session identified by a virtual circuit identifier of 123 receives forwarded frames whose VLAN ID fields are rewritten to contain the value 5. L2TPv3 is used as both the control plane protocol and the data encapsulation.
l2tp-class class1authenticationpassword secretpseudowire-class vlan-xconnectencapsulation l2tpv3protocol l2tpv3 class1ip local interface Loopback0interface Ethernet0/0.1encapsulation dot1Q 5xconnect 10.0.3.201 123 pw-class vlan-xconnectConfiguring a Negotiated L2TPv3 Session for Local HDLC Switching Example
The following is a sample configuration of a dynamic L2TPv3 session for local HDLC switching. In this example, note that it is necessary to configure two different IP addresses at the endpoints of the L2TPv3 pseudowire because the virtual circuit identifier must be unique for a given IP address.
interface loopback 1ip address 10.0.0.1 255.255.255.255interface loopback 2ip address 10.0.0.2 255.255.255.255pseudowire-class loopback1encapsulation l2tpv3ip local interface loopback1pseudowire-class loopback2encapsulation l2tpv3ip local interface loopback2interface s0/0encapsulation hdlcxconnect 10.0.0.1 100 pw-class loopback2interface s0/1encapsulation hdlcxconnect 10.0.0.2 100 pw-class loopback1Configuring a Pseudowire Class for Fragmentation of IP Packets Example
The following is a sample configuration of a pseudowire class that will allow IP traffic generated from the CE router to be fragmented before entering the pseudowire:
pseudowire class class1encapsulation l2tpv3ip local interface Loopback0ip pmtuip dfbit setConfiguring the Xconnect Attachment Circuit for ATM VP Mode Single Cell Relay over L2TPv3 Example
The following configuration binds a PVP to an Xconnect attachment circuit to forward ATM cells over an established L2TPv3 pseudowire:
pw-class atm-xconnectencapsulation l2tpv3interface ATM 4/1/0atm pvp 5 l2transportxconnect 10.0.3.201 888 pw-class atm-xconnectVerifying an L2TPv3 Session Example
To display detailed information about current L2TPv3 sessions on a router, use the show l2tun session all command:
Router# show l2tunnel session allSession Information Total tunnels 0 sessions 1Session id 111 is up, tunnel id 0Call serial number is 0Remote tunnel name isInternet address is 2.0.0.1Session is manually signalledSession state is established, time since change 00:06:050 Packets sent, 0 received0 Bytes sent, 0 receivedReceive packets dropped:out-of-order: 0total: 0Send packets dropped:exceeded session MTU: 0total: 0Session vcid is 123Session Layer 2 circuit, type is ATM VPC CELL, name is ATM3/0/0:1000007Circuit state is UPRemote session id is 222, remote tunnel id 0DF bit off, ToS reflect disabled, ToS value 0, TTL value 255Session cookie information:local cookie, size 8 bytes, value 00 00 00 00 00 00 00 64remote cookie, size 8 bytes, value 00 00 00 00 00 00 00 C8SSS switching enabledSequencing is offVerifying an L2TP Control Channel Example
To display detailed information the L2TP control channels that are set up to other L2TP-enabled devices for all L2TP sessions on the router, use the show l2tun tunnel all command. The L2TP control channel is used to negotiate capabilities, monitor the health of the peer PE router, and set up various components of an L2TPv3 session.
Router# show l2tun session allSession Information Total tunnels 0 sessions 1Session id 111 is up, tunnel id 0Call serial number is 0Remote tunnel name isInternet address is 2.0.0.1Session is manually signalledSession state is established, time since change 00:06:050 Packets sent, 0 received0 Bytes sent, 0 receivedReceive packets dropped:out-of-order: 0total: 0Send packets dropped:exceeded session MTU: 0total: 0Session vcid is 123Session Layer 2 circuit, type is ATM VPC CELL, name is ATM3/0/0:1000007Circuit state is UPRemote session id is 222, remote tunnel id 0DF bit off, ToS reflect disabled, ToS value 0, TTL value 255Session cookie information:local cookie, size 8 bytes, value 00 00 00 00 00 00 00 64remote cookie, size 8 bytes, value 00 00 00 00 00 00 00 C8SSS switching enabledSequencing is offVerifying ATM VP Mode Single Cell Relay over L2TPv3 Configuration
To verify the configuration of a PVP, use the show atm vp command in EXEC mode.
Router# show atm vp 5ATM4/1/0 VPI: 5, Cell-Relay, PeakRate: 155000, CesRate: 0, DataVCs: 0,CesVCs: 0, Status: ACTIVEVCD VCI Type InPkts OutPkts AAL/Encap Status8 3 PVC 0 0 F4 OAM ACTIVE9 4 PVC 0 0 F4 OAM ACTIVETotalInPkts: 0, TotalOutPkts: 0, TotalInFast: 0, TotalOutFast: 0,TotalBroadcasts: 0Additional References
For additional information related to L2TPv3, refer to the following references:
•
•
Related Documents
Standards
draft-ietf-l2tpext-l2tp-base-03.txt
Layer Two Tunneling Protocol (Version 3)'L2TPv3'
MIBs
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
RFCs
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
•
atm pvp
To create a permanent virtual path (PVP) used to multiplex (or bundle) one or more virtual circuits (VCs), use the atm pvp command in interface configuration mode. To remove a PVP, use the no form of this command.
atm pvp vpi [peak-rate] [l2transport]
no atm pvp vpi
Syntax Description
Defaults
PVP is not configured.
The default peak rate is the line rate.
Command Modes
Interface configuration
Command History
11.1
This command was introduced.
12.0(25)S
This command was updated to include the l2transport keyword.
Usage Guidelines
This command is commonly used to create a PVP that is used in multiplex circuit emulation service (CES) and data VCs.
The ATM-CES port adapter supports multiplexing of one or more VCs over a virtual path that is shaped at a constant bandwidth. For example, you can buy a virtual path service from an ATM service provider and multiplex both the CES and data traffic over the virtual path.
All subsequently created VCs with a vpi argument matching the vpi value specified with the atm pvp command are multiplexed onto this PVP. This PVP connection is an ATM connection where switching is performed on the VPI field of the cell only. A PVP is created and left up indefinitely. All VCs that are multiplexed over a PVP share and are controlled by the traffic parameters associated with the PVP.
Changing the peak-rate argument causes the ATM-CES port adapter to go down and then back up.
When you create a PVP, two VCs are created (VCI 3 and 4) by default. These VCs are created for VP end-to-end loopback and segment loopback operation, administration, and maintenance (OAM) support.
When you use the l2transport keyword with the atm pvp command, the command mode becomes the l2transport PVP submode. You must issue the l2transport keyword to configure the ATM cell relay over MPLS feature in port mode or to configure the ATM cell relay over L2TPv3 feature.
To verify the configuration of a PVP, use the show atm vp command in EXEC mode.
Examples
The following example creates a permanent virtual path with a peak rate of 2000 kbps. The subsequent VCs created are multiplexed onto this virtual path.
interface atm 6/0atm pvp 1 2000atm pvc 13 1 13 aal5snapexitinterface cbr 6/1ces circuit 0ces pvc 9 interface atm6/0 vpi 1 vci 100exitThe following example configures ATM Cell Relay over MPLS in port mode:
interface atm5/0atm pvp 1 l2transportxconnect 10.0.0.1 123 encapsulation mplsThe following example configures ATM Cell Relay over L2TPv3:
pw-class atm-xconnectencapsulation l2tpv3interface atm 4/1/0atm pvp 5 l2transportxconnect 10.0.3.201 888 pw-class atm-xconnectRelated Commands
show atm vp
Displays the statistics for all VPs on an interface or for a specific VP.
authentication
To enable Layer 2 Tunnel Protocol Version 3 (L2TPv3) authentication, use the authentication command in L2TP class configuration mode. To disable L2TPv3 authentication, use the no form of this command.
authentication
no authentication
Syntax Description
This command has no arguments or keywords.
Defaults
L2TPv3 authentication is disabled.
Command Modes
L2TP class configuration
Command History
Usage Guidelines
Use the authentication command to enable L2TPv3 authentication.
Examples
The following example enables authentication in L2TPv3 pseudowires configured using the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# authenticationRelated Commands
debug acircuit
To troubleshoot events and failures related to an attachment circuit, use the debug acircuit command in privileged EXEC mode. To disable the debug acircuit command, use the no form of this command.
debug acircuit {error | event}
no debug acircuit {error | event}
Syntax Description
error
Displays errors that occur in attachment circuits.
event
Displays events that occur in attachment circuits.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug acircuit command to identify provisioning events, setup failures, circuit up and down events, and configuration failures.Examples
The following example shows output from the debug acircuit command for an Xconnect session on an Ethernet interface:
Router# debug acircuit23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/123:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() calling acmgr_circuit_up23:28:35: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connecting23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/123:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() ignoring up event. Already connected or connecting.23:28:35: ACMGR: Receive <Circuit Up> msg23:28:35: Et2/1 ACMGR: circuit up event, SIP state chg down to connecting, action is service request23:28:35: Et2/1 ACMGR: Sent a sip service request23:28:37: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up23:28:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to up23:28:53: Et2/1 ACMGR: Rcv SIP msg: resp connect forwarded, hdl D6000002, sss_hdl 9E00000F23:28:53: Et2/1 ACMGR: service connected event, SIP state chg connecting to connected, action is respond forwarded23:28:53: ACLIB: pthru_intf_response hdl is D6000002, response is 123:28:53: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-ConnectedRelated Commands
debug vpdn
To troubleshoot Layer 2 Tunnel Protocol Version 3 (L2TPv3) and the surrounding Layer 2 tunneling infrastructure, use the debug vpdn command in privileged EXEC mode. To disable the debug vpdn command, use the no form of this command.
debug vpdn {error | event | l2x-errors | l2x-events | l2x-packets | packet | packet detail | packet errors}
no debug vpdn {error | event | l2x-errors | l2x-events | l2x-packets | packet | packet detail | packet errors}
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Note that the debug vpdn packet and debug vpdn packet detail commands generate several debug operations per packet. Depending on the L2TP traffic pattern, these commands may cause the CPU load to increase to a high level that impacts performance.
Examples
The following example shows output from the debug vpdn command for an Xconnect session on an Ethernet interface:
Router# debug vpdn23:31:18: L2X: l2tun session [1669204400], event [client request], old state [open], new state [open]23:31:18: L2X: L2TP: Received L2TUN message <Connect>23:31:18: Tnl/Sn58458/28568 L2TP: Session state change from idle to wait-for-tunnel23:31:18: Tnl/Sn58458/28568 L2TP: Create session23:31:18: Tnl58458 L2TP: SM State idle23:31:18: Tnl58458 L2TP: O SCCRQ23:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds23:31:18: Tnl58458 L2TP: Tunnel state change from idle to wait-ctl-reply23:31:18: Tnl58458 L2TP: SM State wait-ctl-reply23:31:18: Tnl58458 L2TP: I SCCRP from router23:31:18: Tnl58458 L2TP: Tunnel state change from wait-ctl-reply to established23:31:18: Tnl58458 L2TP: O SCCCN to router tnlid 801223:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds23:31:18: Tnl58458 L2TP: SM State established23:31:18: Tnl/Sn58458/28568 L2TP: O ICRQ to router 8012/023:31:18: Tnl/Sn58458/28568 L2TP: Session state change from wait-for-tunnel to wait-reply23:31:19: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds23:31:20: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up23:31:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to up23:31:25: L2X: Sending L2TUN message <Connect OK>23:31:25: Tnl/Sn58458/28568 L2TP: O ICCN to router 8012/3514923:31:25: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds23:31:25: Tnl/Sn58458/28568 L2TP: Session state change from wait-reply to established23:31:25: L2X: l2tun session [1669204400], event [server response], old state [open], new state [open]23:31:26: Tnl58458 L2TP: Control channel retransmit delay set to 1 secondsRelated Commands
debug acircuit
Displays events and failures related to attachment circuits.
debug xconnect
Displays errors and events related to an Xconnect configuration.
debug xconnect
To debug a problem related to the Xconnect configuration, use the debug xconnect command in privileged EXEC mode. To disable the debug xconnect command, use the no form of this command.
debug xconnect {error | event}
no debug xconnect {error | event}
Syntax Description
error
Displays errors related to an Xconnect configuration.
event
Displays events related to an Xconnect configuration processing.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to display debugging information about Xconnect sessions.
Examples
The following example shows output from the debug xconnect command for a Xconnect session on an Ethernet interface:
Router# debug xconnect00:01:16: XC AUTH [Et2/1, 5]: Event: start xconnect authorization, state changed from IDLE to AUTHORIZING00:01:16: XC AUTH [Et2/1, 5]: Event: found xconnect authorization, state changed from AUTHORIZING to DONE00:01:16: XC AUTH [Et2/1, 5]: Event: free xconnect authorization request, state changed from DONE to ENDRelated Commands
encapsulation l2tpv3
To specify that Layer 2 Tunnel Protocol Version 3 (L2TPv3) is used as the data encapsulation method for tunneling IP traffic over the pseudowire, use the encapsulation l2tpv3 command in pseudowire class or VC class configuration mode. To remove L2TPv3 as the encapsulation method, use the no pseudowire-class command (see the Usage Guidelines for more information).
encapsulation l2tpv3
no pseudowire-class
Syntax Description
This command has no arguments or keywords.
Command Default
No encapsulation method is specified.
Command Modes
Pseudowire class configuration
VC class configurationCommand History
Usage Guidelines
This command must be configured if the pseudowire class will be referenced from an Xconnect configured to forward L2TPv3 traffic.
Once you specify the encapsulation l2tpv3 command, you cannot remove it using the no encapsulation l2tpv3 command. Nor can you change the command's setting using the encapsulation mpls command. Those methods result in the following error message:
Encapsulation changes are not allowed on an existing pw-class.To remove the command, you must delete the pseudowire with the no pseudowire-class command. To change the type of encapsulation, remove the pseudowire with the no pseudowire-class command and re-establish the pseudowire and specify the new encapsulation type.
Examples
The following example shows how to configure L2TPv3 as the data encapsulation method for the pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# encapsulation l2tpv3The following example configures ATM AAL5 over L2TPv3 in VC class configuration mode:
vc-class atm aal5classencapsulation aal5Related Commands
hello
To configure the interval used to exchange hello keepalive packets in a Layer 2 Tunnel Protocol Version 3 (L2TPv3) control channel, use the hello command in L2TP class configuration mode. To disable the sending of hello keepalive packets, use the no form of this command.
hello interval
no hello interval
Syntax Description
Defaults
60 seconds
Command Modes
L2TP class configuration
Command History
Usage Guidelines
You can configure different values with the hello command on the PE router at each end of an L2TPv3 control channel.
Examples
The following example sets an interval of 120 seconds between the sending of hello keepalive messages in L2TPv3 pseudowires configured using the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# hello 120Related Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
hidden
To hide the attribute-value pair (AVP) values in Layer 2 Tunneling Protocol (L2TP) control messages, use the hidden command in L2TP class configuration mode. To unhide AVPs, use the no form of this command.
hidden
no hidden
Syntax Description
This command has no arguments or keywords.
Defaults
L2TP AVP hiding is disabled.
Command Modes
L2TP class configuration
Command History
Usage Guidelines
Use the hidden command to provide additional security for the exchange of control messages between provider edge routers in a Layer 2 Tunnel Protocol Version 3 (L2TPv3) control channel. Because username and password information is exchanged between devices in clear text, it is useful to encrypt L2TP AVP values with the hidden command.
Examples
The following example enables AVP hiding and encrypts AVPs in control messages in L2TPv3 pseudowires configured using the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# hiddenRelated Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
hostname
To configure the host name that the router will use to identify itself during Layer 2 Tunnel Protocol Version 3 (L2TPv3) authentication, use the hostname command in L2TP class configuration mode. To remove the host name, use the no form of this command.
hostname name
no hostname name
Syntax Description
Defaults
No host name is specified for L2TPv3 authentication.
Command Modes
L2TP class configuration
Command History
Usage Guidelines
If you do not use the hostname command, the host name of the router is used for L2TPv3 authentication.
Examples
The following example configures the host name yb2 for a provider edge router used at one end of an L2TPv3 control channel in an L2TPv3 pseudowire configured using the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# hostname yb2Related Commands
ip dfbit set
To enable the Don't Fragment (DF) bit in the outer Layer 2 Tunnel Protocol Version 3 (L2TPv3) header, use the ip dfbit set command in pseudowire class configuration mode. To disable the DF bit setting, use the no form of this command.
ip dfbit set
no ip dfbit set
Syntax Description
This command has no arguments or keywords.
Defaults
The default value is DF bit off, except for Cisco 12000 series Internet routers, which have this command enabled by default.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Use this command to set the DF bit on if, for performance reasons, you do not want tunneled packet reassembly to be performed on the router.
Note
Examples
The following example shows how to enable the DF bit in the outer L2TPv3 header in pseudowires created from the pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# ip dfbit setRelated Commands
ip pmtu
Enables the discovery of a PMTU for L2TPv3 traffic.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
ip local interface
To configure the IP address of the provider edge router interface to be used as the source IP address for sending tunneled packets, use the ip local interface command in pseudowire class configuration mode. To remove the IP address, use the no form of this command.
ip local interface interface-name
no ip local interface interface-name
Syntax Description
interface-name
Name of the PE interface whose IP address is used as the source IP address for sending tunneled packets over an Layer 2 Tunnel Protocol Version 3 (L2TPv3) pseudowire.
Defaults
No ip address is configured.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Use the same local interface name for all pseudowire classes configured between a pair of PE routers. It is highly recommended that a loopback interface is configured with this command. If you do not configure a loopback interface, the router will choose the "best available local address," which could be any IP address configured on a core-facing interface. This configuration could prevent a control channel from being established.
The ip local interface command must be configured for pseudo-wire class configurations using L2TPv3 as the data encapsulation method.
Note
On the Cisco 10720 Internet Router, it is highly recommended that you configure a loopback interface as the IP local interface. A LAN interface is also supported as the IP local interface. Multiple L2TPv3 tunnel sessions can exist between Cisco 10720 Internet routers on different IP LANs.Examples
The following example shows how to configure the IP address of the local Ethernet interface named e0/0 as the source IP address for sending Ethernet packets through an L2TPv3 session:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# ip local interface e0/0Related Commands
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
ip pmtu
To enable the discovery of a path maximum transmission unit (PMTU) for Layer 2 Tunnel Protocol Version 3 (L2TPv3) traffic, use the ip pmtu command in pseudowire class configuration mode. To disable PMTU discovery, use the no form of this command.
ip pmtu
no pmtu
Syntax Description
This command has no arguments or keywords.
Defaults
Path MTU discovery is disabled.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
The ip pmtu command enables the processing of Internet Control Message Protocol (ICMP) unreachable messages that indicate fragmentation errors in the IP backbone network carrying the tunneled traffic. The MTU of the L2TPv3 session is updated according to the MTU information contained in the ICMP unreachable message.
The ip pmtu command also enables MTU checking for IP packets that are sent into an L2TPv3 session with the Don't Fragment (DF) bit set. If an IP packet is larger than the MTU of the tunnel, the packet is dropped and an ICMP unreachable message is sent. If an IP packet is smaller than the MTU of the tunnel, the DF bit in the packet header is reflected from the inner IP header to the tunnel header.
Examples
The following example shows how to enable the discovery of the path MTU for pseudowires created from the pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# ip pmtuRelated Commands
ip dfbit set
Enables the DF bit in the outer L2TPv3 tunnel header.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
ip protocol
To configure the Layer 2 Tunnel Protocol (L2TP) or Universal Tunnel Interface (UTI) as the IP protocol used for tunneling packets in an L2TP Version 3 (L2TPv3) pseudowire, use the ip protocol command in pseudowire class configuration mode. To remove the IP protocol configuration, use the no form of this command.
ip protocol {l2tp | uti | protocol-number}
no ip protocol {l2tp | uti | protocol-number}
Syntax Description
Defaults
The default IP protocol is L2TP.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Use the ip protocol command to ensure backward compatibility with routers running UTI. This command allows you to configure an L2TPv3 pseudowire between a router running L2TPv3 and a peer router running UTI.
Note
To configure L2TP as the IP protocol used to tunnel packets in an L2TPv3 pseudowire, you may enter 115, the IP protocol number assigned to L2TPv3, instead of l2tp in the ip protocol command.
To configure UTI as the IP protocol used to tunnel packets in an L2TPv3 pseudowire, you may enter 120, the IP protocol number assigned to UTI, instead of uti in the ip protocol command.
Note
Examples
The following example shows how to configure UTI as the IP protocol used to tunnel packets in an L2TPv3 pseudowire created from the pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# encapsulation l2tpv3Router(config-pw)# ip protocol utiRelated Commands
ip tos
To configure the Type of Service (ToS) byte in the header of Layer 2 Tunnel Protocol Version 3 (L2TPv3) tunneled packets, use the ip tos command in pseudowire class configuration mode. To disable a configured ToS value or IP ToS reflection, use the no form of this command.
ip tos {value value | reflect}
no tos {value value | reflect}
Syntax Description
Defaults
The default ToS value is 0.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
The ip tos command allows you to manually configure the value of the ToS byte used in the headers of L2TPv3 tunneled packets or to have the ToS value reflected from the IP header of the encapsulated packet.
Note
Note
In addition, you can configure both IP ToS reflection and a ToS priority level (from 0 to 255) for a pseudowire class. In this case, the ToS value in the tunnel header defaults to the value you specify with the ip tos value value command. IP packets received on the Layer 2 interface and encapsulated into the L2TPv3 session have their ToS byte reflected into the outer IP session, overriding the default value configured with the ip tos value value command.
Examples
The following example shows how to configure the ToS byte in the headers of tunneled packets in L2TPv3 tunnels created from the pseudowire class named ether-pw to be reflected from the ToS value in the header of each encapsulated IP packet:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# ip tos reflectRelated Commands
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
ip ttl
To configure the time-to-live (TTL) byte in the IP headers of Layer 2 Tunnel Protocol Version 3 (L2TPv3) tunneled packets, use the ip ttl command in pseudowire class configuration mode. To remove the configured TTL value, use the no form of this command.
ip ttl value
no ip ttl value
Syntax Description
value
Value of the TTL byte in the IP headers of L2TPv3 tunneled packets. The valid values range from 1 to 255. The default value is 255.
Defaults
The default value of the TTL byte is 255.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Use this command to set the Don't Fragment (DF) bit on if, for performance reasons, you do not want tunneled packet reassembly to be performed on the router.
Examples
The following example shows how to set the TTL byte to 100 in the IP header of L2TPv3 tunneled packets in pseudowires created from the pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# ip ttl 100Related Commands
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
l2tp-class
To create a template of Layer 2 Tunnel Protocol (L2TP) control plane configuration settings that can be inherited by different pseudowire classes and to enter L2TP class configuration mode, use the l2tp-class command in global configuration mode.
l2tp-class [l2tp-class-name]
Syntax Description
l2tp-class-name
(Optional) Name of the L2TP class. The l2tp-class-name argument must be specified if you want to configure multiple sets of L2TP control parameters.
Defaults
No L2TP classes are defined.
Command Modes
Global configuration
Command History
Usage Guidelines
The l2tp-class l2tp-class-name command allows you to configure an L2TP class template that consists of configuration settings used by different pseudowire classes. An L2TP class includes the following configuration settings:
•
•
•
•
•
•
•
The l2tp-class command enters L2TP class configuration mode, where L2TP control plane parameters are configured.
You must use the same L2TP class in the pseudowire configuration at both ends of an L2TPv3 control channel.
Examples
The following example shows how to enter L2TP class configuration mode to create an L2TP class configuration template for the class named ether-pw:
Router(config)# l2tp-class ether-pwRelated Commands
l2tp cookie local
To configure the size of the cookie field used in the Layer 2 Tunnel Protocol Version 3 (L2TPv3) headers of incoming packets received from the remote provider edge (PE) peer router, use the l2tp cookie local command in xconnect configuration mode. To remove the configured cookie field parameters, use the no form of this command.
l2tp cookie local size low-value [high-value]
no l2tp cookie local size low-value [high-value]
Syntax Description
Defaults
No cookie value is included in the header of L2TP packets.
Command Modes
Xconnect configuration mode
Command History
Usage Guidelines
The l2tp cookie local command specifies the values that the peer PE router includes in the cookie field in L2TPv3 headers of the packets it sends to the local PE router through an L2TPv3 session. These values are required in a static L2TPv3 session.
The cookie field is an optional part of an L2TPv3 header with a length of either 4 or 8 bytes. If you specify an 8-byte length, you must also enter a value for the high-value argument.
Note
Examples
The following example shows how to configure the cookie field of 4 bytes starting at 54321 for the L2TPv3 headers in incoming tunneled packets sent from the remote PE peer:
Router(config)# interface Ethernet 0/0Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pwRouter(config-if-xconn)# l2tp cookie local 4 54321Related Commands
l2tp cookie remote
To configure the size of the cookie field used in the Layer 2 Tunnel Protocol Version 3 (L2TPv3) headers of outgoing packets sent from the local provider edge (PE) peer router, use the l2tp cookie remote command in xconnect configuration mode. To remove the configured cookie field parameters, use the no form of this command.
l2tp cookie remote size low-value [high-value]
no l2tp cookie remote size low-value [high-value]
Syntax Description
Defaults
No cookie value is included in the header of L2TP packets.
Command Modes
Xconnect configuration
Command History
Usage Guidelines
The l2tp cookie local command specifies the values that the local PE router includes in the cookie field in L2TPv3 headers of the packets it sends to the remote PE router through an L2TPv3 session. These values are required in a static L2TPv3 session.
The cookie field is an optional part of an L2TPv3 header with a length of either 4 or 8 bytes. If you specify an 8-byte length, you must also enter a value for the high-value argument.
Examples
The following example shows how to configure the cookie field of 4 bytes starting at 12345 for the L2TPv3 headers in outgoing tunneled packets sent to the remote PE peer:
Router(config)# interface Ethernet 0/0Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pwRouter(config-if-xconn)# l2tp cookie remote 4 12345Related Commands
l2tp hello
To specify the use of a hello keepalive setting contained in a specified Layer 2 Tunneling Protocol class configuration for a static Layer 2 Tunnel Protocol Version 3 (L2TPv3) session, use the l2tp hello command in xconnect configuration mode. To disable the sending of hello keepalive messages, use the no form of this command.
l2tp hello l2tp-class-name
no l2tp hello l2tp-class-name
Syntax Description
l2tp-class-name
Specifies the L2TP class configuration in which the hello keepalive interval to be used for the L2TPv3 session is stored.
Defaults
No hello keepalive messages are sent.
Command Modes
Xconnect configuration
Command History
Usage Guidelines
Because a static L2TPv3 session does not use a control plane to dynamically negotiate control channel parameters, you must use the l2tp hello command to specify an L2TP class configuration that contains the interval for sending hello keepalive messages.
The following example shows how to configure the time interval for hello keepalive messages stored in the L2TP class configuration named l2tp-defaults for an Ethernet interface using the configuration settings stored in the pseudowire class named ether-pw:
Router(config)# interface Ethernet 0/0Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pwRouter(config-if-xconn)# l2tp hello lt2p-defaultsRelated Commands
l2tp id
To configure the identifiers used by the local and remote provider edge routers at each end of a Layer 2 Tunnel Protocol Version 3 (L2TPv3) session, use the l2tp id command in Xconnect configuration mode. To remove the configured identifiers for local and remote sessions, use the no form of this command.
l2tp id local-session-ID remote-session-ID
no l2tp id local-session-ID remote-session-ID
Syntax Description
local-session-ID
The identifier used by the local PE router for as its local session identifier.
remote-session-ID
The identifier used by the remote PE router as its local session identifier.
Defaults
No session identifiers are configured.
Command Modes
Xconnect configuration
Command History
Usage Guidelines
The Xconnect configuration that binds an attachment circuit to an L2TPv3 pseudowire is not complete without configured values for the local-session-ID and remote-session-ID arguments.
Examples
The following example shows how to configure the identifiers named 222 for the local PE router and 111 for the remote peer in an L2TPv3 session bound to an Ethernet circuit using the L2TPv3 configuration settings stored in the pseudowire class named ether-pw:
Router(config)# interface Ethernet 0/0Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pwRouter(config-if-xconn)# l2tp id 222 111Related Commands
password
To configure the password used by a provider edge (PE) router for Layer 2 Tunnel Protocol Version 3 (L2TPv3) authentication, use the password command in L2TP class configuration mode. To disable a configured password, use the no form of this command.
password [encryption-type] password
no password [encryption-type] password
Syntax Description
Defaults
If a password is not configured for the L2TP class with the password command, the password configured with the username password command in global configuration mode is used.
Command Modes
L2TP class configuration
Command History
Usage Guidelines
The password that you define with the password command is also used for attribute-value pair (AVP) hiding.
The password hierarchy sequence used for a local and remote peer PE for L2TPv3 authentication is as follows:
•
•
Examples
The following example sets the password named tunnel2 to be used to authenticate an L2TPv3 session between the local and remote peers in L2TPv3 pseudowires configured with the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# password tunnel2Related Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
protocol
To specify the signaling protocol to be used to manage the pseudowires created from a pseudowire class for a dynamic Layer 2 Tunnel Protocol Version 3 (L2TPv3) session, and that control plane configuration settings are to be taken from a specified L2TP class, use the protocol command in pseudowire class configuration mode. To remove the signaling protocol (and the control plane configuration to be used) for a pseudowire class, use the no form of this command.
protocol {l2tpv3 | none} [l2tp-class-name]
no protocol {l2tpv3 | none} [l2tp-class-name]
Syntax Description
Defaults
The default protocol option is l2tpv3.
If you do not enter a value for the l2tp-class-name argument, the default control plane configuration settings in the L2TP signaling protocol are used.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
Use the protocol l2tpv3 command to configure L2TPv3 as the signaling protocol to use in dynamic L2TPv3 sessions created from the specified pseudowire class. In addition, you can use this command to specify the L2TP class (see the section "Configuring the Xconnect Attachment Circuit") from which the control plane configuration settings are to be taken for use in a dynamic L2TPv3 session.
Use the protocol none command to specify that no signaling will be used in L2TPv3 sessions created from the specified pseudowire class. This configuration is required for interoperability with a remote peer running the Universal Tunnel Interface (UTI).
Do not use the command if you want to configure a pseudowire class used to create manual L2TPv3 sessions (see the section "Static L2TPv3 Sessions").
Examples
The following example shows how to enter pseudowire configuration mode, and how to configure L2TPv3 as the signaling protocol. The control plane configuration used in the L2TP class named class1 will be used to create dynamic L2TPv3 sessions for a VLAN Xconnect interface:
Router(config)# pseudowire-class vlan-xconnectRouter(config-pw)# protocol l2tpv3 class1Related Commands
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
pseudowire-class
To specify the name of a Layer 2 Tunnel Protocol Version 3 (L2TPv3) pseudowire class and enter pseudowire class configuration mode, use the pseudowire-class command in global configuration mode.
pseudowire-class [pw-class-name]
Syntax Description
pw-class-name
(Optional) The name of a L2TP pseudowire class. If you want to configure more than one pseudowire class, you must enter a value for the pw-class-name argument.
Defaults
No pseudowire class is defined.
Command Modes
Global configuration
Command History
Usage Guidelines
The pseudowire-class command allows you to configure a pseudowire class template that consists of configuration settings used by all attachment circuits bound to the class. A pseudowire class includes the following configuration settings:
•
•
•
•
•
After you enter the pseudowire-class command, you switch to pseudowire class configuration mode, where pseudowire settings may be configured.
Examples
The following example shows how to enter pseudowire class configuration mode to configure a pseudowire configuration template named ether-pw:
Router(config)# pseudowire-class ether-pwRelated Commands
receive-window
To configure the packet size of the receive window on the remote provider edge router at the other end of a Layer 2 Tunnel Protocol Version 3 (L2TPv3) control channel, use the receive-window command in L2TP class configuration mode. To disable the configured value, use the no form of this command.
receive-window size
no receive-window size
Syntax Description
Defaults
The default value is the upper limit the remote peer has for receiving packets.
Command Modes
L2TP class configuration
Command History
Usage Guidelines
To determine the upper limit for the size argument, refer to the platform-specific documentation for the peer router.
Examples
The following example sets a receive window of 30 packets to the remote peer in L2TPv3 pseudowires configured with the L2TP class named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# receive-window 30Related Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
retransmit
To configure the retransmission settings of control packets, use the retransmit command in L2TP class configuration mode. To disable the configured values, use the no form of this command.
retransmit {initial retries initial-retries | retries retries | timeout {max | min} timeout}
no retransmit {initial retries initial-retries | retries retries | timeout {max | min} timeout}
Syntax Description
Defaults
Initial retries: 2
Retries: 15
Maximum timeout interval: 8 seconds
Minimum timeout interval: 1 secondCommand Modes
L2TP class configuration
Command History
Usage Guidelines
Use this command to configure the amount of time spent trying to establish or maintain a control channel.
Examples
The following example configures ten retries for sending Layer 2 Tunnel Protocol Version 3 (L2TPv3) tunneled packets to a remote peer in L2TPv3 pseudowires configured with the L2TP class named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# retransmit retries 10Related Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
sequencing
To configure the direction in which sequencing is enabled for data packets in an a Layer 2 Tunnel Protocol Version 3 (L2TPv3) pseudowire, use the sequencing command in pseudowire class configuration mode. To remove the sequencing configuration from the pseudowire class, use the no form of this command.
sequencing {transmit | receive | both}
no sequencing {transmit | receive | both}
Syntax Description
Defaults
Sequencing is off.
Command Modes
Pseudowire class configuration
Command History
Usage Guidelines
When you enable sequencing using any of the available options, L2TPv3 automatically enables the sending of sequence numbers and requests the remote provider edge (PE) peer to send sequence numbers. Out-of-order packets received on the pseudowire are dropped only if you use the sequencing receive or sequencing both command.
In Cisco IOS Release 12.0(23)S, sequencing is not supported on the Cisco 10720 Internet router and the Cisco 12000 series Internet routers. If the L2TPv3 peer router requests sequence numbers for an L2TPv3 session configured on a Cisco 10720 Internet router or Cisco 12000 series Internet router, the request to establish the session is denied.
If sequencing is enabled for L2TPv3 pseudowires on the Cisco 7500 series, all traffic on the pseudowires is switched through the Route Switch Processor (RSP) regardless of the setting configured with the ip cef distributed command.
Examples
The following example shows how to enable sequencing in data packets in L2TPv3 pseudowires created from the pseudowire class named ether-pw so that Sequence Number field is updated in tunneled packet headers for data packets both sent and received over the pseudowire:
Router(config)# pseudowire-class ether-pwRouter(config-pw)# sequencing bothRelated Commands
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire class configuration mode.
show l2tun session
To display the current state of a Layer 2 session and display protocol information about a Layer 2 Tunnel Protocol Version 3 (L2TPv3) control channel, use the show l2tun session command in EXEC mode.
show l2tun session [all [ip-addr ip-address [vcid number] | vcid number] | brief [ip-addr ip-address [vcid number] | vcid number] | circuit [ip-addr ip-address [vcid number] | vcid number] | l2tp [ip-addr ip-address [vcid number] | vcid number] | packets [ip-addr ip-address [vcid number] | vcid number] | sequence [ip-addr ip-address [vcid number] | vcid number] | state [ip-addr ip-address [vcid number] | vcid number]]
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
When you use the show l2tun session command to display information about current L2TPv3 sessions on the router, you can filter the output as follows:
•
•
•
Examples
The following example shows how to display detailed information about all current L2TPv3 sessions:
Router# show l2tun session allSession Information Total tunnels 0 sessions 1Session id 111 is up, tunnel id 0Call serial number is 0Remote tunnel name isInternet address is 2.0.0.1Session is manually signalledSession state is established, time since change 00:06:050 Packets sent, 0 received0 Bytes sent, 0 receivedReceive packets dropped:out-of-order: 0total: 0Send packets dropped:exceeded session MTU: 0total: 0Session vcid is 123Session Layer 2 circuit, type is ATM VPC CELL, name is ATM3/0/0:1000007Circuit state is UPRemote session id is 222, remote tunnel id 0DF bit off, ToS reflect disabled, ToS value 0, TTL value 255Session cookie information:local cookie, size 8 bytes, value 00 00 00 00 00 00 00 64remote cookie, size 8 bytes, value 00 00 00 00 00 00 00 C8SSS switching enabledSequencing is offThe following example shows how to display information only about the L2TPv3 session set up on a peer PE router with an IP address of 172.18.184.142 and a virtual circuit identifier of 300:
Router# show l2tun session all ip-addr 172.18.184.142 vcid 300L2TP SessionSession id 32518 is up, tunnel id 35217Call serial number is 2074900020Remote tunnel name is tun1Internet address is 172.18.184.142Session is L2TP signalledSession state is established, time since change 03:06:399932 Packets sent, 9932 received1171954 Bytes sent, 1171918 receivedSession vcid is 300Session Layer 2 circuit, type is Ethernet Vlan, name is FastEthernet0/1/0.3:3Circuit state is UPRemote session id is 18819, remote tunnel id 37340Set DF bit to 0Session cookie information:local cookie, size 4 bytes, value CF DC 5B F3remote cookie, size 4 bytes, value FE 33 56 C4SSS switching enabledSequencing is onNs 9932, Nr 10001, 0 out of order packets discardedThe following example shows how to display information about the circuit status of L2TPv3 sessions on a router:
Router# show l2tun session circuitSession Information Total tunnels 3 sessions 3LocID TunID Peer-address Type Stat Username, Intf/Vcid, Circuit32517 26515 172.18.184.142 VLAN UP 100, Fa0/1/0.1:132519 30866 172.18.184.142 VLAN UP 200, Fa0/1/0.2:232518 35217 172.18.184.142 VLAN UP 300, Fa0/1/0.3:3Related Commands
show l2tun tunnel
To display the current state of a Layer 2 Tunnel Protocol Version 3 (L2TPv3) session and display information about currently configured sessions, including local and remote L2TP host names, aggregate packet counts, and L2TP control channels, use the show l2tun tunnel command in EXEC mode.
show l2tun tunnel [all [id identifier | local-name local-name remote-name | remote-name remote-name local-name] | packets [id identifier | local-name local-name remote-name | remote-name remote-name local-name] | state [id identifier | local-name local-name remote-name | remote-name remote-name local-name] | summary [id identifier | local-name local-name remote-name | remote-name remote-name local-name] | transport [id identifier | local-name local-name remote-name | remote-name remote-name local-name]]
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
When you use the show l2tun tunnel command to display information about configured L2TP sessions on the router, you can filter the output as follows:
•
•
Examples
The following example shows how to display detailed information about all currently configured L2TP sessions:
Router# show l2tun tunnel allSession Information Total tunnels 1 sessions 1Tunnel Information Total tunnels 1 sessions 1Tunnel id 26515 is up, remote id is 41814, 1 active sessionsTunnel state is established, time since change 03:11:50Tunnel transport is IP (115)Remote tunnel name is tun1Internet Address 172.18.184.142, port 0Local tunnel name is RouterInternet Address 172.18.184.116, port 0Tunnel domain isVPDN group for tunnel is0 packets sent, 0 received0 bytes sent, 0 receivedControl Ns 11507, Nr 11506Local RWS 2048 (default), Remote RWS 800Tunnel PMTU checking disabledRetransmission time 1, max 1 secondsUnsent queuesize 0, max 0Resend queuesize 1, max 1Total resends 0, ZLB ACKs sent 11505Current nosession queue check 0 of 5Retransmit time distribution: 0 0 0 0 0 0 0 0 0Sessions disconnected due to lack of resources 0The 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 tun1Tunnel Information Total tunnels 3 sessions 3LocID Type Prot Local Address Port Remote Address Port26515 IP 115 172.18.184.116 0 172.18.184.142 030866 IP 115 172.18.184.116 0 172.18.184.142 035217 IP 115 172.18.184.116 0 172.18.184.142 0The following example shows how to display information about the current state of L2TP sessions with the local and remote host names of each session:
Router# show l2tun tunnel stateLocID RemID Local Name Remote Name State Last-Chg26515 41814 Router tun1 est 03:13:1530866 6809 Router tun1 est 03:13:1535217 37340 Router tun1 est 03:13:15Related Commands
show l2tun session
Displays the current state of a Layer 2 session and displays protocol information about an L2TPv3 control channel.
snmp-server enable traps l2tun session
To enable Simple Network Management Protocol (SNMP) notifications (traps or inform requests) for Layer 2 Tunnel Protocol Version 3 (L2TPv3) sessions, use the snmp-server enable traps l2tun session command in global configuration mode. To disable SNMP notifications, use the no form of this command.
snmp-server enable traps l2tun session
no snmp-server enable traps l2tun session
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for L2TP sessions. To specify whether the notifications should be sent as traps or informs, use the snmp-server host [traps | informs] command.
If you do not enter the snmp-server enable traps l2tun session command, no notifications are sent.
The snmp-server enable traps l2tun session command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications.
Examples
The following example enables the router to send L2TP session traps to the host specified by the name myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable traps l2tun sessionRouter(config)# snmp-server host myhost.cisco.com publicRelated Commands
timeout setup
To configure the amount of time allowed to set up a control channel with a remote provider edge (PE) router at the other end of a Layer 2 Tunnel Protocol Version 3 (L2TPv3) pseudowire, use the timeout setup command in L2TP class configuration mode. To disable the configured value, use the no form of this command.
timeout setup seconds
no timeout setup seconds
Syntax Description
seconds
The number of seconds allowed to set up an L2TPv3 control channel. The valid values range from 60 to 6000. The default value is 300 seconds.
Defaults
300 seconds
Command Modes
L2TP class configuration
Command History
Usage Guidelines
Use this command to configure the amount of time spent attempting to establish a control channel.
Examples
The following example sets a timeout period of 200 seconds to establish a control channel with a remote peer in L2TPv3 pseudowires configured with the L2TP class named l2tp class1:
Router(config)# l2tp-class l2tp-class1Router(config-l2tp-class)# timeout setup 200Related Commands
l2tp-class
Creates a template of L2TP control plane configuration settings that can be inherited by different pseudowire classes and enters L2TP class configuration mode.
xconnect
To bind an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to a Layer 2 Tunnel Protocol Version 3 (L2TPv3) pseudowire for Xconnect service and enter xconnect configuration mode, use the xconnect command in interface configuration mode or l2transport PVP configuration mode.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
Syntax Description
Defaults
The default behavior is to use L2TPv3 as the data encapsulation method with sequencing off.
Command Modes
Interface configuration
l2transport PVP configurationCommand History
Usage Guidelines
The combination of the peer-ip-address and vcid must be unique on the router. Each Xconnect configuration must have a unique combination of peer-ip-address and vcid configuration.
Note
The same vcid value that identifies the attachment circuit must be configured using the xconnect command on the local and remote PE router at each end of an L2TPv3 session. The virtual circuit identifier creates the binding between a pseudowire and an attachment circuit.
To manually configure the L2TP settings used in the attachment circuit, enter encapsulation l2tpv3 manual in the xconnect command. This configuration is called a static L2TPv3 session. The router is placed in xconnect configuration mode and you can then configure the following options:
•
•
•
•
For more information about configuring a static L2TPv3 sessions, see the section "Manually Configuring L2TPv3 Session Parameters."
If you do not enter encapsulation l2tpv3 manual in the xconnect command, the data encapsulation type for the L2TPv3 session is taken from the encapsulation type configured for the pseudowire class specified with the pw-class pw-class-name command (see the section "Configuring the L2TPv3 Pseudowire").
The pw-class pw-class-name value binds the Xconnect configuration of an attachment circuit to a specific pseudowire class. In this way, the pseudowire class configuration serves as a template that contains settings used by all attachment circuits bound to it with the xconnect command.
Note
Examples
The following example shows how to configure Xconnect service for an Ethernet interface by binding the Ethernet circuit to the L2TPv3 pseudowire named 123 with a remote peer 10.0.3.201, and by using the L2TP configuration settings in the pseudowire class named vlan-xconnect:
Router(config)# interface Ethernet0/0.1Router(config-if)# xconnect 10.0.3.201 123 pw-class vlan-xconnectRelated Commands
Glossary
AVPs—attribute-value pairs.
BECN—backward explicit congestion notification. Bit set by a Frame Relay network in frames traveling in the opposite direction of frames encountering a congested path. DTE receiving frames with the BECN bit set can request that higher-level protocols take flow control action as appropriate.
CE—customer edge (Frame Relay switch or user device).
CIR—committed information rate. Rate at which a Frame Relay network agrees to transfer information under normal conditions, averaged over a minimum increment of time. CIR, measured in bits per second, is one of the key negotiated tariff metrics.
data-link control layer—Layer 2 in the SNA architectural model. Responsible for the transmission of data over a particular physical link. Corresponds approximately to the data link layer of the OSI model.
DCE—data circuit-terminating equipment (ITU-T expansion). Devices and connections of a communications network that comprise the network end of the user-to-network interface.
dCEF—distributed Cisco Express Forwarding.
DLCI—data-link connection identifier. A unique number assigned to a PVC endpoint in a Frame Relay network. Identifies a particular PVC endpoint within an access channel in a Frame Relay network and has local significance only to that channel.
DTE—data terminal equipment. Device at the user end of a user-network interface that serves as a data source, destination, or both.
FECN—forward explicit congestion notification. Bit set by a Frame Relay network to inform DTE receiving the frame that congestion was experienced in the path from source to destination. DTE receiving frames with the FECN bit set can request that higher-level protocols take flow-control action as appropriate.
HDLC—High-Level Data Link Control. A generic link-level communications protocol developed by the International Organization for Standardization (ISO). HDLC manages synchronous, code-transparent, serial information transfer over a link connection.
ICMP—Internet Control Message Protocol. A network protocol that handles network errors and error messages.
IDB—interface descriptor block.
IS-IS—Intermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol based on DECnet Phase V routing, whereby ISs (routers) exchange routing information based on a single metric to determine network topology.
L2TP—An extension to PPP merging features of two tunneling protocols: Layer 2 Forwarding (L2F) from Cisco Systems and Point-to-Point Tunneling (PPTP) from Microsoft. L2TP is an Internet Engineering Task Force (IETF) standard endorsed by Cisco Systems, and other networking industry leaders.
L2TPv3—Draft version of L2TP that enhances functionality in RFC 2661 (L2TP).
LMI—Local Management Interface.
MPLS—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.
MQC—modular quality of service command-line interface.
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can handle.
NNI—Network-to-Network Interface. ATM Forum standard that defines the interface between two ATM switches that are both located in a private network or are both located in a public network. The UNI standard defines the interface between a public switch and a private one. Also, the standard interface between two Frame Relay switches meeting the same criteria.
PE—Provider edge router providing Frame Relay over L2TPv3 functionality.
PPP—Point-to-Point Protocol. A link-layer encapsulation method for dialup or dedicated circuits. A successor to Serial Line IP (SLIP), PPP provides router-to-router and host-to-network connections over synchronous and asynchronous circuits.
PVC—permanent virtual circuit. A virtual circuit that is permanently established. A Frame Relay logical link, whose endpoints and class of service are defined by network management. Analogous to an X.25 permanent virtual circuit, a PVC consists of the originating Frame Relay network element address, originating data-link control identifier, terminating Frame Relay network element address, and termination data-link control identifier. Originating refers to the access interface from which the PVC is initiated. Terminating refers to the access interface at which the PVC stops. Many data network customers require a PVC between two points. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time. Data terminating equipment with a need for continuous communication uses PVCs.
PW—pseudowire.
SNMP—Simple Network Management Protocol. Network management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security.
tunneling—Architecture that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme.
UNI—User-Network Interface.
UTI—Universal Transport Interface.
VPDN—virtual private dialup network. A network that allows separate and autonomous protocol domains to share common access infrastructure, including modems, access servers, and ISDN routers. A VPDN enables users to configure secure networks that take advantage of ISPs that tunnel remote access traffic through the ISP cloud.
WAN—wide-area network. Data communications network that serves users across a broad geographic area and often uses transmission devices provided by common carriers. Frame Relay, SMDS, and X.25 are examples of WANs.
Note
Copyright © 2004 Cisco Systems, Inc. All rights reserved.
