• Cisco Express Forwarding must be enabled for the L2TPv3 feature to function. The xconnect configuration mode is blocked until Cisco Express Forwarding is enabled. On distributed platforms, such as the Cisco 7500 series, if Cisco Express Forwarding is disabled while a session is established, the session is torn down. The session remains down until Cisco Express Forwarding is reenabled. To enable Cisco Express Forwarding, 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 PPP, High-Level Data Link Control (HDLC), Ethernet, or 802.1q VLAN ports 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 D channel data-link connection identifiers (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 session.

• To convert an interface with Any Transport over MPLS (AToM) xconnect to L2TPv3 xconnect, remove the AToM configuration from the interface and then configure L2TPv3. Some features may not work if L2TPv3 is configured before removing the AToM configuration.
• 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 Local Management Interface (LMI).
• Static L2TPv3 sessions do not support Frame Relay LMI interworking.
• Static L2TPv3 sessions do not interoperate with Universal Tunnel Interface (UTI) using keepalives.
• Layer 2 fragmentation of IP packets and Intermediate System-to-Intermediate System (IS-IS) fragmentation through a static L2TPv3 session are not supported.
• Layer 3 fragmentation is not recommended because of performance degradation.
• The L2TPv3 Layer 2 (IP packet) fragmentation feature (see the Configuring the L2TPv3 Pseudowire task) is not supported when the customer edge (CE) router is running special Layer 2 options such as Layer 2 sequencing, compression, or encryption. Examples of these options are Frame Relay compression and fragmentation or PPP compression. In these scenarios, the IP payload is not in a format that is compatible with IP fragmentation.
• The Stateful Switchover (SSO), Route Processor Redundancy (RPR) and RPR+ components of the HA functions are supported only at the coexistence level. If you attempt a switchover using SSO, RPR, or RPR+, the tunnels will fail and then eventually recover after an undetermined time duration. This includes both IPv4 and IPv6 traffic.
• Interworking is not allowed when sequencing is enabled.

• ATM port mode cell relay is only supported on the PA-A3-T3, PA-A3-E3, and PA-A3-OC-3 ATM port adapters.
• The features ATM Single Cell Relay VC Mode over L2TPv3 and ATM VP Mode Single Cell Relay over L2TPv3 are only supported on the PA-A3-T3, PA-A3-E3, and PA-A3-OC-3 ATM port adapters.
• VPI or VPI/VCI rewrite is not supported for any ATM transport mode. Both pairs of PE to CE peer routers must be configured with matching VPI and VCI values except in OAM local emulation mode. For example, if PE1 and CE1 are connected by PVC 10/100, PE2 and CE2 should also be connected by PVC 10/100.
• In OAM local emulation mode only, the VPI/VCI values used for each pair of PE to CE routers need not match. PE1 and CE1 may be configured with one VPI/VCI value, and PE2 and CE2 may be configured with a different VPI/VCI value. For example, if PE1 and CE1 are connected by PVC 10/100, PE2 and CE2 may be connected by PVC 20/200.

• The L2TPv3 Distributed Sequencing feature in Cisco IOS Release 12.2(27)SBC is supported only on the Cisco 7304 NPE-G100.
• The Protocol Demultiplexing feature in Cisco IOS Release 12.2(27)SBC is supported only on the Cisco 7304 NPE-G100.
• On the Cisco 7304 platforms, ATM cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC-3 ATM port adapters. ATM cell relay is not supported on the native line cards 7300-1OC-12ATM and 7300-2OC-3ATM.

• Distributed sequencing is supported on Cisco 7500 series routers only. The ip cef distributedcommand must be configured.
• ATM port mode cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC-3 ATM port adapters.
• VPI or VPI/VCI rewrite is not supported for any ATM transport mode. The peer routers must be configured with matching VPI or VCI values.

The following shared port adapters (SPAs) support L2TPv3 on the Cisco 7600 series routers.

Ethernet

• SPA_TYPE_ETHER_2xGE (2-port Gigabit Ethernet)
• SPA_TYPE_ETHER_2xGE_V2 (2-port Gigabit Ethernet)
• SPA_TYPE_ETHER_5xGE_V2 (5-port Gigabit Ethernet)
• SPA_TYPE_ETHER_1x10GE_V2 (single-port 10-Gigabit Ethernet)

ATM

• SPA_TYPE_KATM_2xOC3 (ATM, 2-port OC3)
• SPA_TYPE_KATM_4xOC3 (ATM, 4-port OC3)
• SPA_TYPE_KATM_1xOC12 (ATM, 1-port OC12)
• SPA_TYPE_KATM_1xOC48 (ATM, 1-port OC48)
• SPA_TYPE_CEOP_24xT1E1(CEoP 24-port T1/E1)
• SPA_TYPE_CEOP_1xOC3 (CEoP 1-port OC3)
• SPA_TYPE_CEOP_2xT3E3 (CEoP 2-port T3/E3)

On the Cisco 7600 series routers, L2TPv3 is a line card feature that was traditionally implemented only on the 7600-SIP-400 line card. In Cisco IOS Release 12.2(33)SRD, L2TPv3 is supported on the 7600-ES+20/40 line cards in the hardware, with the same capabilities (excluding the non-Ethernet interface support) and restrictions as in the 7600-SIP-400 line card. The minimum hardware requirement for enabling the L2TPv3 service on a Cisco 7600 router are an L2TPv3-aware line card (such as the 7600-SIP-400/ES+) at the Layer 2 CE-facing side and an IP interface on any line card at the IP core-facing side. A service card is not required for L2TPv3.

General Restrictions

L2TPv3 imposes the following general restrictions:

• The layer 2-facing line card must be an L2TPv3-supporting line card.
• There must be at least one distinct L2TPv3 tunnel per Layer 2-facing line card.
• Only IPv4 tunneling is supported for Layer 2 frames (configurations such as EoL2TPv3oMPLS (on the encapsulating provider edge (PE) device are not supported).

EVC/EFP Restrictions

L2TPv3 is not supported in conjunction with EVC features. L2TPv3 can coexist with EVC on the same port, meaning that while one subinterface is used to tunnel dot1q-tagged traffic over L2TP, another subinterface can be used to perform EVC features.

SVI VLAN Interfaces Restrictions

L2TPv3 is not supported on SVI VLAN interfaces.

MIB Support Restrictions

There is no L2TPv3-specific MIB support.

Layer Frame Fragmentation Restrictions

Layer 2 frame fragmentation is not supported. Even if the Layer 2 frame recovered after the L2TPv3 decapsulation exceeds the Layer 2 MTU on the CE-facing interface, the SIP-400 line card still sends the entire Layer 2 frame to the CE device. The Layer 2 frame may be dropped on the CE device because of MRU violations.

Layer 2 Virtual Private Network Interworking Restrictions

The SIP-400 line card does not support Layer 2 VPN interworking ("like to like" is the only mode supported for L2TPv3 tunneling).

Packet Sequencing Restrictions

The initial release of L2TPv3 focuses on tunneling Ethernet and ATM traffic over L2TPv3. Because of performance issues, the SIP-400 line card does not support L2TPv3 packet sequencing for Ethernet and ATM traffic. As a result, the 4-byte Layer 2-specific sublayer control word is not supported for Ethernet pseudowires. Configuring sequencing on a pseudowire will cause L2VPN traffic corruption.

By default, sequencing is disabled. However, you can configure sequencing in the pseudowire class, because the pseudowire class may be applied to pseudowires on other 7600 line cards that support sequencing. You must keep sequencing disabled when the pseudowire is handled on the SIP-400 line card.

Counters Restrictions

Per-session counters are provided by the line card. Per-tunnel counters are not provided.

Security and QoS ACLs Restrictions

The security QoS ACLs are not supported on the Layer 2 interfaces facing customer device, which means that you cannot apply ACLs to Layer 2 VPN traffic. (The Security ACL and the QoS ACL can still be applied to the IP interfaces at the core-facing side.)

DF Bit Reflection from Inner IP to Outer IP Restrictions

Traffic on ATM interfaces may have a deep stack of Layer 2 encapsulations. For example, the IP packet may be embedded first in Ethernet, then in Subnetwork Access Protocol (SNAP) and ATM Adaptation Layer 5 (AAL5). There is no guarantee that the SIP-400 line card will find the IP packet inside the AAL5 envelope. Therefore, Don't Fragment (DF) bit reflection from inner IP to outer IP is not performed for traffic on ATM interfaces.

Session Cookie

A cookie check is supported for data packets. Cookies (remote and local) can be part of the decapsulation table indexed by session-id.

Scalability

Up to 8000 pseudowires and 512 tunnels are supported.

Set DF Bit in Outer IP

When the ip dfbit set command is configured for the pseudowire, the SIP-400 line card sets the DF bit in the outer IP header during L2TPv3 encapsulation. This DF bit handling is subject to IS-IS packet fragmentation.

Set TTL in Outer IP

When the ip ttl value command is configured for the pseudowire, the SIP-400 line card sets the TTL value in the outer IP header during L2TPv3 encapsulation. When the TTL value is not set, the TTL value in the outer IP header is set to 254.

Layer 2-Specific Sublayer Control Word

The Layer 2-specific sublayer control word is defined in L2TPv3 RFCs solely for the purpose of packet sequencing (with the exception of AAL5 payload). On Cisco 7200 series, Cisco 7500 series, and Cisco 12000 series routers, the control word is omitted when sequencing is disabled on non-ATM AAL5 pseudowires. To interoperate with Cisco 7200 series, Cisco 7500 series, and Cisco 12000 series routers, the SIP-400 line card does not support control words on all non-AAL5 pseudowire types in the initial release.

MTU Support

MTU processing is done on the ingress path on the SIP-400 line card. The SIP-400 line card enforces Layer 2 MRU checking for every Layer 2 frame received from the CE device. All frames that fail MRU checking are dropped, and the accepted frames are entered into the L2TPv3 encapsulation process. During the process, the whole L2TPV3 packets (including outer IP) are checked again using IP MTU. The packets that pass IP MTU checking are sent to Enhanced Address Recognition Logic (EARL) for IP routing. The failed packets are sent to RP for IP fragmentation or for drop accounting and notifying.

Path MTU discovery is enabled when the ip pmtu command is configured for the pseudowire. This feature requires an ingress Layer 2 frame to be dropped if, after L2TPv3 encapsulation, the total packet length exceeds L2TP tunnel path MTU, and the DF bit of the IP header inside the Layer 2 frame is 1. To support this feature, the SIP-400 line card performs tunnel path MTU checking on each ingress Layer 2 frame during L2TPv3 encapsulation phase. If the total packet length after encapsulation exceeds path MTU, the SIP-400 line card forwards the original Layer 2 frame to the route processor. On receiving the Layer 2 frame, the route processor may send an Internet Control Message Protocol (ICMP) unreachable message to the source of the IP packet, depending on how deep the IP packet is embedded in the Layer 2 frame.

L2TPv3 IP packet fragmentation and reassembly is done by software on the route processor. The SIP-400 line card performs core-facing interface IP MTU checking on all packets encapsulated in L2TPv3. If the MTU checking fails, the original Layer 2 frames are sent to the route processor for IP fragmentation. Fragmented L2TPV3 IP packets received from the IP core are received by the route processor from the core facing interface by EARL. The route processor handles L2TPv3 packet reassembly and recovers the inner Layer 2 frame. The route processor also sends the Layer 2 frame to the CE-facing interface by using index-directed WAN dbus frames.

With IS-IS packet fragmentation, IS-IS packets are often padded to the maximum MTU size. L2TPv3 encapsulation increases the packet size by 28 to 36 bytes. A Layer 2 frame with an IS-IS packet embedded may exceed the tunnel path MTU after L2TPV3 encapsulation. Therefore, Layer 3 fragmentation is often needed. To support fragmentation, the SIP-400 line card searches for IS-IS packets in a Layer 2 Frame. If an IS-IS packet is found during L2TPv3 encapsulation, the SIP-400 line card clears the DF bit in the outer IP and sets IP precedence to 6. This allows the IP packet to be fragmented when traveling through the IP core.

Ethernet Attachment Circuits

The SIP-400 line card supports Ethernet over L2TPv3 in compliance with RFC4719. Two types of pseudowire are supported: Ethernet VLAN pseudowire type (0x0004) and Ethernet pseudowire type (0x0005). When xconnect is configured on an Ethernet main interface, Ethernet frames are tunneled over L2TPv3 using Ethernet port pseudowires (type 0x0005). In this mode, Ethernet frames received on the port (tagged or untagged) are delivered to the remote CE device unaltered.

When xconnect is configured on a dot1q subinterface, the tagged Ethernet frames are tunneled using an Ethernet VLAN pseudowire (type 0x0004). In this case, the pseudowire connects one Ethernet VLAN to another Ethernet VLAN. Received Ethernet VLAN frames from the CE device are tunneled over L2TPv3 unchanged. When arriving on the destination PE device, the original VLAN tag is written to use the destination VLAN ID. While doing so, the priority field in the VLAN tag is preserved.

Ethernet OAM Support

The SIP-400 line card supports service-level OAM and link-level OAM features on Ethernet interfaces.

Service-level OAM packets, also known as Connectivity Fault Management (CFM) packets, are sent using SNAP header with type 0x0126. Link-level OAM packets, also known as Link Monitoring (LM) packets are sent on Ether-Type 0x8809.

The SIP-400 line card monitors the above two types of ingress OAM frames from the CE device. When the OAM frames are found and OAM features are configured on the Ethernet interface, the OAM frames are intercepted and forwarded to the route processor. If there is no Ethernet OAM configuration, all OAM frames are tunneled in L2TPv3 as normal data frames.

ATM Attachment Circuits

The SIP-400 line card supports ATM over L2TPv3 in compliance with RFC 4454 with minor deviation. RFC 4454 defines four types of ATM pseudowire:

• ATM AAL5 SDU VCC transport (0x0002)
• ATM cell transport port mode (0x0003)
• ATM cell transport VCC mode (0x0009)
• ATM cell transport VPC mode (0x000A)

ATM cell transport port mode is not supported.

When xconnect is configured on a PVC with encapsulation AAL5, ATM AAL5 pseudowire (0x0002) is used to tunnel AAL5 frames between PE devices. The SIP-400 line card supports Layer 2 sublayer-specific control words for AAL5 pseudowire. This is the only type of pseudowire allowed to carry control words.

When xconnect is configured on PVC in AAL0 mode, an ATM cell transport VCC pseudowire (type 0x0009) is used. When xconnect is configured on PVP in AAL0 mode, an ATM cell transport VPC pseudowire (type 0x000A) is used. In both types of pseudowire, each L2TPv3 packet carries one ATM cell. Cell packing is not supported.

ATM OAM Cells

The SIP-400 line card supports ATM OAM cells operating at VP and VC levels. F4 cells operate at the VP level. They use the same VPI as the user data cells. However, they use two different reserved VCIs, as follows:

• VCI = 3 Segment OAM F4 cells
• VCI = 4 End-to-end OAM F4 cells

OAM F5 cells operate at the VC level. They use the same VPI and VCI as the user cells. To distinguish between data and OAM cells, the PTI field is used as follows:

• PTI = 100 (4) Segment OAM F5 cells processed by the next segment
• PTI =101 (5) End-to-end OAM F5 cells which are only processed by end stations terminating an ATM link

In the ingress direction (CE to PE), because of OAM emulation not supported in the 12.2(33)SRC release, all OAM cells are handled the same as data cells on the SIP-400 line card. Both segment and end-to-end OAM F4/F5 cells are tunneled over L2TPv3 to the remote PE device. They are sent transparently across the IP core in L2TPv3 tunnels.

In the egress direction (PE to CE), the SIP-400 line card sends all OAM cells to the CE device similar to sending ATM data cells.

Loopback Interface Reservation

You must reserve a loopback interface used as a source of the L2TPv3 tunnel for a particular line card to prevent it from being used across multiple line cards. These loopback interfaces host the local IP addresses used by the L2TP tunnels. A minimum of one such IP address is needed for every CE-facing line card. In most cases, you must create multiple loopback interfaces to accommodate routing protocol configuration and L2TPv3 configuration. Also, you must explicitly use the mpls ldp router-id command to avoid LDP router ID changes after system reload.

To reserve a loopback interface, use the mls reserve l2tpv3 slot slot-number [processor processor-number] command on the route processor in interface configuration mode.

This command binds the loopback interface to the specified slot/NP. Once configured, the loopback cannot be used to configure L2TPv3 tunnels on other LC/NPs. You must create another loopback interface in order to configure an L2TPv3 pseudowire on an interface that resides on another LC/NP.

QoS

QoS is handled on the line card. EARL does not perform QoS operations on L2TPv3 packets.

QoS at L2TPv3 Tunnel Ingress

The SIP-400 line card applies QoS to ingress traffic before doing L2TPv3 encapsulation. Given the order of traffic processing, the SIP-400 line card can support full-fledged interface/PVC level MQC on Layer 2 traffic. QoS on IP tunnel traffic is limited to ToS marking only.

The supported QoS-on-ingress Layer 2 frames are as follows.

• Classification. Ethernet interfaces: match on vlan, cos, ip dscp, ip precedence. ATM interfaces: match on atm clp
• Marking:
  • Ethernet interfaces: set cos
  • ATM interfaces: none
• Policing on both Ethernet and ATM interfaces
• Queuing on Ethernet interfaces

QoS at L2TPv3 Tunnel Egress

With egress traffic flow on the SIP-400 line card, QoS is again applied to Layer 2 traffic after L2TPv3 de-encapsulation. While the SIP-400 line card can support full-fledged Layer 2 MQC at the interface/PVC level, no QoS can be done on the IP tunnel traffic.

The supported QoS-on-egress Layer 2 frames are as follows.

• Classification:
  • Ethernet interfaces: match on vlan, cos, ip dscp, ip precedence
  • ATM interfaces: none
• Marking:
  • Ethernet interfaces: set cos, ip dscp, ip precedence
  • ATM interfaces: set atm clp
• Policing on both Ethernet and ATM interfaces
• Queuing on both Ethernet and ATM interfaces

L2TPv3 Packet ToS Marking

L2TPv3 packet ToS marking is done on the SIP-400 ingress path. There are three ways of marking the ToS field:

• Configure the ip tos value value command on each pseudowire to set the ToS field
• Configure the ip tos reflect command on each pseudowire to allow the inner IP ToS copied to the outer IP ToS
• By default, Layer 2 QoS is automatically reflected to outer IP ToS. For example, if the Layer 2 frame is an 802.Q frame, the 3-bit priority field in the VLAN tag is copied to the precedence bits in the outer IP ToS field

When the ip tos reflect command is configured, the SIP-400 line card searches for an IP header inside each received Layer 2 frame. If an IP packet is found, its ToS is copied to the outer ToS. Otherwise, the ToS value in the L2TPv3 IP header is set 0.

When neither the ip tos value command nor the ip tos reflect command is configured, the SIP-400 line card searches for a VLAN tag in each Ethernet frame. If a tag is found, the inner Layer 2 QoS is reflected to the outer IP ToS. Otherwise, the L2TPv3 IP ToS field is set 0.

• Variable cookie size and L2TPv3 sequencing are not supported.
• Starting in Cisco IOS Release 12.0(32)SY, the L2TPv3 Layer 2 Fragmentation feature is supported on the Cisco 10720 Internet router to enable the fragmentation of IP packets to occur before data enters the pseudowire. When you enable this feature in an L2TPv3 pseudowire configuration using the ip pmtu command, the Don't Fragment (DF) bit in the outer Layer 2 packet header is automatically set on so that (for performance reasons) tunneled packets are not reassembled on the decapsulation router.
• The Cisco 10720 Internet router supports the reassembly only of fragmented IS-IS packets in an L2TPv3 pseudowire. IS-IS packet reassembly is performed by the Route Processor (RP) at the process level, not in the Parallel eXpress Forwarding (PXF) forwarding path.
• On the Cisco 10720 Internet router, the uti translation command is not migrated for xconnect service and is not supported. Although the uti command is supported in L2TPv3 releases, the translation option is lost in the migration.
• On the Cisco 10720 Internet router, although it is not required, we highly recommend that you configure a loopback interface as the IP local interface.

You can also configure a LAN interface as the IP local interface so that the tunnel control session is tied to an operational LAN (Gigabit Ethernet or Fast Ethernet) interface or subinterface. However, in this case, the tunnel control plane is used only as long as the Gigabit Ethernet or Fast Ethernet interface is operational.

Tunnel Server Card Versus Native L2TPv3 Implementation

On the Cisco 12000 series Internet router, L2TPv3 is implemented in two different ways:

• The 1-port OC-48c/STM-16c POS/SDH line card is required as the dedicated tunnel server card (TSC) to accelerate the encapsulation and decapsulation of Layer 2 data on engine 2 (and earlier engine types) line cards in an L2TPv3 tunnel session.
• The enhanced edge capabilities of IP services engine (ISE) and engine 5 line cards do not require a tunnel server card for Layer 2 data encapsulation and decapsulation in an L2TPv3 tunnel. This is called a native L2TPv3 session.

Note	Native L2TPv3 tunnel sessions on customer-facing ISE and Engine 5 line cards can coexist with tunnel sessions that use a tunnel server card.

Different combinations of engine types are supported as customer-facing and backbone-facing line cards for encapsulation and decapsulation in L2TPv3 tunneling.

Note

If you have native cards (engine 3 and engine 5) in the PE routers and the Tunnel Server Card is configured to support the non-native cards, then you must remove the TSC configuration by using the no hw-module slot<number> mode server command. If the TSC configuration exists in the PE router and the TSC card is removed, all the tunnels will fail.

L2TPv3 Encapsulation

When a Layer 2 packet arrives on a customer-facing interface, if the interface is bound to an L2TPv3 tunnel, L2TPv3 encapsulation is supported as follows:

• If the customer-facing line card is engine 2 or an earlier engine type, the line card forwards the packet to the tunnel server card, which performs L2TPv3 encapsulation.
• If the customer-facing line card is ISE or engine 5, the line card performs L2TPv3 encapsulation.

A backbone-facing line card of any engine type sends the packet across the service provider backbone network.

L2TPv3 Decapsulation

When an L2TPv3 packet arrives on a backbone-facing interface, L2TPv3 decapsulation is supported as follows:

• If the backbone-facing line card is non-ISE/E5 (any engine type besides ISE and Engine 5), the line card forwards the packet to the tunnel server card. The tunnel server card determines if the packet is bound to an Engine 2 (or earlier engine) or an ISE/E5 customer-facing line card.
  • If the packet is bound to an Engine 2 (or earlier engine) customer-facing line card, the TSC completes packet decapsulation and sends the Layer 2 packet to the customer-facing interface.
  • If the packet is bound to an ISE/E5 customer-facing line card, the TSC sends the packet to the line card for further decapsulation.
• If the backbone-facing line card is ISE/E5, the line card determines if the packet is bound to an Engine 2 (or earlier engine) or an ISE/E5 customer-facing line card.
  • If the packet is bound to an Engine 2 (or earlier engine) customer-facing line card, the packet is sent to the tunnel server card for further decapsulation. Afterward, the decapsulated Layer 2 packet is sent to the Engine 2 (or earlier engine) customer-facing interface.
  • If the packet is bound to an ISE/E5 customer-facing line card, the packet is sent to the ISE/E5 line card for decapsulation.

Note

If no tunnel server card is installed, L2TPv3 decapsulation is not supported in the following conditions: - The customer-facing line card is Engine 2 or an earlier engine line card. - The customer-facing line card is ISE/E5 and the backbone-facing line card is non-ISE/5. In these cases, packets received on the backbone-facing interface are dropped. The following warning message is logged: L2TPv3 decapsulation packet dropped.

Cisco 12000 Series Line Cards--General Restrictions

• IS-IS protocol packet fragmentation is supported only for dynamic L2TPv3 sessions.
• Hairpinning is not supported for local-to-local switching. The start and end of an L2TPv3 session must terminate on different routers linked by an IP or MPLS backbone.
• The L2TPv3 feature set is supported as follows. If a tunnel server card is:
  • Installed, and only Engine 2 or older customer-facing line cards are used, normal L2TPv3 tunnel sessions are supported with the L2TPv3 feature set described in L2TPv3 Features.
  • Is not installed and ISE/E5 backbone-facing and ISE/E5 customer-facing line cards are used, native L2TPv3 tunnel sessions are supported with the native L2TPv3 feature set described in GUID-A16A6A13-AA82-412C-936E-3EB898920C616.
  • Installed and a combination of Engine 2 or older and ISE/E5 line cards is used as customer-facing line cards, a mixed L2TPv3 tunnel session is supported with the native L2TPv3 feature set described in GUID-A16A6A13-AA82-412C-936E-3EB898920C616.
  • Installed and a ISE/E5 customer-facing and Engine 2 or older backbone-facing line cards are used, a mixed L2TPv3 tunnel session is supported with the native L2TPv3 feature set described in Cisco 12000 Series-Specific Restrictions and Cisco 12000 Series-Specific Restrictions.
• Engine 4 and Engine 4 Plus (E4+) line cards are not supported as the customer-facing line cards in an L2TPv3 tunnel session. However, Engine 4 and Engine 4+ line cards may be used to provide other services in a Layer 2 VPN.
• In a native L2TPv3 tunnel session configured on ISE/E5 interfaces, 802.1q (VLAN) is supported as an L2TPv3 payload starting in Cisco IOS Release 12.0(31)S.

Engine 2 and Earlier Engine-Specific Restrictions

• A dedicated 1-port OC-48c/STM-16c POS/SDH tunnel server card is required for L2TPv3 to function. The server card does not run Engine 2 features.
• TSC-based L2TPv3 tunnel sessions are supported only if a tunnel server card is configured.

To configure the server card, you must enter the ip unnumberedcommand and configure the IP address on the PoS interface of the server card before you configure hardware modules. Then enter the hw-module slot slot-number mode server command.

This initial 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 is automatically set to loopback internal and no keepalives when the hw-module slot slot-number mode server command is configured.

Note	Starting in Cisco IOS Release 12.0(30)S, you must first remove all L2TPv3 xconnect attachment circuits on all Engine-2 or earlier engine customer-facing line cards before you enter the no hw-module slot slot-number mode server command to unconfigure a tunnel server card.

• On the tunnel server card:
  • The IP local interface must be a local loopback interface. Configuring any other interface as the IP local interface results in nonoperational 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.
  • The maximum performance of 2.5 million packets per second (pps) 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 asiccommand, where slot-number is the slot number of the server card.
• Cover the optics of the tunnel server card because of possible interference or noise causing cyclic redundancy check (CRC) errors on the line card. These errors are caused by a framer problem in the line card.
• The aggregate performance is bound by the server card limit of 2.5 million pps.
• Because of a framer problem, the server card interfaces accounting in (packets out) are not accurate.
• Only features found in the Vanilla uCode bundle are supported on Engine 2 line cards that are associated with an L2TPv3 session and on a different interface, DLCI, or VLAN of the same line card.
• When you configure an Engine 2 feature, which is not in the Vanilla uCode bundle on an Engine 2 line card, on an interface bound to an L2TPv3 tunnel session, the Vanilla uCode is swapped out. As a result, all traffic through the L2TPv3 session stops on the Engine 2 line card. In this case, you must restore the Vanilla uCode bundle on the line card, and rebind the attachment circuit to the L2TPv3 session as described in the GUID-80F9B081-EE01-4453-9E45-E58C2B650351.
• Configuring output Access Control Lists (ACLs) on any line card swaps out the running Engine 2 line card Vanilla uCode bundle in favor of the ACL uCode bundle. This configuration causes all traffic through the L2TPv3 session to stop on those Engine 2 line cards. If output ACLs are essential on the router, we advise you to originate all L2TPv3 sessions on Engine 0 line cards. Output ACLs do not swap out the server card uCode bundle because of 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 permanent virtual circuit (PVC) counters are not updated.
• If the 8-port Fast Ethernet (Engine 1) line card is connected to a hub or switch when L2TPv3 is configured on the ingress side of one or more of its ports, duplicate pckets are generated, causing the router to be flooded with packets. This restriction results from the requirement that CAM filtering is disabled when L2TPv3 is used.
• On the 3-port Gigabyte Ethernet (Engine 2) line card, performance degradation can occur if IP packets coming from a port are sent to the slow path for forwarding. This performance degradation occurs 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.

Edge Line Card-Specific Restrictions

The following restrictions apply to L2TPv3 sessions configured on IP Services Engine (ISE) and Engine 5 edge line cards:

• Native L2TPv3 sessions are supported only if the feature mode is configured on a customer-facing ISE/E5 line card.

To configure the feature mode, enter the hw-module slot slot-number np mode feature command. You cannot unconfigure the feature mode on a customer-facing ISE/E5 line card until all L2TPv3 xconnect attachment circuits on the line card are removed.

A backbone-facing ISE/E5 line card can operate in any mode and no special feature mode configuration is required.

• Starting in Cisco IOS Release 12.0(31)S, 802.1q (VLAN) is supported as an L2TPv3 payload in a native L2TPv3 tunnel session configured on ISE/E5 interfaces.
• Native L2TPv3 tunnel sessions on customer-facing ISE/E5 line cards can coexist with tunnel sessions that use a tunnel server card.
• L2TPv3 encapsulation on a customer-facing ISE/E5 line card does not support the L2TPv3 Layer 2 Fragmentation feature.

This means that if you enter the ip pmtu command to enable the discovery of a path maximum transmission unit (PMTU) for L2TPv3 traffic, and a customer IP packet exceeds the PMTU, IP fragmentation is not performed on the IP packet before L2TPv3 encapsulation. These packets are dropped. For more information, see the L2TPv3 Layer 2 Fragmentation.

The first two tables below show the ISE and E5 interfaces that are supported in a native L2TPv3 tunnel on:

• Customer-facing line cards (ingress encapsulation and egress decapsulation)
• Backbone-facing line cards (ingress decapsulation and egress encapsulation)

The table below describes the L2TPv3 features supported in a native L2TPv3 tunnel session and the customer-facing ISE/E5 line cards that support each feature. Note that although native L2TPv3 sessions do not support L2TPv3 Layer 2 (IP packet) fragmentation and slow-path switching features, ATM (as a transport type) and QoS features (traffic policing and shaping) across all media types are supported.

• 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, 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.
• To use DCE or a Network-to-Network Interface (NNI) on a Frame Relay port, you must configure the frame-relay switching command.
• The configuration of an L2TPv3 session on a Multilink Frame Relay (MLFR) bundle interface is supported only on Cisco 12000 series 2-port channelized OC-3/STM-1 (DS1/E1) and 6-port Channelized T3 (T1) line cards. (For more information, see Binding L2TPv3 Sessions to Multilink Frame Relay Interfaces.)
• 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 support is for 10-bit DLCI addresses. Frame Relay Extended Addressing is not supported.
• Multipoint DLCI is not supported.
• The keepalive is automatically disabled on interfaces that have an xconnect applied to them, except for Frame Relay encapsulation, which is a requirement for LMI.
• Static L2TPv3 sessions do not support Frame Relay LMI interworking.

• A PE router is responsible only for static VLAN membership entries that are configured manually on the router. Dynamic VLAN membership entries, entry aging, and membership discovery are not supported.
• Implicit tagging for VLAN memberships operating on other layers, such as membership by MAC address, protocol type at Layer 2, or membership by IP subnet at Layer 3, is not supported.
• 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.

• The ATM VP Mode Single Cell Relay over L2TPv3 feature is supported only on the Cisco 7200 and Cisco 7500 series routers with ATM Deluxe PA-A3 interfaces.
• After the ATM VP Mode Single Cell Relay feature is configured for a virtual path connection (VPC), no other permanent virtual circuits (PVCs) are allowed for the same virtual path identifier (VPI).

• The ATM AAL5 OAM Emulation over L2TPv3 feature and the ATM Single Cell Relay VC Mode over L2TPv3 feature are supported only on the Cisco 7200, Cisco 7301, Cisco 7304 NSE-100, Cisco 7304 NPE-G100, and Cisco 7500 series routers with ATM Deluxe PA-A3 interfaces.
• Sequencing is supported only for ATM adaptation layer 5 (AAL5) service data unit (SDU) frames or ATM cell relay packets. Sequencing of Operation, Administration, and Maintenance (OAM) cells is not supported.
• Sequencing is supported in CEF mode. If sequencing is enabled with dCEF, all L2TP packets that require sequence number processing are sent to the RSP module.
• L2TPv3 manual mode configuration does not support ATM alarm signaling over the pseudowire.
• The Cisco 7200 series and the Cisco 7500 series ATM driver cannot forward Resource Management (RM) OAM cells over the packet-switched network (PSN) for available bit rate (ABR) ToS. The RM cells are locally terminated.

• Port mode and virtual path (VP) or VC mode cell relay are mutually exclusive. After the ATM interface is configured for cell relay, no permanent virtual path (PVP) or PVC commands are allowed on that interface.
• ATM port mode cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC-3 ATM port adapters.
• ATM port mode cell relay is not supported on the PA-A3-8T1IMA and PA-A3-8E1IMA port adapters.

• The ATM Cell Packing over L2TPv3 feature is supported only on PA-A3 ATM interfaces on Cisco 7200 and Cisco 7500 routers. Cell packing cannot be configured on other platforms or interface cards.
• A minimum of 2 and a maximum of 28 ATM cells can be packed into an L2TPv3 data packet.

• IPv6 protocol demultiplexing is supported only for Ethernet and terminated DLCI Frame Relay interfaces, PPP traffic, and HDLC traffic.
• IPv6 protocol demultiplexing is supported over noninterworking sessions.
• Frame Relay demultiplexing is supported for point-to-point or multipoint.
• FRF.12 end-to-end fragmentation is supported on the Cisco 7500 and Cisco 12000 series routers only between the CE and PE routers.
• FRF.9 hardware payload compression is supported on the Cisco 7200 series and Cisco 7500 series routers only between the CE and PE routers.
• FRF.9 software payload compression is supported on the Cisco 7500 series routers only between the CE and PE routers.
• FRF.9 process switched payload compression is not supported.
• IETF encapsulation must be used with FRF.9.
• FRF.16 is supported only between the CE and PE routers.
• HDLC restrictions for protocol demultiplexing:
  • IP must be enabled on the interface if you want to configure protocol demultiplexing using the xconnect command.
  • IPv6 cannot be enabled on the interface at the same time as the xconnect command (with or without protocol demultiplexing).
  • Payload compression is not supported.
• Cisco 12000 series router restrictions for protocol demultiplexing:
  • If a Cisco 12000 series router is acting as the PE with IPv6 protocol demultiplexing using PPP, the remote PE must also be a Cisco 12000 series router.
  • IPv6 protocol demultiplexing for Ethernet encapsulation on Engine-5 line cards is only supported with Version-2 Ethernet SPAs. It is not supported with Version-1 Ethernet SPAs.
  • IPv6 protocol demultiplexing is not supported on the SIP-400 Engine-3 line card.
• IPv6 protocol demultiplexing with PPP encapsulation must be configured in the following order to ensure a working tunnel session:
• Configure the IP address on the interface.
• Enter the encapsulation PPP command.
• Enter the PPP ipv6cp id proxy ipv6-address command.
• Enter the xconnect command with the match protocol ipv6 command.

If this configuration order is not followed, the tunnel session cannot operate until you issue a shut/no shut command on the protocol demultiplexing interface or do an OIR.

• L2TPv3 control channel authentication configured using the digest command requires bidirectional configuration on the peer routers. A shared secret must be configured on the communicating nodes.
• For a compatibility matrix of all the L2TPv3 authentication methods, see the Valid Configuration Scenarios table in the IPv6 Protocol Demultiplexing section.

• 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.
• In Cisco IOS Release 12.0(30)S, a maximum of two passwords can be configured simultaneously using the digest secret command.

For more information about the L2TPv3 Control Message Hashing feature, see the L2TPv3 Control Message Hashingsection.

Quality of service (QoS) policies configured with the modular QoS CLI (MQC) are supported in L2TPv3 tunnel sessions with the following restrictions:

Frame Relay Interface (Non-ISE/E5)

• On the Cisco 7500 series with distributed CEF (dCEF), in a QoS policy applied to a Frame Relay interface configured for L2TPv3, only the MQC commands match fr-dlci in class-map configuration mode and bandwidth in policy-map configuration mode are supported. (See the Configuring QoS for L2TPv3 on the Cisco 7500 Series Example task.)
• On the Cisco 12000 series, a QoS policy is supported in TSC-based L2TPv3 tunnel sessions on the Frame Relay interfaces of a 2-port channelized OC-3/STM-1 (DS1/E1) or 6-port channelized T3 (T1) line card with the following restrictions:
  • The police command is supported as follows:
    • Only the transmit option for the action keyword is supported with the conform-action command.
    • Only the set-frde-transmit option for the action keyword is supported with the exceed-action command.
    • Only the drop option for the action keyword is supported with the violate-action command.
    • Backward explicit congestion notification (BECN) and forward explicit congestion notification (FECN) configuration are not supported.
    • The type of service (ToS) byte must be configured in IP headers of tunneled Frame Relay packets when you configure the L2TPv3 pseudowire (see GUID-48F43492-0A1E-44FD-8485-E82C3194E89D).
    • All standard restrictions for configuring QoS on Cisco 12000 series line cards apply to configuring QoS for L2TPv3 on Cisco 12000 series 2-port Channelized OC-3/STM-1 (DS1/E1) or 6-port Channelized T3 line cards.
  • On the ingress side of a Cisco 12000 series Frame Relay interface configured for TSC-based L2TPv3 tunneling:
    • Weighted random early detection (WRED) and modified deficit round robin (MDRR) configurations are not supported.
  • On the egress side of a Cisco 12000 series Frame Relay interface configured for TSC-based L2TPv3 tunneling:
    • MDRR is the only queueing strategy supported.
    • WRED is the only packet drop strategy supported.
    • MDRR is supported only in the following modes:
      • With both a low latency (priority) queue and class-default queue configured. (The low latency queue is supported only in combination with the class-default queue, and cannot be configured with normal distributed round robin (DRR) queues.)
      • Without a low latency queue configured. (In this case, only six queues are supported, including the class-default queue.)
    • Egress queueing is determined according to the IP precedence values configured for classes of L2TPv3 Frame Relay traffic using the match ip precedence command, instead of on a per-DLCI basis.

For an example, see Configuring QoS on a Frame Relay Interface in a TSC-Based L2TPv3 Tunnel Session.

Edge Engine (ISE/E5) Interface

On the Cisco 12000 series, a QoS policy is supported in native L2TPv3 tunnel sessions on ISE/E5 interfaces (see Quality of Service Restrictions in L2TPv3 Tunneling and Quality of Service Restrictions in L2TPv3 Tunneling for a list of supported line cards) with the following restrictions:

• On a Frame Relay or ATM ISE/E5 interface, traffic policing supports only the following conform, exceed, and violate values for the actionargument of the police command:

conform-action actions set-prec-tunnel set-dscp-tunnel transmit

exceed-action actions drop set-clp (ATM only)set-dscp-tunnel set-dscp-tunnel and set-clp(ATM only)set-dscp-tunnel and set-frde(Frame Relay only)set-frde(Frame Relay only)set-prec-tunnel set-prec-tunnel and set-clp(ATM only)set-prec-tunnel and set-frde(Frame Relay only)transmit

violate-action actions drop

• On a Frame Relay ISE/E5 interface:
  • FECN and BECN configuration are not supported.
  • Marking the Frame Relay discard eligible (DE) bit using a MQC set command is not supported. To set (mark) the DE bit, use the police exceed-action actions command in policy-map configuration mode.
  • Configuring Tofab MDRR or WRED using legacy QoS (not MQC) commands is supported and is based on the tunnel precedence value.
  • Egress queueing on a Packet-over-SONET ISE/E5 interface is class-based when configured using MQC.
  • Egress queueing on a per-DLCI basis is not supported.
• On an ATM ISE/E5 interface:
  • Traffic shaping is supported on ATM egress interfaces for the following service categories:
• Lowest priority: UBR (unspecified bit rate) Second priority: VBR-nrt (variable bit rate nonreal-time) Highest priority: VBR-rt (VBR real time) Highest priority: CBR (constant bit rate)
• Note that VBR-rt and CBR share the same high-priority shaping. ATM traffic shaping restricts traffic to the maximum rate configured on an ATM VC or PVP with due priority among the respective service categories.
• You can configure queue limits for an ATM VC or PVP. The queue limits are dual thresholds in which two different thresholds can be configured for CLP=1 cells and CLP0+1 cells. The CLP1 threshold must be lower than the queue limit threshold so that CLP=1 cells are dropped earlier than CLP=0 cells when packets start to fill the queue.
  • Although the dual-rate, 3-Color Marker policer is not supported on ATM ISE/E5 interfaces (as on Frame Relay ISE/E5 interfaces), the ATM Forum Traffic Management Version 4.1-compliant Generic Cell Rate Algorithm (GCRA) policer is supported. The GCRA policer uses rate, peak rate, delay tolerance, and ATM maximum burst size, and supports the following actions:

set-dscp-tunnel set-dscp-tunnel and set-clp-transmit set-prec-tunnel set-prec-tunnel and set-clp-transmit

Protocol Demultiplexing Interface

Protocol demultiplexing requires a combination of an IP address and the xconnect command configured on the interface. The interface is then treated as a regular L3. To apply QoS on the Layer 2 IPv6 traffic, you must classify the IPv6 traffic into a separate class before applying any feature(s) to it.

The following match criterion is used to classify Layer 2 IPv6 traffic on a protocol demultiplexing interface:

class-map match-ipv6
     match protocol ipv6

In the absence of a class to handle Layer 2 IPv6 traffic, the service policy is not accepted on a protocol demultiplexing interface.

For detailed information about QoS configuration tasks and command syntax, refer to:

• Cisco IOS Quality of Service Solutions Configuration Guide
• Cisco IOS Quality of Service Solutions Command Reference

UTI is a Cisco proprietary protocol that offers a simple high-speed transparent Layer 2-to-Layer 2 service over an IP backbone. The UTI protocol lacks the signaling capability and standards support necessary for large-scale commercial service. To begin to answer the need for a standard way to provide large-scale VPN connectivity over an IP core network, limited migration from UTI to L2TPv3 was introduced in Cisco IOS Release 12.0(21)S. The L2TPv3 feature in Cisco IOS Release 12.0(23)S introduced a more robust version of L2TPv3 to replace UTI.

As described in the section "L2TPv3 Header Description," the UTI data header is identical to the L2TPv3 header but with no sequence numbers and an 8-byte cookie. By manually configuring an L2TPv3 session using an 8-byte cookie (see the section "GUID-F16385E9-3369-4438-8317-DF071EC4FA2E") and by setting the IP protocol number of outgoing data packets to 120 (as described in the section "GUID-48F43492-0A1E-44FD-8485-E82C3194E89D"), you can ensure that a PE running L2TPv3 may interoperate with a peer PE running UTI. However, because UTI does not define a signaling plane, dynamically established L2TPv3 sessions cannot interoperate with UTI.

When a customer upgrades from a pre-L2TPv3 Cisco IOS release to a post-L2TPv3 release, an internal UTI-to-xconnect command-line interface (CLI) migration utility will automatically convert the UTI commands to xconnect and pseudowire class configuration commands without the need for any user intervention. After the CLI migration, the UTI commands that were replaced will not be available. The old-style UTI CLI is 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 to preserve the functionality provided by the UTI keepalive.

L2TPv3 provides similar and enhanced services to replace the current UTI implementation, including the following features:

• Xconnect for Layer 2 tunneling through a pseudowire over an IP network
• Layer 2 VPNs for PE-to-PE router service using xconnect that supports Ethernet, 802.1q (VLAN), Frame Relay, HDLC, and PPP Layer 2 circuits, including both static (UTI-like) and dynamic (using the new L2TPv3 signaling) forwarded sessions

The initial Cisco IOS Release 12.0(23)S features supported only the following features:

• 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 Frame Relay

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 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--Example

In the figure above, 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 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 L2TPv3 operation:

• All packets received on interface int1 are 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 are encapsulated directly in IP and sent through the pseudowire session tu2 to R2 interface e2, where it is sent on LAN2.
• A VLAN on an Ethernet interface can be mapped to an L2TPv3 session.

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 the figure below.

Figure 2

L2TPv3 Header Format

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 through the CLI. See the section "How to Configure L2TPv3" for more information on the CLI commands for L2TPv3.

• Session ID
  
• Session Cookie
  
• Pseudowire Control Encapsulation
  

L2TPv3 provides xconnect support for Ethernet, 802.1q (VLAN), Frame Relay, HDLC, and PPP.

• Control Channel Parameters
  
• L2TPv3 Control Channel Authentication Parameters
  
• Static L2TPv3 Sessions
  
• Dynamic L2TPv3 Sessions
  
• Sequencing
  
• Local Switching
  
• Distributed Switching
  
• L2TPv3 Layer 2 Fragmentation
  
• L2TPv3 Type of Service Marking
  
• Keepalive
  
• MTU Handling
  
• L2TPv3 Control Message Hashing
  
• L2TPv3 Control Message Rate Limiting
  
• L2TPv3 Digest Secret Graceful Switchover
  
• L2TPv3 Pseudowire
  
• Manual Clearing of L2TPv3 Tunnels
  
• L2TPv3 Tunnel Management
  
• L2TPv3 Protocol Demultiplexing
  
• Color Aware Policer on Ethernet over L2TPv3
  
• Site of Origin for Border Gateway Protocol VPNs
  
• L2TPv3 Custom Ethertype for Dot1q and QinQ Encapsulations
  

The table below compares L2TPv3 and UTI feature support for the Cisco 7200 and Cisco 7500 series routers.

• Frame Relay
  
• Ethernet
  
• VLAN
  
• HDLC
  
• PPP
  
• ATM
  
• IPv6 Protocol Demultiplexing
  

The following port adapters support L2TPv3 on the Cisco 7200 series and Cisco 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
• Single-port enhanced OC-3 ATM port adapter
• 8-port multichannel E1 G.703/G.704 120-ohm interfaces
• 2-port multichannel E1 G.703/G.704 120-ohm interfaces
• 8-port multichannel T1 with integrated data service units (DSUs)
• 8-port multichannel T1 with integrated channel service units (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 Packet over SONET (PoS), single-mode, long reach
• Single-port PoS, single-mode, intermediate reach
• Single-port PoS, multimode
• Eight-port T1 ATM port adapter with inverse multiplexing over ATM (IMA)
• Eight-port E1 ATM port adapter with IMA

The following port adapters support L2TPv3 on the Cisco 7200 series routers only:

• 8-port Ethernet adapter
• 4-port Ethernet adapter

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
  
• Configuring L2TPv3 Control Channel Authentication Parameters
  
• Configuring L2TP Control Channel Maintenance Parameters
  

1.    enable

2.    configure terminal

3.    pseudowire-class [pw-class-name]

4.    encapsulation l2tpv3

5.    protocol {l2tpv3 | none}[l2tp-class-name]

6.    ip local interface interface-name

7.    ip pmtu

8.    ip tos {value value | reflect}

9.    ip dfbit set

10.    ip ttl value

11.    ip protocol {l2tp | protocol-number}

12.    sequencing {transmit | receive | both}

13.    exit

1.    enable

2.    configure terminal

3.    interface type slot / port

4.    xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]

5.    exit

1.    enable

2.    configure terminal

3.    interface type slot / port

4.    xconnect peer-ip-address vc-id encapsulation l2tpv3 manual pw-class pw-class-name

5.    l2tp id local-session-id remote-session-id

6.    l2tp cookie local size low-value [high-value]

7.    l2tp cookie remote size low-value [high-value]

8.    l2tp hello l2tp-class-name

9.    exit

10.    exit

1.    enable

2.    configure terminal

3.    interface type slot / port

4.    atm pvp vpi [l2transport]

5.    xconnect peer-ip-address vcid pw-class pw-class-name

1.    enable

2.    configure terminal

3.    interface type slot / port

4.    pvc [name] vpi / vci l2transport

5.    encapsulation aal0

6.    xconnect peer-ip-address vcid pw-class pw-class-name

1.    enable

2.    configure terminal

3.    interface type slot / port

4.    xconnect peer-ip-address vcid pw-class pw-class-name

The ATM Cell Packing over L2TPv3 feature allows multiple ATM frames to be packed into a single L2TPv3 data packet. ATM cell packing can be configured for Port mode, VP mode, and VC mode. Perform one of the following tasks to configure the ATM Cell Packing over L2TPv3 feature:

• Configuring Port Mode ATM Cell Packing over L2TPv3
  
• Configuring VP Mode ATM Cell Packing over L2TPv3
  
• Configuring VC Mode ATM Cell Packing over L2TPv3
  

The ATM AAL5 SDU Mode feature maps the AAL5 payload of an AAL5 PVC to a single L2TPv3 session. This service will transport OAM and RM cells, but does not attempt to maintain the relative order of these cells with respect to the cells that comprise the AAL5 CPCS-PDU. OAM cells that arrive during the reassembly of a single AAL5 CPCS-PDU are sent immediately over the pseudowire, followed by the AAL5 SDU payload.

Beginning in Cisco IOS Release 12.0(30)S, you may choose to configure the ATM AAL5 SDU Mode feature in ATM VC configuration mode or in VC class configuration mode.

To enable the ATM AAL5 SDU Mode feature, perform one of the following tasks:

• Configuring ATM AAL5 SDU Mode over L2TPv3 in ATM VC Configuration Mode
  
• Configuring ATM AAL5 SDU Mode over L2TPv3 in VC Class Configuration Mode