Wide-Area Networking Configuration Guide: Layer 2 Services, Cisco IOS XE Release 3S (Cisco ASR 1000)
Layer 2 Tunneling Protocol Version 3
Layer 2 Tunneling Protocol Version 3
Last Updated: December 4, 2012
The Layer 2 Tunneling Protocol Version 3 feature expands Cisco's support of Layer 2 VPNs. Layer 2 Tunneling Protocol Version 3 (L2TPv3) is an IETF l2tpext working group draft that provides several enhancements to L2TP to tunnel any Layer 2 payload over L2TP. Specifically, L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network by using Layer 2 VPNs.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Layer 2 Tunneling Protocol Version 3
Restrictions for Layer 2 Tunneling Protocol Version 3
General L2TPv3 Restrictions
IPv6 Protocol Demultiplexing for L2TPv3 Restrictions
L2TPv3 Control Message Hashing Restrictions
L2TPv3 Digest Secret Graceful Switchover Restrictions
This feature works only with authentication passwords configured using the L2TPv3 Control Message Hashing feature. L2TPv3 control channel authentication passwords configured with the older, Challenge Handshake Authentication Protocol (CHAP)-like authentication system cannot be updated without tearing down L2TPv3 tunnels and sessions. For more information about the L2TPv3 Control Message Hashing feature, see the L2TPv3 Control Message Hashing section.
Quality of Service Restrictions in L2TPv3 Tunneling
Quality of service (QoS) policies configured using the modular QoS CLI (MQC) are supported in L2TPv3 tunnel sessions with the following restrictions:
For detailed information about QoS configuration tasks and command syntax, see:
Information About Layer 2 Tunneling Protocol Version 3
L2TPv3 provides a method for delivering L2TP services over an IPv4 (non-UDP) backbone network. It encompasses the signaling protocol as well as the packet encapsulation specification.
L2TPv3 Header Description
The following figure shows the format of the L2TPv3 header:
Each L2TPv3 packet contains an L2TPv3 header that includes a unique session ID representing one session and cookie of variable length. The L2TPv3 Session ID and Cookie field lengths are assigned through CLI. For more information about the CLI commands for L2TPv3, see the How to Configure Layer 2 Tunneling Protocol Version 3 section.
The L2TPv3 header comprises the following:
The L2TPv3 session ID 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.
The L2TPv3 header contains a control channel cookie field. The control channel cookie field 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 configured manually for static sessions or determined dynamically 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 Sequencing section). 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 includes the following features:
The initial Cisco IOS software supported only the following features:
The attachment circuit is the physical interface or subinterface attached to the pseudowire.
The figure below shows 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 devices of the IP network treat the traffic as any other IP traffic and need not know anything about the customer networks.
In the figure above, the PE devices R1 and R2 provide L2TPv3 services. The R1 and R2 devices communicate with each other using a pseudowire over the IP backbone network through a path comprising interfaces int1 and int2, the IP network, and interfaces int3 and int4.
In this example, the customer edge (CE) devices R3 and R4 communicate through a pair of xconnect Ethernet or 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 through 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.
Note the following features regarding the L2TPv3 operation:
L2TPv3 provides xconnect support for Ethernet and VLAN using Static and Dynamic sessions.
Static L2TPv3 Sessions
Typically, the L2TP control plane is responsible for negotiating session parameters, such as the session ID or the cookie, 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 set up static L2TPv3 sessions for a PE device by configuring fixed values for the fields in the L2TP data header. A static L2TPv3 session allows the PE device to tunnel Layer 2 traffic as soon as the attachment circuit to which the session is bound comes up.
Static configuration allows sessions to be established without dynamically negotiating control connection parameters. This means that although sessions are displayed in the show l2tun session command output, no control channel information is displayed in the show l2tun tunnel command output.
If 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 (AV) pairs. Each AV pair contains information about the nature of the Layer 2 link being forwarded, including the payload type and virtual circuit (VC) ID.
Multiple L2TP sessions, one for each forwarded Layer 2 circuit, can exist between a pair of PE devices 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 set link info (SLI) message.
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 device at each end of the control channel. Configuring L2TP control channel parameters is optional. However, the L2TP class must be configured before it is associated with a pseudowire class (see the Configuring the L2TPv3 Pseudowire task).
L2TPv3 Control Channel Authentication Parameters
Two methods of control channel message authentication are available: the L2TPv3 Control Message Hashing feature and CHAP-style L2TP control channel. The L2TPv3 Control Message Hashing feature introduces a more robust authentication method than the older, CHAP-style L2TP control channel method of authentication. You may choose to enable both the methods of authentication to ensure interoperability with peers that support only one of these methods of authentication, but this configuration will yield control of the authentication method used on the peer PE device. Enabling both the methods of authentication should be considered as an interim solution to solve backward compatibility issues during software upgrades.
The principal difference between the two methods of authentication lies in the L2TPv3 Control Message Hashing feature using the entire message in the hash instead of computing the hash over selected contents of a received control message. In addition, instead of including the hash digest in only the start control channel replay (SCCRP) and start control channel connected (SCCCN) messages, it includes it in all messages.
Support for L2TP control channel authentication is maintained for backward compatibility. Either or both authentication methods can be enabled to allow interoperability with peers supporting only one of the authentication methods.
The table below shows a compatibility matrix for the different L2TPv3 authentication methods. PE1 is running the new authentication method. The possible authentication configurations for PE1 are shown in the first column. The other columns represent PE2 running software with different available authentication options. The tables cells in these columns indicate compatible configuration options for PE2. If any PE1/PE2 authentication configuration poses ambiguity about the authentication method used, the winning authentication method is indicated in bold. If both the old and new authentication methods are enabled on PE1 and PE2, both types of authentication occur.
1 Any PE software that supports only the old CHAP-like authentication system.
2 Any PE software that supports only the new message digest authentication and integrity checking authentication system, but does not understand the old CHAP-like authentication system. This type of software may be implemented by other vendors based on the latest L2TPv3 draft.
3 Any PE software that supports both the old CHAP-like authentication and the new message digest authentication and integrity checking authentication system.
Ethernet over L2TPv3
The Ethernet over L2TPv3 feature provides support for Ethernet-based Layer 2 payload tunneling over IP core networks using L2TPv3.
The Ethernet over L2TPv3 feature supports the following like-to-like switching modes:
The Ethernet over L2TPv3 feature supports the following types of internetworking:
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 by 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 AV pair when the session is being negotiated. A sender (or one that is manually configured to send sequenced packets) that receives this AV pair uses the Layer 2-specific pseudowire control encapsulation defined in L2TPv3.
You can configure L2TP to drop only out-of-order packets; you cannot configure L2TP to deliver the packets out-of-order. No reordering mechanism is available.
Interworking is not allowed when sequencing is enabled.
L2TPv3 Type of Service Marking
When Layer 2 traffic is tunneled across an IP network, information contained in the Type of Service (ToS) bits may be transferred to the L2TP-encapsulated IP packets in one of the following ways:
For more details on how to configure ToS, see the Example Configuring a Negotiated L2TPv3 Session for Local HDLC Switching section.
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 configure sessions manually.
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), SCCRP, and SCCCN control messages. The control channel is responsible for maintaining only 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 peer has gone down through the keepalive mechanism, it sends a StopCCN control message and then notifies all the pseudowires to the peer about the event. This notification results in the teardown of both manually configured and dynamic sessions.
It is important that you configure a Maximum Transmission Unit (MTU) appropriate for each L2TPv3 tunneled link. The configured MTU size ensures the following:
L2TPv3 handles the MTU as follows:
If you enable this feature, the following processing is performed:
L2TPv3 Control Message Hashing
The L2TPv3 Control Message Hashing feature introduces a new and more secure authentication system that replaces the CHAP-like authentication system inherited from L2TPv2, which uses the Challenge and Challenge Response AV pairs in the SCCRQ, SCCRP, and SCCCN messages. The L2TPv3 Control Message Hashing feature incorporates an optional authentication or integrity check for all control messages.
The per-message authentication introduced by the L2TPv3 Control Message Hashing feature is designed to:
The new authentication method uses the following:
Received control messages that lack any of the required security elements are dropped.
L2TPv3 control message integrity checking is a unidirectional mechanism that does not require the configuration of a shared secret. If integrity checking is enabled on the local PE device, control messages are sent with the message digest calculated without the shared secret or Nonce AV pairs and are verified by the remote PE device. If verification fails, the remote PE device drops the control message.
Enabling the L2TPv3 Control Message Hashing feature will impact performance during control channel and session establishment because additional digest calculation of the full message content is required for each sent and received control message. This is an expected trade-off for the additional security provided by this feature. In addition, network congestion may occur if the receive window size is too small. If the L2TPv3 Control Message Hashing feature is enabled, message digest validation must be enabled. Message digest validation deactivates the data path received sequence number update and restricts the minimum local receive window size to 35.
You may choose to configure control channel authentication or control message integrity checking. Control channel authentication requires participation by both peers and a shared secret must be configured on both devices. Control message integrity check is unidirectional and requires configuration on only one of the peers.
L2TPv3 Control Message Rate Limiting
The L2TPv3 Control Message Rate Limiting feature was introduced to counter the possibility of a denial-of-service (DoS) attack on a device running L2TPv3. The L2TPv3 Control Message Rate Limiting feature limits the rate at which SCCRQ control packets arriving at the PE that terminates the L2TPv3 tunnel can be processed. SCCRQ control packets initiate the process of bringing up the L2TPv3 tunnel and require a large amount of control plane resources of the PE device.
No configuration is required for the L2TPv3 Control Message Rate Limiting feature. This feature automatically runs in the background in supported releases.
L2TPv3 Digest Secret Graceful Switchover
Authentication of L2TPv3 control channel messages occurs using a password that is configured on all participating peer PE devices. Before the introduction of this feature, changing this password required removing of the old password from the configuration before adding the new password, causing an interruption in L2TPv3 services. The authentication password must be updated on all peer PE devices, which are often at different physical locations. It is difficult for all peer PE devices to be updated with the new password simultaneously to minimize interruptions in L2TPv3 services.
The L2TPv3 Digest Secret Graceful Switchover feature allows the password used to authenticate L2TPv3 control channel messages to be changed without tearing down the established L2TPv3 tunnels. This feature works only for authentication passwords configured with the L2TPv3 Control Message Hashing feature. Authentication passwords configured with the older, CHAP-like authentication system cannot be updated without tearing down L2TPv3 tunnels.
The L2TPv3 Digest Secret Graceful Switchover feature allows two control channel passwords to be configured simultaneously, so a new control channel password can be enabled without first removing the old password. Established tunnels are rapidly updated with the new password, but continue to use the old password until it is removed from the configuration. This allows authentication to continue normally with peer PE devices that have not yet been updated to use the new password. After all peer PE devices are configured with the new password, the old password can be removed from the configuration.
During the period when both a new and an old password are configured, authentication will occur only with the new password if the attempt to authenticate using the old password fails.
The pseudowire class configuration procedure creates a configuration template for the pseudowire. Use this template or class to configure session-level parameters for L2TPv3 sessions that are 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, Layer 3 fragmentation, payload-specific options, and IP properties. The setting that determines whether signaling is used to set up the pseudowire is also included.
If you specify the encapsulation l2tpv3 command, you cannot remove it by using the no encapsulation l2tpv3 command. You also cannot change the command setting by using the encapsulation mpls command. These 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 by using the no pseudowire-class command. To change the type of encapsulation, remove the pseudowire by using the no pseudowire-class command, reestablish the pseudowire, and specify the new encapsulation type.
Manual Clearing of L2TPv3 Tunnels
This feature lets you clear L2TPv3 tunnels manually. Before the introduction of this feature, there was no provision to clear a specific L2TPv3 tunnel manually. This functionality provides users more control over an L2TPv3 network.
L2TPv3 Tunnel Management
New and enhanced commands have been introduced to facilitate the management and diagnosis of problems with xconnect configurations. No specific configuration tasks are associated with these commands.
L2TPv3 Protocol Demultiplexing
The L2TPv3 Protocol Demultiplexing feature introduces the ability to provide native IPv6 support by utilizing a specialized IPv6 network to offload IPv6 traffic from the IPv4 network. The IPv6 traffic is tunneled to the IPv6 network transparently by using L2TPv3 pseudowires without affecting the configuration of the CE devices. IPv4 traffic is routed as usual within the IPv4 network, maintaining the existing performance and reliability of the IPv4 network.
The IPv4 PE devices must be configured to demultiplex the incoming IPv6 traffic from IPv4 traffic. The PE devices facing the IPv6 network do not require the IPv6 configuration. The configuration of the IPv6 network is beyond the scope of this document. For more information on configuring an IPv6 network, see the IPv6 Configuration Guide.
L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations
The L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations feature lets you configure an Ethertype other than 0x8100 on Gigabit Ethernet interfaces with the QinQ or Dot1Q encapsulation. You can set the custom Ethertype to 0x9100, 0x9200, or 0x88A8. This allows interoperability in a multivendor Gigabit Ethernet environment.
HDLC over L2TPv3
HDLC for Layer 2 Data Encapsulation provides encapsulation of port-to-port Layer 2 traffic. All HDLC traffic including IPv4, IPv6, and non-IP packet, such as IS-IS, is tunneled over L2TPv3. HDLC does not support interworking mode.
Simplifies Deployment of VPNs
L2TPv3 is an industry-standard Layer 2 tunneling protocol that ensures interoperability among vendors, thus increasing customer flexibility and service availability.
Omits the Need for MPLS
Service providers need not deploy Multiprotocol Label Switching (MPLS) in the core IP backbone to set up VPNs using L2TPv3 over the IP backbone, resulting in operational savings and increased revenue.
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.
Supported L2TPv3 Payloads
An Ethernet frame arriving at a PE device 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 of the interface.
L2TPv3 supports VLAN memberships 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.
IPv6 Protocol Demultiplexing
Upgrading a service provider network to support IPv6 is a long and expensive process. As an interim solution, the Protocol Demultiplexing for L2TPv3 feature introduces the ability to provide native IPv6 support by setting up a specialized IPv6 network and offloading IPv6 traffic from the IPv4 network. IPv6 traffic is tunneled transparently to the IPv6 network using L2TPv3 pseudowires without affecting the configuration of the CE devices. IPv4 traffic is routed as usual within the IPv4 network, maintaining the existing performance and reliability of the IPv4 network.
The figure below shows a network deployment that offloads IPv6 traffic from the IPv4 network to a specialized IPv6 network. The PE devices demultiplex the IPv6 traffic from the IPv4 traffic. IPv6 traffic is routed to the IPv6 network over an L2TPv3 pseudowire, while IPv4 traffic is routed normally. The IPv4 PE devices must be configured to demultiplex the incoming IPv6 traffic from the IPv4 traffic. The PE devices facing the IPv6 network do not require the IPv6 configuration.
If no IP address is configured, the protocol demultiplexing configuration is rejected. If an IP address is configured, the xconnect command configuration is rejected unless protocol demultiplexing is enabled in xconnect configuration mode before exiting that mode. If an IP address is configured with an xconnect command configuration and protocol demultiplexing is enabled, the IP address cannot be removed. To change or remove the configured IP address, the xconnect command configuration must first be disabled.
The table below shows the valid combinations of configurations.
Performance Impact of L2TPv3 on Cisco ASR 1000 Series Routers
L2TPv3 supports the following maximum number of attachment circuits and tunnels:
L2TPv3 adds tunnel encapsulation to TCP packets, which can cause fragmentation of big packets (packet size larger than the session MTU). Consider a scenario where a big TCP packet is followed by a small TCP packet (packet size smaller than the session MTU). After L2TPv3 encapsulation, the encapsulated big TCP packet will be fragmented, but the encapsulated small TCP packet will not be fragmented. On the Cisco ASR 1000 Series Routers, the fragmentation and reassembly of the big TCP packet requires an additional processor cycle. Because Cisco ASR 1000 Series Routers follow multithread processing, the small packet will need shorter processing time and may be forwarded ahead of the fragmented big packet. This process may result in packet sequence changes on the receiver's end.
As a workaround, you can enable the ip pmtu command to prevent the fragmentation of tunneled packets (see the "MTU Handling" section).
How to Configure Layer 2 Tunneling Protocol Version 3
Configuring L2TP Control Channel Parameters
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 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, default values are applied.
Configuring L2TPv3 Control Channel Authentication Parameters
Configuring Authentication for the L2TP Control Channel
The L2TP control channel method of authentication is the older, CHAP-like authentication system inherited from L2TPv2.
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, default values are applied.
Configuring L2TPv3 Control Message Hashing
Configuring L2TPv3 Digest Secret Graceful Switchover
Perform this task to make the transition from an old L2TPv3 control channel authentication password to a new L2TPv3 control channel authentication password without disrupting established L2TPv3 tunnels.
Before You BeginSUMMARY STEPS
Before performing this task, you must enable control channel authentication as documented in the Configuring L2TPv3 Control Message Hashing task.
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 is applied.
Configuring the L2TPv3 Pseudowire
Configuring the Xconnect Attachment Circuit
The virtual circuit identifier that you configure creates the binding between a pseudowire configured on a PE device and an attachment circuit in a CE device. The virtual circuit identifier configured on the PE device at one end of the L2TPv3 control channel must also be configured on the peer PE device at the other end.
Manually Configuring L2TPv3 Session Parameters
When you bind an attachment circuit to an L2TPv3 pseudowire for the xconnect service by using the xconnect l2tpv3 manual command (see the section "Configuring the Xconnect Attachment Circuit") because you do not want signaling, you must configure L2TP-specific parameters to complete the L2TPv3 control channel configuration.
Configuring Protocol Demultiplexing for L2TPv3
Configuring Protocol Demultiplexing for Ethernet Interfaces
Configuring an L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations
The L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations feature lets you configure an Ethertype other than 0x8100 on Gigabit Ethernet interfaces with QinQ or Dot1Q encapsulations. You can set the custom Ethertype to 0x9100, 0x9200, or 0x88A8. To define the Ethertype field type, you use the dot1q tunneling ethertype command.
Perform this task to set a custom Ethertype.
Manually Clearing L2TPv3 Tunnels
Configuration Examples for Layer 2 Tunneling Protocol Version 3
Example: Configuring a Static L2TPv3 Session for an Xconnect Ethernet Interface
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 device 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-defaults retransmit initial retries 30 cookie-size 8 pseudowire-class ether-pw encapsulation l2tpv3 protocol none ip local interface Loopback0 interface Ethernet 0/0 xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw l2tp id 222 111 l2tp cookie local 4 54321 l2tp cookie remote 4 12345 l2tp hello l2tp-defaults
Example: Configuring a Negotiated L2TPv3 Session for an Xconnect VLAN Subinterface
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 class1 authentication password secret pseudowire-class vlan-xconnect encapsulation l2tpv3 protocol l2tpv3 class1 ip local interface Loopback0 interface Ethernet0/0.1 encapsulation dot1Q 5 xconnect 10.0.3.201 123 pw-class vlan-xconnect
Configuring 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 1 ip address 10.0.0.1 255.255.255.255 interface loopback 2 ip address 10.0.0.2 255.255.255.255 pseudowire-class loopback1 encapsulation l2tpv3 ip local interface loopback1 pseudowire-class loopback2 encapsulation l2tpv3 ip local interface loopback2 interface s0/0 encapsulation hdlc xconnect 10.0.0.1 100 pw-class loopback2 interface s0/1 encapsulation hdlc xconnect 10.0.0.2 100 pw-class loopback1
Example: Verifying an L2TPv3 Session
To display information about current L2TPv3 sessions on a device, use the show l2tun session brief command.
Device# show l2tun session brief L2TP Session Information Total tunnels 1 sessions 1 LocID TunID Peer-address State Username, Intf/ sess/cir Vcid, Circuit 2391726297 2382731778 22.214.171.124 est,UP 100, Gi0/2/0
To display detailed information about current L2TPv3 sessions on a device, use the show l2tun session all command.
Device# show l2tun session all L2TP Session Information Total tunnels 1 sessions 1 Session id 2391726297 is up, logical session id 36272, tunnel id 2382731778 Remote session id is 193836624, remote tunnel id 2280318174 Locally initiated session Unique ID is 12 Session Layer 2 circuit, type is Ethernet, name is GigabitEthernet0/2/0 Session vcid is 100 Circuit state is UP Local circuit state is UP Remote circuit state is UP Call serial number is 98300002 Remote tunnel name is l2tp-asr-2 Internet address is 126.96.36.199 Local tunnel name is l2tp-asr-1 Internet address is 188.8.131.52 IP protocol 115 Session is L2TP signaled Session state is established, time since change 00:05:25 94 Packets sent, 58 received 9690 Bytes sent, 5642 received Last clearing of counters never Counters, ignoring last clear: 94 Packets sent, 58 received 9690 Bytes sent, 5642 received Receive packets dropped: out-of-order: 0 other: 0 total: 0 Send packets dropped: exceeded session MTU: 0 other: 0 total: 0 DF bit off, ToS reflect disabled, ToS value 0, TTL value 255 Sending UDP checksums are disabled Received UDP checksums are verified No session cookie information available FS cached header information: encap size = 24 bytes 45000014 00000000 ff73a965 03030303 06060606 0b8db650 Sequencing is off Conditional debugging is disabled SSM switch id is 4101, SSM segment id is 12294
Example: Verifying an L2TP Control Channel
The L2TP control channel is used to negotiate capabilities, monitor the health of the peer PE device, and set up various components of an L2TPv3 session.To display information about L2TP control channels to other L2TP-enabled devices for all L2TP sessions on the device, use the show l2tun tunnel command.
Device# show l2tun tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 2382731778 2280318174 l2tp-asr-2 est 184.108.40.206 1 l2tp_default_clTo display detailed information about L2TP control channels to other L2TP-enabled devices for all L2TP sessions on the device, use the show l2tun tunnel all command.
Device# show l2tun tunnel all L2TP Tunnel Information Total tunnels 1 sessions 1 Tunnel id 2382731778 is up, remote id is 2280318174, 1 active sessions Locally initiated tunnel Tunnel state is established, time since change 00:02:59 Tunnel transport is IP (115) Remote tunnel name is l2tp-asr-2 Internet Address 220.127.116.11, port 0 Local tunnel name is l2tp-asr-1 Internet Address 18.104.22.168, port 0 L2TP class for tunnel is l2tp_default_class Counters, taking last clear into account: 54 packets sent, 35 received 5676 bytes sent, 3442 received Last clearing of counters never Counters, ignoring last clear: 54 packets sent, 35 received 5676 bytes sent, 3442 received Control Ns 5, Nr 4 Local RWS 1024 (default), Remote RWS 1024 Control channel Congestion Control is disabled Tunnel PMTU checking disabled Retransmission time 1, max 1 seconds Unsent queuesize 0, max 0 Resend queuesize 0, max 2 Total resends 0, ZLB ACKs sent 2 Total out-of-order dropped pkts 0 Total out-of-order reorder pkts 0 Total peer authentication failures 0 Current no session pak queue check 0 of 5 Retransmit time distribution: 0 0 0 0 0 0 0 0 0 Control message authentication is disabled
Example: Configuring L2TPv3 Control Channel Authentication
The following example shows how to configure CHAP-style authentication of the L2TPv3 control channel:
l2tp-class class0 authentication password ciscoThe following example shows how to configure control channel authentication using the L2TPv3 Control Message Hashing feature:
l2tp-class class1 digest secret cisco hash sha hiddenThe following example shows how to configure control channel integrity checking and how to disable validation of the message digest using the L2TPv3 Control Message Hashing feature:
l2tp-class class2 digest hash sha no digest checkThe following example shows how to disable the validation of the message digest using the L2TPv3 Control Message Hashing feature:
l2tp-class class3 no digest check
Example: Configuring L2TPv3 Digest Secret Graceful Switchover
The following example shows how to use the L2TPv3 Digest Secret Graceful Switchover feature to change the L2TP control channel authentication password for the L2TP class named class1. This example assumes that you already have an old password configured for the L2TP class named class1.
Device(config)# l2tp-class class1 Device(config-l2tp-class)# digest secret cisco2 hash sha ! ! Verify that all peer PE devices have been updated to use the new password before ! removing the old password. ! Device(config-l2tp-class)# no digest secret cisco hash sha
Example: Verifying L2TPv3 Digest Secret Graceful Switchover
The following show l2tun tunnel all command output shows information about the L2TPv3 Digest Secret Graceful Switchover feature:
Device# show l2tun tunnel all ! The output below displays control channel password information for a tunnel which has ! been updated with the new control channel authentication password. ! Tunnel id 12345 is up, remote id is 54321, 1 active sessions Control message authentication is on, 2 secrets configured Last message authenticated with first digest secret ! ! The output below displays control channel password information for a tunnel which has ! only a single control channel authentication password configured. ! Tunnel id 23456 is up, remote id is 65432, 1 active sessions ! Control message authentication is on, 1 secrets configured Last message authenticated with first digest secret ! ! The output below displays control channel password information for a tunnel which is ! communicating with a peer that has only the new control channel authentication password ! configured. ! Tunnel id 56789 is up, remote id is 98765, 1 active sessions ! Control message authentication is on, 2 secrets configured Last message authenticated with second digest secret
Example: Configuring a Pseudowire Class for Fragmentation of IP Packets
Example: Configuring Protocol Demultiplexing for L2TPv3
Example: Manually Clearing an L2TPv3 Tunnel
Example: Configuring an L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations
The following example shows how to configure an Ethertype other than 0x8100 on Gigabit Ethernet interfaces with QinQ or Dot1Q encapsulations. In this example, the Ethertype field is set to 0x9100 on Gigabit Ethernet interface 1/0/0.
Device> enable Device# configure terminal Device(config)# interface gigabitethernet 1/0/0 Device(config-if)# dot1q tunneling ethertype 0x9100
Example: Configuring an L2TPv3 HDLC Like-to-Like Layer 2 Transport
Example: Configuring an L2TPv3 HDLC Like-to-Like Layer 2 Transport on Dynamic Mode
The following example shows how to configure xconnect on a serial interface with HDLC encapsulation on a dynamic mode. The dynamic mode uses L2TPv3 signaling in control channel to set up the L2TPv3 tunnel.
pseudowire-class 774 encapsulation l2tpv3 protocol l2tpv3 ip local interface GigabitEthernet0/0/1.774 ! interface Serial0/2/0:0 no ip address xconnect 22.214.171.124 200 pw-class 774
Example: Configuring an L2TPv3 HDLC Like-to-Like Layer 2 Transport on Static Mode
The following example shows how to configure xconnect on a serial interface with HDLC encapsulation on a static mode. The static mode is used to disable signaling in the L2TPv3 control channel. Since signaling is disabled, you must specify the manual option in xconnect and configure L2TP-specific parameters to complete the L2TPv3 control channel configuration.
pseudowire-class pe1-ether-pw encapsulation l2tpv3 protocol none ip local interface Loopback1 ! interface Serial0/2/0:0 no ip address xconnect 126.96.36.199 50 encapsulation l2tpv3 manual pw-class pe1-ether-pw l2tp id 111 111 l2tp cookie local 4 54321 l2tp cookie remote 4 12345
Standards and RFCs
Feature Information for Layer 2 Tunneling Protocol Version 3
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
AV pairs--Attribute-value pairs.
CEF--Cisco Express Forwarding. The Layer 3 IP switching technology that optimizes network performance and scalability for networks with large and dynamic traffic patterns.
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.
DF bit--Don't Fragment bit. The bit in the IP header that can be set to indicate that the packet should not be fragmented.
DTE--Data terminal equipment. The device at the user end of a user-network interface that serves as a data source, destination, or both.
HDLC--High-Level Data Link Control. A generic link-level communications protocol developed by the 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. The OSI link-state hierarchical routing protocol based on DECnet Phase V routing, whereby ISs (devices) exchange routing information based on a single metric to determine network topology.
L2TP--An extension to PPP that merges features of two tunneling protocols: Layer 2 Forwarding (L2F) from Cisco Systems and Point-to-Point Tunneling Protocol (PPTP) from Microsoft. L2TP is an IETF standard endorsed by Cisco Systems and other networking industry leaders.
L2TPv3--The draft version of L2TP that enhances functionality in RFC 2661 (L2TP).
LMI--Local Management Interface.
MPLS--Multiprotocol Label Switching. A switching method that forwards IP traffic using a label. This label instructs the devices in the network where to forward packets based on preestablished IP routing information.
MQC--Modular quality of service CLI.
MTU--Maximum Transmission Unit. The maximum packet size, in bytes, that a particular interface can handle.
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 the 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.
SNMP--Simple Network Management Protocol. The network management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices and 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.
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 devices. A VPDN enables users to configure secure networks that take advantage of ISPs that tunnel remote access traffic through the ISP cloud.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2012 Cisco Systems, Inc. All rights reserved.