Layer 2 Tunnel Protocol Version 3

Transcription

1 Layer 2 Tunnel Protocol Version 3 Feature History Release Modification 12.0(21)S Initial data plane support for the Layer 2 Tunnel Protocol Version 3 (L2TPv3) was introduced on the Cisco 7200 series, Cisco 7500 series, Cisco 10720, and Cisco series platforms. 12.0(23)S L2TPv3 control plane support was introduced on the Cisco 7200 series, Cisco 7500 series, Cisco 10720, and Cisco series platforms. This document describes the Layer 2 Tunnel Protocol Version 3 feature. This document includes the following sections: Feature Overview, page 1 Supported Platforms, page 18 Supported Standards, MIBs, and RFCs, page 19 Prerequisites, page 20 Configuration Tasks, page 20 Configuration Examples, page 28 Command Reference, page 32 Glossary, page 83 Feature Overview The Layer 2 Tunnel Protocol Version 3 feature expands on Cisco support of the Layer 2 Tunnel Protocol Version 3 (L2TPv3). Previous Cisco IOS Releases contained only limited support of L2TPv3. This feature introduces L2TPv3 control plane support and new commands for configuring both static and dynamic L2TPv3 sessions. 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). 1

2 Feature Overview Layer 2 Tunnel Protocol Version 3 L2TP has two fundamental parts: A control plane responsible for setting up the connection A data plane responsible for tunneling Layer 2 frames. L2TPv3 signaling is responsible for negotiating control plane parameters, session IDs and cookies; for performing authentication; and for exchanging configuration parameters. L2TPv3 is also used to reliably deliver hello messages and circuit status messages. These messages are critical to support circuit interworking, such as the Local Management Interface (LMI), and to monitor the remote circuit status. For more information about L2TP, refer to and Migration from UTI to L2TPv3 The Universal Tunnel Interface (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 Release 12.0(23)S introduces 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 of any user intervention. After the CLI migration, the old UTI commands that were replaced will not be available. The old-style UTI CLI will be hidden from the user. Note The UTI keepalive feature will not be migrated. The UTI keepalive feature will no longer be supported in post-l2tpv3 releases. You should convert to using dynamic L2TPv3 sessions in order to preserve the functionality provided by the UTI keepalive. L2TPv3 Operation L2TPv3 provides similar and enhanced services to replace the current UTI implementation, including the following: Xconnect for Layer 2 tunneling via a pseudowire over an IP network Layer 2 VPNs for provider edge-to-provider edge (PE-to-PE) router service via Xconnect that support Ethernet, 802.1q (VLAN), Frame Relay, high-level data link control (HDLC) and PPP Layer 2 circuits, including both static (UTI-like) and dynamic (using the new L2TPv3 signaling) forwarded sessions 2

3 Layer 2 Tunnel Protocol Version 3 Feature Overview The initial features support only the following: Layer 2 tunneling (as used in an L2TP access concentrator, or LAC) to an attachment circuit, not Layer 3 tunneling L2TPv3 data encapsulation directly over IP (IP protocol number 115), not using User Datagram Protocol (UDP) Point-to-point sessions, not point-to-multipoint or multipoint-to-point sessions Sessions between the same Layer 2 protocols; for example, Ethernet-to-Ethernet, VLAN-to-VLAN, but not VLAN-to-Ethernet or FrameRelay 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 Xconnected interface Pseudowire tu1 L2TPv3-based L2 tunnel Xconnected interface CE R3 int1 int2 IP network int3 int4 CE R4 PE R1 e1 Pseudowire tu2 e2 PE R2 LAN1 LAN2 L2TPv3 tunneled LAN L2TPv3 tunneled LAN 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: All packets received on interface int1 will be forwarded to R4. R3 and R4 cannot detect the intervening network. For Ethernet interfaces, any packet received from LAN1 by R1 on Ethernet interface e1 will be encapsulated directly in IP and sent via the pseudowire session tu2 to R2 interface e2, where it will be sent on LAN2. A VLAN on an Ethernet interface can be mapped to an L2TPv3 session. 3

4 Feature Overview Layer 2 Tunnel Protocol Version 3 For Cisco series Internet Routers, the other LAN ports on the 8-port Fast Ethernet line card that are not being used for L2TPv3 must have a router connected to them: When content-addressable memory (CAM) assisted MAC filtering is turned OFF to allow L2TPv3 to work, it is turned OFF on all ports. 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. Refer to the section Configuration Tasks for more information on the CLI commands for L2TPv3. Figure 2 L2TPv3 Header Format IP Delivery Header (20 bytes) Protocol ID: 115 L2TPV3 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 The local session ID must be unique on the decapsulating system and is restricted to the least significant ten bits. 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. 4

5 Layer 2 Tunnel Protocol Version 3 Feature Overview 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 Static L2TPv3 Sessions L2TPv3 provides Xconnect support for Ethernet, 802.1q (VLAN), Frame Relay, HDLC, and PPP, using the following sessions: Static L2TPv3 Sessions (nonnegotiated, PVC-like forwarded sessions) Dynamic L2TPv3 Sessions (negotiated, forwarded sessions using the L2TPv3 control plane for session negotiation) L2TPv3 also includes support for the following features: Sequencing Local Switching Distributed Switching L2TPv3 Type of Service Markingg Keepalive MTU Handling 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 In an L2TPv3 static session, you can still run the L2TP control channel to perform peer authentication and dead-peer detection. If the L2TP control channel cannot be established or is torn down because of a hello failure, the static session is also torn down. 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. 5

6 Feature Overview Layer 2 Tunnel Protocol Version 3 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 Distributed 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 an example of how to configure local port switching. Distributed Cisco Express Forwarding (dcef) switching is supported for L2TP on the Cisco 7500 series and Cisco series Internet routers, but not on the Cisco 7200 series or Cisco Internet router. Note For the Cisco 7500 series, sequencing is supported, but all L2TP packets that require sequence number processing are sent to the Route Switch Processor (RSP). Sequencing is not supported for the Cisco series Internet routers in Release 12.0(23)S. On th e Cisco series Internet routers, equencing will be supported in a future release with sequence number processing done by the server card fast path. 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: If the tunneled Layer 2 frames encapsulate IP packets themselves, it may be desirable to simply copy the ToS bytes of the inner IP packets to the outer IP packet headers. This action is known as ToS byte reflection. Static ToS byte configuration. You specify the ToS byte value used by all packets sent across the pseudowire. 6

7 Layer 2 Tunnel Protocol Version 3 Feature Overview On the Cisco 10720, ToS configuration can be done using modular quality of service (QoS) command line interface (MQC). If both static ToS byte configuration and MQC ToS byte configuration are implemented, the MQC configuration will take precedence. See the section Configuring a Negotiated L2TPv3 Session for Local HDLC Switching 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 a maximum transmission unit (MTU) appropriate for a each L2TPv3 tunneled link. The configured MTU size ensures the following: The lengths of the tunneled Layer 2 frames fall below the MTU of the destination attachment circuit The tunneled packets are not fragmented, which forces the receiving PE to reassemble them L2TPv3 handles the MTU as follows: The default behavior is to fragment packets that are larger than the session MTU. The one exception is on Cisco series Internet routers, where fragmentation of tunneled packets is not allowed. If you enable the ip dfbit set command in the pseudowire class, the default MTU behavior changes so that any packets that cannot fit within the tunnel MTU are dropped. 7

8 Feature Overview Layer 2 Tunnel Protocol Version 3 If you enable the ip pmtu command in the pseudowire class, the L2TPv3 control channel participates in the path MTU discovery. When you enable this feature, the following processing is performed: Internet Control Message Protocol (ICMP) unreachable messages sent back to the L2TPv3 router are deciphered and the tunnel MTU is updated accordingly. In order to receive ICMP unreachable messages for fragmentation errors, the Don t Fragment (DF) bit in the tunnel header is set according to the DF bit value received from the CE, or statically if the ip dfbit set option is enabled. The tunnel MTU is periodically reset to the default value based on a periodic timer. ICMP unreachable messages are sent back to the clients on the CE side. ICMP unreachable messages are sent to the CE whenever IP packets arrive on the CE-PE interface and have a packet size greater than the tunnel MTU. For the packets that match this check, an ICMP unreachable message is sent back to the src IP address of the packet. A Layer 2 header calculation is performed before the ICMP unreachable message is sent to the CE. L2TPv3 and UTI Feature Comparison Table 1 compares L2TPv3 and UTI support. Table 1 Comparison of L2TPv3 and UTI Support Feature L2TPv3 UTI Maximum number of sessions Cisco 7200 series:3000 Cisco 7500 series: 3000 Cisco 10720: 2000 Cisco series: 2000 Cisco 7200 series: 1000 Cisco 7500 series: 1000 Cisco series: 1000 Cisco series: 1000 Tunnel cookie length 0-, 4-, or 8-byte cookies are supported for the Cisco 7200 series and the Cisco 7500 series routers. For the Cisco and Cisco series Internet routers, only 8-byte cookies can be received in Release 12.0(23)S; 0-, 4-, or 8-byte cookies can be sent. 8 bytes Static sessions Supported in Release 12.0(21)S. Supported Dynamic sessions Supported in Release 12.0(23)S. Not supported Static ToS Supported in Release 12.0(23)S. Supported MQC ToS Supported in Release 12.0(23)S for the Supported Cisco only. Inner IP ToS mapping Supported on the Cisco 7200 and Cisco 7500 series routers. To be supported in a future release for the Cisco and Cisco series Internet routers. Not supported 802.1p mapping Supported in Release 12.0(23)S for the Cisco only. Not supported 8

9 Layer 2 Tunnel Protocol Version 3 Feature Overview Feature L2TPv3 UTI Keepalive Supported in Release 12.0(23)S. Supported on the Cisco only. Path MTU discovery Supported on the Cisco 7200 series, Cisco 7500 series and Cisco Internet Routers. To be supported in a future release for the Cisco Internet Router. Not supported ICMP unreachable VLAN rewrite Supported on the Cisco 7200 series, Cisco 7500 series, and Cisco Internet routers. To be supported in a future release for the Cisco Internet router. Supported on the Cisco 7200 series, Cisco 7500 series, and the Cisco Internet router in Release 12.0(23)S. To be supported in a future release for Cisco series Internet routers. Not supported Supported VLAN and non-vlan translation To be supported in a future release. Supported on the Cisco only. Port trunking Supported in Release 12.0(23)S. Supported IS-IS packet fragmentation through an L2TPv3 session Supported on the Cisco series Internet routers in Release 12.0(23)S. To be supported in a future release for the Cisco 7200 series, Cisco 7500 series, and the Cisco Internet router. Not supported IP packet fragmentation through an To be supported in a future release. Not supported L2TPv3 session Payload sequence number checking To be supported in a future release. Not supported MIB support VPDN MIB for the pseudowire IfTable MIB for the attachment circuit. IfTable MIB for the session interface. Supported L2TPv3 Payloads L2TPv3 supports the following Layer 2 payloads that can be included in L2TPv3 packets tunneled over the pseudowire: Frame Relay Ethernet 802.1q (VLAN) High-Level Data Link Control PPP 9

10 Feature Overview Layer 2 Tunnel Protocol Version 3 Note Each L2TPv3 tunneled packet includes the entire Layer 2 frame of the payloads described in this section. If sequencing is required (see the section Sequencing ), a Layer 2-specific sublayer (see the section Pseudowire Control Encapsulation ) is included in the L2TPv3 header to provide the Sequence Number field. Frame Relay L2TPv3 supports the Frame Relay functionality described in the following sections: Port-to-Port Trunking DLCI-to-DLCI Switching PVC Status Signaling Sequencing ToS Marking CIR Guarantees Port-to-Port Trunking DLCI-to-DLCI Switching PVC Status Signaling Port-to-port trunking is where two CE Frame Relay interfaces are connected together 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 examine or change the data-link connection identifiers (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. 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 is propagated toward Frame Relay end users by the LMI protocol. You can configure the LMI to operate in any of the following modes: UNI DTE mode PVC status is not reported, only received. 10

11 Layer 2 Tunnel Protocol Version 3 Feature Overview UNI DCE mode PVC status is reported but not received. NNI mode PVC status is reported and received independently. 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. 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 In, CIR guarantees are supported only on the Cisco 7500 series with dcef. This support requires that the core has sufficient bandwidth to handle all CE traffic and that the congestion occurs only at the egress PE. 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. 11

12 Feature Overview Layer 2 Tunnel Protocol Version 3 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 Due to the way in which L2TPv3 handles Ethernet frames, an Ethernet interface must be configured to promiscuous mode in order to capture all traffic received on the Ethernet segment attached to the router. All frames will be tunneled through the L2TP pseudowire q (VLAN) L2TPv3 supports VLAN membership in the following ways: Port-based, in which undated Ethernet frames are received. VLAN-based, in which tagged Ethernet frames are received. 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: User priority field Canonical format indicator (CFI) A 12-bit VLAN ID (VID) 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 Due to the way in which L2TPv3 handles 802.1q VLAN packets, the Ethernet interface must be configured in promiscuous mode to capture all traffic received on the Ethernet segment attached to the router. All frames are tunneled through the L2TP pseudowire. High-Level Data Link Control 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. 12

13 Layer 2 Tunnel Protocol Version 3 Feature Overview Benefits 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 Multiprotocol Label Switching (MPLS) in the core IP backbone to set up VPNs using L2TPv3 over the IP backbone, resulting in operational savings and higher 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. Restrictions The following subsections contain information on restrictions: Supported Port Adapters for the Cisco 7200 and 7500 Series Routers Supported Line Cards for the Cisco Internet Router Supported Line Cards for the Cisco Series Internet Routers General L2TPv3 Restrictions Cisco 7500-Specific Restrictions Cisco Specific Restrictions Cisco Series-Specific Restrictions Frame Relay-Specific Restrictions VLAN-Specific 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: Single-port Fast Ethernet 100BASE-TX Single-port Fast Ethernet 100BASE-FX Dual-port Fast Ethernet 100BASE-TX Dual-port Fast Ethernet 100BASE-FX Gigabit Ethernet port adapter 12-port Ethernet/2-port FE adapter 4-port synchronous serial port adapter Enhanced 4-port synchronous serial port adapter 8-port synchronous serial port adapter Single-port HSSI adapter Dual-port HSSI adapter 13

14 Feature Overview Layer 2 Tunnel Protocol Version 3 8-port multichannel E1 G.703/G ohm interfaces 2-port multichannel E1 G.703/G ohm interfaces 8-port multichannel T1 with integrated DSUs 8-port multichannel T1 with integrated CSUs and DSUs 4-port multichannel T1 with integrated CSUs and DSUs 2-port multichannel T1 with integrated CSUs and DSUs 8-port multichannel T1/E1 1-port multichannel T3 interface 1-port multichannel E3 interface 2-port enhanced multichannel T3 port adapter Single-port T3 port adapter Single-port E3 port adapter 2-port T3 port adapter 2-port T3 port adapter Single-port PoS, single-mode, long reach Single-port PoS, single-mode, intermediate reach Single-port PoS, multimode L2TPv3 is supported on the following port adapters for the Cisco 7200 series routers only: 8-port Ethernet adapter 4-port Ethernet adapter Supported Line Cards for the Cisco Internet Router L2TPv3 is supported on the following uplink and access cards in the Cisco Internet router: 24-port 10/100-Mbps Ethernet TX access card 24-port 100-Mbps Ethernet FX access card multimode (MM) 24-port 100-Mbps Ethernet FX access card single-mode (SM) Gigabit Ethernet SFP module short reach line card Gigabit Ethernet SFP module intermediate reach line card Supported Line Cards for the Cisco Series Internet Routers Table 1 shows the line cards that support L2TPv3 for the Cisco series Internet routers. Supported line cards for the Cisco series Internet routers Line Card Engine Type Port Session DLCI Session VLAN Session PoS Engine 0 Supported Supported Unsupported PoS Engine 2 Supported Supported Unsupported 2-port Ch OC-3/STM-1(DS1/E1) Engine 0 Supported Supported Unsupported 6-port Ch T3 Engine 0 Supported Supported Unsupported 3-port Gigabit Ethernet Engine 2 Supported Unsupported Supported 1-port Gigabit Ethernet Engine 1 Supported Unsupported Supported 14

15 Layer 2 Tunnel Protocol Version 3 Feature Overview Line Card Engine Type Port Session DLCI Session VLAN Session 8-port Fast Ethernet Engine 1 Supported Unsupported Supported 6-port E3 Engine 0 Supported Supported Unsupported 12-port E3 Engine 0 Supported Supported Unsupported 6-port DS3 Engine 0 Supported Supported Unsupported 12-port DS3 Engine 0 Supported Supported Unsupported General L2TPv3 Restrictions CEF must be enabled for the L2TPv3 feature to function. The Xconnect configuration submode is blocked until CEF is enabled. On distributed platforms, such as the Cisco 7500 and Cisco series, if CEF is disabled while a session is established, the session is torn down and remains down until CEF is reenabled. To enable CEF, use the ip cef or ip cef distributed command. The IP local interface must be a loopback interface. Configuring any other interface with the ip local interface command will result in a nonoperational setting. The number of sessions on a PPP, HDLC, Ethernet, or 802.1q VLAN port is limited by the number of interface descriptor blocks (IDBs) that the router can support. For PPP, HDLC, Ethernet, and 802.1q VLAN circuit types, an IDB is required for each circuit. 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.0S. Frame Relay support includes only 10-bit DLCI addressing. The L2TPv3 feature does not support Frame Relay extended addressing. The interface keepalive feature is automatically disabled on the interface to which Xconnect is applied, except for Frame Relay encapsulation, which is required for LMI. Static L2TPv3 sessions do not support Frame Relay LMI interworking. Static L2TPv3 sessions do not interoperate with UTI using keepalives. The ip pmtu command used to configure the pseudowire class (see the section Configuring the L2TPv3 Pseudowire ) is not supported for static L2TPv3 sessions. As a result, IS-IS fragmentation through a static L2TPv3 session is not supported. Cisco 7500-Specific Restrictions Although L2TPv3 sequencing is supported on Cisco 7500 series routers, all L2TP packets that require sequence number processing will be sent to the Route Switch Processor (RSP) module. Cisco Specific Restrictions L2TPv3 sequencing is not supported. Although the Cisco Internet router can send cookie lengths of 0-, 4-, or 8-bytes to an L2TP peer device, it supports the reception of only 8-byte L2TPv3 cookies. Support for reception of 0- and 4-byte cookie lengths will be introduced in future releases. The ToS reflect feature is not supported. The reassembly of L2TPv3 packets is not supported. The Path MTU feature is not supported. 15

16 Feature Overview Layer 2 Tunnel Protocol Version 3 On the Cisco Internet router, the uti translation command is not migrated for Xconnect service and is not supported in. Although the uti command is supported in L2TPv3 releases, the translation option is lost in the migration. Cisco Series-Specific Restrictions The variable cookie size, VLAN rewrite, sequencing, ip tos reflect, ip dfbit, fragmentation, and the counters for out-of-order and exceeded session MTU packets are not supported in Release 12.0(23)S. IS-IS protocol packet fragmentation is only supported for dynamic L2TPv3 sessions. The IP local interface must be a local loopback interface. Configuring any other interface as the IP local interface will result in non-operational sessions. The IP local interface must be dedicated for the use of L2TPv3 sessions. This interface must not be shared by any other routing or tunneling protocols. Hairpinning is not supported for local-to-local switching. The start and end of an L2TPv3 session must terminate on different routers linked via an IP or MPLS backbone. The aggregate performance is bound by the server card limit of 2.5 million packets per second (pps). The dedicated tunnel server card 1-Port OC-48c/STM-16c POS/SDH is required for L2TPv3 to function. The server card will not run any Engine 2 features. The ip unnumbered command and IP address should be configured under the PoS interface of the server card prior to hardware-module configuration. This configuration makes the server card IP-Aware for backbones requiring an Address Resolution Protocol (ARP) to be generated by the line card. The backbone types that require this configuration are Ethernet and spatial reuse protocol (SRP). This configuration is also a requirement for session keepalives. The interface port of the server card will automatically be set to loopback internal and no keepalives once the hw-module slot slot-number mode server command is configured. Due to a framer problem, the server card interfaces accounting in (packets out) will not be accurate. Only features found in the Vanilla ucode bundle are supported on Engine 2 line cards that are associated with a L2TPv3 session and on a different interface, DLCI or VLAN of the same line card. Configuring Engine 2 features not found in the Vanilla ucode bundle on any port of the Engine 2 line card that has a L2TPv3 session bound to one or more interfaces will cause the Vanilla ucode to be swapped out. This configuration will cause all traffic through the L2TPv3 session to stop on that Engine 2 line card. In this case, rebinding of the L2TPv3 session will be required when the Vanilla ucode bundle is restored. Configuring output access control lists (ACLs) on any line card will swap out the running Engine 2 line card Vanilla ucode bundle in favor of the ACL ucode bundle. This configuration will cause all traffic through the L2TPv3 session to stop on those Engine 2 line cards. If output ACLs are essential on the router, it is advisable to originate all L2TPv3 sessions on Engine 0 line cards. Output ACLs will not swap out the server card ucode bundle due to the higher priority. Engine 2 line cards do not support Frame Relay switching and Frame Relay L2TPv3 DLCI session on the same line card. On Engine 2 line cards, the input Frame Relay PVC counters will not be updated. The 8-port Fast Ethernet line card should not be connected to a hub or switch when L2TPv3 is configured on the ingress side of one or more of its ports, or duplicate packets will be generated, causing the router to be flooded with packets. This restriction results from the requirement that CAM filtering is disabled when L2TPv3 is used. 16

17 Layer 2 Tunnel Protocol Version 3 Feature Overview On the 3-port Gigabyte Ethernet line card, performance degradation can occur if IP packets coming from a port are sent to the slow path for forwarding. This performance degradation will occur if both the following conditions are met: The port has at least one 802.1q subinterface that is in an L2TPv3 session. The IP packet comes from the port interface itself (not 802.1q encapsulated) or from an 802.1q subinterface that is under the port interface but has no L2TPv3 session bound to it. On the 1-Port OC-48c/STM-16c POS/SDH linecard, the maximum performance of 2.5 million packets per second is achieved only if you use transmit buffer management (TBM) ASIC ID 60F1. Other ASIC ID versions can cause the performance to be reduced by half. To determine the ASIC value of the line card, use the execute-on slot slot-number show controller frfab bma reg include asic command, where slot-number is the slot number of the server card. The optics of the 1-Port OC-48c/STM-16c POS/SDH line card should be covered due to possible interference or noise causing CRC errors on the line card. These errors are caused by a framer problem in the line card. Frame Relay-Specific Restrictions Frame Relay per-dlci forwarding and port-to-port trunking are mutually exclusive. L2TPv3 does not support the use of both on the same interface at the same time. The xconnect command is not supported on Frame Relay interfaces directly. For Frame Relay, the Xconnect is applied under the connect command specifying the DLCI to be used. Changing the encapsulation type on any interface removes any existing xconnect command applied to that interface. The DE bit value does not influence the ToS bits. To use DCE or a Network-to-Network Interface (NNI) on a Frame Relay port, you must configure the frame-relay switching command. The MQC supported by L2TPv3 on Frame Relay interfaces is supported only on the Cisco 7500 series with dcef and is limited to using the match fr-dlci command with the bandwidth command. Frame Relay policing is nondistributed on the Cisco 7500 series. By configuring Frame Relay policing, you cause traffic on the affected PVCs to be sent to the RSP for processing. Frame Relay policing is not supported on the Cisco series Internet router. Frame Relay support is for 10-bit DLCI addresses. Frame Relay Extended Addressing is not supported. Multi-point DLCI is not supported. The keepalive will automatically be disabled on interfaces that have an Xconnect applied to them, except for Frame Relay encapsulation which is a requirement for LMI. Static L2TPv3 sessions will not support Frame Relay LMI interworking. VLAN-Specific Restrictions A PE router is responsible only for static VLAN membership entries that are manually configured on the router. Dynamic VLAN membership entries, entry aging, and membership discovery are not supported. Implicit tagging for VLAN membership operating on the other layers (such as at Layer 2, membership by MAC address or protocol type, at Layer 3, or membership by IP subnet) is not supported. 17

18 Supported Platforms Layer 2 Tunnel Protocol Version 3 Point-to-multipoint and multipoint-to-point configurations are not supported. There is a 1:1 relationship between an attachment circuit and an L2TPv3 session. VLAN ID rewrite is not supported on the Cisco series Internet router. Related Features and Technologies Wide-area networking VPNs L2TP UTI Related Documents Layer 2 Tunneling Protocol Version 3 Technical Overview Cisco IOS Release 12.0 Configuration Fundamentals Configuration Guide Cisco IOS Release 12.0 Configuration Fundamentals Command Reference Cisco IOS Release 12.0 Dial Solutions Command Reference Network Protocols Command Reference, Part 1, Release 11.3 Cisco IOS Release 12.0 Wide-Area Networking Command Reference Universal Transport Interface (UTI) Layer 2 Tunnel Protocol Layer 2 Tunneling Protocol: A Feature in Cisco IOS Software Supported Platforms Cisco 7200 series Cisco 7500 series Cisco Cisco series Determining Platform Support Through Cisco Feature Navigator Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature. Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common. 18

19 Layer 2 Tunnel Protocol Version 3 Supported Standards, MIBs, and RFCs To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank to cco-locksmith@cisco.com. An automatic check will verify that your address is registered with Cisco.com. If the check is successful, account details with a new random password will be ed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL: Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL: Availability of Cisco IOS Software Images Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator. Supported Standards, MIBs, and RFCs Standards draft-ietf-l2tpext-l2tp-base-03.txt MIBs VPDN MIB MIB support for L2TPv3 is based on the VPDN MIB. To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: 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: 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 to cco-locksmith@cisco.com. An automatic check will verify that your address is registered with Cisco.com. If the check is successful, account details with a new random password will be ed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL: RFCs RFC 2661 (L2TP) 19

20 Prerequisites Layer 2 Tunnel Protocol Version 3 Prerequisites Before you configure an Xconnect attachment circuit for a CE device (see the section Configuring the Xconnect Attachment Circuit ), the CEF feature must be enabled. To enable CEF on an interface, use the ip cef or ip cef distributed command. You must configure a loopback interface on the router for originating and terminating the L2TPv3 traffic. The loopback interface must have an IP address that is reachable from the remote PE device at the other end of an L2TPv3 control channel. To enable SNMP notifications of L2TP session up and down events, enter the snmp-server enable traps l2tun session command before configuring L2TPv3. Configuration Tasks See the following sections for configuration tasks for the L2TPv3 feature. Each task in the list is identified as either required or optional. Configuring L2TP Control Channel Parameters (optional) Configuring the L2TPv3 Pseudowire (required) Configuring the Xconnect Attachment Circuit (required) Manually Configuring L2TPv3 Session Parameters (required) Verifying an L2TPv3 Session (optional) Verifying an L2TP Control Channel (optional) 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: Configuring L2TP Control Channel Timing Parameters Configuring L2TP Control Channel Authentication Parameters Configuring L2TP Control Channel Maintenance 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 L2TP class control channel parameters can be applied to a connection between any pair of IP addresses. 20

21 Layer 2 Tunnel Protocol Version 3 Configuration Tasks Configuring L2TP Control Channel Timing Parameters The following L2TP control channel timing parameters can be configured in L2TP class configuration mode: Packet size of the receive window used for the control channel Retransmission parameters used for control messages Timeout parameters used for the control channel To configure a set of timing control channel parameters in an L2TP class, use the following commands beginning in global configuration mode. 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 will be applied. Step 1 Step 2 Step 3 Step 4 Command Router(config)# l2tp-class [l2tp-class-name] Router(config-l2tp-class)# receive-window size Router(config-l2tp-class)# retransmit {initial retries initial-retries retries retries timeout {max min} timeout} Router(config-l2tp-class)# timeout setup seconds Purpose Specifies the L2TP class name and enters L2TP class configuration mode. The l2tp-class-name argument is optional. However, if you want to configure multiple L2TP classes you must specify a unique l2tp-class-name for each one. (Optional) Configures the number of packets that can be received by the remote peer before backoff queuing occurs. The valid values range from 1 to the upper limit the peer has for receiving packets. The default value is the upper limit. (Optional) Configures parameters that affect the retransmission of control packets: initial retries specifies how many SCCRQs are resent before giving up on the session. Valid values for the initial-retries argument range from 1 to The default value is 2. retries specifies how many retransmission cycles occur before determining that the peer PE router does not respond. Valid values for the retries argument range from 1 to The default value is 15. timeout {max min} specifies maximum and minimum retransmission intervals (in seconds) for resending control packets. Valid values for the timeout argument range from 1 to 8. The default maximum interval is 8; the default minimum interval is 1. (Optional) Configures the amount of time, in seconds, allowed to set up a control channel. Valid values for the seconds argument range from 60 to The default value is 300. Configuring L2TP Control Channel Authentication Parameters The following L2TP control channel authentication parameters can be configured in L2TP class configuration mode: Authentication for the L2TP control channel Local host name used for authenticating the control channel 21