Layer 2 Tunnel Protocol Version 3
The Layer 2 Tunnel Protocol Version 3 feature expands on Cisco support of the Layer 2 Tunnel Protocol
Version 3 (L2TPv3). L2TPv3 is an Internet Engineering Task Force (IETF) l2tpext working group draft
that provides several enhancements to L2TP for the capability to tunnel any Layer 2 payload over L2TP.
Specifically, L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network
using Layer 2 virtual private networks (VPNs). Benefits of this feature include the following:
•
L2TPv3 simplifies deployment of VPNs
•
L2TPv3 does not require Multiprotocol Label Switching (MPLS)
•
L2TPv3 supports Layer 2 tunneling over IP for any payload
History for the Layer 2 Tunneling Protocol Version 3 Feature
Release
Modification
12.0(21)S
Initial data plane support for L2TPv3 was introduced on the Cisco 7200
series, Cisco 7500 series, Cisco 10720, and Cisco 12000 series platforms.
12.0(23)S
L2TPv3 control plane support was introduced on the Cisco 7200 series,
Cisco 7500 series, Cisco 10720, and Cisco 12000 series platforms.
12.0(24)S
L2TPv3 was enhanced to support fragmentation of IP packets before
entering the pseudowire on the Cisco 7200 series, Cisco 7500 series, and
Cisco 12000 series Internet routers.
12.0(25)S
Support was added for the ATM VP Mode Single Cell Relay over L2TPv3
feature on the Cisco 7200 and Cisco 7500 series routers with ATM Deluxe
PA-A3 interfaces.
L2TPv3 control plane support was introduced on the Cisco 12000 series
One-Port Channelized OC-12(DS3) line card.
12.0(23)S3
L2TPv3 control plane support was introduced on the Cisco 12000 series
One-Port Channelized OC-12(DS3) line card.
12.0(24)S1
L2TPv3 control plane support was introduced on the Cisco 12000 series
One-Port Channelized OC-12(DS3) line card.
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
Layer 2 Tunnel Protocol Version 3
12.0(27)S
12.0(28)S
12.0(29)S
12.2(25)S
Support for the following features was added to Cisco 12000 series
Two-Port Channelized OC-3/STM-1 (DS1/E1) and Six-Port Channelized
T3 (T1) line cards:
Quality of service (QoS) for Frame Relay attachment circuits
•
Binding L2TPv3 sessions to Multilink Frame Relay (MLFR) interfaces
Support was added for the following features on the Cisco 7200 series and
Cisco 7500 series routers:
•
ATM AAL5 OAM Emulation over L2TPv3
•
ATM Single Cell Relay VC Mode over L2TPv3
•
L2TPv3 support for PA-A3-8T1IMA PA and PA-A3-8E1IMA Port
Adapters
•
L2TPv3 Distributed Sequencing
Support was added for the following features:
•
ATM Port Mode Cell Relay over L2TPv3
•
ATM Cell Packing over L2TPv3
•
L2TPv3 Control Message Hashing
•
L2TPv3 Control Message Rate Limiting
•
Protocol Demultiplexing for L2TPv3
Support for the following features was added to Cisco IOS
Release 12.2(25)S:
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
2
•
•
L2TPv3: Layer 2 Tunneling Protocol
•
L2TPv3 Layer 2 fragmentation
•
ATM AAL5 OAM Emulation over L2TPv3
•
ATM VP Mode Single Cell Relay over L2TPv3
•
ATM Single Cell Relay VC Mode over L2TPv3
•
L2TPv3 Support for PA-A3-8T1IMA PA and PA-A3-8E1IMA Port
Adapters
•
L2TPv3 Distributed Sequencing
Layer 2 Tunnel Protocol Version 3
Contents
12.0(30)S
Support for the following features was added to Cisco IOS
Release 12.0(30)S:
•
VC Class Provisioning for L2VPN
•
L2TPv3 Digest Secret Graceful Switchover
•
Manual Clearing of L2TPv3 Tunnels
Support was added for native L2TPv3 tunneling on IP services engine (ISE)
line cards on the Cisco 12000 series Internet router.
12.2(27)SBA
Support for the following features was added to Cisco IOS
Release 12.2(27)SBA:
•
Layer 2 VPN (L2 VPN): Syslog, SNMP Trap, and show Command
Enhancements for AToM and L2TPv3
•
L2TPv3 Control Message Hashing
•
L2TPv3 Control Message Rate Limiting
•
Protocol Demultiplexing for L2TPv3
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for Layer 2 Tunnel Protocol Version 3, page 4
•
Restrictions for Layer 2 Tunnel Protocol Version 3, page 4
•
Information About Layer 2 Tunnel Protocol Version 3, page 20
•
How to Configure Layer 2 Tunnel Protocol Version 3, page 37
•
Configuration Examples for Layer 2 Tunnel Protocol Version 3, page 76
•
Additional References, page 97
•
Command Reference, page 99
•
Glossary, page 213
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
3
Layer 2 Tunnel Protocol Version 3
Prerequisites for Layer 2 Tunnel Protocol Version 3
Prerequisites for Layer 2 Tunnel Protocol Version 3
•
Before you configure an xconnect attachment circuit for a customer edge (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 provider
edge (PE) device at the other end of an L2TPv3 control channel.
•
To enable Simple Network Management Protocol (SNMP) notifications of L2TP session up and
down events, enter the snmp-server enable traps l2tun session command before configuring
L2TPv3.
Restrictions for Layer 2 Tunnel Protocol Version 3
The following subsections contain information on restrictions:
•
Supported Port Adapters for the Cisco 7200 Series and Cisco 7500 Series Routers
•
General L2TPv3 Restrictions
•
Cisco 7200 Series-Specific Restrictions
•
Cisco 7500 Series-Specific Restrictions
•
Cisco 10720-Specific Restrictions
•
Cisco 12000 Series-Specific Restrictions
•
Frame Relay-Specific Restrictions
•
VLAN-Specific Restrictions
•
ATM VP Mode Single Cell Relay over L2TPv3 Restrictions
•
ATM AAL5 SDU over L2TPv3 and Single Cell Relay VC Mode over L2TPv3 Restrictions
•
ATM Port Mode Cell Relay over L2TPv3 Restrictions
•
ATM Cell Packing over L2TPv3 Restrictions
•
Protocol Demultiplexing for L2TPv3 Restrictions
•
L2TPv3 Control Message Hashing Restrictions
•
L2TPv3 Digest Secret Graceful Switchover Restrictions
•
Quality of Service Restrictions in L2TPv3 Tunneling
Supported Port Adapters for the Cisco 7200 Series and Cisco 7500 Series
Routers
L2TPv3 is supported on the following port adapters in 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
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
4
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
•
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 OC3 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
L2TPv3 is supported on the following port adapters for the Cisco 7200 series routers only:
•
8-port Ethernet adapter
•
4-port Ethernet adapter
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
5
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
General L2TPv3 Restrictions
•
CEF must be enabled for the L2TPv3 feature to function. The xconnect configuration mode is
blocked until CEF is enabled. On distributed platforms, such as the Cisco 7500 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, High-Level Data Link Control (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 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.
•
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.
•
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, IP packet
fragmentation and Intermediate System-to-Intermediate System (IS-IS) fragmentation through a
static L2TPv3 session are not supported.
•
IP packet fragmentation is not supported when the 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.
Cisco 7200 Series-Specific Restrictions
•
ATM port mode cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC3 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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
6
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Cisco 7500 Series-Specific Restrictions
•
Distributed sequencing is supported on Cisco 7500 series routers only. The ip cef distributed
command must be configured.
•
ATM port mode cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC3 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.
Cisco 10720-Specific Restrictions
•
Variable cookie size, IP packet fragmentation, and L2TPv3 sequencing are not supported.
•
The reassembly of fragmented L2TPv3 packets is performed on the Cisco 10720 Internet router 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, it is highly recommended 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.
Cisco 12000 Series-Specific Restrictions
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) 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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
7
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Different combinations of engine types are supported as customer-facing and backbone-facing line cards
for encapsulation and decapsulation in L2TPv3 tunneling.
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, 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 (any engine type besides ISE), 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 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 customer-facing line card, the TSC sends the packet to the line
card for further decapsulation.
•
If the backbone-facing line card is ISE, the line card determines if the packet is bound to an Engine 2
(or earlier engine) or an ISE 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 customer-facing line card, the packet is sent to the ISE 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 and the backbone-facing line card is non-ISE.
In these cases, packets received on the backbone-facing interface are dropped. A warning message,
"L2TPv3 decapsulation packet dropped", is logged.
Cisco 12000 Series Line Cards—General Restrictions
•
Protocol demultiplexing for L2TPv3 is not supported on the Cisco 12000 series Internet router.
•
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 non-ISE backbone-facing and customer-facing line
cards are used, normal L2TPv3 tunnel sessions are supported with the L2TPv3 feature set
described in L2TPv3 Features, page 24.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
8
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
– If a tunnel server card is not installed and ISE backbone-facing and customer-facing line cards
are used, native L2TPv3 tunnel sessions are supported with the native L2TPv3 feature set
described in Table 2.
– If a tunnel server card is installed and a combination of non-ISE and ISE line cards is used as
backbone-facing and customer-facing line cards, a mixed L2TPv3 tunnel session is supported
with the native L2TPv3 feature set described in Table 2.
•
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 interfaces, 802.1q (VLAN) is not supported as
an L2TPv3 payload.
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 unnumbered command 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.
•
On the tunnel server card, 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.
•
On the tunnel server card, 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 asic command,
where slot-number is the slot number of the server card.
•
The optics of the tunnel server card should be covered due to 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.
•
Due to a framer problem, the server card interfaces accounting in (packets out) will not be accurate.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
9
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
•
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.
•
Configuring Engine 2 features not found in the Vanilla uCode bundle on any port of the Engine 2
line card that has an L2TPv3 session bound to one or more interfaces causes 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 is required when the Vanilla uCode
bundle is restored.
•
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 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 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 packets 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.
IP Services Engine-Specific Restrictions
•
Native L2TPv3 sessions are supported only if the feature mode is configured on a supported
customer-facing ISE 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 line card until all L2TPv3
xconnect attachment circuits on the line card are removed.
A backbone-facing ISE line card can operate in any mode and no special feature mode configuration
is required.
•
In a native L2TPv3 tunnel session configured on ISE interfaces, 802.1q (VLAN) is not supported as
an L2TPv3 payload.
•
Table 1 shows the ISE 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)
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
10
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Table 1 ISE Interfaces Supported in a Native L2TPv3 Tunnel Session
ISE Line Card
Native L2TPv3 Session on
Customer-Facing Interface
Native L2TPv3 Session on
Backbone-Facing Interface
1-port OC-48 POS ISE
Supported
Supported
1-port Channelized OC-48 POS ISE
Not supported
Not supported
1-port Channelized OC-12 (DS1) ISE
Supported
Not supported
4-port OC-3 ATM ISE
Supported
Supported
4-port OC-12 ATM ISE
Supported
Supported
•
Native L2TPv3 tunnel sessions on customer-facing ISE line cards can coexist with tunnel sessions
that use a tunnel server card.
•
L2TPv3 encapsulation on a customer-facing ISE line card does not support the IP Packet
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.
•
Table 2
Table 2 describes the L2TPv3 features supported in a native L2TPv3 tunnel session and the
customer-facing ISE line cards that support each feature. Note that although native L2TPv3 sessions
do not support 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.
L2TPv3 Features Supported in a Native L2TPv3 Session
ISE Line Cards (Customer-Facing)
Supported
Native L2TPv3 Feature
Description
Native L2TPv3 tunneling
(fast-path)
Native L2TPv3 tunneling supports the same
L2TPv3 features that are supported by server
card-based L2TPv3 tunneling (see the
“L2TPv3 Features” section), except that IP
packet fragmentation is not supported.
L2TP class and pseudowire class
configuration
You can create an L2TP template of L2TP
control channel parameters that can be
inherited by different pseudowire classes
configured on a PE router.
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
4-port OC-3 ATM ISE
4-port OC-12 ATM ISE
1-port Channelized OC-12 (DS1) ISE
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
You can also configure a pseudowire template
4-port OC-3 ATM ISE
of L2TPv3 session-level parameters that can
4-port OC-12 ATM ISE
be used to configure the transport Layer 2
1-port Channelized OC-12 (DS1) ISE
traffic over an xconnect attachment circuit.
See the sections “Configuring L2TP Control
Channel Parameters” and “Configuring the
L2TPv3 Pseudowire.”
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
11
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Table 2
L2TPv3 Features Supported in a Native L2TPv3 Session (continued)
Native L2TPv3 Feature
Description
Frame Relay DLCI-to-DLCI
tunneling
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
an L2TPv3 tunnel to another DLCI on the other
interface.
See “DLCI-to-DLCI Switching” in the “Frame
Relay” section.
ATM single cell and packed cell
relay: VC mode
ISE Line Cards (Customer-Facing)
Supported
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
1-port Channelized OC-12 (DS1) ISE
Each VC is mapped to a single L2TPv3 tunnel 4-port OC-3 ATM ISE
session. The following ATM cell relay modes 4-port OC-12 ATM ISE
are supported:
•
ATM cells arriving at an ATM interface
with the specified VPI and VCI are
encapsulated into a single L2TP packet
(single cell relay).
•
ATM cells arriving at an ingress ATM
interface are packed into L2TPv3 data
packets and transported to the egress ATM
interface (packed cell relay).
See the “ATM” section.
ATM single cell and packed cell
relay: VP mode
ATM cells arriving into a predefined PVP on
the ATM interface are transported to a
predefined PVP on the egress ATM interface.
The following ATM cell relay modes are
supported:
•
A single ATM cell is encapsulated into
each L2TPv3 data packet (single cell
relay).
•
Multiple ATM cells are packed into a
single L2TPv3 data packet (packed cell
relay).
4-port OC-3 ATM ISE
4-port OC-12 ATM ISE
See the “ATM” section.
ATM single cell relay and packed ATM cells arriving at an ingress ATM interface 4-port OC-3 ATM ISE
cell relay: Port mode
are encapsulated into L2TPv3 data packets and 4-port OC-12 ATM ISE
transported to the egress ATM interface.The
following ATM cell relay modes are supported:
•
A single ATM cell is encapsulated into
each L2TPv3 data packet (single cell
relay).
•
Multiple ATM cells are packed into a
single L2TPv3 data packet (packed cell
relay).
See the “ATM” section.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
12
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Table 2
L2TPv3 Features Supported in a Native L2TPv3 Session (continued)
Native L2TPv3 Feature
Description
ISE Line Cards (Customer-Facing)
Supported
ATM AAL5 PVC tunneling
The ATM AAL5 payload of an AAL5 PVC is
mapped to a single L2TPv3 session.
4-port OC-3 ATM ISE
4-port OC-12 ATM ISE
See “ATM AAL5” in the “ATM” section.
OAM emulation mode for ATM
AAL5
4-port OC-3 ATM ISE
OAM local emulation mode for ATM AAL5
payloads is supported. Instead of being passed 4-port OC-12 ATM ISE
through the pseudowire, OAM cells are
terminated and handled locally. On the
L2TPv3-based pseudowire, the CE device
sends an SLI message across the pseudowire to
notify the peer PE node about the defect, rather
than tearing down the session.
See “ATM AAL5 over L2TPv3: OAM Local
Emulation Mode” in the “ATM” section.
OAM transparent mode for ATM
AAL5
OAM transparent mode for ATM AAL5
payloads is supported. The PE routers pass
OAM cells transparently across the L2TPv3
tunnel.
4-port OC-3 ATM ISE
4-port OC-12 ATM ISE
See “ATM AAL5 over L2TPv3: OAM
Transparent Mode” in the “ATM” section.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
13
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Table 2
L2TPv3 Features Supported in a Native L2TPv3 Session (continued)
ISE Line Cards (Customer-Facing)
Supported
Native L2TPv3 Feature
Description
L2TPv3 tunnel marking and
traffic policing on the following
types of ISE ingress interfaces,
when bound to a native L2TPv3
tunnel session:
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
4-port OC-3 ATM ISE
The set commands can also be used to set (or
4-port OC-12 ATM ISE
mark) the IP precedence or DSCP value in the
1-port Channelized OC-12 (DS1) ISE
tunnel header of a L2TPv3 tunneled packet on
an ingress interface.
- ATM
- Frame Relay DLCIs
The following “conform,” “exceed,” and
“violate” values for the action argument are
supported for the police command when QoS
policies are configured on an ISE ingress
interface bound to a native L2TPv3 tunnel.
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
See “QoS: Tunnel Marking for L2TPv3
Tunnels” for information about how to use the
L2TPv3 tunnel marking and traffic policing
features on Engine 2 (and earlier engine)
interfaces bound to a TSC-based L2TPv3
tunnel session.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
14
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
Table 2
L2TPv3 Features Supported in a Native L2TPv3 Session (continued)
ISE Line Cards (Customer-Facing)
Supported
Native L2TPv3 Feature
Description
Dual rate, 3-Color Marker for
traffic policing on Frame Relay
DLCIs of ISE ingress interfaces,
when bound to a native L2TPv3
tunnel session1
The dual rate, 3-Color Marker in color-aware
and color-blind modes, as defined in RFC 2698
for traffic policing, is supported on ingress ISE
interfaces to classify packets.
See “QoS: Color-Aware Policer” for more
information about this feature.
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
1-port Channelized OC-12 (DS1) ISE
Traffic shaping on ATM and
Traffic shaping on ATM and Frame Relay
Frame Relay ISE egress interfaces egress interfaces based on class map
configuration is supported.
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
Traffic shaping is supported on ATM egress
interfaces for the following service categories: 1-port OC-48 POS ISE
4-port OC-3 ATM ISE
• Lowest priority: UBR (unspecified bit
4-port OC-12 ATM ISE
rate)
1-port Channelized OC-12 (DS1) ISE
•
Second priority: VBR-nrt (variable bit rate
nonreal-time)
•
Highest priority: VBR-rt (VBR real time)
•
Highest priority: CBR (constant bit rate) 2
See “Traffic Shaping on ATM Line Cards for
the Cisco 12000 Series.”
1. Although the dual-rate, 3-Color Marker policer is not supported on ATM ISE 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 options:
- set-dscp-tunnel
- set-dscp-tunnel and set-clp-transmit
- set-prec-tunnel
- set-prec-tunnel and set-clp-transmit
2. 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.
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,
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
15
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
•
The configuration of an L2TPv3 session on a Multilink Frame Relay (MLFR) bundle interface is
supported only on Cisco 12000 series Two-Port Channelized OC-3/STM-1 (DS1/E1) and Six-Port
Channelized T3 (T1) line cards. (For more information, see Binding L2TPv3 Sessions to Multilink
Frame Relay Interfaces, page 32.)
•
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.
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.
•
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 12000 series Internet router.
ATM VP Mode Single Cell Relay over L2TPv3 Restrictions
•
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.
•
Once the ATM VP Mode Single Cell Relay feature is configured for a virtual path connection (VPC),
no other permanent virtual circuits (PVCs) will be allowed for the same virtual path identifier (VPI).
ATM AAL5 SDU over L2TPv3 and Single Cell Relay VC Mode over L2TPv3
Restrictions
•
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 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 will be sent to the RSP module.
•
L2TPv3 manual mode configuration does not support ATM alarm signaling over the pseudowire.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
16
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
•
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.
ATM Port Mode Cell Relay over L2TPv3 Restrictions
•
Port mode and virtual path (VP) or VC mode cell relay are mutually exclusive. Once the ATM
interface is configured for cell relay, no permanent virtual path (PVP) or PVC commands will be
allowed on that interface.
•
ATM port mode cell relay is supported only on the PA-A3-T3, PA-A3-E3, and PA-A3-OC3 ATM
port adapters.
•
ATM port mode cell relay is not supported on the PA-A3-8T1IMA and PA-A3-8E1IMA port
adapters.
ATM Cell Packing over L2TPv3 Restrictions
•
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.
Protocol Demultiplexing for L2TPv3 Restrictions
•
IPv6 protocol demultiplexing is supported only for Ethernet and terminated DLCI Frame Relay
interfaces.
•
Frame Relay demultiplexing is supported for point-to-point or multipoint.
•
FRF.12 end-to-end fragmentation is supported on the Cisco 7500 series routers only between the CE
and the PE routers.
•
FRF.9 hardware payload compression is supported on the Cisco 7200 series and Cisco 7500 series
routers only between the CE and the PE routers.
•
FRF.9 software payload compression is supported on the Cisco 7500 series routers only between the
CE and the 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 the PE routers.
L2TPv3 Control Message Hashing Restrictions
•
L2TPv3 control channel authentication configured with the digest command requires bidirectional
configuration on the peer routers, and a shared secret must be configured on the communicating
nodes.
•
See Table 6 for a compatibility matrix of all the L2TPv3 authentication methods available in
Cisco IOS Release 12.0(29)S, Cisco IOS Release 12.2(27)SBA, and later releases.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
17
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
L2TPv3 Digest Secret Graceful Switchover Restrictions
•
This feature works only with authentication passwords configured using the L2TPv3 Control
Message Hashing feature. L2TPv3 control channel authentication passwords configured with the
older, 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.
Quality of Service Restrictions in L2TPv3 Tunneling
Quality of service (QoS) policies configured with the modular QoS command-line interface (MQC) are
supported in L2TPv3 tunnel sessions with the following restrictions:
Frame Relay Interface (Non-ISE)
•
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
Configuring QoS for L2TPv3 on the Cisco 7500 Series: Example, page 88.)
•
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 Configuring the L2TPv3 Pseudowire,
page 49).
•
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
18
Layer 2 Tunnel Protocol Version 3
Restrictions for Layer 2 Tunnel Protocol Version 3
•
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, page 88.
IP Services Engine (ISE) Interface
On the Cisco 12000 series, a QoS policy is supported in native L2TPv3 tunnel sessions on ISE interfaces
(see Table 2 on page 11 for a list of supported line cards) with the following restrictions:
•
On a Frame Relay or ATM ISE interface, traffic policing supports only the following “conform”,
“exceed”, and “violate” values for the action argument 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 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/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 interface is class-based when configured using
MQC.
– Egress queueing on a per-DLCI basis is not supported.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
19
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
•
On an ATM ISE 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 interfaces (as on
Frame Relay ISE 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
For detailed information about QoS configuration tasks and command syntax, refer to:
•
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3
•
Cisco IOS Quality of Service Solutions Command Reference, Release 12.3
Information About Layer 2 Tunnel Protocol Version 3
To configure the Layer 2 Tunnel Protocol Version 3 feature, you must understand the following concepts:
•
Migration from UTI to L2TPv3, page 20
•
L2TPv3 Operation, page 21
•
Benefits of Using L2TPv3, page 22
•
L2TPv3 Header Description, page 23
•
L2TPv3 Features, page 24
•
L2TPv3 and UTI Feature Comparison, page 29
•
Supported L2TPv3 Payloads, page 30
Migration from UTI to L2TPv3
UTI is a Cisco proprietary protocol that offers a simple high-speed transparent Layer 2-to-Layer 2
service over an IP backbone. The UTI protocol lacks the signaling capability and standards support
necessary for large-scale commercial service. To begin to answer the need for a standard way to provide
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
20
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
large-scale VPN connectivity over an IP core network, limited migration from UTI to L2TPv3 was
introduced in Cisco IOS Release 12.0(21)S. The L2TPv3 feature in Cisco IOS Release 12.0(23)S
introduced a more robust version of L2TPv3 to replace UTI.
As described in the section “L2TPv3 Header Description,” the UTI data header is identical to the
L2TPv3 header but with no sequence numbers and an 8-byte cookie. By manually configuring an
L2TPv3 session using an 8-byte cookie (see the section “Manually Configuring L2TPv3 Session
Parameters”) and by setting the IP protocol number of outgoing data packets to 120 (as described in the
section “Configuring the L2TPv3 Pseudowire”), you can ensure that a PE running L2TPv3 may
interoperate with a peer PE running UTI. However, because UTI does not define a signaling plane,
dynamically established L2TPv3 sessions cannot interoperate with UTI.
When a customer upgrades from a pre-L2TPv3 Cisco IOS release to a post-L2TPv3 release, an internal
UTI-to-xconnect command-line interface (CLI) migration utility will automatically convert the UTI
commands to xconnect and pseudowire class configuration commands without the need for any user
intervention. After the CLI migration, the UTI commands that were replaced will not be available. The
old-style UTI CLI will be hidden from the user.
Note
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 features:
•
Xconnect for Layer 2 tunneling via a pseudowire over an IP network
•
Layer 2 VPNs for PE-to-PE router service via xconnect that support 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.
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
21
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Figure 1
L2TPv3 Operation
Xconnected
interface
CE R3
Pseudowire tu1
int2
int1
PE R1
IP network
e1
L2TPv3-based
L2 tunnel
Xconnected
interface
int3
e2
int4
CE R4
PE R2
Pseudowire tu2
L2TPv3 tunneled LAN
LAN2
L2TPv3 tunneled LAN
80653
LAN1
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.
Benefits of Using L2TPv3
L2TPv3 Simplifies Deployment of VPNs
L2TPv3 is an industry-standard Layer 2 tunneling protocol that ensures interoperability among vendors,
increasing customer flexibility and service availability.
L2TPv3 Does Not Require MPLS
With L2TPv3 service providers need not deploy MPLS in the core IP backbone to set up VPNs using
L2TPv3 over the IP backbone, resulting in operational savings and increased revenue.
L2TPv3 Supports Layer 2 Tunneling over IP for Any Payload
L2TPv3 provides enhancements to L2TP to support Layer 2 tunneling of any payload over an IP core
network. L2TPv3 defines the base L2TP protocol as being separate from the Layer 2 payload that is
tunneled.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
22
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
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.
Figure 2
L2TPv3 Header Format
IP Delivery Header (20 bytes)
Protocol ID: 115
Layer 2 Payload
103361
L2TPV3 Header consisting of:
Session ID (4 bytes)
Cookie (0, 4, or 8 bytes)
Pseudowire Control Encapsulation
(4 bytes by default)
Each L2TPv3 packet contains an L2TPv3 header that includes a unique session ID representing one
session and a variable cookie length. The L2TPv3 session ID and the Tunnel Cookie field length are
assigned via the CLI. See the section “How to Configure Layer 2 Tunnel Protocol Version 3” for more
information on the CLI commands for L2TPv3.
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.
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”) and to distinguish AAL5 data and OAM
cells for AAL5 SDU mode over L2TPv3. For the purposes of sequencing, only the first bit and bits 8 to
31 are relevant.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
23
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Bit 1 indicates whether the Sequence Number field, bits 8 to 31, contains a valid sequence number and
is to be updated.
L2TPv3 Features
L2TPv3 provides xconnect support for Ethernet, 802.1q (VLAN), Frame Relay, HDLC, and PPP, using
the sessions described in the following sections:
•
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 features described in the following sections:
•
Sequencing
•
Local Switching
•
Distributed Switching
•
IP Packet Fragmentation
•
L2TPv3 Type of Service Marking
•
Keepalive
•
MTU Handling
•
L2TPv3 Control Message Hashing
•
L2TPv3 Control Message Rate Limiting
•
L2TPv3 Digest Secret Graceful Switchover
•
Manual Clearing of L2TPv3 Tunnels
•
Syslog, SNMP Trap, and show Command Enhancements for L2TPv3
Static L2TPv3 Sessions
Typically, the L2TP control plane is responsible for negotiating session parameters, such as the session
ID or the cookie, in order to set up the session. However, some IP networks require sessions to be
configured so that no signaling is required for session establishment. You can, therefore, set up static
L2TPv3 sessions for a PE router by configuring fixed values for the fields in the L2TP data header. A
static L2TPv3 session allows the PE to tunnel Layer 2 traffic as soon as the attachment circuit to which
the session is bound comes up.
Note
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
24
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Dynamic L2TPv3 Sessions
A dynamic L2TP session is established through the exchange of control messages containing
attribute-value pairs (AVPs). Each AVP contains information about the nature of the Layer 2 link being
forwarded: the payload type, virtual circuit (VC) ID, and so on.
Multiple L2TP sessions (one for each forwarded Layer 2 circuit) can exist between a pair of PEs, and
can be maintained by a single control channel. Session IDs and cookies are dynamically generated and
exchanged as part of a dynamic session setup. Information such as sequencing configuration is also
exchanged. Circuit state changes (UP/DOWN) are conveyed using the set link info (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.
You can configure L2TP to only drop out-of-order packets; you cannot configure L2TP to deliver the
packets out-of-order. No reordering mechanism is available.
Cisco IOS software Release 12.0(28)S introduces support for L2TPv3 distributed sequencing on the
Cisco 7500 series routers.
Local Switching
Local switching (from one port to another port in the same router) is supported for both static and
dynamic sessions. You must configure separate IP addresses for each xconnect statement.
See the section “Configuration Examples for Layer 2 Tunnel Protocol Version 3” for an example of how
to configure local port switching.
Distributed Switching
Distributed CEF switching is supported for L2TP on the Cisco 7500 series routers.
Note
For the Cisco 7500 series, sequencing is supported, but all L2TP packets that require sequence number
processing are sent to the RSP.
IP Packet Fragmentation
It is desirable to avoid fragmentation issues in the service provider network because reassembly is
computationally expensive. The easiest way to avoid fragmentation issues is to configure the CE routers
with an path maximum transmission unit (MTU) value that is smaller than the pseudowire path MTU.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
25
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
However, in scenarios where this is not an option, fragmentation issues must be considered. L2TP
initially supported only the following options for packet fragmentation when a packet is determined to
exceed the L2TP path MTU:
•
Unconditionally drop the packet
•
Fragment the packet after L2TP/IP encapsulation
•
Drop the packet and send an Internet Control Message Protocol (ICMP) unreachable message back
to the CE router
Cisco IOS Release 12.0(24)S introduced the ability to allow IP traffic from the CE router to be
fragmented before the data enters the pseudowire, forcing the computationally expensive reassembly to
occur in the CE network rather than in the service provider network. The number of fragments that must
be generated is determined based on the discovered pseudowire path MTU. The original Layer 2 header
is then copied to each of the generated fragments, the L2TP/IP encapsulation is added, and the frames
are then forwarded. This feature will be implicitly enabled whenever the ip pmtu command is enabled
in the pseudowire class. It will be applied to any packets received from the CE network that have a Don’t
Fragment (DF) bit set to 0 and that exceed the L2TP path MTU in size.
Support for the fragmentation of IP packets before the data enters the pseudowire was introduced on the
Cisco 7200 series and Cisco 7500 series routers in Cisco IOS Release 12.0(24)S.
L2TPv3 Type of Service Marking
When Layer 2 traffic is tunneled across an IP network, information contained in the ToS bits may be
transferred to the L2TP-encapsulated IP packets in one of the following ways:
•
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.
See the section “Configuring a Negotiated L2TPv3 Session for Local HDLC Switching: Example” for
more information about how to configure ToS information.
Keepalive
The keepalive mechanism for L2TPv3 extends only to the endpoints of the tunneling protocol. L2TP has
a reliable control message delivery mechanism that serves as the basis for the keepalive mechanism. The
keepalive mechanism consists of an exchange of L2TP hello messages.
If a keepalive mechanism is required, the control plane is used, although it may not be used to bring up
sessions. You can manually configure sessions.
In the case of static L2TPv3 sessions, a control channel between the two L2TP peers is negotiated
through the exchange of start control channel request (SCCRQ), start control channel replay (SCCRP),
and start control channel connected (SCCCN) control messages. The control channel is responsible only
for maintaining the keepalive mechanism through the exchange of hello messages.
The interval between hello messages is configurable per control channel. If one peer detects that the
other has gone down through the keepalive mechanism, it sends a StopCCN control message and then
notifies all of the pseudowires to the peer about the event. This notification results in the teardown of
both manually configured and dynamic sessions.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
26
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
MTU Handling
It is important that you configure an 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.
•
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.
•
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:
– 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 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. A Layer 2 header calculation is performed before the
ICMP unreachable message is sent to the CE.
L2TPv3 Control Message Hashing
The L2TPv3 Control Message Hashing feature introduces a new and more secure authentication system
that replaces the Challenge Handshake Authentication Protocol (CHAP)-like authentication system
inherited from L2TPv2, which uses the Challenge and Challenge Response AVPs in the SCCRQ,
SCCRP, and SCCCN messages.
The per-message authentication introduced by the L2TPv3 Control Message Hashing feature is designed
to perform a mutual authentication between L2TP nodes, check integrity of all control messages, and
guard against control message spoofing and replay attacks that would otherwise be trivial to mount
against the network.
The L2TPv3 Control Message Hashing feature incorporates an optional authentication or integrity check
for all control messages. The new authentication method uses a computed one-way hash over the header
and body of the L2TP control message, a pre-configured shared secret that must be defined on
communicating L2TP nodes, and a local and remote random value exchanged via the Nonce AVPs.
Received control messages that lack any of the required security elements are dropped.
L2TPv3 control message integrity checking is a unidirectional mechanism that does not require the
configuration of a shared secret. If integrity checking is enabled on the local PE router, control messages
are sent with the message digest calculated without the shared secret or Nonce AVPs, and are verified
by the remote PE router. If verification fails, the remote PE router drops the control message.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
27
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
L2TPv3 Control Message Rate Limiting
Cisco IOS Release 12.0(29)S and Cisco IOS Release 12.2(27)SBA introduce the L2TPv3 Control
Message Rate Limiting feature to counter the possibility of a denial-of-service attack on a router running
L2TPv3. The L2TPv3 Control Message Rate Limiting feature limits the rate at which SCCRQ control
packets arriving at the PE that terminates the L2TPv3 tunnel can be processed. SCCRQ control packets
initiate the process of bringing up the L2TPv3 tunnel and require a large amount of the control plane
resources of the PE router.
On distributed platforms, most control packet filtering will occur at the line card level, and the CPU of
the RP will be minimally impacted even in a worst-case denial-of-service attack scenario. This feature
will have minimal impact on the shared bus or switching fabric, which are typically the bottleneck of a
router.
No configuration is required for the L2TPv3 Control Message Rate Limiting feature. This feature will
automatically run in the background of Cisco IOS Release 12.0(29)S, Cisco IOS Release 12.2(27)SBA,
and later releases.
L2TPv3 Digest Secret Graceful Switchover
Authentication of L2TPv3 control channel messages occurs using a password that is configured on all
participating peer PE routers. In Cisco IOS releases prior to 12.0(30)S, changing this password requires
removing the old password from the configuration before adding the new password, causing an
interruption in L2TPv3 services.The authentication password must be updated on all peer PE routers,
which are often at different physical locations. It is difficult for all peer PE routers be updated with the
new password simultaneously to minimize interruptions in L2TPv3 services.
Cisco IOS Release 12.0(30)S introduces the L2TPv3 Digest Secret Graceful Switchover feature. This
feature allows the password used to authenticate L2TPv3 control channel messages to be changed
without tearing down established L2TPv3 tunnels. This feature works only for authentication passwords
configured with the L2TPv3 Control Message Hashing feature. Authentication passwords configured
with the older, CHAP-like authentication system cannot be updated without tearing down L2TPv3
tunnels.
The L2TPv3 Digest Secret Graceful Switchover feature allows two control channel passwords to be
configured simultaneously, so a new control channel password can be enabled without first removing the
old password. Established tunnels are rapidly updated with the new password, but will continue to use
the old password until it is removed from the configuration. This allows authentication to continue
normally with peer PE routers that have not yet been updated to use the new password. Once all peer PE
routers have been configured with the new password, the old password can be removed from the
configuration.
Manual Clearing of L2TPv3 Tunnels
Cisco IOS Release 12.0(30)S introduces the ability to clear L2TPv3 tunnels manually. In Cisco IOS
releases prior to 12.0(30)S, no provision was made to manually clear a specific L2TPv3 tunnel at will.
This functionality provides users more control over an L2TPv3 network.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
28
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Syslog, SNMP Trap, and show Command Enhancements for L2TPv3
Cisco IOS Release 12.2(27)SBA introduces new and enhanced commands for managing and diagnosing
problems with xconnect configurations. No specific configuration tasks are associated with this feature.
The following commands have been introduced:
•
show xconnect—Displays xconnect-specific information, providing a sortable single point of
reference for information about all xconnect configurations.
•
snmp-server enable traps l2tun pseudowire status—Enables the sending of Simple Network
Management Protocol (SNMP) notifications when a pseudowire changes state.
•
xconnect logging pseudowire status—Enables syslog reporting of pseudowire status events.
The following commands have been enhanced:
•
debug vpdn—The output of this command has been enhanced to include authentication failure
messages.
•
show l2tun session—The hostname keyword option has been added, allowing the peer hostname
to be displayed in the output.
•
show l2tun tunnel—The authentication keyword option has been added, allowing the display of
global information about L2TP control channel authentication attribute-value pairs (AV pairs).
Complete documentation for these commands is available in the “Command Reference” section of this
publication.
L2TPv3 and UTI Feature Comparison
Table 3 compares L2TPv3 and UTI feature support for the Cisco 7200 and Cisco 7500 series routers.
Table 3
Comparison of L2TPv3 and UTI Feature Support
Feature
L2TPv3
UTI
Maximum number of sessions
Cisco 7200 and Cisco 7500 series:3000
Cisco 7200 and Cisco 7500 series: 1000
Tunnel cookie length
0-, 4-, or 8-byte cookies are supported for 8 bytes
the Cisco 7200 series and the Cisco 7500
series routers.
Static sessions
Supported in Cisco IOS
Release 12.0(21)S.
Supported
Dynamic sessions
Supported in Cisco IOS
Release 12.0(23)S.
Not supported
Static ToS
Supported in Cisco IOS
Release 12.0(23)S.
Supported
MQC ToS
Supported in Cisco IOS
Release 12.0(27)S.
Supported
Inner IP ToS mapping
Supported on the Cisco 7200 series
routers and Cisco 7500 series routers.
Not supported
802.1p mapping
Not supported.
Not supported
Keepalive
Supported in Cisco IOS
Release 12.0(23)S.
Not supported
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
29
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Table 3
Comparison of L2TPv3 and UTI Feature Support (continued)
Feature
L2TPv3
UTI
Path MTU discovery
Supported on the Cisco 7200 series and
Cisco 7500 series routers.
Not supported
ICMP unreachable
Supported on the Cisco 7200 series and
Cisco 7500 series routers.
Not supported
VLAN rewrite
Supported on the Cisco 7200 series and
Cisco 7500 series routers in Cisco IOS
Release 12.0(23)S.
Supported
VLAN and non-VLAN translation
To be supported in a future release.
Not supported
Port trunking
Supported in Cisco IOS
Release 12.0(23)S.
Supported
IS-IS packet fragmentation through Supported on the Cisco 7200 series and
an L2TPv3 session
Cisco 7500 series routers.
Not supported
IP packet fragmentation through an Supported on the Cisco 7200 series and
L2TPv3 session
Cisco 7500 series routers in Cisco IOS
Release 12.0(24)S.
Not supported
Payload sequence number checking Supported on the Cisco 7500 series in
Cisco IOS Release 12.0(28)S.
Not supported
MIB support
IfTable MIB for the session interface.
VPDN MIB for the pseudowire
IfTable MIB for the attachment circuit.
Supported L2TPv3 Payloads
L2TPv3 supports the following Layer 2 payloads that can be included in L2TPv3 packets tunneled over
the pseudowire:
Note
•
Frame Relay
•
Ethernet
•
802.1q (VLAN)
•
HDLC
•
PPP
•
ATM
•
IPv6 Protocol Demultiplexing
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
30
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
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
•
Binding L2TPv3 Sessions to Multilink Frame Relay Interfaces
Port-to-Port Trunking
Port-to-port trunking is where two CE Frame Relay interfaces are connected as by a leased line (UTI
“raw” mode). All traffic arriving on one interface is forwarded transparently across the pseudowire to
the other interface.
For example, in Figure 1, if the two CE routers are connected by a virtual leased line, the PE routers
transparently transport all packets between CE R3 and CE R4 over a pseudowire. PE R1 and PE R2 do
not examine or change the DLCIs, and do not participate in the LMI protocol. The two CE routers are
LMI peers. There is nothing Frame Relay-specific about this service as far as the PE routers are
concerned. The CE routers should be able to use any encapsulation based on HDLC framing without
needing to change the provider configuration.
DLCI-to-DLCI Switching
Frame Relay DLCI-to-DLCI switching is where individual Frame Relay DLCIs are connected to create
an end-to-end Frame Relay PVC. Traffic arriving on a DLCI on one interface is forwarded across the
pseudowire to another DLCI on the other interface.
For example, in Figure 1, CE R3 and PE R1 are Frame Relay LMI peers; CE R4 and PE R2 are also LMI
peers. You can use a different type of LMI between CE R3 and PE R1 compared to what you use between
CE R4 and PE R2.
The CE devices may be a Frame Relay switch or end-user device. Each Frame Relay PVC is composed
of multiple segments. The DLCI value is local to each segment and is changed as traffic is switched from
segment to segment. Note that, in Figure 1, two Frame Relay PVC segments are connected by a
pseudowire. Frame Relay header flags (FECN, BECN, C/R, DE) are preserved across the pseudowire.
PVC Status Signaling
PVC status signaling is propagated toward Frame Relay end users by the LMI protocol. You can
configure the LMI to operate in any of the following modes:
•
UNI DTE mode—PVC status is not reported, only received.
•
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
31
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
Note that any keepalive functions on the session are independent of Frame Relay, but any state changes
that are detected are fed into the PVC status reporting. For example, the L2TP control channel uses hello
packets as a keepalive function. If the L2TPv3 keepalive fails, all L2TPv3 sessions are torn down. Loss
of the session is notified to Frame Relay, which can then report PVCs INACTIVE to the CE devices.
For example, in Figure 1, CE R3 reports ACTIVE to PE R1 only if the PVC is available within CE R3.
When CE R3 is a switch, it reports all the way to the user device in the customer network.
PE R1 reports ACTIVE to CE R3 only if the PVC is available within PE R1 and all the way to the
end-user device (via PE R2 and CE R3) in the other customer VPN site.
The ACTIVE state is propagated hop-by-hop, independently in each direction, from one end of the
Frame Relay network to the other end.
Sequencing
Frame Relay provides an ordered service in which packets sent to the Frame Relay network by one
end-user device are delivered in order to the other end-user device. When switching is occurring over the
pseudowire, packet ordering must be able to be preserved with a very high probability to closely emulate
a traditional Frame Relay service. If the CE router is not using a protocol that can detect misordering
itself, configuring sequence number processing may be important. For example, if the Layer 3 protocol
is IP and Frame Relay is therefore used only for encapsulation, sequencing is not required. To detect
misordering, you can configure sequence number processing separately for transmission or reception.
For more information about how to configure sequencing, see the section “Configuring a Negotiated
L2TPv3 Session for Local HDLC Switching: Example.”
ToS Marking
The ToS bytes in the IP header can be statically configured or reflected from the internal IP header. The
Frame Relay discard eligible (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
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.
Binding L2TPv3 Sessions to Multilink Frame Relay Interfaces
The configuration of an L2TPv3 session on a Multilink Frame Relay (MLFR) bundle interface is
supported only on Cisco 12000 series Two-Port Channelized OC-3/STM-1 (DS1/E1) and Six-Port
Channelized T3 (T1) line cards.
The Multilink Frame Relay feature introduces functionality based on the Frame Relay Forum Multilink
Frame Relay UNI/NNI Implementation Agreement (FRF.16). This feature provides a cost-effective way
to increase bandwidth for particular applications by enabling multiple serial links to be aggregated into
a single bundle of bandwidth.
For an example of how to configure L2TPv3 tunneling on a multilink Frame Relay bundle interface, see
Configuring MLFR for L2TPv3 on the Cisco 12000 Series: Example, page 96.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
32
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
For information about how configure and use the MLFR feature, refer to the Multilink Frame Relay
(FRF.16) publication.
Ethernet
An Ethernet frame arriving at a PE router is simply encapsulated in its entirety with an L2TP data header.
At the other end, a received L2TP data packet is stripped of its L2TP data header. The payload, an
Ethernet frame, is then forwarded to the appropriate attachment circuit.
Because the L2TPv3 tunneling protocol serves essentially as a bridge, it need not examine any part of
an Ethernet frame. Any Ethernet frame received on an interface is tunneled, and any L2TP-tunneled
Ethernet frame is forwarded out the interface.
Note
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.
802.1q (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.
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.
HDLC
L2TPv3 encapsulates an HDLC frame arriving at a PE in its entirety (including the Address, Control,
and Protocol fields, but not the Flag fields and the frame check sequence) with an L2TP data header.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
33
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
PPP
PEs that support L2TPv3 forward PPP traffic using a “transparent pass-through” model, in which the
PEs play no role in the negotiation and maintenance of the PPP link. L2TPv3 encapsulates a PPP frame
arriving at a PE in its entirety (including the HDLC Address and Control fields) with an L2TP data
header.
ATM
L2TPv3 can connect two isolated ATM clouds over a packet-switched network (PSN) while maintaining
an end-to-end ATM Service Level Agreement (SLA). The ATM Single Cell Relay features forward one
ATM cell per packet. The ATM Cell Packing over L2TPv3 features allows multiple ATM frames to be
packed into a single L2TPv3 data packet. All packets are transparently forwarded over the L2TPv3
pseudowire.
Note
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 or 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.
Table 4 shows the releases that introduced support for the ATM cell relay features.
Table 4
Release Support for the ATM Cell Relay Features
Transport Type
Single Cell Relay
Packed Cell Relay
VC mode
12.0(28)S, 12.2(25)S
12.0(29)S
VP mode
12.0(25)S, 12.2(25)S
12.0(29)S
Port mode
12.0(29)S
12.0(29)S
ATM Single Cell Relay VC Mode over L2TPv3
The ATM Single Cell Relay VC mode over L2TPv3 feature maps one VC to a single L2TPv3 session.
All ATM cells arriving at an ATM interface with the specified VPI and VCI are encapsulated into a single
L2TP packet. Each ATM cell will have a 4-byte ATM cell header without Header Error Control
Checksum (HEC) and a 48-byte ATM cell payload.
The ATM Single Cell Relay VC mode feature can be used to carry any type of AAL traffic over the
pseudowire. It will not distinguish OAM cells from User data cells. In this mode, Performance and
Security OAM cells are also transported over the pseudowire.
ATM VP Mode Single Cell Relay over L2TPv3
The ATM VP Mode Single Cell Relay over L2TPv3 feature allows cells coming into a predefined PVP
on the ATM interface to be transported over an L2TPv3 pseudowire to a predefined PVP on the egress
ATM interface. A single ATM cell is encapsulated into each L2TPv3 data packet.
ATM Port Mode Cell Relay over L2TPv3
The ATM Port Mode Cell Relay over L2TPv3 feature packs ATM cells arriving at an ingress ATM
interface into L2TPv3 data packets and transports them to the egress ATM interface. A single ATM cell
is encapsulated into each L2TPv3 data packet.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
34
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
ATM Cell Packing over L2TPv3
The ATM Cell Packing over L2TPv3 feature enhances throughput and uses bandwidth more efficiently
than the ATM cell relay features. Instead of a single ATM cell being packed into each L2TPv3 data
packet, multiple ATM cells can be packed into a single L2TPv3 data packet. ATM cell packing is
supported for Port mode, VP mode, and VC mode. Cell packing must be configured on the PE devices.
No configuration is required on the CE devices.
ATM AAL5 over L2TPv3
The ATM AAL5 over L2TPv3 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 common part convergence sublayer
protocol data unit (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 payload without the AAL5
pad and trailer bytes.
VC Class Provisioning for L2TPv3
Beginning in Cisco IOS Release 12.0(30)S, ATM AAL5 encapsulation over L2TPv3 can be configured
in VC class configuration mode in addition to ATM VC configuration mode. The ability to configure
ATM encapsulation parameters in VC class configuration mode provides greater control and flexibility
for AAL5 encapsulation configurations.
OAM Transparent Mode
In OAM transparent mode, the PEs will pass the following OAM cells transparently across the
pseudowire:
Note
•
F5 segment and end-to-end Fault Management (FM) OAM cells
•
RM OAM cells, except Performance Management (PM) and Security OAM cells
The Cisco 7200 and the Cisco 7500 ATM driver cannot forward RM cells over the PSN for ABR ToS.
The RM cells will be locally terminated.
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.
OAM Local Emulation Mode
In OAM Local Emulation mode, OAM cells are not passed through the pseudowire. All F5 OAM cells
are terminated and handled locally. On the L2TPv3-based pseudowire, the CE device sends an SLI
message across the pseudowire to notify the peer PE node about the defect, rather than tearing down the
session. The defect can occur at any point in the link between the local CE and the PE. OAM
management can also be enabled on the PE node using existing OAM management configurations.
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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
35
Layer 2 Tunnel Protocol Version 3
Information About Layer 2 Tunnel Protocol Version 3
IPv6 Protocol Demultiplexing
Upgrading a service provider network to support IPv6 is a long and expensive process. As an interim
solution, the Protocol Demultiplexing for L2TPv3 feature introduces the ability to provide native IPv6
support by setting up a specialized IPv6 network and offloading IPv6 traffic from the IPv4 network. IPv6
traffic is transparently tunneled to the IPv6 network using L2TPv3 pseudowires without affecting the
configuration of the CE routers. IPv4 traffic is routed as usual within the IPv4 network, maintaining the
existing performance and reliability of the IPv4 network.
Figure 3 shows a network deployment that offloads IPv6 traffic from the IPv4 network to a specialized
IPv6 network. The PE routers demultiplex the IPv6 traffic from the IPv4 traffic. IPv6 traffic is routed to
the IPv6 network over an L2TPv3 pseudowire, while IPv4 traffic is routed normally. The IPv4 PE routers
must be configured to demultiplex incoming IPv6 traffic from IPv4 traffic. The PE routers facing the
IPv6 network do not require demultiplexing configuration.
Figure 3
Protocol Demultiplexing of IPv6 Traffic from IPv4 Traffic
IPv6 network
L2TPv3 pseudowire
IPv6 PEs
L2TPv3 pseudowire
IPv4/v6 CE
IPv4 PE
IPv4 PE
IPv6 traffic
IPv4/v6 CE
121105
IPv4 network
IPv4 traffic
IPv6 protocol demultiplexing is supported only for Ethernet and Frame Relay traffic in Cisco IOS
Release 12.0(29)S, Cisco IOS Release 12.2(27)SBA, and later releases. Protocol demultiplexing
requires supporting the combination of an IP address and an xconnect command configuration on the
IPv4 PE interface. This combination of configurations is not allowed without enabling protocol
demultiplexing, with the exception of switched Frame Relay PVCs. If no IP address is configured, the
protocol demultiplexing configuration is rejected. If an IP address is configured, the xconnect command
configuration is rejected unless protocol demultiplexing is enabled in xconnect configuration mode
before exiting that mode. If an IP address is configured with an xconnect command configuration and
protocol demultiplexing enabled, the IP address cannot be removed. To change or remove the configured
IP address, the xconnect command configuration must first be disabled.
Table 5 shows the valid combinations of configurations.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
36
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Table 5
Valid Configuration Scenarios
Scenario
IP Address
xconnect Configuration
Protocol Demultiplexing
Configuration
Routing
Yes
No
—
L2VPN
No
Yes
No
IPv6 Protocol
Demultiplexing
Yes
Yes
Yes
How to Configure Layer 2 Tunnel Protocol Version 3
This section contains the following procedures:
•
Configuring L2TP Control Channel Parameters, page 38 (optional)
•
Configuring the L2TPv3 Pseudowire, page 49 (required)
•
Configuring the Xconnect Attachment Circuit, page 52 (required)
•
Manually Configuring L2TPv3 Session Parameters, page 55 (required)
•
Configuring the Xconnect Attachment Circuit for ATM VP Mode Single Cell Relay over L2TPv3,
page 56 (optional)
•
Configuring the Xconnect Attachment Circuit for ATM Single Cell Relay VC Mode over L2TPv3,
page 57 (optional)
•
Configuring the Xconnect Attachment Circuit for ATM Port Mode Cell Relay over L2TPv3, page 59
(optional)
•
Configuring the Xconnect Attachment Circuit for ATM Cell Packing over L2TPv3, page 60
(optional)
•
Configuring the Xconnect Attachment Circuit for ATM AAL5 SDU Mode over L2TPv3, page 64
(optional)
•
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3, page 68 (optional)
•
Configuring Protocol Demultiplexing for L2TPv3, page 72 (optional)
•
Manually Clearing L2TPv3 Tunnels, page 75 (optional)
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
37
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
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 L2TPv3 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.
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
This task configures a set of timing control channel parameters in an L2TP class. All of the timing
control channel parameter configurations are optional and may be configured in any order. If these
parameters are not configured, the default values are applied.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
l2tp-class [l2tp-class-name]
4.
receive-window size
5.
retransmit {initial retries initial-retries | retries retries | timeout {max | min} timeout}
6.
timeout setup seconds
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
38
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
l2tp-class [l2tp-class-name]
Specifies the L2TP class name and enters L2TP class
configuration mode.
•
Example:
Router(config)# l2tp-class class1
Step 4
receive-window size
(Optional) Configures the number of packets that can be
received by the remote peer before backoff queueing occurs.
•
Example:
Router(config-l2tp-class)# receive-window 30
Step 5
retransmit {initial retries initial-retries |
retries retries | timeout {max | min} timeout}
•
initial retries—specifies how many SCCRQs are
re-sent before giving up on the session. Valid values for
the initial-retries argument range from 1 to 1000. 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 1000. 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.
Router(config-l2tp-class)# retransmit retries
10
timeout setup seconds
(Optional) Configures the amount of time, in seconds,
allowed to set up a control channel.
•
Example:
Router(config-l2tp-class)# timeout setup 400
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.
Example:
Step 6
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.
Valid values for the seconds argument range from 60 to
6000. The default value is 300.
Configuring L2TPv3 Control Channel Authentication Parameters
Two methods of control channel message authentication are available in Cisco IOS Release 12.0(29)S,
Cisco IOS Release 12.2(27)SBA, and later releases. The L2TPv3 Control Message Hashing feature
introduces a more robust authentication method than the older CHAP-style L2TP control channel
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
39
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
method of authentication. You may choose to enable both methods of authentication to ensure
interoperability with peers that support only one of these methods of authentication, but this
configuration will yield control of which authentication method is used to the peer PE router. Enabling
both methods of authentication should be considered an interim solution to solve
backward-compatibility issues during software upgrades.
The principal difference between the L2TPv3 Control Message Hashing feature and CHAP-style L2TP
control channel authentication is that, instead of computing the hash over selected contents of a received
control message, the L2TPv3 Control Message Hashing feature uses the entire message in the hash. In
addition, instead of including the hash digest in only the SCCRP and SCCCN messages, it includes it in
all messages.
Support for the L2TPv3 Control Message Hashing feature is introduced in Cisco IOS Release 12.0(29)S
and Cisco IOS Release 12.2(27)SBA. Support for L2TP control channel authentication is maintained for
backward compatibility. Either or both authentication methods can be enabled to allow interoperability
with peers supporting only one of the authentication methods.
Table 6 shows a compatibility matrix for the different L2TPv3 authentication methods. PE1 is running
a Cisco IOS software version that supports the L2TPv3 Control Message Hashing feature, and the
different possible authentication configurations for PE1 are shown in the first column. Each remaining
column represents PE2 running software with different available authentication options, and the
intersections indicate the different compatible configuration options for PE2. If any PE1/PE2
authentication configuration poses ambiguity on which method of authentication will be used, the
winning authentication method is indicated in bold. If both the old and new authentication methods are
enabled on PE1 and PE2, both types of authentication will occur.
Table 6
Compatibility Matrix for L2TPv3 Authentication Methods
PE1
Authentication
Configuration
PE2 Supporting Old
Authentication1
PE2 Supporting New
Authentication2
PE2 Supporting Old and
New Authentication3
None
None
None
None
New integrity check
New integrity check
—
Old authentication
Old
authentication
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
New
authentication
—
New integrity
check
None
New authentication
Old authentication and
new authentication
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
40
New authentication
None
None
New integrity check
New integrity check
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Table 6
PE1
Authentication
Configuration
Old and new
authentication
Compatibility Matrix for L2TPv3 Authentication Methods (continued)
PE2 Supporting Old
Authentication1
PE2 Supporting New
Authentication2
PE2 Supporting Old and
New Authentication3
Old authentication
New authentication
Old authentication
New authentication
Old and new
authentication
Old authentication and
new integrity check
Old authentication
Old
authentication
and new integrity
check
—
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
1. Any PE software that supports only the old CHAP-like authentication system.
2. Any PE software that supports only the new message digest authentication and integrity checking authentication system,
but does not understand the old CHAP-like authentication system. This type of software may be implemented by other
vendors based on the latest L2TPv3 draft.
3. Any PE software that supports both the old CHAP-like authentication and the new message digest authentication and
integrity checking authentication system, such as Cisco IOS 12.0(29)S, Cisco IOS 12.2(27)SBA, or later releases.
Perform one or both of the following tasks to configure authentication parameters for the L2TPv3 control
channel messages:
•
Configuring Authentication for the L2TP Control Channel, page 41 (optional)
•
Configuring L2TPv3 Control Message Hashing, page 43 (optional)
If you choose to configure authentication using the L2TPv3 Control Message Hashing feature, you may
perform the following optional task:
•
Configuring L2TPv3 Digest Secret Graceful Switchover, page 45 (optional)
Configuring Authentication for the L2TP Control Channel
The L2TP control channel method of authentication is the older, CHAP-like authentication system
inherited from L2TPv2.
The following L2TP control channel authentication parameters can be configured in L2TP class
configuration mode:
•
Authentication for the L2TP control channel
•
Password used for L2TP control channel authentication
•
Local hostname used for authenticating the control channel
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
41
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
This task configures a set of authentication control channel parameters in an L2TP class. All of the
authentication control channel parameter configurations are optional and may be configured in any
order. If these parameters are not configured, the default values will be applied.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
l2tp-class [l2tp-class-name]
4.
authentication
5.
password [0 | 7] password
6.
hostname name
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
l2tp-class [l2tp-class-name]
Example:
Router(config)# l2tp-class class1
Step 4
authentication
Example:
Router(config-l2tp-class)# authentication
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
42
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) Enables authentication for the control channel
between PE routers.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 5
Command or Action
Purpose
password [0 | 7] password
(Optional) Configures the password used for control
channel authentication.
•
Example:
Router(config-l2tp-class)# password cisco
[0 | 7]—(Optional) Specifies the input format of the
shared secret. The default value is 0.
– 0—Specifies that a plain-text secret will be
entered.
– 7—Specifies that an encrypted secret will be
entered.
•
Step 6
password—Defines the shared password between peer
routers.
(Optional) Specifies a hostname used to identify the router
during L2TP control channel authentication.
hostname name
•
Example:
Router(config-l2tp-class)# hostname yb2
If you do not use this command, the default hostname
of the router is used.
Configuring L2TPv3 Control Message Hashing
The L2TPv3 Control Message Hashing feature introduced in Cisco IOS Release 12.0(29)S and
Cisco IOS Release 12.2(27)SBA is a new authentication system that is more secure than the CHAP-style
L2TP control channel method of authentication. L2TPv3 Control Message Hashing incorporates an
optional authentication or integrity check for all control messages. This per-message authentication is
designed to guard against control message spoofing and replay attacks that would otherwise be trivial to
mount against the network.
Enabling the L2TPv3Control Message Hashing feature will impact performance during control channel
and session establishment because additional digest calculation of the full message content is required
for each sent and received control message. This is an expected trade-off for the additional security
afforded by this feature. In addition, network congestion may occur if the receive window size is too
small. If the L2TPv3 Control Message Hashing feature is enabled, message digest validation must be
enabled. Message digest validation deactivates the data path received sequence number update and
restricts the minimum local receive window size to 35.
You may choose to configure control channel authentication or control message integrity checking.
Control channel authentication requires participation by both peers, and a shared secret must be
configured on both routers. Control message integrity check is unidirectional, and requires configuration
on only one of the peers.
This task configures L2TPv3 Control Message Hashing feature for an L2TP class.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
l2tp-class [l2tp-class-name]
4.
digest [secret [0 | 7] password] [hash {md5 | sha}]
5.
digest check
6.
hidden
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
43
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
l2tp-class [l2tp-class-name]
Example:
Specifies the L2TP class name and enters L2TP class
configuration mode.
•
Router(config)# l2tp-class class1
Step 4
digest [secret [0 | 7] password] [hash {md5 |
sha}]
(Optional) Enables L2TPv3 control channel authentication
or integrity checking.
•
Example:
Router(config-l2tp-class)# digest secret cisco
hash sha
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.
Note
•
secret—(Optional) Enables L2TPv3 control channel
authentication.
If the digest command is issued without the secret
keyword option, L2TPv3 integrity checking will be
enabled.
[0 | 7]—Specifies the input format of the shared secret.
The default value is 0.
– 0—Specifies that a plain-text secret will be
entered.
– 7—Specifies that an encrypted secret will be
entered.
•
password—Defines the shared secret between peer
routers. The value entered for the password argument
must be in the format that matches the input format
specified by the [0 | 7] keyword option.
•
hash {md5 | sha}—(Optional) Specifies the hash
function to be used in per-message digest calculations.
– md5—Specifies HMAC-MD5 hashing.
– sha—Specifies HMAC-SHA-1 hashing.
The default hash function is md5.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
44
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 5
Command or Action
Purpose
digest check
(Optional) Enables the validation of the message digest in
received control messages.
•
Example:
Router(config-l2tp-class)# digest check
Step 6
Note
Validation of the message digest is enabled by default.
Validation of the message digest cannot be disabled
if authentication has been enabled using the digest
secret command. If authentication has not been
configured with the digest secret command, the
digest check can be disabled to increase
performance.
(Optional) Enables AVP hiding when sending control
messages to an L2TPv3 peer.
hidden
Example:
Router(config-l2tp-class)# hidden
•
AVP hiding is disabled by default.
•
Beginning in Cisco IOS Release 12.0(29)S and
Cisco IOS Release 12.2(27)SBA, only the hiding of the
cookie AVP is supported.
•
If a cookie is configured in L2TP class configuration
mode (see the section “Manually Configuring L2TPv3
Session Parameters”), enabling AVP hiding causes that
cookie to be sent to the peer as a hidden AVP using the
password configured with the digest secret command.
Note
AVP hiding is enabled only if authentication has
been enabled using the digest secret command, and
no other authentication method is configured.
Configuring L2TPv3 Digest Secret Graceful Switchover
L2TPv3 control channel authentication occurs using a password that is configured on all participating
peer PE routers. The L2TPv3 Digest Secret Graceful Switchover feature allows a transition from an old
control channel authentication password to a new control channel authentication password without
disrupting established L2TPv3 tunnels. This feature was introduced in Cisco IOS Release 12.0(30)S.
During the period when both a new and an old password are configured, authentication will occur only
with the new password if the attempt to authenticate using the old password fails.
Perform this task to make the transition from an old L2TPv3 control channel authentication password to
a new L2TPv3 control channel authentication password without disrupting established L2TPv3 tunnels.
Prerequisites
Before performing this task, you must enable control channel authentication as documented in the task
“Configuring L2TPv3 Control Message Hashing.”
Restrictions
This task is not compatible with authentication passwords configured with the older, CHAP-like control
channel authentication system.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
45
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
l2tp-class [l2tp-class-name]
4.
digest [secret [0 | 7] password] [hash {md5 | sha}]
5.
end
6.
show l2tun tunnel all
7.
configure terminal
8.
l2tp-class [l2tp-class-name]
9.
no digest [secret [0 | 7] password] [hash {md5 | sha}]
10. end
11. show l2tun tunnel all
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
l2tp-class [l2tp-class-name]
Specifies the L2TP class name and enters L2TP class configuration mode.
•
Example:
Router(config)# l2tp-class
class1
Step 4
digest [secret [0 | 7]
password] [hash {md5 | sha}]
Configures a new password to be used in L2TPv3 control channel
authentication.
•
Example:
Router(config-l2tp-class)#
digest secret cisco2 hash sha
Step 5
Note
A maximum of two passwords may be configured at any time.
Authentication will now occur using both the old and new passwords.
Ends your configuration session by exiting to privileged EXEC mode.
end
Example:
Router(config-l2tp-class)# end
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
46
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.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 6
Command or Action
Purpose
show l2tun tunnel all
(Optional) Displays the current state of Layer 2 tunnels and information about
configured tunnels, including local and remote Layer 2 Tunneling Protocol
(L2TP) hostnames, aggregate packet counts, and control channel information.
Example:
Router# show l2tun tunnel all
•
Note
Step 7
configure terminal
Tunnels should be updated with the new control channel authentication
password within a matter of seconds. If a tunnel does not update to show
that two secrets are configured after several minutes have passed, that
tunnel can be manually cleared and a defect report should be filed with the
Cisco Technical Assistance Center (TAC). To manually clear an L2TPv3
tunnel, perform the task “Manually Clearing L2TPv3 Tunnels.”
Issue this command to determine if any tunnels are not using the new
password for control channel authentication. The output displayed for
each tunnel in the specified L2TP class should show that two secrets
are configured.
Enters global configuration mode.
Example:
Router# configure terminal
Step 8
l2tp-class [l2tp-class-name]
Specifies the L2TP class name and enters L2TP class configuration mode.
•
Example:
Router(config)# l2tp-class
class1
Step 9
no digest [secret [0 | 7]
password] [hash {md5 | sha}]
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.
Removes the old password used in L2TPv3 control channel authentication.
Note
Do not remove the old password until all peer PE routers have been
updated with the new password.
Example:
Router(config-l2tp-class)# no
digest secret cisco hash sha
Step 10
end
Ends your configuration session by exiting to privileged EXEC mode.
Example:
Router(config-l2tp-class)# end
Step 11
show l2tun tunnel all
Example:
Router# show l2tun tunnel all
(Optional) Displays the current state of Layer 2 tunnels and information about
configured tunnels, including local and remote Layer 2 Tunneling Protocol
(L2TP) hostnames, aggregate packet counts, and control channel information.
•
Note
Tunnels should no longer be using the old control channel authentication
password. If a tunnel does not update to show that only one secret is
configured after several minutes have passed, that tunnel can be manually
cleared and a defect report should be filed with TAC. To manually clear an
L2TPv3 tunnel, perform the task “Manually Clearing L2TPv3 Tunnels.”
Issue this command to ensure that all tunnels are using only the new
password for control channel authentication. The output displayed for
each tunnel in the specified L2TP class should show that one secret is
configured.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
47
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring L2TP Control Channel Maintenance Parameters
The L2TP hello packet keepalive interval control channel maintenance parameter can be configured in
L2TP class configuration mode.
This task configures the interval used for hello messages in an L2TP class. This control channel
parameter configuration is optional. If this parameter is not configured, the default value will be applied.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
l2tp-class [l2tp-class-name]
4.
hello interval
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
l2tp-class [l2tp-class-name]
Example:
Specifies the L2TP class name and enters L2TP class
configuration mode.
•
Router(config)# l2tp-class class1
Step 4
hello interval
Example:
Router(config-l2tp-class)# hello 100
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
48
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) Specifies the exchange interval (in seconds) used
between L2TP hello packets.
•
Valid values for the interval argument range from 0 to
1000. The default value is 60.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring the L2TPv3 Pseudowire
The pseudowire class configuration procedure creates a configuration template for the pseudowire. You
use this template, or class, to configure session-level parameters for L2TPv3 sessions that will be used
to transport attachment circuit traffic over the pseudowire.
The pseudowire configuration specifies the characteristics of the L2TPv3 signaling mechanism,
including the data encapsulation type, the control protocol, sequencing, fragmentation, payload-specific
options, and IP properties. The setting that determines if signaling is used to set up the pseudowire is
also included.
For simple L2TPv3 signaling configurations on most platforms, pseudowire class configuration is
optional. However, specifying a source IP address to configure a loopback interface is highly
recommended. If you do not configure a loopback interface, the router will choose the best available
local address, which could be any IP address configured on a core-facing interface. This configuration
could prevent a control channel from being established. On the Cisco 12000 series Internet routers,
specifying a source IP address is mandatory, and you should configure a loopback interface that is
dedicated for the use of L2TPv3 sessions exclusively. If you do not configure other pseudowire class
configuration commands, the default values are used.
SUMMARY STEPS
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 | uti | protocol-number}
12. sequencing {transmit | receive | both}
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
49
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 3
Command or Action
Purpose
pseudowire-class [pw-class-name]
Enters pseudowire class configuration mode and optionally
specifies the name of the L2TP pseudowire class.
Example:
Router(config)# pseudowire-class etherpw
Step 4
encapsulation l2tpv3
Specifies that L2TPv3 is used as the data encapsulation
method to tunnel IP traffic.
Example:
Router(config-pw)# encapsulation l2tpv3
Step 5
protocol {l2tpv3 | none}[l2tp-class-name]
Example:
Router(config-pw)# protocol l2tpv3 class1
Step 6
ip local interface interface-name
Example:
(Optional) Specifies the L2TPv3 signaling protocol to be
used to manage the pseudowires created with the control
channel parameters in the specified L2TP class (see the
section “Configuring L2TP Control Channel Parameters”).
•
If the l2tp-class-name argument is not specified, the
default values for L2TP control channel parameters
will be used. The default protocol option is l2tpv3.
•
If you do not want to use signaling in the L2TPv3
sessions created with this pseudowire class, enter
protocol none. (The protocol none configuration is
necessary when configuring interoperability with a
remote peer that runs UTI.)
Specifies the PE router interface whose IP address is to be
used as the source IP address for sending tunneled packets.
•
Router(config-pw)# ip local interface e0/0
Note
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
50
Use the same local interface name for all pseudowire
classes configured between a pair of PE routers.
This command must be configured for
pseudowire-class configurations using L2TPv3 as
the data encapsulation method.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 7
Command or Action
Purpose
ip pmtu
(Optional) Enables the discovery of the path MTU for
tunneled traffic.
Example:
•
This command enables the processing of ICMP
unreachable messages that indicate fragmentation
errors in the backbone network that carries L2TPv3
session traffic. Also, this command enables MTU
checking for IP packets sent into the session and that
have the DF bit set. Any IP packet larger than the MTU
is dropped and an ICMP unreachable message is sent.
MTU discovery is disabled by default.
Note
The ip pmtu command is not supported if you
disabled signaling with the protocol none
command in Step 5.
•
This command must be enabled in the pseudowire class
configuration for fragmentation of IP packets before
the data enters the pseudowire to occur.
Router(config-pw)# ip pmtu
Note
Step 8
ip tos {value value | reflect}
Example:
Router(config-pw)# ip tos reflect
Step 9
ip dfbit set
Example:
(Optional) Configures the value of the ToS byte in IP
headers of tunneled packets, or reflects the ToS byte value
from the inner IP header.
•
ip ttl value
Example:
Router(config-pw)# ip ttl 100
Valid values for the value argument range from 0 to
255. The default ToS byte value is 0.
(Optional) Configures the value of the DF bit in the outer
headers of tunneled packets.
•
Router(config-pw)# ip dfbit set
Step 10
For fragmentation of IP packets before the data
enters the pseudowire, it is recommended that the ip
dfbit set command is also enabled in the
pseudowire class configuration. This allows the
PMTU to be obtained more rapidly.
Use this command if (for performance reasons) you do
not want reassembly of tunneled packets to be
performed on the peer PE router. This command is
disabled by default.
(Optional) Configures the value of the time to live (TTL)
byte in the IP headers of tunneled packets.
•
Valid values for the value argument range from 1 to
255. The default TTL byte value is 255.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
51
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 11
Command or Action
Purpose
ip protocol {l2tp | uti | protocol-number}
(Optional) Configures the IP protocol to be used for
tunneling packets.
•
Example:
Router(config-pw)# ip protocol uti
Step 12
sequencing {transmit | receive | both}
Example:
For backward compatibility with UTI, enter uti or 120,
the UTI protocol number. The default IP protocol value
is l2tp or 115, the L2TP protocol number.
(Optional) Specifies the direction in which sequencing of
data packets in a pseudowire is enabled:
•
transmit—Updates the Sequence Number field in the
headers of data packets sent over the pseudowire
according to the data encapsulation method that is used.
•
receive—Keeps the Sequence Number field in the
headers of data packets received over the pseudowire.
Out-of-order packets are dropped.
•
both—Enables both the transmit and receive options.
Router(config-pw)# sequencing both
Configuring the Xconnect Attachment Circuit
This configuration procedure binds an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to an
L2TPv3 pseudowire for xconnect service. The virtual circuit identifier that you configure creates the
binding between a pseudowire configured on a PE router and an attachment circuit in a CE device. The
virtual circuit identifier configured on the PE router at one end of the L2TPv3 control channel must also
be configured on the peer PE router at the other end.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
52
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type (for example, Ethernet) and slot and port
number, and enters interface configuration mode.
Example:
Router(config)# interface
ethernet 0/0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
53
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 4
Command or Action
Purpose
xconnect peer-ip-address vcid
pseudowire-parameters
[sequencing {transmit | receive
| both}]
Specifies the IP address of the peer PE router and the 32-bit virtual circuit
identifier shared between the PE at each end of the control channel.
Example:
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
At least one of the following pseudowire class parameters must be
configured for the pseudowire-parameters argument:
Router(config-if)# xconnect
10.0.3.201 123 pw-class
vlan-xconnect
– encapsulation {l2tpv3 [manual] | mpls}—Specifies the tunneling
method used to encapsulate data in the pseudowire:
•
l2tpv3—L2TPv3 is the tunneling method to be used.
•
manual—(Optional) No signaling is to be used in the L2TPv3 control
channel. This command places the router in xconnect configuration
mode for manual configuration of L2TPv3 parameters for the
attachment circuit.
•
mpls—MPLS is the tunneling method to be used.
– pw-class {pw-class-name}—The pseudowire class configuration
from which the data encapsulation type (L2TPv3) will be taken.
•
The optional encapsulation parameter specifies the method of pseudowire
tunneling used: L2TPv3 or MPLS. Enter manual if you do not want
signaling used in the L2TPv3 control channel. The encapsulation l2tpv3
manual keyword combination enters xconnect configuration submode.
See the section “Manually Configuring L2TPv3 Session Parameters” for
the other L2TPv3 commands that you must enter to complete the
configuration of the L2TPv3 control channel. If you do not enter an
encapsulation value, the encapsulation method entered with the
password command in the section “Configuring the Xconnect Attachment
Circuit” is used.
•
The optional pw-class parameter binds the xconnect statement to a
specific pseudowire class. The pseudowire class then serves as the
template configuration for all attachment circuits bound to it. Specify the
pseudowire-class option if you need to configure more advanced options.
Note
You must configure either the encapsulation or the pw-class option.
You may configure both options.
Note
If you select L2TPv3 as your data encapsulation method, you must
specify the pw-class keyword.
•
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
54
The optional sequencing parameter specifies whether sequencing is
required for packets that are received, sent, or both received and sent.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Manually Configuring L2TPv3 Session Parameters
When you bind an attachment circuit to an L2TPv3 pseudowire for xconnect service using the xconnect
l2tpv3 manual command (see the section “Configuring the Xconnect Attachment Circuit”) because you
do not want signaling, you must then configure L2TP-specific parameters to complete the L2TPv3
control channel configuration.
SUMMARY STEPS
1.
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
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Example:
Specifies the interface by type (for example, Ethernet) and
slot and port number, and enters interface configuration
mode.
Router(config)# interface ethernet 0/0
Step 4
xconnect peer-ip-address vc-id encapsulation
l2tpv3 manual pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit
virtual circuit identifier shared between the PE at each end
of the control channel.
Example:
•
Router(config-if)# xconnect 10.0.3.201 123
encapsulation l2tpv3 manual pw-class
vlan-xconnect
The peer router ID (IP address) and virtual circuit ID
must be a unique combination on the router.
•
The encapsulation l2tpv3 manual parameter specifies
that L2TPv3 is to be used as the pseudowire tunneling
method, and enters xconnect configuration mode.
•
The mandatory pw-class pw-class-name keyword and
argument combination specifies the pseudowire class
configuration from which the data encapsulation type
(L2TPv3) will be taken.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
55
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 5
Command or Action
Purpose
l2tp id local-session-id remote-session-id
Configures the identifiers for the local L2TPv3 session and
for the remote L2TPv3 session on the peer PE router.
•
Example:
Router(config-if-xconn)# l2tp id 222 111
Step 6
l2tp cookie local size low-value [high-value]
Example:
(Optional) Specifies the value that the peer PE must include
in the cookie field of incoming (received) L2TP packets.
•
The size of the cookie field can be 4 or 8 bytes. If you
do not enter this command, no cookie value is included
in the header of L2TP packets.
•
If you configure the cookie length in incoming packets
as 8 bytes, you must specify a 4-byte high value and a
4-byte low value.
Router(config-if-xconn)# l2tp cookie local 4
54321
Step 7
l2tp cookie remote size low-value [high-value]
Example:
(Optional) Specifies the value that the router includes in the
cookie field of outgoing (sent) L2TP packets.
•
The size of the cookie field can be 4 or 8 bytes. If you
do not enter this command, no cookie value is included
in the header of L2TP packets.
•
If you configure the cookie length in outgoing packets
as 8 bytes, you must specify a 4-byte high value and a
4-byte low value.
Router(config-if-xconn)# l2tp cookie remote 4
12345
Step 8
l2tp hello l2tp-class-name
Example:
Router(config-if-xconn)# l2tp hello
l2tp-defaults
This command is required to complete the attachment
circuit configuration and for a static L2TPv3 session
configuration.
(Optional) Specifies the L2TP class name to use (see the
section “Configuring L2TP Control Channel Parameters”)
for control channel configuration parameters, including the
interval to use between hello keepalive messages.
Note
This command assumes that there is no control
plane to negotiate control channel parameters and
that a control channel is to be used to provide
keepalive support through an exchange of L2TP
hello messages. By default, no hello messages are
sent.
Configuring the Xconnect Attachment Circuit for ATM VP Mode Single Cell
Relay over L2TPv3
The ATM VP Mode Single Cell Relay over L2TPv3 feature allows cells coming into a predefined PVP
on the ATM interface to be transported over an L2TPv3 pseudowire to a predefined PVP on the egress
ATM interface. This task binds a PVP to an L2TPv3 pseudowire for xconnect service.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
56
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
4.
atm pvp vpi [l2transport]
5.
xconnect peer-ip-address vcid pw-class pw-class-name
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM 4/1
Step 4
atm pvp vpi [l2transport]
Specifies that the PVP is dedicated to transporting ATM cells.
•
Example:
Router(config-if)# atm pvp 5
l2transport
Step 5
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The
pw-class parameter binds the xconnect statement to a specific
pseudowire class. The pseudowire class then serves as the template
configuration for all attachment circuits bound to it.
Example:
Router(config-if-atm-l2trans-pvp)#
xconnect 10.0.3.201 888 pw-class
atm-xconnect
The l2transport keyword indicates that the PVP is for cell relay. Once
you enter this command, the router enters l2transport PVP
configuration mode. This configuration mode is for Layer 2 transport
only; it is not for terminated PVPs.
Configuring the Xconnect Attachment Circuit for ATM Single Cell Relay VC
Mode over L2TPv3
The ATM Single Cell Relay VC Mode over L2TPv3 feature maps one VCC to a single L2TPv3 session.
All ATM cells arriving at an ATM interface with the specified VPI and VCI are encapsulated into a single
L2TP packet.
The ATM Single Cell Relay VC mode feature can be used to carry any type of AAL traffic over the
pseudowire. It will not distinguish OAM cells from User data cells. In this mode, PM and Security OAM
cells are also transported over the pseudowire.
Perform this task to enable the ATM Single Cell Relay VC Mode over L2TPv3 feature.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
57
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
SUMMARY STEPS
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
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
pvc [name] vpi/vci l2transport
Example:
Creates or assigns a name to an ATM PVC, specifies the encapsulation type on
an ATM PVC, and enters ATM VC configuration mode.
•
Router(config-if)# pvc 5/500
l2transport
Step 5
encapsulation aal0
Specifies ATM AAL0 encapsulation for the PVC.
Example:
Router(config-atm-vc)#
encapsulation aal0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
58
The l2transport keyword indicates that the PVC is for Layer 2 switched
connections. Once you enter this command, the router enters ATM VC
configuration mode.
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 6
Command or Action
Purpose
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
parameter binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Example:
Router(config-atm-vc)# xconnect
10.0.3.201 888 pw-class
atm-xconnect
Note
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Configuring the Xconnect Attachment Circuit for ATM Port Mode Cell Relay
over L2TPv3
The ATM Port Mode Cell Relay feature packs ATM cells arriving at an ingress ATM interface into
L2TPv3 data packets and transports them to the egress ATM interface. A single ATM cell is encapsulated
into each L2TPv3 data packet.
Perform this task to enable the ATM Port Mode Cell Relay over L2TPv3 feature.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
xconnect peer-ip-address vcid pw-class pw-class-name
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
59
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 3
Command or Action
Purpose
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
parameter binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Example:
Router(config-if)# xconnect
10.0.3.201 888 pw-class
atm-xconnect
Note
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Configuring the Xconnect Attachment Circuit for ATM Cell Packing over L2TPv3
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, page 60
•
Configuring VP Mode ATM Cell Packing over L2TPv3, page 62
•
Configuring VC Mode ATM Cell Packing over L2TPv3, page 63
Configuring Port Mode ATM Cell Packing over L2TPv3
Perform this task to configure port mode ATM cell packing over L2TPv3.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
atm mcpt-timers [timeout-value-1 timeout-value-2 timeout-value-3]
5.
cell packing [cells] [mcpt-timer timer]
6.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
60
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
atm mcpt-timers
[timeout-value-1
timeout-value-2
timeout-value-3]
(Optional) Sets up the cell-packing timers, which specify how long the PE
router can wait for cells to be packed into an L2TPv3 packet.
Example:
Router(config-if)# atm
mcpt-timers 10 100 1000
Step 5
cell-packing [cells]
[mcpt-timer timer]
Enables the packing of multiple ATM cells into each L2TPv3 data packet.
•
cells—(Optional) The number of cells to be packed into an L2TPv3 data
packet. The default number of ATM cells to be packed is the maximum
transmission unit (MTU) of the interface divided by 52.
•
mcpt-timer timer—(Optional) Specifies which maximum cell packing
timeout (MCPT) timer to use. The MCPT timers are set using the
mcpt-timers command. The default value is 1.
Example:
Router(config-if)# cell-packing
10 mcpt-timer 2
Step 6
xconnect peer-ip-address vcid
pseudowire-parameters
[sequencing {transmit | receive
| both}]
Binds an attachment circuit to a Layer 2 pseudowire and enters xconnect
configuration mode.
Example:
Router(config-if)# xconnect
10.0.3.201 888 encapsulation
l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
61
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring VP Mode ATM Cell Packing over L2TPv3
Perform this task to configure VP mode ATM cell packing over L2TPv3.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
atm mcpt-timers [timeout-value-1 timeout-value-2 timeout-value-3]
5.
atm pvp vpi [peak-rate] [l2transport]
6.
cell packing [cells] [mcpt-timer timer]
7.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
atm mcpt-timers
[timeout-value-1
timeout-value-2
timeout-value-3]
(Optional) Sets up the cell-packing timers, which specify how long the PE
router can wait for cells to be packed into an L2TPv3 packet.
Example:
Router(config-if)# atm
mcpt-timers 10 100 1000
Step 5
atm pvp vpi [peak-rate]
[l2transport]
Create a PVP used to multiplex (or bundle) one or more VCs.
Example:
Router(config-if)# atm pvp 10
l2transport
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
62
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 6
Command or Action
Purpose
cell-packing [cells]
[mcpt-timer timer]
Enables the packing of multiple ATM cells into each L2TPv3 data packet.
•
cells—(Optional) The number of cells to be packed into an L2TPv3 data
packet. The default number of ATM cells to be packed is the MTU of the
interface divided by 52.
•
mcpt-timer timer—(Optional) Specifies which MCPT timer to use. The
MCPT timers are set using the mcpt-timers command. The default value
is 1.
Example:
Router(config-if)# cell-packing
10 mcpt-timer 2
Step 7
xconnect peer-ip-address vcid
pseudowire-parameters
[sequencing {transmit | receive
| both}]
Binds an attachment circuit to a Layer 2 pseudowire and enters xconnect
configuration mode.
Example:
Router(config-if)# xconnect
10.0.3.201 888 encapsulation
l2tpv3
Configuring VC Mode ATM Cell Packing over L2TPv3
Perform this task to configure VC mode ATM cell packing over L2TPv3.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
atm mcpt-timers [timeout-value-1 timeout-value-2 timeout-value-3]
5.
pvc [name] vpi/vci [ces | ilmi | qsaal | smds | l2transport]
6.
cell packing [cells] [mcpt-timer timer]
7.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
63
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 3
Command or Action
Purpose
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
atm mcpt-timers
[timeout-value-1
timeout-value-2
timeout-value-3]
(Optional) Sets up the cell-packing timers, which specify how long the PE
router can wait for cells to be packed into an L2TPv3 packet.
Example:
Router(config-if)# atm
mcpt-timers 10 100 1000
Step 5
pvc [name] vpi/vci [ces | ilmi
| qsaal | smds | l2transport]
Creates or assigns a name to an ATM PVC, specifies the encapsulation type on
an ATM PVC, and enters ATM VC configuration mode.
Example:
Router(config-if)# pvc 1/32
l2transport
Step 6
cell-packing [cells]
[mcpt-timer timer]
Enables the packing of multiple ATM cells into each L2TPv3 data packet.
•
cells—(Optional) The number of cells to be packed into an L2TPv3 data
packet. The default number of ATM cells to be packed is the MTU of the
interface divided by 52.
•
mcpt-timer timer—(Optional) Specifies which timer to use. The mcpt
timers are set using the mcpt-timers command. The default value is 1.
Example:
Router(config-if-atm-vc)#
cell-packing 10 mcpt-timer 2
Step 7
xconnect peer-ip-address vcid
pseudowire-parameters
[sequencing {transmit | receive
| both}]
Binds an attachment circuit to a Layer 2 pseudowire and enters xconnect
configuration mode.
Example:
Router(config-if-atm-vc)#
xconnect 10.0.3.201 888
encapsulation l2tpv3
Configuring the Xconnect Attachment Circuit for ATM AAL5 SDU Mode 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.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
64
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
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, page 65
•
Configuring ATM AAL5 SDU Mode over L2TPv3 in VC Class Configuration Mode, page 66
Configuring ATM AAL5 SDU Mode over L2TPv3 in ATM VC Configuration Mode
Perform this task to bind a PVC to an L2TPv3 pseudowire for ATM AAL5 SDU mode xconnect service.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
pvc [name] vpi/vci [l2transport]
5.
encapsulation aal5
6.
xconnect peer-ip-address vcid pw-class pw-class-name
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
pvc [name] vpi/vci
[l2transport]
Example:
Router(config-if)# pvc 5/500
l2transport
Creates or assigns a name to an ATM permanent virtual circuit (PVC),
specifies the encapsulation type on an ATM PVC, and enters ATM VC
configuration mode.
•
The l2transport keyword indicates that the PVC is for Layer 2 switched
connections. Once you enter this command, the router enters ATM VC
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
65
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 5
Command or Action
Purpose
encapsulation aal5
Specifies ATM AAL5 encapsulation for the PVC.
Example:
Router(config-atm-vc)#
encapsulation aal5
Step 6
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
keyword binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Example:
Router(config-atm-vc)# xconnect
10.0.3.201 888 pw-class
atm-xconnect
Note
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Configuring ATM AAL5 SDU Mode over L2TPv3 in VC Class Configuration Mode
You can create a VC class that specifies AAL5 encapsulation and then attach the VC class to an interface,
subinterface, or PVC. Perform this task to create a VC class configured for AAL5 encapsulation and
attach the VC class to an interface.
Restrictions
This task requires Cisco IOS Release 12.0(30)S or a later release.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
vc-class atm vc-class-name
4.
encapsulation layer-type
5.
end
6.
interface type slot/port
7.
class-int vc-class-name
8.
pvc [name] vpi/vci l2transport
9.
xconnect peer-router-id vcid encapsulation l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
66
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
vc-class atm name
Creates a VC class and enters VC class configuration
mode.
Example:
Router(config)# vc-class atm aal5class
Step 4
encapsulation layer-type
Configures the ATM adaptation layer (AAL) and
encapsulation type.
Example:
Router(config-vc-class)# encapsulation aal5
Step 5
end
Ends your configuration session by exiting to privileged
EXEC mode.
Example:
Router(config-vc-class)# end
Step 6
interface type slot/port
Specifies the interface by type, slot, and port number, and
enters interface configuration mode.
Example:
Router(config)# interface atm 1/0
Step 7
class-int vc-class-name
Applies a VC class on an the ATM main interface or
subinterface.
Example:
Note
You can also apply a VC class to a PVC.
Router(config-if)# class-int aal5class
Step 8
pvc [name] vpi/vci l2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Step 9
xconnect peer-router-id vcid encapsulation
l2tpv3
Creates or assigns a name to an ATM permanent virtual
circuit (PVC), specifies the encapsulation type on an
ATM PVC, and enters ATM VC configuration mode.
•
The l2transport keyword indicates that the PVC is
for Layer 2 switched connections. Once you enter
this command, the router enters ATM VC
configuration mode.
Binds the attachment circuit to a pseudowire VC.
Example:
Router(config-if-atm-l2trans-pvc)# xconnect
10.13.13.13 100 encapsulation l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
67
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3
If a PE router does not support the transport of OAM cells across an L2TPv3 session, you can use OAM
cell emulation to locally terminate or loopback the OAM cells. You configure OAM cell emulation on
both PE routers. You use the oam-ac emulation-enable command on both PE routers to enable OAM
cell emulation.
After you enable OAM cell emulation on a router, you can configure and manage the ATM VC in the
same manner as you would a terminated VC. A VC that has been configured with OAM cell emulation
can send loopback cells at configured intervals toward the local CE router. The endpoint can be either of
the following:
•
End-to-end loopback, which sends OAM cells to the local CE router.
•
Segment loopback, which responds to OAM cells to a device along the path between the PE and CE
routers.
The OAM cells have the following information cells:
•
Alarm indication signal (AIS)
•
Remote defect indication (RDI)
These cells identify and report defects along a VC. When a physical link or interface failure occurs,
intermediate nodes insert OAM AIS cells into all the downstream devices affected by the failure. When
a router receives an AIS cell, it marks the ATM VC as down and sends an RDI cell to let the remote end
know about the failure.
Beginning in Cisco IOS Release 12.0(30)S, you may choose to configure the OAM Local Emulation for
ATM AAL5 over L2TPv3 feature in ATM VC configuration mode or in VC class configuration mode.
To enable the OAM Local Emulation for ATM AAL5 over L2TPv3 feature, perform one of the following
tasks:
•
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3 in ATM VC Configuration Mode,
page 68
•
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3 in VC Class Configuration Mode,
page 70
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3 in ATM VC Configuration Mode
Perform this task to enable the OAM Local Emulation for ATM AAL5 over L2TPv3 feature in ATM VC
configuration mode.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
pvc [name] vpi/vci [l2transport]
5.
encapsulation aal5
6.
xconnect peer-ip-address vcid pw-class pw-class-name
7.
oam-ac emulation-enable [ais-rate]
8.
oam-pvc manage [frequency]
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
68
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface ATM
4/1
Step 4
pvc [name] vpi/vci
[l2transport]
Creates or assigns a name to an ATM PVC, specifies the encapsulation type on
an ATM PVC, and enters ATM VC configuration mode.
•
Example:
Router(config-if)# pvc 5/500
l2transport
Step 5
encapsulation aal5
The l2transport keyword indicates that the PVC is for Layer 2 switched
connections. Once you enter this command, the router enters ATM VC
configuration mode.
Specifies ATM AAL5 encapsulation for the PVC.
Example:
Router(config-atm-vc)#
encapsulation aal5
Step 6
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
parameter binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Example:
Router(config-atm-vc)# xconnect
10.0.3.201 888 pw-class
atm-xconnect
Note
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
69
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 7
Command or Action
Purpose
oam-ac emulation-enable
[ais-rate]
Enables OAM cell emulation on AAL5 over L2TPv3.
•
Example:
The oam-ac emulation-enable command lets you specify the rate at
which AIS cells are sent. The default is one cell every second. The range
is 0 to 60 seconds.
Router(config-atm-vc)# oam-ac
emulation-enable 30
Step 8
oam-pvc manage [frequency]
(Optional) Enables the PVC to generate end-to-end OAM loopback cells that
verify connectivity on the virtual circuit.
•
Example:
Router(config-atm-vc)# oam-pvc
manage
Note
The optional frequency argument is the interval between transmission of
loopback cells and ranges from 0 to 600 seconds. The default value is
10 seconds.
You can configure the oam-pvc manage command only after you issue
the oam-ac emulation-enable command.
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3 in VC Class Configuration Mode
This task configures OAM Cell Emulation as part of a VC class. Once a VC class is configured, you can
apply the VC class to an interface, a subinterface, or a VC.
When you apply a VC class to an interface, the settings in the VC class apply to all the VCs on that
interface unless you specify otherwise at a lower level, such as the subinterface or VC level. For example,
if you create a VC class that specifies OAM cell emulation and sets the AIS cell rate to 30 seconds and
apply that VC class to an interface, every VC on that interface will use the AIS cell rate of 30 seconds.
If you then enable OAM cell emulation on a single PVC and set the AIS cell rate to 15 seconds, the 15
second AIS cell rate configured at the PVC level will take precedence over the 30 second AIS cell rate
configured at the interface level.
Perform this task to create a VC class configured for OAM emulation and to attach the VC class to an
interface.
Restrictions
This task requires Cisco IOS Release 12.0(30)S or a later release.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
vc-class atm name
4.
encapsulation layer-type
5.
oam-ac emulation-enable [ais-rate]
6.
oam-pvc manage [frequency]
7.
end
8.
interface type slot/port
9.
class-int vc-class-name
10. pvc [name] vpi/vci l2transport
11. xconnect peer-router-id vcid encapsulation l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
70
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
vc-class atm name
Creates a VC class and enters vc-class configuration
mode.
Example:
Router(config)# vc-class atm oamclass
Step 4
encapsulation layer-type
Configures the ATM adaptation layer (AAL) and
encapsulation type.
Example:
Router(config-vc-class)# encapsulation aal5
Step 5
oam-ac emulation-enable [ais-rate]
Enables OAM cell emulation for AAL5 over L2TPv3.
•
Example:
Router(config-vc-class)# oam-ac emulation-enable
30
Step 6
oam-pvc manage [frequency]
Example:
Router(config-vc-class)# oam-pvc manage
(Optional) Enables the PVC to generate end-to-end
OAM loopback cells that verify connectivity on the
virtual circuit.
•
Note
Step 7
end
The ais-rate variable lets you specify the rate at
which AIS cells are sent. The default is one cell
every second. The range is 0 to 60 seconds.
The optional frequency argument is the interval
between transmission of loopback cells and ranges
from 0 to 600 seconds. The default value is
10 seconds.
You can configure the oam-pvc manage
command only after you issue the oam-ac
emulation-enable command.
Ends your configuration session by exiting to privileged
EXEC mode.
Example:
Router(config-vc-class)# end
Step 8
interface type slot/port
Specifies the interface by type, slot, and port number, and
enters interface configuration mode.
Example:
Router(config)# interface atm1/0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
71
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 9
class-int vc-class-name
Applies a VC class on an the ATM main interface or
subinterface.
Example:
Note
You can also apply a VC class to a PVC.
Router(config-if)# class-int oamclass
Step 10
pvc [name] vpi/vci l2transport
Example:
Creates or assigns a name to an ATM PVC, specifies the
encapsulation type on an ATM PVC, and enters ATM VC
configuration mode.
•
Router(config-if)# pvc 1/200 l2transport
Step 11
xconnect peer-router-id vcid encapsulation
l2tpv3
The l2transport keyword indicates that the PVC is
for Layer 2 switched connections. Once you enter
this command, the router enters ATM VC
configuration mode.
Binds the attachment circuit to a pseudowire VC.
Example:
Router(config-if-atm-l2trans-pvc)# xconnect
10.13.13.13 100 encapsulation l2tpv3
Configuring Protocol Demultiplexing for L2TPv3
The Protocol Demultiplexing feature introduces the ability to provide native IPv6 support by utilizing a
specialized IPv6 network to offload IPv6 traffic from the IPv4 network. IPv6 traffic is transparently
tunneled to the IPv6 network using L2TPv3 pseudowires without affecting the configuration of the CE
routers. IPv4 traffic is routed as usual within the IPv4 network, maintaining the existing performance
and reliability of the IPv4 network.
The IPv4 PE routers must be configured to demultiplex incoming IPv6 traffic from IPv4 traffic. The PE
routers facing the IPv6 network do not require demultiplexing configuration. The configuration of the
IPv6 network is beyond the scope of this document. For more information on configuring an IPv6
network, refer to the Cisco IOS IPv6 Configuration Library.
Perform one of the following tasks on the customer-facing IPv4 PE routers to enable IPv6 protocol
demultiplexing:
•
Configuring Protocol Demultiplexing for Ethernet Interfaces, page 72
•
Configuring Protocol Demultiplexing for Frame Relay Interfaces, page 74
Configuring Protocol Demultiplexing for Ethernet Interfaces
Perform this task to configure the Protocol Demultiplexing feature on an Ethernet interface.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port
4.
ip address ip-address mask [secondary]
5.
xconnect peer-ip-address vcid pw-class pw-class-name
6.
match protocol ipv6
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
72
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type slot/port
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface
ethernet 0/1
Step 4
ip address ip-address mask
[secondary]
Sets a primary or secondary IP address for an interface.
Example:
Router(config-if)# ip address
172.16.128.4
Step 5
xconnect peer-ip-address vcid
pw-class pw-class-name
Example:
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel and enters xconnect
configuration mode.
•
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
parameter binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Router(config-if)# xconnect
10.0.3.201 888 pw-class demux
Note
Step 6
match protocol ipv6
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Enables protocol demultiplexing of IPv6 traffic.
Example:
Router(config-if-xconn)# match
protocol ipv6
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
73
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Configuring Protocol Demultiplexing for Frame Relay Interfaces
Perform this task to configure the Protocol Demultiplexing feature on a Frame Relay interface.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type slot/port-adapter.subinterface-number [multipoint | point-to-point]
4.
ip address ip-address mask [secondary]
5.
frame-relay interface-dlci dlci [ietf | cisco] [voice-cir cir] [ppp virtual-template-name]
6.
xconnect peer-ip-address vcid pw-class pw-class-name
7.
match protocol ipv6
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
interface type
slot/port-adapter.subinterfacenumber [multipoint |
point-to-point]
Specifies the interface by type, slot, and port number, and enters interface
configuration mode.
Example:
Router(config)# interface
serial 1/1.2 multipoint
Step 4
ip address ip-address mask
[secondary]
Sets a primary or secondary IP address for an interface.
Example:
Router(config-if)# ip address
172.16.128.4
Step 5
frame-relay interface-dlci dlci
[ietf | cisco] [voice-cir cir]
[ppp virtual-template-name]
Assigns a DLCI to a specified Frame Relay subinterface on the router or access
server, assigns a specific PVC to a DLCI, or applies a virtual template
configuration for a PPP session and enters Frame Relay DLCI interface
configuration mode.
Example:
Router(config-if)# frame-relay
interface-dlci 100
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
74
Layer 2 Tunnel Protocol Version 3
How to Configure Layer 2 Tunnel Protocol Version 3
Step 6
Command or Action
Purpose
xconnect peer-ip-address vcid
pw-class pw-class-name
Specifies the IP address of the peer PE router and the 32-bit VCI shared
between the PE at each end of the control channel and enters xconnect
configuration mode.
Example:
•
Router(config-fr-dlci)#
xconnect 10.0.3.201 888
pw-class atm-xconnect
The peer router ID (IP address) and virtual circuit ID must be a unique
combination on the router.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. The pw-class
parameter binds the xconnect statement to a specific pseudowire class. The
pseudowire class then serves as the template configuration for all
attachment circuits bound to it.
Note
Step 7
match protocol ipv6
The L2TPv3 session can also be provisioned manually. See the section
“Manually Configuring L2TPv3 Session Parameters” for information
about manually configuring the L2TPv3 session parameters.
Enables protocol demultiplexing of IPv6 traffic.
Example:
Router(config-if-xconn)# match
protocol ipv6
Manually Clearing L2TPv3 Tunnels
Perform this task to manually clear a specific L2TPv3 tunnel and all the sessions in that tunnel.
SUMMARY STEPS
1.
enable
2.
clear l2tun {l2tp-class l2tp-class-name | tunid tunnel-id | local ip ip-address | remote ip ip-address
| all}
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
75
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
DETAILED STEPS
Step 1
Enables privileged EXEC mode.
enable
•
Enter your password if prompted.
Example:
Router> enable
Step 2
clear l2tun {l2tp-class
l2tp-class-name | tunid
tunnel-id | local ip ip-address
| remote ip ip-address | all}
(Optional) Clears the specified L2TPv3 tunnel.
•
l2tp-class l2tp-class-name—All L2TPv3 tunnels with the specified L2TP
class name will be torn down.
•
tunid tunnel-id—The L2TPv3 tunnel with the specified tunnel ID will be
torn down.
•
local ip ip-address—All L2TPv3 tunnels with the specified local IP
address will be torn down.
•
remote ip ip-address—All L2TPv3 tunnels with the specified remote IP
address will be torn down.
•
all—All L2TPv3 tunnels will be torn down.
Example:
Router# clear l2tun tunid 56789
Configuration Examples for Layer 2 Tunnel Protocol Version 3
This section provides the following configuration examples:
•
Configuring a Static L2TPv3 Session for an Xconnect Ethernet Interface: Example, page 77
•
Configuring a Negotiated L2TPv3 Session for an Xconnect VLAN Subinterface: Example, page 78
•
Configuring a Negotiated L2TPv3 Session for Local HDLC Switching: Example, page 78
•
Verifying an L2TPv3 Session: Example, page 79
•
Verifying an L2TP Control Channel: Example, page 79
•
Configuring L2TPv3 Control Channel Authentication: Examples, page 80
•
Configuring L2TPv3 Digest Secret Graceful Switchover: Example, page 80
•
Verifying L2TPv3 Digest Secret Graceful Switchover: Example, page 81
•
Configuring Frame Relay DLCI-to-DLCI Switching: Example, page 87
•
Configuring ATM VP Mode Single Cell Relay over L2TPv3: Example, page 81
•
Verifying ATM VP Mode Single Cell Relay over L2TPv3 Configuration: Example, page 82
•
Configuring ATM Single Cell Relay VC Mode over L2TPv3: Example, page 82
•
Verifying ATM Single Cell Relay VC Mode over L2TPv3: Example, page 82
•
Configuring ATM Port Mode Cell Relay over L2TPv3: Example, page 83
•
Configuring ATM Cell Packing over L2TPv3: Examples, page 83
•
Configuring ATM AAL5 SDU Mode over L2TPv3: Examples, page 84
•
Verifying ATM AAL5 SDU Mode over L2TPv3 Configuration: Examples, page 84
•
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3: Examples, page 85
•
Verifying OAM Local Emulation for ATM AAL5 over L2TPv3 Configuration: Examples, page 86
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
76
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
•
Configuring Protocol Demultiplexing for L2TPv3: Examples, page 86
•
Manually Clearing an L2TPv3 Tunnel: Example, page 87
•
Configuring Frame Relay DLCI-to-DLCI Switching: Example, page 87
•
Configuring Frame Relay Trunking: Example, page 87
•
Configuring QoS for L2TPv3 on the Cisco 7500 Series: Example, page 88
•
Configuring QoS for L2TPv3 on the Cisco 12000 Series: Examples, page 88
•
Configuring a QoS Policy for Committed Information Rate Guarantees: Example, page 94
•
Setting the Frame Relay DE Bit Configuration: Example, page 94
•
Matching the Frame Relay DE Bit Configuration: Example, page 95
•
Configuring MLFR for L2TPv3 on the Cisco 12000 Series: Example, page 96
•
Configuring an MQC for Committed Information Rate Guarantees: Example, page 96
Configuring a Static L2TPv3 Session for an Xconnect Ethernet
Interface: Example
L2TPv3 is the only encapsulation method that supports a manually provisioned session setup. This
example shows how to configure a static session configuration in which all control channel parameters
are set up in advance. There is no control plane used and no negotiation phase to set up the control
channel. The PE router starts sending tunneled traffic as soon as the Ethernet interface (int e0/0) comes
up. The virtual circuit identifier, 123, is not used. The PE sends L2TP data packets with session ID 111
and cookie 12345. In turn, the PE expects to receive L2TP data packets with session ID 222 and cookie
54321.
l2tp-class l2tp-defaults
retransmit initial retries 30
cookie-size 8
pseudowire-class ether-pw
encapsulation l2tpv3
protocol none
ip local interface Loopback0
interface Ethernet 0/0
xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
l2tp id 222 111
l2tp cookie local 4 54321
l2tp cookie remote 4 12345
l2tp hello l2tp-defaults
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
77
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring a Negotiated L2TPv3 Session for an Xconnect VLAN
Subinterface: Example
The following is a sample configuration of a dynamic L2TPv3 session for a VLAN xconnect interface.
In this example, only VLAN traffic with a VLAN ID of 5 is tunneled. In the other direction, the L2TPv3
session identified by a virtual circuit identifier of 123 receives forwarded frames whose VLAN ID fields
are rewritten to contain the value 5. L2TPv3 is used as both the control plane protocol and the data
encapsulation.
l2tp-class class1
authentication
password secret
pseudowire-class vlan-xconnect
encapsulation l2tpv3
protocol l2tpv3 class1
ip local interface Loopback0
interface Ethernet0/0.1
encapsulation dot1Q 5
xconnect 10.0.3.201 123 pw-class vlan-xconnect
Configuring a Negotiated L2TPv3 Session for Local HDLC Switching: Example
The following is a sample configuration of a dynamic L2TPv3 session for local HDLC switching. In this
example, note that it is necessary to configure two different IP addresses at the endpoints of the L2TPv3
pseudowire because the virtual circuit identifier must be unique for a given IP address.
interface loopback 1
ip address 10.0.0.1 255.255.255.255
interface loopback 2
ip address 10.0.0.2 255.255.255.255
pseudowire-class loopback1
encapsulation l2tpv3
ip local interface loopback1
pseudowire-class loopback2
encapsulation l2tpv3
ip local interface loopback2
interface s0/0
encapsulation hdlc
xconnect 10.0.0.1 100 pw-class loopback2
interface s0/1
encapsulation hdlc
xconnect 10.0.0.2 100 pw-class loopback1
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
78
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Verifying an L2TPv3 Session: Example
To display detailed information about current L2TPv3 sessions on a router, use the show l2tun session
all command:
Router# show l2tunnel session all
Session Information Total tunnels 0 sessions 1
Session id 111 is up, tunnel id 0
Call serial number is 0
Remote tunnel name is
Internet address is 10.0.0.1
Session is manually signalled
Session state is established, time since change 00:06:05
0 Packets sent, 0 received
0 Bytes sent, 0 received
Receive packets dropped:
out-of-order:
0
total:
0
Send packets dropped:
exceeded session MTU:
0
total:
0
Session vcid is 123
Session Layer 2 circuit, type is ATM VPC CELL, name is ATM3/0/0:1000007
Circuit state is UP
Remote session id is 222, remote tunnel id 0
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
Session cookie information:
local cookie, size 8 bytes, value 00 00 00 00 00 00 00 64
remote cookie, size 8 bytes, value 00 00 00 00 00 00 00 C8
SSS switching enabled
Sequencing is off
Verifying an L2TP Control Channel: Example
To display detailed information the L2TP control channels that are set up to other L2TP-enabled devices
for all L2TP sessions on the router, use the show l2tun tunnel all command. The L2TP control channel
is used to negotiate capabilities, monitor the health of the peer PE router, and set up various components
of an L2TPv3 session.
Router# show l2tun tunnel all
Tunnel id 26515 is up, remote id is 41814, 1 active sessions
Tunnel state is established, time since change 03:11:50
Tunnel transport is IP (115)
Remote tunnel name is tun1
Internet Address 172.18.184.142, port 0
Local tunnel name is Router
Internet Address 172.18.184.116, port 0
Tunnel domain is
VPDN group for tunnel is
0 packets sent, 0 received
0 bytes sent, 0 received
Control Ns 11507, Nr 11506
Local RWS 2048 (default), Remote RWS 800
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 1, max 1
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
79
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Total resends 0, ZLB ACKs sent 11505
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
Configuring L2TPv3 Control Channel Authentication: Examples
The following example configures CHAP-style authentication of the L2TPv3 control channel:
l2tp-class class0
authentication
password cisco
The following example configures control channel authentication using the L2TPv3 Control Message
Hashing feature:
l2tp-class class1
digest secret cisco hash sha
hidden
The following example configures control channel integrity checking and disables validation of the
message digest using the L2TPv3 Control Message Hashing feature:
l2tp-class class2
digest hash sha
no digest check
The following example disables validation of the message digest using the L2TPv3 Control Message
Hashing feature:
l2tp-class class3
no digest check
Configuring L2TPv3 Digest Secret Graceful Switchover: Example
The following example uses the L2TPv3 Digest Secret Graceful Switchover feature to change the L2TP
control channel authentication password for the L2TP class named class1. This example assumes that
you already have an old password configured for the L2TP class named class1.
Router(config)# l2tp-class class1
Router(config-l2tp-class)# digest secret cisco2 hash sha
!
! Verify that all peer PE routers have been updated to use the new password before
! removing the old password.
!
Router(config-l2tp-class)# no digest secret cisco hash sha
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
80
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Verifying L2TPv3 Digest Secret Graceful Switchover: Example
The following show l2tun tunnel all command output shows information about the L2TPv3 Digest
Secret Graceful Switchover feature:
Router# show l2tun tunnel all
! The output below displays control channel password information for a tunnel which has
! been updated with the new control channel authentication password.
!
Tunnel id 12345 is up, remote id is 54321, 1 active sessions
Control message authentication is on, 2 secrets configured
Last message authenticated with first digest secret
!
! The output below displays control channel password information for a tunnel which has
! only a single control channel authentication password configured.
!
Tunnel id 23456 is up, remote id is 65432, 1 active sessions
!
Control message authentication is on, 1 secrets configured
Last message authenticated with first digest secret
!
! The output below displays control channel password information for a tunnel which is
! communicating with a peer that has only the new control channel authentication password
! configured.
!
Tunnel id 56789 is up, remote id is 98765, 1 active sessions
!
Control message authentication is on, 2 secrets configured
Last message authenticated with second digest secret
Configuring a Pseudowire Class for Fragmentation of IP Packets: Example
The following is a sample configuration of a pseudowire class that will allow IP traffic generated from
the CE router to be fragmented before entering the pseudowire:
pseudowire class class1
encapsulation l2tpv3
ip local interface Loopback0
ip pmtu
ip dfbit set
Configuring ATM VP Mode Single Cell Relay over L2TPv3: Example
The following configuration binds a PVP to an xconnect attachment circuit to forward ATM cells over
an established L2TPv3 pseudowire:
pw-class atm-xconnect
encapsulation l2tpv3
interface ATM 4/1
atm pvp 5 l2transport
xconnect 10.0.3.201 888 pw-class atm-xconnect
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
81
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Verifying ATM VP Mode Single Cell Relay over L2TPv3 Configuration: Example
To verify the configuration of a PVP, use the show atm vp command in privileged EXEC mode:
Router# show atm vp 5
ATM4/1/0 VPI: 5, Cell-Relay, PeakRate: 155000, CesRate: 0, DataVCs: 0,
CesVCs: 0, Status: ACTIVE
VCD
8
9
VCI Type
3 PVC
4 PVC
InPkts
0
0
OutPkts
0
0
AAL/Encap
F4 OAM
F4 OAM
Status
ACTIVE
ACTIVE
TotalInPkts: 0, TotalOutPkts: 0, TotalInFast: 0, TotalOutFast: 0,
TotalBroadcasts: 0
Configuring ATM Single Cell Relay VC Mode over L2TPv3: Example
The following example shows how to configure the ATM Single Cell Relay VC Mode over L2TPv3
feature:
pw-class atm-xconnect
encapsulation l2tpv3
interface ATM 4/1
pvc 5/500 l2transport
encapsulation aal0
xconnect 10.0.3.201 888 pw-class atm-xconnect
Verifying ATM Single Cell Relay VC Mode over L2TPv3: Example
The following show atm vc command output displays information about VCC cell relay configuration:
Router# show atm vc
VCD/
Interface
2/0
Name
4
VPI
9
VCI
901
Type
PVC
Encaps
AAL0
Peak
Kbps
149760
Avg/Min
Kbps
N/A
Burst
Cells
The following show l2tun session command output displays information about VCC cell relay
configuration:
Router# show l2tun session all
Session Information Total tunnels 1 sessions 2
Session id 41883 is up, tunnel id 18252
Call serial number is 3211600003
Remote tunnel name is khur-l2tp
Internet address is 10.0.0.2
Session is L2TP signalled
Session state is established, time since change 00:00:38
8 Packets sent, 8 received
416 Bytes sent, 416 received
Receive packets dropped:
out-of-order:
0
total:
0
Send packets dropped:
exceeded session MTU:
0
total:
0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
82
Sts
UP
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Session vcid is 124
Session Layer 2 circuit, type is ATM VCC CELL, name is ATM2/0:9/901
Circuit state is UP
Remote session id is 38005, remote tunnel id 52436
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
No session cookie information available
FS cached header information:
encap size = 24 bytes
00000000 00000000 00000000 00000000
00000000 00000000
Sequencing is off
Configuring ATM Port Mode Cell Relay over L2TPv3: Example
The following example shows how to configure the ATM Port Mode Cell Relay over L2TPv3 feature:
pw-class atm-xconnect
encapsulation l2tpv3
interface atm 4/1
xconnect 10.0.3.201 888 pw-class atm-xconnect
Configuring ATM Cell Packing over L2TPv3: Examples
The following examples show how to configure the ATM Cell Packing over L2TPv3 feature for Port
mode, VP mode, and VC mode:
Port Mode
interface atm 4/1
atm mcpt-timers 10 100 1000
cell-packing 10 mcpt-timer 2
xconnect 10.0.3.201 888 encapsulation l2tpv3
VP Mode
interface atm 4/1
atm mcpt-timers 10 100 1000
atm pvp 10 l2transport
cell-packing 10 mcpt-timer 2
xconnect 10.0.3.201 888 encapsulation l2tpv3
VC Mode
interface atm 4/1
atm mcpt-timers 10 100 1000
pvc 1/32 l2transport
cell-packing 10 mcpt-timer 2
xconnect 10.0.3.201 888 encapsulation l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
83
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring ATM AAL5 SDU Mode over L2TPv3: Examples
Configuring ATM AAL5 SDU Mode over L2TPv3 in ATM VC Configuration Mode
The following configuration binds a PVC to an xconnect attachment circuit to forward ATM cells over
an established L2TPv3 pseudowire:
pw-class atm-xconnect
encapsulation l2tpv3
interface atm 4/1
pvc 5/500 l2transport
encapsulation aal5
xconnect 10.0.3.201 888 pw-class atm-xconnect
Configuring ATM AAL5 SDU Mode over L2TPv3 in VC-Class Configuration Mode
The following example configures ATM AAL5 over L2TPv3 in VC class configuration mode. The VC
class is then applied to an interface.
vc-class atm aal5class
encapsulation aal5
!
interface atm 1/0
class-int aal5class
pvc 1/200 l2transport
xconnect 10.13.13.13 100 encapsulation l2tpv3
Verifying ATM AAL5 SDU Mode over L2TPv3 Configuration: Examples
Verifying ATM AAL5 over MPLS in ATM VC Configuration Mode
To verify the configuration of a PVC, use the show atm vc command in privileged EXEC mode:
Router# show atm vc
VCD/
Interface
2/0
2/0
Name
pvc
4
VPI
9
9
VCI
900
901
Type
PVC
PVC
Encaps
AAL5
AAL5
Peak
Kbps
2400
149760
Avg/Min
Kbps
200
N/A
Burst
Cells
Sts
UP
UP
The following show l2tun session command output displays information about ATM VC mode
configurations:
Router# show l2tun session brief
Session Information Total tunnels 1 sessions 2
LocID
TunID
Peer-address
State
sess/cir
41875
18252
10.0.0.2
est,UP
111
0
10.0.0.2
est,UP
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
84
Username, Intf/
Vcid, Circuit
124, AT2/0:9/901
123, AT2/0:9/900
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Verifying ATM AAL5 over MPLS in VC Class Configuration Mode
To verify that ATM AAL5 over L2TPv3 is configured as part of a VC class, issue the show atm
class-links command. The command output shows the type of encapsulation and that the VC class was
applied to an interface.
Router# show atm class links 1/100
Displaying vc-class inheritance for ATM1/0.0, vc 1/100:
no broadcast - Not configured - using default
encapsulation aal5 - VC-class configured on main interface
.
.
.
Configuring OAM Local Emulation for ATM AAL5 over L2TPv3: Examples
Configuring OAM Cell Emulation for ATM AAL5 over L2TPv3 in ATM VC Configuration Mode
The following configuration binds a PVC to an xconnect attachment circuit to forward ATM AAL5
frames over an established L2TPv3 pseudowire, enables OAM local emulation, and specifies that AIS
cells will be sent every 30 seconds:
pw-class atm-xconnect
encapsulation l2tpv3
interface ATM 4/1
pvc 5/500 l2transport
encapsulation aal5
xconnect 10.0.3.201 888 pw-class atm-xconnect
oam-ac emulation-enable 30
Configuring OAM Cell Emulation for ATM AAL5 over L2TPv3 in VC Class Configuration Mode
The following example configures OAM cell emulation for ATM AAL5 over L2TPv3 in VC class
configuration mode. The VC class is then applied to an interface.
vc-class atm oamclass
encapsulation aal5
oam-ac emulation-enable 30
oam-pvc manage
!
interface atm1/0
class-int oamclass
pvc 1/200 l2transport
xconnect 10.13.13.13 100 encapsulation l2tpv3
The following example configures OAM cell emulation for ATM AAL5 over L2TPv3 in VC class
configuration mode. The VC class is then applied to a PVC.
vc-class atm oamclass
encapsulation aal5
oam-ac emulation-enable 30
oam-pvc manage
!
interface atm1/0
pvc 1/200 l2transport
class-vc oamclass
xconnect 10.13.13.13 100 encapsulation l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
85
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
The following example configures OAM cell emulation for ATM AAL5 over L2TPv3 in VC class
configuration mode. The OAM cell emulation AIS rate is set to 30 for the VC class. The VC class is then
applied to an interface. One PVC is configured with OAM cell emulation at an AIS rate of 10. That PVC
uses the AIS rate of 10 instead of 30.
vc-class atm oamclass
encapsulation aal5
oam-ac emulation-enable 30
oam-pvc manage
!
interface atm1/0
class-int oamclass
pvc 1/200 l2transport
oam-ac emulation-enable 10
xconnect 10.13.13.13 100 encapsulation l2tpv3
Verifying OAM Local Emulation for ATM AAL5 over L2TPv3 Configuration:
Examples
The following show atm pvc command output shows that OAM cell emulation is enabled and working
on the ATM PVC:
Router# show atm pvc 5/500
ATM4/1/0.200: VCD: 6, VPI: 5, VCI: 500
UBR, PeakRate: 1
AAL5-LLC/SNAP, etype:0x0, Flags: 0x34000C20, VCmode: 0x0
OAM Cell Emulation: enabled, F5 End2end AIS Xmit frequency: 1 second(s)
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC state: Not ManagedVerified
ILMI VC state: Not Managed
InPkts: 564, OutPkts: 560, InBytes: 19792, OutBytes: 19680
InPRoc: 0, OutPRoc: 0
InFast: 4, OutFast: 0, InAS: 560, OutAS: 560
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 26
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 26
OAM cells sent: 77
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 77, F5 OutRDI: 0
OAM cell drops: 0
Status: UP
Configuring Protocol Demultiplexing for L2TPv3: Examples
The following examples show how to configure the Protocol Demultiplexing feature on the IPv4 PE
routers. The PE routers facing the IPv6 network do not require demultiplexing configuration.
Ethernet Interface
interface ethernet 0/1
ip address 172.16.128.4
xconnect 10.0.3.201 888 pw-class demux
match protocol ipv6
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
86
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Frame Relay Interface
interface serial 1/1.1 multipoint
ip address 172.16.128.4
frame-relay interface-dlci 100
xconnect 10.0.3.201 888 pw-class atm-xconnect
match protocol ipv6
Manually Clearing an L2TPv3 Tunnel: Example
The following example demonstrates how to manually clear a specific L2TPv3 tunnel using the tunnel
ID:
clear l2tun tunid 65432
Configuring Frame Relay DLCI-to-DLCI Switching: Example
The following is a sample configuration for switching a Frame Relay DLCI over a pseudowire:
pseudowire-class fr-xconnect
encapsulation l2tpv3
protocol l2tpv3
ip local interface Loopback0
sequencing both
!
interface Serial0/0
encapsulation frame-relay
frame-relay intf-type dce
!
connect one Serial0/0 100 l2transport
xconnect 10.0.3.201 555 pw-class fr-xconnect
!
connect two Serial0/0 200 l2transport
xconnect 10.0.3.201 666 pw-class fr-xconnect
Configuring Frame Relay Trunking: Example
The following is a sample configuration for setting up a trunk connection for an entire serial interface
over a pseudowire. All incoming packets are switched to the pseudowire regardless of content.
Note that when you configure trunking for a serial interface, the trunk connection does not require an
encapsulation method. You do not, therefore, need to enter the encapsulation frame-relay command.
Reconfiguring the default encapsulation removes all xconnect configuration settings from the interface.
interface Serial0/0
xconnect 10.0.3.201 555 pw-class serial-xconnect
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
87
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring QoS for L2TPv3 on the Cisco 7500 Series: Example
The following example shows the MQC commands used on a Cisco 7500 series router to configure a
CIR guarantee of 256 kbps on DLCI 100 and 512 kbps for DLCI 200 on the egress side of a Frame Relay
interface that is also configured for L2TPv3 tunneling:
ip cef distributed
class-map dlci100
match fr-dlci 100
class-map dlci200
match fr-dlci 200
!
policy-map dlci
class dlci100
bandwidth 256
class dlci200
bandwidth 512
!
interface Serial0/0
encapsulation frame-relay
frame-relay interface-type dce
service-policy output dlci
!
connect one Serial0/0 100 l2transport
xconnect 10.0.3.201 555 encapsulation l2tpv3 pw-class mqc
!
connect two Serial0/0 200 l2transport
xconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class mqc
Configuring QoS for L2TPv3 on the Cisco 12000 Series: Examples
This section contains the following examples for configuring QoS for L2TPv3 on the Cisco 12000
series:
•
Configuring QoS on a Frame Relay Interface in a TSC-Based L2TPv3 Tunnel Session, page 88
•
Configuring Traffic Policing on an ISE Interface in a Native L2TPv3 Tunnel Session, page 90
•
Configuring Tunnel Marking in a Native L2TPv3 Tunnel Session, page 92
•
Configuring Traffic Shaping in a Native L2TPv3 Tunnel Session, page 92
Configuring QoS on a Frame Relay Interface in a TSC-Based L2TPv3 Tunnel Session
To apply a QoS policy for L2TPv3 to a Frame Relay interface on a Cisco 12000 series 2-port
Channelized OC-3/STM-1 (DS1/E1) or 6-port Channelized T3 line card in a tunnel server card-based
L2TPv3 tunnel session, you must:
•
Use the map-class frame-relay class-name command in global configuration mode to apply a QoS
policy to a Frame Relay class of traffic.
•
Use the frame-relay interface-dcli dcli-number switched command (in interface configuration
mode) to enter Frame Relay DLCI interface configuration mode and then the class command to
configure a QoS policy for a Frame Relay class of traffic on the specified DLCI. You must enter a
separate series of these configuration commands to configure QoS for each Frame Relay DLCI on
the interface.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
88
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
As shown in the following example, when you configure QoS for L2TPv3 on the ingress side of a
Cisco 12000 series Frame Relay interface, you may also configure the value of the ToS byte used in IP
headers of tunneled packets when you configure the L2TPv3 pseudowire (see the section “Configuring
the L2TPv3 Pseudowire”).
The following example shows the MQC commands and ToS byte configuration used on a Cisco 12000
series router to apply a QoS policy for DLCI 100 on the ingress side of a Frame Relay interface
configured for server card-based L2TPv3 tunneling:
policy-map frtp-policy
class class-default
police cir 8000 bc 6000 pir 32000 be 4000 conform-action transmit exceed-action
set-frde-transmit violate-action drop
!
map-class frame-relay fr-map
service-policy input frtp-policy
!
interface Serial0/1/1:0
encapsulation frame-relay
frame-relay interface-dlci 100 switched
class fr-map
connect frol2tp1 Serial0/1/1:0 100 l2transport
xconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class aaa
!
pseudowire-class aaa
encapsulation l2tpv3
ip tos value 96
To apply a QoS policy for L2TPv3 to the egress side of a Frame Relay interface on a Cisco 12000 series
2-port Channelized OC-3/STM-1 (DS1/E1) or 6-port Channelized T3 line card, you must:
•
Use the match ip precedence command in class-map configuration mode to configure the IP
precedence value used to determine the egress queue for each L2TPv3 packet with a Frame Relay
payload.
•
Use the random-detect command in policy-map class configuration mode to enable a WRED drop
policy for a Frame Relay traffic class that has a bandwidth guarantee. Use the random-detect
precedence command to configure the WRED and MDRR parameters for particular IP precedence
values.
The next example shows the MQC commands used on a Cisco 12000 series Internet router to apply a
QoS policy with WRED/MDRR settings for specified IP precedence values to DLCI 100 on the egress
side of a Frame Relay interface configured for a server card-based L2TPv3 tunnel session:
class-map match-all d2
match ip precedence 2
class-map match-all d3
match ip precedence 3
!
policy-map o
class d2
bandwidth percent 10
random-detect
random-detect precedence 1 200 packets 500 packets 1
class d3
bandwidth percent 10
random-detect
random-detect precedence 1 1 packets 2 packets 1
!
map-class frame-relay fr-map
service-policy output o
!
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
89
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
interface Serial0/1/1:0
encapsulation frame-relay
frame-relay interface-dlci 100 switched
class fr-map
connect frol2tp1 Serial0/1/1:0 100 l2transport
xconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class aaa
Configuring Traffic Policing on an ISE Interface in a Native L2TPv3 Tunnel Session
Starting in Cisco IOS Release 12.0(30)S, QoS traffic policing is supported on the following types of ISE
ingress interfaces bound to a native L2TPv3 tunnel session:
•
ATM
•
Frame Relay DLCIs
QoS traffic shaping in a native L2TPv3 tunnel session is supported on ATM ISE egress interfaces for the
following service categories:
•
UBR (unspecified bit rate)
•
VBR-nrt (variable bit rate nonreal-time)
Traffic policing allows you to control the maximum rate of traffic sent or received on an interface and to
partition a network into multiple priority levels or classes of service (CoS). The dual rate, 3-Color
Marker in color-aware and color-blind modes, as defined in RFC 2698 for traffic policing, is supported
on ingress ISE interfaces to classify packets.
The police command configures traffic policing using two rates, the committed information rate (CIR)
and the peak information rate (PIR). The following “conform,” “exceed,” and “violate” values for the
actions argument are supported with the police command in policy-map configuration mode on an ISE
interface bound to an L2TPv3 tunnel session:
•
conform-action actions: Actions taken on packets that conform to the CIR and PIR.
– set-prec-tunnel: Sets the IP precedence value in the tunnel header of a packet encapsulated for
native L2TPv3 tunneling.
– set-dscp-tunnel: Sets the IP differentiated services code point (DSCP) value in the tunnel
header of a packet encapsulated for native L2TPv3 tunneling.
– transmit: Sends the packet with no alteration.
•
exceed-action actions: Actions taken on packets that conform to the CIR but not the PIR.
– drop: Drops the packet.
– set-clp (ATM only): Sets the Cell Loss Priority (CLP) bit from 0 to 1 in an ATM cell
encapsulated for native L2TPv3 tunneling.
– set-dscp-tunnel: Sets the DSCP value in the tunnel header of a packet encapsulated for native
L2TPv3 tunneling.
– set-dscp-tunnel and set-clp (ATM only): Sets the DSCP value in the tunnel header and the CLP
bit in an ATM cell encapsulated for native L2TPv3 tunneling.
– set-dscp-tunnel and set-frde (Frame Relay only): Sets the DSCP value in the tunnel header and
discard eligible (DE) bit in a Frame Relay packet encapsulated for native L2TPv3 tunneling.
– set-frde (Frame Relay only): Sets the DE bit in a Frame Relay packet encapsulated for native
L2TPv3 tunneling.
– set-prec-tunnel and set-clp (ATM only): Sets the precedence value in the tunnel header and the
CLP bit in an ATM cell encapsulated for native L2TPv3 tunneling.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
90
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
– set-prec-tunnel and set-frde (Frame Relay only): Sets the precedence value in the tunnel
header and the Frame Relay DE bit in a Frame Relay packet encapsulated for native L2TPv3
tunneling.
– transmit: Sends the packet with no alteration.
•
violate-action actions: Actions taken on packets that exceed the PIR.
– drop: Drops the packet.
You can configure these “conform,” “exceed,” and “violate” values for the actions argument of the police
command in policy-map configuration mode on an ATM or Frame Relay ISE interface at the same time
you use the ip tos command to configure the value of the ToS byte in IP headers of tunneled packets in
a pseudowire class configuration applied to the interface (see the sections “Configuring the L2TPv3
Pseudowire” and “Manually Configuring L2TPv3 Session Parameters”).
However, the values you configure with the police command on an ISE interface for native L2TPv3
tunneling take precedence over any IP ToS configuration. This means that the traffic policing you
configure always rewrites the IP header of the tunnel packet and overwrites the values set by an ip tos
command. The priority of enforcement is as follows when you use these commands simultaneously:
1. set-prec-tunnel or set-dscp-tunnel (QoS policing in native L2TPv3 tunnel)
2. ip tos reflect
3. ip tos tos-value
Note
This behavior is designed. We recommend that you configure only native L2TPv3 tunnel sessions and
reconfigure any ISE interfaces configured with the ip tos command to use the QoS policy configured for
native L2TPv3 traffic policing.
The following example shows how to configure traffic policing using the dual rate, 3-Color Marker on
an ISE Frame Relay interface in a native L2TPv3 tunnel session.
Note
This example shows how to use the police command in conjunction with the conform-color command
to specify the policing actions to be taken on packets in the conform-color class and the exceed-color
class. This is called a “color-aware” method of policing and is described in QoS: Color-Aware Policer.
However, you can also configure “color-blind” traffic policing on an ISE Frame Relay interface in a
native L2TPv3 tunnel session, using only the police command without the conform-color command.
class-map match-any match-not-frde
match not fr-de
!
class-map match-any match-frde
match fr-de
!
policy-map 2R3C_CA
class class-default
police cir 16000 bc 4470 pir 32000 be 4470
conform-color match-not-frde exceed-color match-frde
conform-action set-prec-tunnel-transmit 2
exceed-action set-prec-tunnel-transmit 3
exceed-action set-frde-transmit
violate-action drop
The following example shows how to configure a QoS policy for traffic on the egress side of an ISE
Frame Relay interface configured for a native L2TPv3 tunnel session.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
91
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Note that the sample output policy configured for a TSC-based L2TPv3 tunnel session in the section
“Configuring QoS on a Frame Relay Interface in a TSC-Based L2TPv3 Tunnel Session” is not supported
on a Frame Relay ISE interface. QoS policies on per-DLCI output traffic are not supported on ISE
interfaces configured for a native L2TPv3 tunnel.
policy-map o
class d2
bandwidth percent 10
random-detect precedence 1 200 packets 500 packets 1
class d3
bandwidth percent 10
random-detect precedence 1 1 packets 2 packets 1
!
interface Serial0/1/1:0
encapsulation frame-relay
frame-relay interface-dlci 100 switched
class fr-map
service output o
Configuring Tunnel Marking in a Native L2TPv3 Tunnel Session
The QoS: Tunnel Marking for L2TPv3 Tunnels feature allows you to set (mark) either the IP precedence
value or the differentiated services code point (DSCP) in the header of an L2TPv3 tunneled packet, using
the set-prec-tunnel or set-dscp-tunnel command without configuring QoS traffic policing. Tunnel
marking simplifies administrative overhead previously required to control customer bandwidth by
allowing you to mark the L2TPv3 tunnel header on an ingress ISE interface.
The following example shows how to configure tunnel marking using MQC set commands for the default
traffic class and a traffic class that matches a specified Frame Relay DE bit value:
class-map match-any match-frde
match fr-de
policy-map set_prec_tun
class match-frde
set ip precedence tunnel 1
class class-default
set ip precedence tunnel 2
!
map-class frame-relay fr_100
service-policy input set_prec_tun
L2TPv3 Customer-Facing ISE Interface
interface POS0/0
frame-relay interface-dlci 100 switched
class fr_100
Configuring Traffic Shaping in a Native L2TPv3 Tunnel Session
The following example shows how to configure traffic shaping on a Frame Relay ISE egress interface
bound to a native L2TPv3 tunnel session. You can configure traffic shaping on a Frame Relay main
egress interface by classifying traffic with different class maps.
Note
You cannot configure per-DLCI shaping using the method shown in this example to configure traffic
shaping.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
92
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
To configure class-based shaping, configure the match qos-group and random-detect discard-class
values according to the incoming IP precedence and DSCP values from packets received on the
backbone-facing ingress interface. Use these values to define traffic classes on the customer-facing
egress interface.
class-map match-any match_prec1
match ip precedence 1
class-map match-any match_prec2
match ip precedence 2
class-map match-any match_prec3
match ip precedence 3
!
class-map match-all match_qos3
match qos-group 3
!
class-map match-any match_qos12
match qos-group 1
match qos-group 2
!
policy-map customer_egress_policy
class match_qos3
bandwidth percent 5
shape average 160000000
class match_qos12
shape average 64000000
random-detect discard-class-based
random-detect discard-class 1 500 packets 1000 packets
random-detect discard-class 2 1000 packets 2000 packets
bandwidth percent 10
class class-default
shape average 64000000
queue-limit 1000 packets
bandwidth percent 1
!
policy-map backbone_ingress_policy
class match_prec1
set qos-group 1
set discard-class 1
class match_prec2
set qos-group 2
set discard-class 2
class match_prec3
set qos-group 3
set discard-class 3
class class-default
set qos-group 5
set discard-class 5
L2TPv3 Customer-Facing ISE Interface
interface POS0/0
service-policy output customer_egress_policy
frame-relay interface-dlci 100 switched
class fr_100
L2TPv3 Backbone-Facing ISE Interface
interface POS1/0
service-policy input backbone_ingress_policy
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
93
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring a QoS Policy for Committed Information Rate Guarantees: Example
The following example shows how to configure a QoS policy that guarantees a CIR of 256 kbps on DLCI
100 and 512 kbps for DLCI 200 on a serial interface at one end of a TSC-based L2TPv3 tunnel session:
ip cef distributed
class-map dlci100
match fr-dlci 100
class-map dlci200
match fr-dlci 200
!
policy-map dlci
class dlci100
bandwidth 256
class dlci200
bandwidth 512
!
interface Serial 0/0
encapsulation frame-relay
frame-relay intf-type dce
service-policy output dlci
!
connect one Serial 0/0 100 l2transport
xconnect 10.0.3.201 555 encapsulation l2tpv3 pw-class mqc
!
connect two Serial 0/0 200 l2transport
xconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class mqc
Setting the Frame Relay DE Bit Configuration: Example
The following example shows how to configure the service policy called set-de and attach it to an output
serial interface bound to a TSC-based L2TPv3 tunnel session. Note that setting the Frame Relay DE bit
is not supported on a Frame Relay ISE interface bound to a native L2TPv3 tunnel session.
In this example, the class map called data evaluates all packets exiting the interface for an IP precedence
value of 1. If the exiting packet has been marked with the IP precedence value of 1, the packet’s DE bit
is set to 1.
class-map data
match qos-group 1
!
policy-map SET-DE
class data
set fr-de
!
interface Serial 0/0/0
encapsulation frame-relay
service-policy output SET-DE
!
connect fr-mpls-100 serial 0/0/0 100 l2transport
xconnect 10.10.10.10 pw-class l2tpv3
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
94
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Matching the Frame Relay DE Bit Configuration: Example
The following example shows how to configure the service policy called match-de and attach it to an
interface bound to a TSC-based L2TPv3 tunnel session. In this example, the class map called “data”
evaluates all packets entering the interface for a DE bit setting of 1. If the entering packet has been a DE
bit value of 1, the packet’s IP precedence value is set to 3.
class-map data
match fr-de
!
policy-map MATCH-DE
class data
set ip precedence tunnel 3
!
ip routing
ip cef distributed
!
mpls label protocol ldp
interface Loopback0
ip address 10.20.20.20 255.255.255.255
!
interface Ethernet1/0/0
ip address 172.16.0.2 255.255.255.0
tag-switching ip
!
interface Serial4/0/0
encapsulation frame-relay
service input MATCH-DE
!
connect 100 Serial4/0/0 100 l2transport
xconnect 10.10.10.10 100 encapsulation l2tpv3
The next example shows how to configure the service policy called set_prec_tunnel_from_frde and
attach it to a Cisco 12000 series ISE interface bound to a native L2TPv3 tunnel session. Note that in a
native L2TPv3 session, you must attach the service policy to a DLCI (in the example, DCLI 100) instead
of to a main interface (as in the preceding example).
class-map match-any match-frde
match fr-de
!
policy-map set_prec_tunnel_from_frde
class match-frde
set ip precedence tunnel 6
class class-default
set ip precedence tunnel 3
!
map-class frame-relay fr_100
service-policy input set_prec_tunnel_from_frde
!
interface POS0/0
description ISE: L2TPv3 Customer-facing interface
frame-relay interface-dlci 100 switched
class fr_100
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
95
Layer 2 Tunnel Protocol Version 3
Configuration Examples for Layer 2 Tunnel Protocol Version 3
Configuring MLFR for L2TPv3 on the Cisco 12000 Series: Example
The following example shows how to configure L2TPv3 tunneling on a multilink Frame Relay bundle
interface on a Cisco 12000 series 2-port Channelized OC-3/STM-1 (DS1/E1) or 6-port Channelized T3
line card:
frame-relay switching
!
pseudowire-class mfr
encapsulation l2tpv3
ip local interface Loopback0
!
interface mfr0
frame-relay intf-type dce
!
interface Serial0/0.1/1:11
encapsulation frame-relay MFR0
!
interface Serial0/0.1/1:12
encapsulation frame-relay MFR0
!
connect L2TPoMFR MFR0 100 l2transport
xconnect 10.10.10.10 3 pw-class mfr
Configuring an MQC for Committed Information Rate Guarantees: Example
The following is a sample configuration of the MQC to guarantee a CIR of 256 kbps on DLCI 100 and
512 kbps for DLCI 200:
ip cef distributed
class-map dlci100
match fr-dlci 100
class-map dlci200
match fr-dlci 200
!
policy-map dlci
class dlci100
bandwidth 256
class dlci200
bandwidth 512
!
interface Serial0/0
encapsulation frame-relay
frame-relay intf-type dce
service-policy output dlci
!
connect one Serial0/0 100 l2transport
xconnect 10.0.3.201 555 encapsulation l2tpv3 pw-class mqc
!
connect two Serial0/0 200 l2transport
xconnect 10.0.3.201 666 encapsulation l2tpv3 pw-class mqc
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
96
Layer 2 Tunnel Protocol Version 3
Additional References
Additional References
The following sections provide additional information related to L2TPv3.
Related Documents
Related Topic
Document Title
L2TPv3
Layer 2 Tunneling Protocol Version 3 Technical Overview
L2VPN interworking
L2VPN Interworking
L2VPN pseudowire switching
L2VPN Pseudowire Switching
L2VPN pseudowire redundancy
L2VPN Pseudowire Redundancy
L2TP
•
Layer 2 Tunnel Protocol
•
Layer 2 Tunneling Protocol: A Feature in Cisco IOS Software
Configuring CEF
“Cisco Express Forwarding” chapter in the Cisco IOS Switching
Configuration Guide, Release 12.0
MTU discovery and packet fragmentation
MTU Tuning for L2TP
Tunnel marking for L2TPv3 tunnels
QoS: Tunnel Marking for L2TPv3 Tunnels
Multilink Frame Relay over L2TPv3/AToM
Multilink Frame Relay over L2TPv3/AToM
Additional VPN commands: complete command
Cisco IOS Release 12.0 Dial Solutions Command Reference
syntax, command mode, defaults, usage guidelines and
examples
Additional Frame Relay commands: complete
command syntax, command mode, defaults, usage
guidelines and examples
Cisco IOS Release 12.0 Wide-Area Networking Command Reference
UTI
Universal Transport Interface (UTI)
IPv6
Cisco IOS IPv6 Configuration Library
Additional IPv6 commands: complete command
Cisco IOS IPv6 Command Reference
syntax, command mode, defaults, usage guidelines and
examples
Standards
Standards
Title
draft-ietf-l2tpext-l2tp-base-03.txt
Layer Two Tunneling Protocol (Version 3)'L2TPv3'
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
97
Layer 2 Tunnel Protocol Version 3
Additional References
MIBs
MIBs
•
MIBs Link
VPDN MIB—MIB support for L2TPv3 is based on To obtain lists of supported MIBs by platform and Cisco IOS
the VPDN MIB
release, and to download MIB modules, go to the Cisco MIB website
on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs
Title
RFC 2661
Layer Two Tunneling Protocol “L2TP”
RFC 1321
The MD5 Message Digest Algorithm
RFC 2104
HMAC-Keyed Hashing for Message Authentication
RFC 3931
Layer Two Tunneling Protocol Version 3 “L2TPv3
Technical Assistance
Description
Link
http://www.cisco.com/techsupport
The Cisco Technical Support website contains
thousands of pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
98
Layer 2 Tunnel Protocol Version 3
Command Reference
Command Reference
This section documents new and modified commands.
•
atm mcpt-timers
•
atm pvp
•
authentication (L2TP)
•
cell-packing
•
clear l2tun
•
clear l2tun tunnel counters
•
debug acircuit
•
debug atm cell-packing
•
debug vpdn
•
debug xconnect
•
digest
•
digest check
•
encapsulation l2tpv3
•
hello
•
hidden
•
hostname (L2TP)
•
ip dfbit set
•
ip local interface
•
ip pmtu
•
ip protocol
•
ip tos (L2TP)
•
ip ttl
•
l2tp-class
•
l2tp cookie local
•
l2tp cookie remote
•
l2tp hello
•
l2tp id
•
match fr-de
•
match protocol (L2TPv3)
•
oam-ac emulation-enable
•
password (L2TP)
•
protocol (L2TP)
•
pseudowire-class
•
receive-window
•
retransmit
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
99
Layer 2 Tunnel Protocol Version 3
Command Reference
•
sequencing
•
show atm cell-packing
•
show l2tun
•
show l2tun session
•
show l2tun tunnel
•
show xconnect
•
snmp-server enable traps l2tun session
•
snmp-server enable traps l2tun pseudowire status
•
snmp-server host
•
timeout setup
•
xconnect
•
xconnect logging pseudowire status
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
100
Layer 2 Tunnel Protocol Version 3
atm mcpt-timers
atm mcpt-timers
To set up the cell-packing timers, which specify how long the provider edge (PE) router can wait for cells
to be packed into a Multiprotocol Label Switching (MPLS) or Layer 2 Tunneling Protocol version 3
(L2TPv3) packet, use the atm mcpt-timers command in interface configuration mode. To disable the
cell-packing timers, use the no form of this command.
atm mcpt-timers [timeout-1 timeout-2 timeout-3]
no atm mcpt-timers
Syntax Description
timeout
Defaults
By default, the timers are not set. If you enable the cell-packing timers, the default values for the PA-A3
port adapters are:
(Optional) Specifies the timeout values for three timers in microseconds.
The timeout’s default and range of acceptable values depends on the ATM
link speed. See the “Usage Guidelines” section for more information.
•
OC-3: 30, 60, and 90 microseconds
•
T3: 100, 200, and 300 microseconds
•
E3: 130, 260, and 390 microseconds
Command Modes
Interface configuration
Command History
Release
Modification
12.0(25)S
This command was introduced.
12.0(29)S
Support for L2TPv3 sessions was added in Cisco IOS Release 12.0(29)S.
Usage Guidelines
For each timer, you specify the maximum cell packing timeout (MCPT). This value gives the
cell-packing function a limited amount of time to complete. If the timer expires before the maximum
number of cells are packed into an Any Transport over MPLS (AToM) or L2TPv3 packet, the packet is
sent anyway.
The timeout’s range of acceptable values depends on the ATM link speed. For the PA-A3 port adapter,
the range of values is:
Examples
•
OC-3: 30, 60, and 90 microseconds
•
T3: 100, 200, and 300 microseconds
•
E3: 130, 260, and 390 microseconds
The following example sets the MCPT timers to 10, 60, and 90 microseconds, respectively.
Router# interface atm 1/0
Router(config-if)# atm mcpt-timers 10 60 90
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
101
Layer 2 Tunnel Protocol Version 3
atm mcpt-timers
Related Commands
Command
Description
cell-packing
Enables ATM cell relay to pack multiple ATM cells into each MPLS or
L2TPv3 packet.
debug atm
cell-packing
Displays ATM cell relay cell packing debugging information.
show atm cell-packing Displays information about the VCs and VPs that have ATM cell relay over
MPLS or L2TPv3 cell packing enabled.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
102
Layer 2 Tunnel Protocol Version 3
atm pvp
atm pvp
To create a permanent virtual path (PVP) used to multiplex (or bundle) one or more virtual circuits
(VCs), use the atm pvp command in interface configuration mode. To remove a PVP, use the no form
of this command.
atm pvp vpi [peak-rate] [l2transport]
no atm pvp vpi
Syntax Description
vpi
ATM network virtual path identifier (VPI) of the VC to multiplex on the permanent
virtual path. The range is 0 to 255. The VPI is an 8-bit field in the header of the ATM
cell. The VPI value is unique only on a single link, not throughout the ATM network
because it has local significance only. The VPI value must match that of the switch.
The number specified for the vpi must not already exist. If the number specified for the
vpi is already being used by an existing VC, this command is rejected.
peak-rate
(Optional) Maximum rate in kbps at which the PVP can transmit data. The range is
84 kbps to line rate. The default is the line rate.
l2transport (Optional) Specifies that the PVP is for the Any Transport over MPLS (AToM) ATM
cell relay feature or the ATM Cell Relay over L2TPv3 feature.
Command Default
PVP is not configured.
Command Modes
Interface configuration
Command History
Release
Modification
11.1
This command was introduced.
12.0(25)S
This command was updated to include the l2transport keyword.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
This command is commonly used to create a PVP that is used multiplex circuit emulation service (CES)
and data VCs.
The ATM-CES port adapter supports multiplexing of one or more VCs over a virtual path that is shaped
at a constant bandwidth. For example, you can buy a virtual path service from an ATM service provider
and multiplex both the CES and data traffic over the virtual path.
All subsequently created VCs with a vpi argument matching the vpi specified with the atm pvp
command are multiplexed onto this PVP. This PVP connection is an ATM connection where switching
is performed on the VPI field of the cell only. A PVP is created and left up indefinitely. All VCs that are
multiplexed over a PVP share and are controlled by the traffic parameters associated with the PVP.
Changing the peak-rate argument causes the ATM-CES port adapter to go down and then back up.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
103
Layer 2 Tunnel Protocol Version 3
atm pvp
When you create a PVP, two VC are created (VCI 3 and 4) by default. These VCs are created for VP
end-to-end loopback and segment loopback OAM support.
When you use the l2transport keyword with the atm pvp command, the router enters l2transport PVP
configuration mode. You must issue the l2transport keyword to configure the ATM cell relay over
MPLS feature in port mode or to configure the ATM cell relay over L2TPv3 feature.
To verify the configuration of a PVP, use the show atm vp command in EXEC mode.
Examples
The following example creates a permanent virtual path with a peak rate of 2000 kbps. The subsequent
VCs created are multiplexed onto this virtual path.
interface atm 6/0
atm pvp 1 2000
atm pvc 13 1 13 aal5snap
exit
interface cbr 6/1
ces circuit 0
ces pvc 9 interface atm6/0 vpi 1 vci 100
exit
The following example configures ATM cell relay over MPLS in port mode:
interface atm5/0
atm pvp 1 l2transport
xconnect 10.0.0.1 123 encapsulation mpls
The following example configures ATM cell relay over L2TPv3:
pw-class atm-xconnect
encapsulation l2tpv3
interface atm 4/1/0
atm pvp 5 l2transport
xconnect 10.0.3.201 888 pw-class atm-xconnect
Related Commands
Command
Description
show atm vp
Displays the statistics for all VPs on an interface or for a specific VP.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
104
Layer 2 Tunnel Protocol Version 3
authentication (L2TP)
authentication (L2TP)
To enable Layer 2 Tunnel Protocol Version 3 (L2TPv3) Challenge Handshake Authentication Protocol
(CHAP) style authentication, use the authentication command in L2TP class configuration mode. To
disable L2TPv3 CHAP-style authentication, use the no form of this command.
authentication
no authentication
Syntax Description
This command has no arguments or keywords.
Command Default
L2TPv3 CHAP-style authentication is disabled.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Two methods of control channel authentication are available in Cisco IOS Release 12.0(29)S, Cisco IOS
Release 12.2(27)SBA, and later releases. The L2TPv3 Control Message Hashing feature (enabled with
the digest command) introduces a more robust authentication method than the older CHAP-style method
of authentication enabled with the authentication command. You may choose to enable both methods
of authentication to ensure interoperability with peers that support only one of these methods of
authentication, but this configuration will yield control of which authentication method is used to the
peer PE router. Enabling both methods of authentication should be considered an interim solution to
solve backward-compatibility issues during software upgrades.
Table 7 shows a compatibility matrix for the different L2TPv3 authentication methods. PE1 is running
a Cisco IOS software release that supports the L2TPv3 Control Message Hashing feature, and the
different possible authentication configurations for PE1 are shown in the first column. Each remaining
column represents PE2 running software with different available authentication options, and the
intersections indicate the different compatible configuration options for PE2. If any PE1/PE2
authentication configuration poses ambiguity on which method of authentication will be used, the
winning authentication method is indicated in bold. If both the old and new authentication methods are
enabled on PE1 and PE2, both types of authentication will occur.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
105
Layer 2 Tunnel Protocol Version 3
authentication (L2TP)
Table 7
Compatibility Matrix for L2TPv3 Authentication Methods
PE1
Authentication
Configuration
PE2 Supporting Old
Authentication1
PE2 Supporting New
Authentication2
PE2 Supporting Old and
New Authentication3
None
None
None
None
New integrity check
New integrity check
—
Old authentication
Old
authentication
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
New
authentication
—
New integrity
check
None
Old and new
authentication
Old authentication
New authentication
New authentication
Old authentication and
new authentication
None
None
New integrity check
New integrity check
New authentication
Old authentication
New authentication
Old and new
authentication
Old authentication and
new integrity check
Old authentication
Old
authentication
and new integrity
check
—
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
1. Any PE software that supports only the old CHAP-like authentication system.
2. Any PE software that supports only the new message digest authentication and integrity checking authentication system,
but does not understand the old CHAP-like authentication system. This type of software may be implemented by other
vendors based on the latest L2TPv3 draft.
3. Any PE software that supports both the old CHAP-like authentication and the new message digest authentication and
integrity checking authentication system, such as Cisco IOS 12.0(29)S, Cisco IOS 12.2(27)SBA, or later releases.
Examples
The following example enables CHAP-style authentication for L2TPv3 pseudowires configured using
the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# authentication
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
106
Layer 2 Tunnel Protocol Version 3
authentication (L2TP)
Related Commands
Command
Description
digest
Enables L2TPv3 control channel authentication or integrity checking.
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
password
Configures the password used by a PE router for CHAP-style L2TPv3
authentication.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
107
Layer 2 Tunnel Protocol Version 3
cell-packing
cell-packing
To enable ATM over Multiprotocol Label Switching (MPLS) or Layer 2 Tunneling Protocol Version 3
(L2TPv3) to pack multiple ATM cells into each MPLS or L2TPv3 packet, use the cell-packing command
in the appropriate configuration mode. To disable cell packing, use the no form of this command.
cell-packing [cells] [mcpt-timer timer]
no cell-packing
Syntax Description
cells
(Optional) The number of cells to be packed into an MPLS or L2TPv3 packet.
The range is from 2 to the maximum transmission unit (MTU) of the interface
divided by 52. The default number of ATM cells to be packed is the MTU of
the interface divided by 52.
If the number of cells packed by the peer provider edge router exceeds this
limit, the packet is dropped.
mcpt-timer timer
(Optional) Specifies which timer to use. Valid values are 1, 2 or 3. The default
value is 1.
Command Default
Cell packing is disabled.
Command Modes
Interface configuration
L2transport VC configuration—for ATM VC
L2transport VP configuration—for ATM VP
VC class configuration
Command History
Release
Modification
12.0(25)S
This command was introduced.
Usage Guidelines
12.0(29)S
Support for L2TPv3 sessions was added in Cisco IOS Release 12.0(29)S.
12.0(30)S
This command was updated to enable cell packing as part of a VC class.
•
The cell-packing command is available only if you configure the ATM virtual circuit (VC) or virtual
path (VP) with ATM adaptation layer 0 (AAL0) encapsulation. If you specify ATM adaptation layer
5 (AAL5) encapsulation, the command is not valid.
•
Only cells from the same VC or VP can be packed into one MPLS or L2TPv3 packet. Cells from
different connections cannot be concatenated into the same packet.
•
When you change, enable, or disable the cell-packing attributes, the ATM VC or VP and the MPLS
or L2TPv3 emulated VC are reestablished.
•
If a PE router does not support cell packing, the PE routers sends only one cell per MPLS or L2TPv3
packet.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
108
Layer 2 Tunnel Protocol Version 3
cell-packing
•
The number of packed cells need not match between the PE routers. The two PE routers agree on
the lower of the two values. For example, if PE1 is allowed to pack 10 cells per MPLS or L2TPv3
packet and PE2 is allowed to pack 20 cells per MPLS or L2TPv3 packet, the two PE routers would
agree to send no more than 10 cells per packet.
•
If the number of cells packed by the peer PE router exceeds the limit, the packet is dropped.
•
If you issue the cell-packing command without first specifying the atm mcpt-timers command, you
get the following error:
Please set mcpt values first
Examples
The following example shows cell packing enabled on an interface set up for VP mode. The cell-packing
command specifies that 10 ATM cells be packed into each MPLS packet. The command also specifies
that the second MCPT timer be used.
Router> enable
Router# configure terminal
Router(config)# interface atm 1/0
Router(config-if)# atm mcpt-timer 1000 800 500
Router(config-if)# atm pvp 100 l2transport
Router(config-if-atm-l2trans-pvp)# xconnect 10.0.0.1 234 encapsulation mpls
Router(config-if-atm-l2trans-pvp)# cell-packing 10 mcpt-timer 2
The following example configures ATM cell relay over MPLS with cell packing in VC class
configuration mode. The VC class is then applied to an interface.
Router> enable
Router# configure terminal
Router(config)# vc-class atm cellpacking
Router(config-vc-class)# encapsulation aal0
Router(config-vc-class)# cell-packing 10 mcpt-timer 1
Router(config)# interface atm1/0
Router(config-if)# atm mcpt-timers 100 200 250
Router(config-if)# class-int cellpacking
Router(config-if)# pvc 1/200 l2transport
Router(config-if-atm-l2trans-pvc)# xconnect 13.13.13.13 100 encapsulation mpls
The following example configures ATM AAL5 over L2TPv3 in VC class configuration mode. The VC
class is then applied to an interface.
Router(config)# vc-class atm aal5class
Router(config-vc-class)# encapsulation aal5
!
Router(config)# interface atm 1/0
Router(config-if)# class-int aal5class
Router(config-if)# pvc 1/200 l2transport
Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation l2tpv3
Related Commands
Command
Description
atm mcpt-timers
Creates cell-packing timers, which specify how long the PE router can wait
for cells to be packed into an MPLS or L2TPv3 packet.
debug atm
cell-packing
Displays ATM cell relay cell packing debugging information.
show atm cell-packing Displays information about the VCs and VPs that have ATM cell packing
enabled.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
109
Layer 2 Tunnel Protocol Version 3
clear l2tun
clear l2tun
To clear the specified L2TPv3 tunnel, use the clear l2tun command in privileged EXEC mode.
clear l2tun {l2tp-class l2tp-class-name | tunid tunnel-id | local ip ip-address | remote ip ip-address
| all}
Syntax Description
l2tp-class
l2tp-class-name
All L2TPv3 tunnels with the specified L2TP class name will be torn down.
tunid tunnel-id
The L2TPv3 tunnel with the specified tunnel ID will be torn down.
local ip ip-address
All L2TPv3 tunnels with the specified local IP address will be torn down.
remote ip ip-address
All L2TPv3 tunnels with the specified remote IP address will be torn down.
all
All L2TPv3 tunnels will be torn down.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(30)S
This command was introduced.
Examples
The following example clears the L2TPv3 tunnel with the tunnel ID 65432:
Router# clear l2tun tunid 65432
Related Commands
Command
Description
show l2tun session
Displays the current state of an L2TPv3 session and displays protocol
information about an L2TPv3 control channel.
show l2tun tunnel
Displays the current state of an L2TPv3 tunnel and displays information
about currently configured tunnels, including local and remote L2TP
hostnames, aggregate packet counts, and L2TP control channels
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
110
Layer 2 Tunnel Protocol Version 3
clear l2tun tunnel counters
clear l2tun tunnel counters
To clear Layer 2 Tunnel Protocol (L2TP) control channel authentication counters, use the clear l2tun
tunnel counters command in privileged EXEC mode.
Cisco IOS Release 12.0(29)S
clear l2tun tunnel counters digest
Cisco IOS Release 12.2(27)SBA
clear l2tun tunnel counters authentication
Syntax Description
digest
Clears the counter for control packets dropped due to failed digest
authentication.
authentication
Clears the L2TP control channel authentication attribute-value pairs (AV
pairs) counters.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(29)S
This command was introduced.
12.2(27)SBA
This command was integrated into Cisco IOS Release 12.2(27)SBA and the
digest keyword was replaced by the authentication keyword. The digest
keyword is no longer accepted.
Usage Guidelines
Use this command to clear the L2TP control channel authentication AV pairs counters displayed by the
show l2tun tunnel command.
Examples
The following example clears the counter for L2TP control packets dropped due to failed digest
authentication in Cisco IOS Release 12.0(29)S:
Router# clear l2tun tunnel counters digest
The following example clears the L2TP control channel authentication counters in Cisco IOS
Release 12.2(27)SBA:
Router# clear l2tun tunnel counters authentication
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
111
Layer 2 Tunnel Protocol Version 3
clear l2tun tunnel counters
Related Commands
Command
Description
show l2tun
Displays general information about Layer 2 tunnels and sessions.
show l2tun tunnel
Displays the current state of Layer 2 tunnels and information about currently
configured tunnels.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
112
Layer 2 Tunnel Protocol Version 3
debug acircuit
debug acircuit
To display errors and events that occur on the attachment circuits (the circuits between the provider edge
(PE) and customer edge (CE) routers), use the debug acircuit command in privileged EXEC mode. To
disable debugging output, use the no form of this command.
debug acircuit {error | event}
no debug acircuit {error | event}
Syntax Description
error
Displays errors that occur in attachment circuits.
event
Displays events that occur in attachment circuits.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use the debug acircuit command to identify provisioning events, setup failures, circuit up and down
events, and configuration failures on attachment circuits.
An attachment circuit connects a PE router to a CE router. A router can have many attachment circuits.
The attachment circuit manager controls all the attachment circuits from one central location. Therefore,
when you enable the debug messages for the attachment circuit, you receive information about all the
attachment circuits.
Examples
The following is sample output from the debug acircuit event command when you enable an interface:
Router# debug acircuit event
*Jan 28 15:19:03.070: ACLIB: ac_cstate() Handling circuit UP for interface Se2/0
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: pthru_intf_handle_circuit_up() calling
acmgr_circuit_up
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Connecting
*Jan 28 15:19:03.070: ACMGR: Receive <Circuit Up> msg
*Jan 28 15:19:03.070: Se2/0 ACMGR: circuit up event, SIP state chg down to connecting,
action is service request
*Jan 28 15:19:03.070: Se2/0 ACMGR: Sent a sip service request
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: AC updating switch context.
*Jan 28 15:19:03.070: Se2/0 ACMGR: Rcv SIP msg: resp connect forwarded, hdl 9500001D,
l2ss_hdl 700001E
*Jan 28 15:19:03.070: Se2/0 ACMGR: service connected event, SIP state chg connecting to
connected, action is respond forwarded
*Jan 28 15:19:03.070: ACLIB: pthru_intf_response hdl is 9500001D, response is 1
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
113
Layer 2 Tunnel Protocol Version 3
debug acircuit
*Jan 28 15:19:03.070: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Connected
The following is sample output from the debug acircuit event command when you disable an interface:
Router# debug acircuit event
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0
*Jan 28 15:25:57.014: ACLIB [11.0.1.1, 200]: Setting new AC state to Ac-Idle
*Jan 28 15:25:57.014: ACLIB: SW AC interface INTF-DOWN for interface Se2/0
*Jan 28 15:25:57.014: Se2/0 ACMGR: Receive <Circuit Down> msg
*Jan 28 15:25:57.014: Se2/0 ACMGR: circuit down event, SIP state chg connected to end,
action is service disconnect
*Jan 28 15:25:57.014: Se2/0 ACMGR: Sent a sip service disconnect
*Jan 28 15:25:57.014: ACLIB [11.0.1.1, 200]: AC deleting switch context.
*Jan 28 15:25:59.014: %LINK-5-CHANGED: Interface Serial2/0, changed state to
administratively down
*Jan 28 15:25:59.014: ACLIB: ac_cstate() Handling circuit DOWN for interface Se2/0
*Jan 28 15:26:00.014:%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed
state to down
The following example shows output from the debug acircuit command for an xconnect session on an
Ethernet interface:
Router# debug acircuit
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/1
23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() calling acmgr_circuit_up
23:28:35: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connecting
23:28:35: ACLIB [10.0.3.201, 5]: SW AC interface UP for Ethernet interface Et2/1
23:28:35: ACLIB [10.0.3.201, 5]: pthru_intf_handle_circuit_up() ignoring up event. Already
connected or connecting.
23:28:35: ACMGR: Receive <Circuit Up> msg
23:28:35: Et2/1 ACMGR: circuit up event, SIP state chg down to connecting, action is
service request
23:28:35: Et2/1 ACMGR: Sent a sip service request
23:28:37: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up
23:28:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to up
23:28:53: Et2/1 ACMGR: Rcv SIP msg: resp connect forwarded, hdl D6000002, sss_hdl 9E00000F
23:28:53: Et2/1 ACMGR: service connected event, SIP state chg connecting to connected,
action is respond forwarded
23:28:53: ACLIB: pthru_intf_response hdl is D6000002, response is 1
23:28:53: ACLIB [10.0.3.201, 5]: Setting new AC state to Ac-Connected
The command output is self-explanatory.
Related Commands
Command
Description
debug vpdn
Displays errors and events relating to L2TP configuration and the
surrounding Layer 2 tunneling infrastructure.
debug xconnect
Displays errors and events related to an xconnect configuration.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
114
Layer 2 Tunnel Protocol Version 3
debug atm cell-packing
debug atm cell-packing
To enable the display of ATM cell relay cell-packing debugging information, use the debug atm
cell-packing command in privileged EXEC mode. To disable the display of debugging information, use
the no form of this command.
debug atm cell-packing
no debug atm cell-packing
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(25)S
This command was introduced.
Examples
The following example enables debugging for ATM virtual circuits (VCs) that have been configured with
cell packing:
Router# debug atm cell-packing
ATM Cell Packing debugging is on
00:09:04: ATM Cell Packing: vc 1/100 remote mncp 22 validated
The following example enables debugging for permanent virtual paths (PVPs) that have been configured
with cell packing:
Router# debug atm cell-packing
ATM Cell Packing debugging is on
00:12:33: ATM Cell Packing: vp 1 remote mncp 22 validated
The output indicates that the router received the MNCP information from the remote PE router.
Related Commands
Command
Description
atm mcpt-timers
Creates cell-packing timers that specify how long the PE router can wait for
cells to be packed into an MPLS or L2TPv3 packet.
cell-packing
Enables the packing of multiple ATM cells into a single MPLS or L2TPv3
packet.
show atm cell-packing Displays information about the VCs and VPs that have ATM cell relay over
MPLS or L2TPv3 cell packing enabled.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
115
Layer 2 Tunnel Protocol Version 3
debug vpdn
debug vpdn
To troubleshoot Layer 2 Forwarding (L2F) or Layer 2 Tunnel Protocol (L2TP) virtual private dialup
network (VPDN) tunneling events and infrastructure, use the debug vpdn command in privileged EXEC
mode. To disable debugging output, use the no form of this command.
debug vpdn {call {event | fsm} | error | event [disconnect] | l2tp-sequencing | l2x-data |
l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event |
fsm}}
no debug vpdn {call {event | fsm} | error | event [disconnect] | l2tp-sequencing | l2x-data |
l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event |
fsm}}
Syntax Description
call event
Displays significant events in the VPDN call manager.
call fsm
Displays significant events in the VPDN call manager finite state machine
(fsm).
error
Displays VPDN errors.
event
Displays VPDN events.
disconnect
(Optional) Displays VPDN disconnect events.
l2tp-sequencing
Displays significant events related to L2TP sequence numbers such as
mismatches, resend queue flushes, and drops.
l2x-data
Displays errors that occur in data packets.
l2x-errors
Displays errors that occur in protocol-specific conditions.
l2x-events
Displays events resulting from protocol-specific conditions.
l2x-packets
Displays detailed information about control packets in protocol-specific
conditions.
message
Displays VPDN interprocess messages.
packet
Displays information about VPDN packets.
detail
(Optional) Displays detailed packet information, including packet dumps.
errors
(Optional) Displays errors that occur in packet processing.
sss error
Displays debug information about VPDN Subscriber Service Switch (SSS)
errors.
sss event
Displays debug information about VPDN SSS events.
sss fsm
Displays debug information about the VPDN SSS fsm.
Command Modes
Privileged EXEC
Command History
0S Release
Modification
12.0(23)S
This command was integrated into Cisco IOS Release 12.0(23)S.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
116
Layer 2 Tunnel Protocol Version 3
debug vpdn
S Release
Modification
12.2(22)S
This command was integrated into Cisco IOS Release 12.2(22)S.
12.2(27)SBA
The output was enhanced to display messages about control channel
authentication events.
T Release
Modification
11.2
This command was introduced.
12.0(5)T
Support was added for L2TP debugging messages. The l2tp-sequencing
and errors keywords were added. The l2f-errors, l2f-events, and
l2f-packets keywords were changed to l2x-errors, l2x-events, and
l2x-packets.
12.2(4)T
Support was added for the message and call {event | fsm} keywords.
12.2(11)T
Support was added for the detail keyword.
12.2(13)T
Support was added for the sss {error | event | fsm} keywords.
Usage Guidelines
Note that the debug vpdn packet and debug vpdn packet detail commands generate several debug
operations per packet. Depending on the L2TP traffic pattern, these commands may cause the CPU load
to increase to a high level that impacts performance.
Examples
This section contains the following examples:
•
Debugging VPDN Events on a NAS—Normal L2F Operations
•
Debugging VPDN Events on the Tunnel Server—Normal L2F Operations
•
Debugging VPDN Events on the NAS—Normal L2TP Operations
•
Debugging VPDN Events on the Tunnel Server—Normal L2TP Operations
•
Debugging Protocol-Specific Events on the NAS—Normal L2F Operations
•
Debugging Protocol-Specific Events on the Tunnel Server—Normal L2F Operations
•
Debugging Errors on the NAS—L2F Error Conditions
•
Debugging L2F Control Packets for Complete Information
•
Debugging an L2TPv3 Xconnect Session—Normal Operations
•
Debugging Control Channel Authentication Events for L2TPv3
Debugging VPDN Events on a NAS—Normal L2F Operations
The network access server (NAS) has the following VPDN configuration:
vpdn-group 1
request-dialin
protocol l2f
domain cisco.com
initiate-to ip 172.17.33.125
username nas1 password nas1
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
117
Layer 2 Tunnel Protocol Version 3
debug vpdn
The following is sample output from the debug vpdn event command on a NAS when an L2F tunnel is
brought up and Challenge Handshake Authentication Protocol (CHAP) authentication of the tunnel
succeeds:
Router# debug vpdn event
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar 2 00:26:05.537: looking for tunnel -- cisco.com -*Mar 2 00:26:05.545: Async6 VPN Forwarding...
*Mar 2 00:26:05.545: Async6 VPN Bind interface direction=1
*Mar 2 00:26:05.553: Async6 VPN vpn_forward_user [email protected] is forwarded
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar 2 00:26:06.289: L2F: Chap authentication succeeded for nas1.
The following is sample output from the debug vpdn event command on a NAS when the L2F tunnel is
brought down normally:
Router# debug vpdn event
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar 2 00:27:18.865: Async6 VPN cleanup
*Mar 2 00:27:18.869: Async6 VPN reset
*Mar 2 00:27:18.873: Async6 VPN Unbind interface
%LINK-3-UPDOWN: Interface Async6, changed state to down
Table 8 describes the significant fields shown in the two previous displays. The output describes normal
operations when an L2F tunnel is brought up or down on a NAS.
Table 8
debug vpdn event Field Descriptions for the NAS
Field
Description
Asynchronous interface coming up
%LINK-3-UPDOWN: Interface Async6,
changed state to up
Asynchronous interface 6 came up.
looking for tunnel -- cisco.com --
Domain name is identified.
Async6 VPN Forwarding...
Async6 VPN Bind interface direction=1
•
1—From the NAS to the tunnel server
•
2—From the tunnel server to the NAS
Async6 VPN vpn_forward_user
[email protected] is forwarded
Tunnel for the specified user and domain name is
forwarded.
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async6, changed state to up
Line protocol is up.
L2F: Chap authentication succeeded for
nas1.
Tunnel was authenticated with the tunnel password
nas1.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
118
Tunnel is bound to the interface. These are the
direction values:
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 8
debug vpdn event Field Descriptions for the NAS (continued)
Field
Description
Virtual access interface coming down
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async6, changed state to down
Normal operation when the virtual access interface is
taken down.
Async6 VPN cleanup
Normal cleanup operations performed when the line or
virtual access interface goes down.
Async6 VPN reset
Async6 VPN Unbind interface
Debugging VPDN Events on the Tunnel Server—Normal L2F Operations
The tunnel server has the following VPDN configuration, which uses nas1 as the tunnel name and the
tunnel authentication name. The tunnel authentication name might be entered in a users file on an
authentication, authorization, and accounting (AAA) server and used to define authentication
requirements for the tunnel.
vpdn-group 1
accept-dialin
protocol l2f
virtual-template 1
terminate-from hostname nas1
The following is sample output from the debug vpdn event command on the tunnel server when an L2F
tunnel is brought up successfully:
Router# debug vpdn event
L2F: Chap authentication succeeded for nas1.
Virtual-Access3 VPN Virtual interface created for [email protected]
Virtual-Access3 VPN Set to Async interface
Virtual-Access3 VPN Clone from Vtemplate 1 block=1 filterPPP=0
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
Virtual-Access3 VPN Bind interface direction=2
Virtual-Access3 VPN PPP LCP accepted sent & rcv CONFACK
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
The following is sample output from the debug vpdn event command on a tunnel server when an L2F
tunnel is brought down normally:
Router# debug vpdn event
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down
Virtual-Access3 VPN cleanup
Virtual-Access3 VPN reset
Virtual-Access3 VPN Unbind interface
Virtual-Access3 VPN reset
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down
Table 9 describes the fields shown in two previous outputs. The output describes normal operations when
an L2F tunnel is brought up or down on a tunnel server.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
119
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 9
debug vpdn event Field Descriptions for the Tunnel Server
Field
Description
Tunnel coming up
L2F: Chap authentication succeeded for
nas1.
PPP CHAP authentication status for the tunnel named
nas1.
Virtual-Access3 VPN Virtual interface
created for [email protected]
Virtual access interface was set up on the tunnel server
for the user [email protected].
Virtual-Access3 VPN Set to Async interface Virtual access interface 3 was set to asynchronous for
character-by-character transmission.
Virtual-Access3 VPN Clone from Vtemplate Virtual template 1 was applied to virtual access
1 block=1 filterPPP=0
interface 3.
%LINK-3-UPDOWN: Interface
Virtual-Access3, changed state to up
Link status is set to up.
Virtual-Access3 VPN Bind interface
direction=2
Tunnel is bound to the interface. These are the
direction values:
•
1—From the NAS to the tunnel server
•
2—From the tunnel server to the NAS
Virtual-Access3 VPN PPP LCP accepted
sent & rcv CONFACK
PPP link control protocol (LCP) configuration settings
(negotiated between the remote client and the NAS)
were copied to the tunnel server and acknowledged.
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Virtual-Access3, changed state
to up
Line protocol is up; the line can be used.
Tunnel coming down
%LINK-3-UPDOWN: Interface
Virtual-Access3, changed state to down
Virtual access interface is coming down.
Virtual-Access3 VPN cleanup
Router is performing normal cleanup operations when
a virtual access interface used for an L2F tunnel comes
down.
Virtual-Access3 VPN reset
Virtual-Access3 VPN Unbind interface
Virtual-Access3 VPN reset
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Virtual-Access3, changed state
to down
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
120
Line protocol is down for virtual access interface 3; the
line cannot be used.
Layer 2 Tunnel Protocol Version 3
debug vpdn
Debugging VPDN Events on the NAS—Normal L2TP Operations
The following is sample output from the debug vpdn event command on the NAS when an L2TP tunnel
is brought up successfully:
Router# debug vpdn event
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:17:
20:19:18:
20:19:18:
20:19:18:
20:19:19:
up
L2TP: I SCCRQ from ts1 tnl 8
L2X: Never heard of ts1
Tnl 7 L2TP: New tunnel created for remote ts1, address 172.21.9.4
Tnl 7 L2TP: Got a challenge in SCCRQ, ts1
Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply
Tnl 7 L2TP: Got a Challenge Response in SCCCN from ts1
Tnl 7 L2TP: Tunnel Authentication success
Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established
Tnl 7 L2TP: SM State established
Tnl/Cl 7/1 L2TP: Session FS enabled
Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel
Tnl/Cl 7/1 L2TP: New session created
Tnl/Cl 7/1 L2TP: O ICRP to ts1 8/1
Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect
Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established
Vi1 VPDN: Virtual interface created for [email protected]
Vi1 VPDN: Set to Async interface
Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Vi1 VPDN: Bind interface direction=2
Vi1 VPDN: PPP LCP accepting rcv CONFACK
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to
Debugging VPDN Events on the Tunnel Server—Normal L2TP Operations
The following is sample output from the debug vpdn event command on the tunnel server when an L2TP
tunnel is brought up successfully:
Router# debug vpdn event
20:47:33:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:35:
20:47:36:
%LINK-3-UPDOWN: Interface Async7, changed state to up
As7 VPDN: Looking for tunnel -- cisco.com -As7 VPDN: Get tunnel info for cisco.com with NAS nas1, IP 172.21.9.13
As7 VPDN: Forward to address 172.21.9.13
As7 VPDN: Forwarding...
As7 VPDN: Bind interface direction=1
Tnl/Cl 8/1 L2TP: Session FS enabled
Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel
As7 8/1 L2TP: Create session
Tnl 8 L2TP: SM State idle
Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply
Tnl 8 L2TP: SM State wait-ctl-reply
As7 VPDN: [email protected] is forwarded
Tnl 8 L2TP: Got a challenge from remote peer, nas1
Tnl 8 L2TP: Got a response from remote peer, nas1
Tnl 8 L2TP: Tunnel Authentication success
Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established
Tnl 8 L2TP: SM State established
As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply
As7 8/1 L2TP: Session state change from wait-reply to established
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
121
Layer 2 Tunnel Protocol Version 3
debug vpdn
Debugging Protocol-Specific Events on the NAS—Normal L2F Operations
The following is sample output from the debug vpdn l2x-events command on the NAS when an L2F
tunnel is brought up successfully:
Router# debug vpdn l2x-events
%LINK-3-UPDOWN: Interface Async6, changed state to up
*Mar 2 00:41:17.365: L2F Open UDP socket to 172.21.9.26
*Mar 2 00:41:17.385: L2F_CONF received
*Mar 2 00:41:17.389: L2F Removing resend packet (type 1)
*Mar 2 00:41:17.477: L2F_OPEN received
*Mar 2 00:41:17.489: L2F Removing resend packet (type 2)
*Mar 2 00:41:17.493: L2F building nas2gw_mid0
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up
*Mar 2 00:41:18.613: L2F_OPEN received
*Mar 2 00:41:18.625: L2F Got a MID management packet
*Mar 2 00:41:18.625: L2F Removing resend packet (type 2)
*Mar 2 00:41:18.629: L2F MID synced NAS/HG Clid=7/15 Mid=1 on Async6
The following is sample output from the debug vpdn l2x-events command on a NAS when an L2F
tunnel is brought down normally:
Router# debug vpdn l2x-events
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down
%LINK-5-CHANGED: Interface Async6, changed state to reset
*Mar 2 00:42:29.213: L2F_CLOSE received
*Mar 2 00:42:29.217: L2F Destroying mid
*Mar 2 00:42:29.217: L2F Removing resend packet (type 3)
*Mar 2 00:42:29.221: L2F Tunnel is going down!
*Mar 2 00:42:29.221: L2F Initiating tunnel shutdown.
*Mar 2 00:42:29.225: L2F_CLOSE received
*Mar 2 00:42:29.229: L2F_CLOSE received
*Mar 2 00:42:29.229: L2F Got closing for tunnel
*Mar 2 00:42:29.233: L2F Removing resend packet
*Mar 2 00:42:29.233: L2F Closed tunnel structure
%LINK-3-UPDOWN: Interface Async6, changed state to down
*Mar 2 00:42:31.793: L2F Closed tunnel structure
*Mar 2 00:42:31.793: L2F Deleted inactive tunnel
Table 10 describes the fields shown in the displays.
Table 10
debug vpdn l2x-events Field Descriptions—NAS
Field
Descriptions
Tunnel coming up
%LINK-3-UPDOWN: Interface Async6,
changed state to up
Asynchronous interface came up normally.
L2F Open UDP socket to 172.21.9.26
L2F opened a User Datagram Protocol (UDP) socket to
the tunnel server IP address.
L2F_CONF received
L2F_CONF signal was received. When sent from the
tunnel server to the NAS, an L2F_CONF indicates the
tunnel server's recognition of the tunnel creation
request.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
122
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 10
debug vpdn l2x-events Field Descriptions—NAS (continued)
Field
Descriptions
L2F Removing resend packet (type ...)
Removing the resend packet for the L2F management
packet.
There are two resend packets that have different
meanings in different states of the tunnel.
L2F_OPEN received
L2F_OPEN management message was received,
indicating that the tunnel server accepted the NAS
configuration of an L2F tunnel.
L2F building nas2gw_mid0
L2F is building a tunnel between the NAS and the
tunnel server, using the Multiplex ID (MID) MID0.
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async6, changed state to up
Line protocol came up. Indicates whether the software
processes that handle the line protocol regard the
interface as usable.
L2F_OPEN received
L2F_OPEN management message was received,
indicating that the tunnel server accepted the NAS
configuration of an L2F tunnel.
L2F Got a MID management packet
MID management packets are used to communicate
between the NAS and the tunnel server.
L2F MID synced NAS/HG Clid=7/15 Mid=1 L2F synchronized the Client IDs on the NAS and the
on Async6
tunnel server, respectively. A multiplex ID is assigned
to identify this connection in the tunnel.
Tunnel coming down
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async6, changed state to down
Line protocol came down. Indicates whether the
software processes that handle the line protocol regard
the interface as usable.
%LINK-5-CHANGED: Interface Async6,
changed state to reset
Interface was marked as reset.
L2F_CLOSE received
NAS received a request to close the tunnel.
L2F Destroying mid
Connection identified by the MID is being taken down.
L2F Tunnel is going down!
Advisory message about impending tunnel shutdown.
L2F Initiating tunnel shutdown.
Tunnel shutdown has started.
L2F_CLOSE received
NAS received a request to close the tunnel.
L2F Got closing for tunnel
NAS began tunnel closing operations.
%LINK-3-UPDOWN: Interface Async6,
changed state to down
Asynchronous interface was taken down.
L2F Closed tunnel structure
NAS closed the tunnel.
L2F Deleted inactive tunnel
Now-inactivated tunnel was deleted.
Debugging Protocol-Specific Events on the Tunnel Server—Normal L2F Operations
The following is sample output from the debug vpdn l2x-events command on a tunnel server when an
L2F tunnel is created:
Router# debug vpdn l2x-events
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
123
Layer 2 Tunnel Protocol Version 3
debug vpdn
L2F_CONF received
L2F Creating new tunnel for nas1
L2F Got a tunnel named nas1, responding
L2F Open UDP socket to 172.21.9.25
L2F_OPEN received
L2F Removing resend packet (type 1)
L2F_OPEN received
L2F Got a MID management packet
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
The following is sample output from the debug vpdn l2x-events command on a tunnel server when the
L2F tunnel is brought down normally:
Router# debug vpdn l2x-events
L2F_CLOSE received
L2F Destroying mid
L2F Removing resend packet (type 3)
L2F Tunnel is going down!
L2F Initiating tunnel shutdown.
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
L2F_CLOSE received
L2F Got closing for tunnel
L2F Removing resend packet
L2F Removing resend packet
L2F Closed tunnel structure
L2F Closed tunnel structure
L2F Deleted inactive tunnel
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Table 11 describes the significant fields shown in the displays.
Table 11
debug vpdn l2x-events Field Descriptions—Tunnel Server
Field
Description
Tunnel coming up
L2F_CONF received
L2F configuration is received from the NAS. When sent
from a NAS to a tunnel server, the L2F_CONF is the
initial packet in the conversation.
L2F Creating new tunnel for nas1
Tunnel named nas1 is being created.
L2F Got a tunnel named nas1, responding
Tunnel server is responding.
L2F Open UDP socket to 172.21.9.25
Opening a socket to the NAS IP address.
L2F_OPEN received
L2F_OPEN management message was received,
indicating the NAS is opening an L2F tunnel.
L2F Removing resend packet (type ...)
Removing the resend packet for the L2F management
packet.
The two resend packet types have different meanings in
different states of the tunnel.
L2F Got a MID management packet
L2F MID management packets are used to
communicate between the NAS and the tunnel server.
%LINK-3-UPDOWN: Interface
Virtual-Access1, changed state to up
Tunnel server is bringing up virtual access interface 1
for the L2F tunnel.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
124
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 11
debug vpdn l2x-events Field Descriptions—Tunnel Server (continued)
Field
Description
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Virtual-Access1, changed state
to up
Line protocol is up. The line can be used.
Tunnel coming down
L2F_CLOSE received
NAS or tunnel server received a request to close the
tunnel.
L2F Destroying mid
Connection identified by the MID is being taken down.
L2F Removing resend packet (type ...)
Removing the resend packet for the L2F management
packet.
There are two resend packets that have different
meanings in different states of the tunnel.
L2F Tunnel is going down!
L2F Initiating tunnel shutdown.
Router is performing normal operations when a tunnel
is coming down.
%LINK-3-UPDOWN: Interface
Virtual-Access1, changed state to down
The virtual access interface is coming down.
L2F_CLOSE received
Router is performing normal cleanup operations when
the tunnel is being brought down.
L2F Got closing for tunnel
L2F Removing resend packet
L2F Removing resend packet
L2F Closed tunnel structure
L2F Closed tunnel structure
L2F Deleted inactive tunnel
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Virtual-Access1, changed state
to down
Line protocol is down; virtual access interface 1 cannot
be used.
Debugging Errors on the NAS—L2F Error Conditions
The following is sample output from the debug vpdn errors command on a NAS when the L2F tunnel
is not set up:
Router# debug vpdn errors
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to down
%LINK-5-CHANGED: Interface Async1, changed state to reset
%LINK-3-UPDOWN: Interface Async1, changed state to down
%LINK-3-UPDOWN: Interface Async1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up
VPDN tunnel management packet failed to authenticate
VPDN tunnel management packet failed to authenticate
Table 12 describes the significant fields shown in the display.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
125
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 12
debug vpdn error Field Descriptions for the NAS
Field
Description
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async1, changed state to down
Line protocol on the asynchronous interface went
down.
%LINK-5-CHANGED: Interface Async1,
changed state to reset
Asynchronous interface 1 was reset.
%LINK-3-UPDOWN: Interface Async1,
changed state to down
Link from asynchronous interface 1 link went down
and then came back up.
%LINK-3-UPDOWN: Interface Async1,
changed state to up
%LINEPROTO-5-UPDOWN: Line protocol
on Interface Async1, changed state to up
Line protocol on the asynchronous interface came back
up.
VPDN tunnel management packet failed to
authenticate
Tunnel authentication failed. This is the most common
VPDN error.
Note
Verify the password for the NAS and the tunnel
server name.
If you store the password on an AAA server, you can
use the debug aaa authentication command.
The following is sample output from the debug vpdn l2x-errors command:
Router# debug vpdn l2x-errors
%LINK-3-UPDOWN: Interface Async1, changed state to up
L2F Out of sequence packet 0 (expecting 0)
L2F Tunnel authentication succeeded for cisco.com
L2F Received a close request for a non-existent mid
L2F Out of sequence packet 0 (expecting 0)
L2F packet has bogus1 key 1020868 D248BA0F
L2F packet has bogus1 key 1020868 D248BA0F
Table 13 describes the significant fields shown in the display.
Table 13
debug vpdn l2x-errors Field Descriptions
Field
Description
%LINK-3-UPDOWN: Interface
Async1, changed state to up
The line protocol on the asynchronous interface came up.
L2F Out of sequence packet 0
(expecting 0)
Packet was expected to be the first in a sequence starting at 0, but
an invalid sequence number was received.
L2F Tunnel authentication
succeeded for cisco.com
Tunnel was established from the NAS to the tunnel server,
cisco.com.
L2F Received a close request for Multiplex ID was not used previously; cannot close the tunnel.
a non-existent mid
L2F Out of sequence packet 0
(expecting 0)
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
126
Packet was expected to be the first in a sequence starting at 0, but
an invalid sequence number was received.
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 13
debug vpdn l2x-errors Field Descriptions (continued)
Field
Description
L2F packet has bogus1 key
1020868 D248BA0F
Value based on the authentication response given to the peer during
tunnel creation. This packet, in which the key does not match the
expected value, must be discarded.
L2F packet has bogus1 key
1020868 D248BA0F
Another packet was received with an invalid key value. The packet
must be discarded.
Debugging L2F Control Packets for Complete Information
The following is sample output from the debug vpdn l2x-packets command on a NAS. This example
displays a trace for a ping command:
Router# debug vpdn l2x-packets
L2F SENDING (17): D0 1 1 10 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 16 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 10 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F SENDING (17): D0 1 1 11 0 0 0 4 0 11 0 0 81 94 E1 A0 4
L2F header flags: 53249 version 53249 protocol 1 sequence 17 mid 0 cid 4
length 17 offset 0 key 1701976070
L2F RECEIVED (17): D0 1 1 11 0 0 0 4 0 11 0 0 65 72 18 6 5
L2F header flags: 57345 version 57345 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key 1701976070
L2F-IN Output to Async1 (16): FF 3 C0 21 9 F 0 C 0 1D 41 AD FF 11 46 87
L2F-OUT (16): FF 3 C0 21 A F 0 C 0 1A C9 BD FF 11 46 87
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 32 offset 0 key -2120949344
L2F-OUT (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 3 1 0 0 1 8 0 62 B1
0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key -2120949344
L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4
length 120 offset 3 key 1701976070
L2F-IN Output to Async1 (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 1 1 0
0 3 0 0 6A B1 0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD
AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB
CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
Table 14 describes the significant fields shown in the display.
Table 14
debug vpdn l2x-packets Field Descriptions
Field
Description
L2F SENDING (17)
Number of bytes being sent. The first set of
“SENDING”...“RECEIVED” lines displays L2F keepalive traffic.
The second set displays L2F management data.
L2F header flags:
Version and flags, in decimal.
version 53249
Version.
protocol 1
Protocol for negotiation of the point-to-point link between the NAS
and the tunnel server is always 1, indicating L2F management.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
127
Layer 2 Tunnel Protocol Version 3
debug vpdn
Table 14
debug vpdn l2x-packets Field Descriptions (continued)
Field
Description
sequence 16
Sequence numbers start at 0. Each subsequent packet is sent with the
next increment of the sequence number. The sequence number is thus
a free running counter represented modulo 256. There is a distinct
sequence counter for each distinct MID value.
mid 0
Multiplex ID, which identifies a particular connection within the
tunnel. Each new connection is assigned a MID currently unused
within the tunnel.
cid 4
Client ID used to assist endpoints in demultiplexing tunnels.
length 17
Size in octets of the entire packet, including header, all fields pre-sent,
and payload. Length does not reflect the addition of the checksum, if
pre-sent.
offset 0
Number of bytes past the L2F header at which the payload data is
expected to start. If it is 0, the first byte following the last byte of the
L2F header is the first byte of payload data.
key 1701976070
Value based on the authentication response given to the peer during
tunnel creation. During the life of a session, the key value serves to
resist attacks based on spoofing. If a packet is received in which the
key does not match the expected value, the packet must be silently
discarded.
L2F RECEIVED (17)
Number of bytes received.
L2F-IN Otput to Async1
(16)
Payload datagram. The data came in to the VPDN code.
L2F-OUT (16):
Payload datagram sent out from the VPDN code to the tunnel.
L2F-OUT (101)
Ping payload datagram. The value 62 in this line is the ping packet
size in hexadecimal (98 in decimal). The three lines that follow this
line show ping packet data.
Debugging an L2TPv3 Xconnect Session—Normal Operations
The following example shows output from the debug vpdn command for an L2TP version 3 (L2TPv3)
xconnect session on an Ethernet interface:
Router# debug vpdn l2x-events
23:31:18: L2X: l2tun session [1669204400], event [client request], old state [open], new
state [open]
23:31:18: L2X: L2TP: Received L2TUN message <Connect>
23:31:18: Tnl/Sn58458/28568 L2TP: Session state change from idle to wait-for-tunnel
23:31:18: Tnl/Sn58458/28568 L2TP: Create session
23:31:18: Tnl58458 L2TP: SM State idle
23:31:18: Tnl58458 L2TP: O SCCRQ
23:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds
23:31:18: Tnl58458 L2TP: Tunnel state change from idle to wait-ctl-reply
23:31:18: Tnl58458 L2TP: SM State wait-ctl-reply
23:31:18: Tnl58458 L2TP: I SCCRP from router
23:31:18: Tnl58458 L2TP: Tunnel state change from wait-ctl-reply to established
23:31:18: Tnl58458 L2TP: O SCCCN to router tnlid 8012
23:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds
23:31:18: Tnl58458 L2TP: SM State established
23:31:18: Tnl/Sn58458/28568 L2TP: O ICRQ to router 8012/0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
128
Layer 2 Tunnel Protocol Version 3
debug vpdn
23:31:18: Tnl/Sn58458/28568 L2TP: Session state change from wait-for-tunnel to wait-reply
23:31:19: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds
23:31:20: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up
23:31:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to
up
23:31:25: L2X: Sending L2TUN message <Connect OK>
23:31:25: Tnl/Sn58458/28568 L2TP: O ICCN to router 8012/35149
23:31:25: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds
23:31:25: Tnl/Sn58458/28568 L2TP: Session state change from wait-reply to established
23:31:25: L2X: l2tun session [1669204400], event [server response], old state [open], new
state [open]
23:31:26: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds
Debugging Control Channel Authentication Events for L2TPv3
The following debug messages show control channel authentication failure events in Cisco IOS
Release 12.2(27)SBA:
Router# debug vpdn l2x-events
!
Tnl41855 L2TP: Per-Tunnel auth counter, Overall Failed, now 1
Tnl41855 L2TP: Tunnel auth counter, Overall Failed, now 219
!
Related Commands
Command
Description
debug aaa authentication
Displays information on AAA/TACACS+ authentication.
debug acircuit
Displays events and failures related to attachment circuits.
debug pppoe
Display debugging information for PPPoE sessions.
debug vpdn pppoe-data
Displays data packets of PPPoE sessions.
debug vpdn pppoe-error
Displays PPPoE protocol errors that prevent a session from
being established or errors that cause an established sessions
to be closed.
debug vpdn pppoe-events
Displays PPPoE protocol messages about events that are part
of normal session establishment or shutdown.
debug vpdn pppoe-packet
Displays each PPPoE protocol packet exchanged.
debug xconnect
Displays errors and events related to an xconnect
configuration.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
129
Layer 2 Tunnel Protocol Version 3
debug xconnect
debug xconnect
To debug a problem related to the xconnect configuration, use the debug xconnect command in
privileged EXEC mode. To disable debugging output, use the no form of this command.
debug xconnect {error | event}
no debug xconnect {error | event}
Syntax Description
error
Displays errors related to an xconnect configuration.
event
Displays events related to an xconnect configuration processing.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use this command to display debugging information about xconnect sessions.
Examples
The following shows sample output from the debug xconnect command for an xconnect session on an
Ethernet interface:
Router# debug xconnect
00:01:16: XC AUTH [Et2/1, 5]: Event: start xconnect authorization, state changed from IDLE
to AUTHORIZING
00:01:16: XC AUTH [Et2/1, 5]: Event: found xconnect authorization, state changed from
AUTHORIZING to DONE
00:01:16: XC AUTH [Et2/1, 5]: Event: free xconnect authorization request, state changed
from DONE to END
Related Commands
Command
Description
debug acircuit
Displays events and failures related to attachment circuits.
debug vpdn
Displays errors and events relating to L2TP configuration and the
surrounding Layer 2 tunneling infrastructure.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
130
Layer 2 Tunnel Protocol Version 3
digest
digest
To enable Layer 2 Tunneling Protocol Version 3 (L2TPv3) control channel authentication or integrity
checking, use the digest command in L2TP class configuration mode. To disable control channel
authentication or integrity checking, use the no form of this command.
digest [secret [0 | 7] password] [hash {md5 | sha}]
no digest [secret password] [hash {md5 | sha}]
Syntax Description
secret
(Optional) Enables L2TPv3 control channel authentication. If the digest
command is issued without the secret keyword option, L2TPv3 integrity
checking will be enabled.
[0 | 7]
Specifies the input format of the shared secret.
•
0—Specifies that a plain-text secret will be entered.
•
7—Specifies that an encrypted secret will be entered.
The default value is 0.
password
The shared secret used between peer provider edge (PE) routers. The value
entered for the password argument must be in the format that matches the
input format specified by the [0 | 7] keyword option.
hash {md5 | sha}
(Optional) Specifies the hash function to be used in per-message digest
calculations.
•
md5—Specifies HMAC-MD5 hashing.
•
sha—Specifies HMAC-SHA-1 hashing.
The default hash function is md5.
Command Default
L2TPv3 control channel authentication and integrity checking are disabled by default.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(29)S
This command was introduced.
12.0(30)S
This command was enhanced to allow two different passwords to be configured
simultaneously.
12.2(27)SBA This command was integrated into Cisco IOS Release 12.2(27)SBA.
Usage Guidelines
Beginning in Cisco IOS Release 12.0(29)S and Cisco IOS Release 12.2(27)SBA, two methods of control
channel authentication are available. The L2TPv3 Control Message Hashing feature (enabled with the
digest command) introduces a more robust authentication method than the older Challenge Handshake
Authentication Protocol (CHAP) style method of authentication enabled with the authentication
command. You may choose to enable both methods of authentication to ensure interoperability with
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
131
Layer 2 Tunnel Protocol Version 3
digest
peers that support only one of these methods of authentication, but this configuration will yield control
of which authentication method is used to the peer PE router. Enabling both methods of authentication
should be considered an interim solution to solve backward-compatibility issues during software
upgrades.
Table 15 shows a compatibility matrix for the different L2TPv3 authentication methods. PE1 is running
a Cisco IOS software release that supports the L2TPv3 Control Message Hashing feature, and the
different possible authentication configurations for PE1 are shown in the first column. Each remaining
column represents PE2 running software with different available authentication options, and the
intersections indicate the different compatible configuration options for PE2. If any PE1/PE2
authentication configuration poses ambiguity on which method of authentication will be used, the
winning authentication method is indicated in bold. If both the old and new authentication methods are
enabled on PE1 and PE2, both types of authentication will occur.
Table 15
Compatibility Matrix for L2TPv3 Authentication Methods
PE1 Authentication
Configuration
PE2 Supporting Old
Authentication1
PE2 Supporting New
Authentication2
PE2 Supporting Old and
New Authentication3
None
None
None
None
New integrity check
New integrity check
—
Old authentication
Old authentication
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
New authentication
—
New authentication
New authentication
Old authentication and
new authentication
New integrity check
Old and new
authentication
None
Old authentication
None
None
New integrity check
New integrity check
New authentication
Old authentication
New authentication
Old and new
authentication
Old authentication and
new integrity check
Old authentication
and new integrity
check
Old authentication
—
Old authentication
Old authentication and
new authentication
Old authentication and
new integrity check
1. Any PE software that supports only the old CHAP-like authentication system.
2. Any PE software that supports only the new message digest authentication and integrity checking authentication system, but
does not understand the old CHAP-like authentication system. This type of software may be implemented by other vendors
based on the latest L2TPv3 draft.
3. Any PE software that supports both the old CHAP-like authentication and the new message digest authentication and integrity
checking authentication system, such as Cisco IOS 12.0(29)S, Cisco IOS Release 12.2(27)SBA, or later releases.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
132
Layer 2 Tunnel Protocol Version 3
digest
In Cisco IOS Release 12.0(30)S, this command was enhanced to allow two L2TPv3 control channel
authentication passwords to be configured simultaneously. This enhancement allows the transition from
using an old authentication password to using a new authentication password without interrupting
L2TPv3 services. No more than two passwords may be configured at a time. In order to configure a new
password when two passwords are already configured, you must remove one of the existing passwords
using the no digest secret password command. The number of configured passwords can be verified
using the show l2tun tunnel command.
Examples
The following example configures control channel authentication and a control channel authentication
password for tunnels belonging to the L2TP class named class1:
l2tp-class class1
digest secret cisco hash sha
hidden
The following example configures a second control channel authentication password for tunnels
belonging to the L2TP class named class1:
l2tp-class class1
digest secret cisco2 hash sha
The following example removes the old control channel authentication password for tunnels belonging
to the L2TP class named class1. The old password should be removed only after all peer routers have
been configured with the new password.
l2tp-class class1
no digest secret cisco hash sha
The following example configures control channel integrity checking and disables validation of the
message digest for L2TPv3 tunnels belonging to the L2TP class named class2:
l2tp-class class2
digest hash sha
no digest check
The following example disables validation of the message digest for L2TPv3 tunnels belonging to the
L2TP class named class3. Control channel authentication and control channel integrity checking are both
disabled.
l2tp-class class3
no digest check
Related Commands
Command
Description
authentication
Enables L2TPv3 CHAP-style authentication.
digest check
Enables the validation of the message digest in received control messages.
l2tp class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
show l2tun tunnel
Displays the current state of L2TPv3 tunnels and displays information about
currently configured tunnels, including local and remote L2TP hostnames,
aggregate packet counts, and L2TP control channels.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
133
Layer 2 Tunnel Protocol Version 3
digest check
digest check
To enable the validation of the message digest in received control messages, use the digest check
command in L2TP class configuration mode. To disable the validation of the message digest in received
control messages, use the no form of this command.
digest check
no digest check
Syntax Description
This command has no keywords or arguments.
Command Default
Message digest validation is enabled by default.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(29)S
This command was introduced.
12.2(27)SBA
This command was integrated into Cisco IOS Release 12.2(27)SBA.
Usage Guidelines
Message digest validation is enabled by default. The data path received sequence number update is
deactivated, and the minimum local receive-window-size is restricted to 35.
If the no digest check command is issued, received message digests will be ignored and control
messages will be accepted. The data path received sequence number update will be activated, and there
will be no restriction on the minimum receive-window-size.
Note
Examples
The no digest check command is not valid if Layer 2 Tunneling Protocol Version 3 (L2TPv3) control
channel authentication has been configured using the digest secret command.
The following example configures control channel integrity checking and disables validation of the
message digest:
l2tp-class class1
digest hash sha
no digest check
The following example disables validation of the message digest. Control channel authentication and
control channel integrity checking are both disabled.
l2tp-class class1
no digest check
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
134
Layer 2 Tunnel Protocol Version 3
digest check
Related Commands
Command
Description
l2tp class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
digest
Enables L2TPv3 control channel authentication or integrity checking.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
135
Layer 2 Tunnel Protocol Version 3
encapsulation l2tpv3
encapsulation l2tpv3
To specify that Layer 2 Tunnel Protocol Version 3 (L2TPv3) is used as the data encapsulation method
for tunneling IP traffic over the pseudowire, use the encapsulation l2tpv3 command in pseudowire class
or VC class configuration mode. To remove L2TPv3 as the encapsulation method, use the no form of
this command.
encapsulation l2tpv3
no encapsulation l2tpv3
Syntax Description
This command has no arguments or keywords.
Command Default
No encapsulation method is specified.
Command Modes
Pseudowire class configuration
VC class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
This command must be configured if the pseudowire class will be referenced from an xconnect
configured to forward L2TPv3 traffic.
Examples
The following example shows how to configure L2TPv3 as the data encapsulation method for the
pseudowire class named ether-pw:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# encapsulation l2tpv3
The following example configures ATM AAL5 over L2TPv3 in VC class configuration mode:
vc-class atm aal5class
encapsulation aal5
Related Commands
Command
Description
encapsulation mpls
Configures MPLS as the data encapsulation method over AToM-enabled
IP/MPLS networks.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
136
Layer 2 Tunnel Protocol Version 3
hello
hello
To configure the interval used to exchange hello keepalive packets in a Layer 2 control channel, use the
hello command in L2TP class configuration mode. To disable the sending of hello keepalive packets, use
the no form of this command.
hello seconds
no hello seconds
Syntax Description
seconds
Command Default
The router sends hello keepalive packets at 60 second intervals.
Command Default
L2TP class configuration
Command History
Release
Number of seconds that a router at one end of a Layer 2 control channel
waits between sending hello keepalive packets to its peer router. The valid
values range from 0 to 1000 seconds. The default value is 60 seconds.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
You can configure different values with the hello command on the router at each end of a Layer 2 control
channel.
Examples
The following example sets an interval of 120 seconds between sendings of hello keepalive messages in
pseudowires that have been configured using the L2TP class configuration named “l2tp class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# hello 120
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
137
Layer 2 Tunnel Protocol Version 3
hidden
hidden
To hide the attribute-value pair (AVP) values in Layer 2 Tunneling Protocol (L2TP) control messages,
use the hidden command in L2TP class configuration mode. To unhide AVPs, use the no form of this
command.
hidden
no hidden
Syntax Description
This command has no arguments or keywords.
Command Default
L2TP AVP hiding is disabled.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.0(29)S
This command was modified to function only with the authentication
method configured with the digest secret command and keyword
combination.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(27)SBA
This command was modified to function only with the authentication
method configured with the digest secret command and keyword
combination.
Usage Guidelines
Use the hidden command to provide additional security for the exchange of control messages between
provider edge routers in a Layer 2 Tunnel Protocol Version 3 (L2TPv3) control channel. Because
username and password information is exchanged between devices in clear text, it is useful to encrypt
L2TP AVP values with the hidden command.
Beginning in Cisco IOS Release 12.0(29)S and Cisco IOS Release 12.2(27)SBA, only the hiding of the
cookie AVP is supported.
In Cisco IOS Release 12.0(29)S and Cisco IOS Release 12.2(27)SBA this command was modified to
function only with the authentication method configured using the digest secret command and keyword
combination. AVP hiding is enabled only when both the digest secret command and keyword
combination and the hidden command have been issued. If another method of authentication is also
configured, such as Challenge Handshake Authentication Protocol (CHAP) style authentication
configured with the L2TP class command authentication, AVP hiding will not be enabled.
If AVP hiding is configured, the session local cookie will be hidden when sent in incoming-call-request
(ICRQ) and incoming-call-reply (ICRP) messages.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
138
Layer 2 Tunnel Protocol Version 3
hidden
Whether or not AVP hiding is enabled, if a hidden AVP is received the AVP will be unhidden using the
shared secret configured with the digest secret command and keyword combination. If no shared secret
is configured, the AVP will not be unhidden and an error will be reported. If the M-bit is set in the
received hidden AVP, the control channel or tunnel will be torn down.
Examples
The following example enables AVP hiding and encrypts AVPs in control messages in L2TPv3
pseudowires configured using the L2TP class configuration named l2tp class1:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# digest secret cisco hash sha
Router(config-l2tp-class)# hidden
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
139
Layer 2 Tunnel Protocol Version 3
hostname (L2TP)
hostname (L2TP)
To configure the hostname that the router will use to identify itself during Layer 2 Tunnel Protocol
Version 3 (L2TPv3) authentication, use the hostname command in L2TP class configuration mode. To
remove the hostname, use the no form of this command.
hostname name
no hostname name
Syntax Description
name
Command Default
No hostname is specified for L2TPv3 authentication.
Command Modes
L2TP class configuration
Command History
Release
Name used to identify the router during authentication.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
If you do not use the hostname command, the hostname of the router is used for L2TPv3 authentication.
Examples
The following example configures the hostname “yb2” for a provider edge router used at one end of an
L2TPv3 control channel in an L2TPv3 pseudowire that has been configured using the L2TP class
configuration named “l2tp class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# hostname yb2
Related Commands
Command
Description
ip local interface
Configures the IP address of the PE router interface to be used as the source
IP address for sending tunneled packets.
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
140
Layer 2 Tunnel Protocol Version 3
ip dfbit set
ip dfbit set
To enable the Don’t Fragment (DF) bit in the outer Layer 2 header, use the ip dfbit set command in
pseudowire class configuration mode. To disable the DF bit setting, use the no form of this command.
ip dfbit set
no ip dfbit set
Syntax Description
This command has no arguments or keywords.
Command Default
For Cisco 12000 series Internet routers, the DF bit is on by default.
For other platforms, the DF bit is off by default.
Command Modes
Pseudowire class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Note
Examples
Use this command to set the DF bit on if, for performance reasons, you do not want tunneled packet
reassembly to be performed on the router.
The no ip dfbit set command is not supported on the Cisco 12000 series Internet routers.
The following example shows how to enable the DF bit in the outer Layer 2 header in pseudowires that
were created from the pseudowire class named “ether-pw”:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# ip dfbit set
Related Commands
Command
Description
ip pmtu (L2TP)
Enables the discovery of a PMTU for Layer 2 traffic.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
141
Layer 2 Tunnel Protocol Version 3
ip local interface
ip local interface
To configure the IP address of the provider edge (PE) router interface to be used as the source IP address
for sending tunneled packets, use the ip local interface command in pseudowire class configuration
mode. To remove the IP address, use the no form of this command.
ip local interface interface-name
no ip local interface interface-name
Syntax Description
interface-name
Command Default
No interface is configured.
Command Modes
Pseudowire class configuration
Command History
Release
Usage Guidelines
Examples
Name of the PE interface whose IP address is used as the source IP address
for sending tunneled packets over a Layer 2 pseudowire.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Use the same local interface name for all pseudowire classes configured between a pair of PE routers. It
is highly recommended that you configure a loopback interface with this command. If you do not
configure a loopback interface, the router will choose the “best available local address,” which could be
any IP address configured on a core-facing interface. This configuration could prevent a control channel
from being established.
Note
The interface configured with the ip local interface command must be a loopback interface on
Cisco 12000 series Internet routers.
Note
This command must be configured for pseudowire class configurations using Layer 2 Tunnel Protocol
version 3 (L2TPv3) as the data encapsulation method.
The following example shows how to configure the IP address of the local Ethernet interface 0/0 as the
source IP address for sending Ethernet packets through an L2TPv3 session:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# ip local interface ethernet 0/0
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
142
Layer 2 Tunnel Protocol Version 3
ip local interface
Related Commands
Command
Description
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
143
Layer 2 Tunnel Protocol Version 3
ip pmtu
ip pmtu
To enable the discovery of a path maximum transmission unit (MTU) for Layer 2 traffic, use the ip pmtu
command in VPDN group configuration mode or pseudowire class configuration mode. To disable path
MTU discovery, use the no form of this command.
ip pmtu
no ip pmtu
Syntax Description
This command has no arguments or keywords.
Command Default
Path MTU discovery is disabled.
Command Modes
VPDN group configuration
Pseudowire class configuration
Command History
Release
Modification
12.2(4)T
This command was introduced.
12.2(11)T
This command was integrated into Cisco IOS Release 12.2(11)T and
implemented on the Cisco 1760, Cisco AS5300, Cisco AS5400, and
Cisco AS5800 platforms.
12.0(23)S
This command was integrated into Cisco IOS Release 12.0(23)S.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
When issued in VPDN group configuration mode, the ip pmtu command enables any Layer 2 Tunnel
Protocol (L2TP) tunnel associated with the specified virtual private dialup network (VPDN) group to
participate in path MTU discovery.
When issued in pseudowire class configuration mode, the ip pmtu command enables any Layer 2 session
derived from the specified pseudowire class configuration to participate in path MTU discovery.
Path MTU checks decrease switching performance; therefore this option is disabled by default.
The ip pmtu command enables the processing of Internet Control Message Protocol (ICMP)
unreachable messages that indicate fragmentation errors in the IP backbone network carrying the
tunneled traffic. The MTU of the Layer 2 session is updated according to the MTU information contained
in the ICMP unreachable message.
The ip pmtu command also enables MTU checking for IP packets that are sent into a Layer 2 session
with the Don’t Fragment (DF) bit set. If an IP packet is larger than the MTU of the tunnel, the packet is
dropped and an ICMP unreachable message is sent. If an IP packet is smaller than the MTU of the tunnel,
the DF bit in the packet header is reflected from the inner IP header to the tunnel header.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
144
Layer 2 Tunnel Protocol Version 3
ip pmtu
Examples
The following example configures a VPDN group named “dial-in” on an L2TP network server and uses
the ip pmtu command to specify that L2TP tunnels will participate in path MTU discovery:
vpdn-group dial-in
accept-dialin
protocol l2tp
virtual-template 1
l2tp security crypto-profile l2tp
no l2tp tunnel authentication
lcp renegotiation on-mismatch
ip pmtu
The following example shows how to enable the discovery of the path MTU for pseudowires that have
been created from the pseudowire class named “ether-pw”:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# ip pmtu
Related Commands
Command
Description
ip dfbit set
Enables the DF bit in the outer Layer 2 tunnel header.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
145
Layer 2 Tunnel Protocol Version 3
ip protocol
ip protocol
To configure the Layer 2 Tunnel Protocol (L2TP) or Universal Tunnel Interface (UTI) as the IP protocol
used for tunneling packets in a Layer 2 pseudowire, use the ip protocol command in pseudowire class
configuration mode. To remove the IP protocol configuration, use the no form of this command.
ip protocol {l2tp | uti | protocol-number}
no ip protocol {l2tp | uti | protocol-number}
Syntax Description
l2tp
Configures L2TP as the IP protocol used to tunnel packets in a Layer 2
pseudowire. This is the default.
uti
Configures UTI as the IP protocol used to tunnel packets in a Layer 2
pseudowire, and allows a router running L2TP version 3 (L2TPv3) to
interoperate with a peer running UTI.
protocol-number
The protocol number of the desired IP protocol. The protocol number for
L2TPv3 is 115. The protocol number for UTI is 120.
Command Default
The default IP protocol is L2TP.
Command Modes
Pseudowire class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Note
Use the ip protocol command to ensure backward compatibility with routers running UTI. This
command allows you to configure an L2TPv3 pseudowire between a router running L2TPv3 and a peer
router running UTI.
You can use the ip protocol command only if you have already entered the encapsulation l2tpv3
command.
To configure L2TP as the IP protocol that is used to tunnel packets in an L2TPv3 pseudowire, you may
enter 115, the IP protocol number assigned to L2TPv3, instead of l2tp in the ip protocol command.
To configure UTI as the IP protocol that is used to tunnel packets in an L2TPv3 pseudowire, you may
enter 120, the IP protocol number assigned to UTI, instead of uti in the ip protocol command.
Note
Interoperability in an L2TPv3 control channel between a router running UTI and a router configured for
L2TPv3 encapsulation is supported only if you disable signaling using the protocol none command.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
146
Layer 2 Tunnel Protocol Version 3
ip protocol
Examples
The following example shows how to configure UTI as the IP protocol used to tunnel packets in an
L2TPv3 pseudowire created from the pseudowire class named “ether-pw”:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# encapsulation l2tpv3
Router(config-pw)# ip protocol uti
Related Commands
Command
Description
encapsulation (L2TP)
Configures the Layer 2 data encapsulation method used to tunnel IP traffic.
protocol (L2TP)
Specifies the signaling protocol to be used to manage the pseudowires
created from a pseudowire class for a Layer 2 session, and that control plane
configuration settings are to be taken from a specified L2TP class.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
147
Layer 2 Tunnel Protocol Version 3
ip tos (L2TP)
ip tos (L2TP)
To configure the Type of Service (ToS) byte in the header of Layer 2 tunneled packets, use the ip tos
command in pseudowire class configuration mode. To disable a configured ToS value or IP ToS
reflection, use the no form of this command.
ip tos {value value | reflect}
no tos {value value | reflect}
Syntax Description
value value
Sets the value of the ToS byte for IP packets in a Layer 2 Tunnel Protocol
version 3 (L2TPv3) session. Valid values range from 0 to 255. The default
value is 0.
reflect
Sets the value of the ToS byte for IP packets in an L2TPv3 session to be
reflected from the inner IP header.
Command Default
The default ToS value is 0.
Command Modes
Pseudowire class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The ip tos command allows you to manually configure the value of the ToS byte used in the headers of
Layer 2 tunneled packets or to have the ToS value reflected from the IP header of the encapsulated
packet.
Note
The reflect option is not supported on the Cisco 10720 and Cisco 12000 series Internet routers.
Note
IP ToS byte reflection functions only if traffic in an L2TPv3 session carries IP packets as its payload.
In addition, you can configure both IP ToS reflection and a ToS priority level (from 0 to 255) for a
pseudowire class. In this case, the ToS value in the tunnel header defaults to the value you specify with
the ip tos value value command. IP packets received on the Layer 2 interface and encapsulated into the
L2TPv3 session have their ToS byte reflected into the outer IP session, overriding the default value
configured with the ip tos value value command.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
148
Layer 2 Tunnel Protocol Version 3
ip tos (L2TP)
Examples
In the following example, the ToS byte in the headers of tunneled packets in Layer 2 tunnels created from
the pseudowire class named “ether-pw” will be reflected from the ToS value in the header of each
encapsulated IP packet:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# ip tos reflect
Related Commands
Command
Description
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
149
Layer 2 Tunnel Protocol Version 3
ip ttl
ip ttl
To configure the time-to-live (TTL) byte in the IP headers of Layer 2 tunneled packets, use the ip ttl
command in pseudowire class configuration mode. To remove the configured TTL value, use the no form
of this command.
ip ttl value
no ip ttl value
Syntax Description
value
Command Default
The default value of the TTL byte is 255.
Command Modes
Pseudowire class configuration
Command History
Release
Value of the TTL byte in the IP headers of L2TPv3 tunneled packets. The
valid values range from 1 to 255. The default value is 255.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use this command to set the Don’t Fragment (DF) bit on if, for performance reasons, you do not want
tunneled packet reassembly to be performed on the router.
Examples
The following example shows how to set the TTL byte to 100 in the IP header of Layer 2 tunneled
packets in pseudowires that were created from the pseudowire class named “ether-pw”:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# ip ttl 100
Related Commands
Command
Description
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
150
Layer 2 Tunnel Protocol Version 3
l2tp-class
l2tp-class
To create a template of Layer 2 Tunnel Protocol (L2TP) control plane configuration settings that can be
inherited by different pseudowire classes and to enter L2TP class configuration mode, use the l2tp-class
command in global configuration mode. To remove a specific L2TP class configuration, use the no form
of this command.
l2tp-class [l2tp-class-name]
no l2tp-class l2tp-class-name
Syntax Description
l2tp-class-name
Command Default
No L2TP classes are defined.
Command Modes
Global configuration
Command History
Release
Usage Guidelines
(Optional) Name of the L2TP class. The name argument must be specified
if you want to configure multiple sets of L2TP control parameters.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
The l2tp-class l2tp-class-name command allows you to configure an L2TP class template that consists
of configuration settings used by different pseudowire classes. An L2TP class includes the following
configuration settings:
•
Hostname of local router used during Layer 2 authentication
•
Authentication enabled
•
Time interval used for exchange of hello packets
•
Password used for control channel authentication
•
Packet size of receive window
•
Retransmission settings for control packets
•
Time allowed to set up a control channel
The l2tp-class command enters L2TP class configuration mode, where L2TP control plane parameters
are configured.
You must use the same L2TP class in the pseudowire configuration at both ends of a Layer 2 control
channel.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
151
Layer 2 Tunnel Protocol Version 3
l2tp-class
Examples
The following example shows how to enter L2TP class configuration mode to create an L2TP class
configuration template for the class named “ether-pw”:
Router(config)# l2tp-class ether-pw
Router(config-l2tp-class)#
Related Commands
Command
Description
protocol (L2TP)
Specifies the Layer 2 signaling protocol to be used to manage the
pseudowires created from a pseudowire class for a dynamic Layer 2 session,
and that control plane configuration settings are to be taken from the
specified L2TP class
pseudowire
Binds an attachment circuit to a Layer 2 pseudowire for xconnect service.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
152
Layer 2 Tunnel Protocol Version 3
l2tp cookie local
l2tp cookie local
To configure the size of the cookie field used in the Layer 2 Tunnel Protocol Version 3 (L2TPv3) headers
of incoming packets received from the remote provider edge (PE) peer router, use the l2tp cookie local
command in xconnect configuration mode. To remove the configured cookie field parameters, use the
no form of this command.
l2tp cookie local size low-value [high-value]
no l2tp cookie local size low-value [high-value]
Syntax Description
size
The size of the cookie field in L2TPv3 headers. The valid values are 0, 4,
and 8.
low-value
The value of the lower 4 bytes of the cookie field.
high-value
(Optional) The value of the upper 4 bytes of the cookie field. For 8-byte
cookie fields, you must enter the value for the upper 4 bytes of the cookie
field.
Command Default
No cookie value is included in the header of L2TP packets.
Command Modes
Xconnect configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The l2tp cookie local command specifies the values that the peer PE router includes in the cookie field
in L2TPv3 headers of the packets it sends to the local PE router through an L2TPv3 session. These values
are required in a static L2TPv3 session.
The cookie field is an optional part of an L2TPv3 header with a length of either 4 or 8 bytes. If you
specify an 8-byte length, you must also enter a value for the high-value argument.
Note
For the Cisco 10720 and Cisco 12000 series Internet routers, an 8-byte cookie must be configured with
this command.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
153
Layer 2 Tunnel Protocol Version 3
l2tp cookie local
Examples
The following example shows how to configure the cookie field of 4 bytes starting at 54321 for the
L2TPv3 headers in incoming tunneled packets that were sent from the remote PE peer:
Router(config)# interface Ethernet 0/0
Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
Router(config-if-xconn)# l2tp cookie local 4 54321
Related Commands
Command
Description
l2tp cookie remote
Configures the size of the cookie field used in the L2TPv3 headers of
outgoing (sent) packets from the remote PE peer router.
l2tp hello
Configures the interval between hello keepalive messages.
l2tp id
Configures the IDs used by the local and remote PE routers at each end of
an L2TPv3 session.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
154
Layer 2 Tunnel Protocol Version 3
l2tp cookie remote
l2tp cookie remote
To configure the size of the cookie field used in the Layer 2 Tunnel Protocol Version 3 (L2TPv3) headers
of outgoing packets sent from the local provider edge (PE) peer router, use the l2tp cookie remote
command in xconnect configuration mode. To remove the configured cookie field parameters, use the
no form of this command.
l2tp cookie remote size low-value [high-value]
no l2tp cookie remote size low-value [high-value]
Syntax Description
size
The size of the cookie field in L2TPv3 headers. The valid values are 0, 4,
and 8.
low-value
The value of the lower 4 bytes of the cookie field.
high-value
(Optional) The value of the upper 4 bytes of the cookie field. For 8-byte
cookie fields, you must enter the value for the upper 4 bytes of the cookie
field.
Command Default
No cookie value is included in the header of L2TP packets.
Command Modes
Xconnect configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The l2tp cookie remote command specifies the values that the local PE router includes in the cookie
field in L2TPv3 headers of the packets it sends to the remote PE router through an L2TPv3 session.
These values are required in a static L2TPv3 session.
The cookie field is an optional part of an L2TPv3 header with a length of either 4 or 8 bytes. If you
specify an 8-byte length, you must also enter a value for the high-value argument.
Examples
The following example shows how to configure the cookie field of 4 bytes starting at 12345 for the
L2TPv3 headers in outgoing tunneled packets sent to the remote PE peer:
Router(config)# interface Ethernet 0/0
Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
Router(config-if-xconn)# l2tp cookie remote 4 12345
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
155
Layer 2 Tunnel Protocol Version 3
l2tp cookie remote
Related Commands
Command
Description
l2tp cookie local
Configures the size of the cookie field used in the L2TPv3 headers of
incoming (received) packets from the remote PE peer router.
l2tp hello
Configures the interval between hello keepalive messages.
l2tp id
Configures the IDs used by the local and remote PE routers at each end of
an L2TPv3 session.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
156
Layer 2 Tunnel Protocol Version 3
l2tp hello
l2tp hello
To specify the use of a hello keepalive setting contained in a specified Layer 2 Tunneling Protocol class
configuration for a static Layer 2 Tunnel Protocol Version 3 (L2TPv3) session, use the l2tp hello
command in xconnect configuration mode. To disable the sending of hello keepalive messages, use the
no form of this command.
l2tp hello l2tp-class-name
no l2tp hello l2tp-class-name
Syntax Description
l2tp-class-name
Command Default
No hello keepalive messages are sent.
Command Modes
Xconnect configuration
Command History
Release
Specifies the L2TP class configuration in which the hello keepalive interval
to be used for the L2TPv3 session is stored.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Because a static L2TPv3 session does not use a control plane to dynamically negotiate control channel
parameters, you must use the l2tp hello command to specify an L2TP class configuration that contains
the interval for sending hello keepalive messages.
Examples
The following example shows how to configure the time interval for hello keepalive messages stored in
the L2TP class configuration named “l2tp-default” for an Ethernet interface using the configuration
settings stored in the pseudowire class named “ether-pw”:
Router(config)# interface Ethernet 0/0
Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
Router(config-if-xconn)# l2tp hello lt2p-defaults
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
157
Layer 2 Tunnel Protocol Version 3
l2tp hello
Related Commands
Command
Description
l2tp cookie local
Configures the size of the cookie field used in the L2TPv3 headers of
incoming (received) packets from the remote PE peer router.
l2tp cookie remote
Configures the size of the cookie field used in the L2TPv3 headers of
outgoing (transmitted) packets from the remote PE peer router.
l2tp id
Configures the IDs used by the local and remote PE routers at each end of
an L2TPv3 session.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
158
Layer 2 Tunnel Protocol Version 3
l2tp id
l2tp id
To configure the identifiers used by the local and remote provider edge (PE) routers at each end of a
Layer 2 Tunnel Protocol Version 3 (L2TPv3) session, use the l2tp id command in xconnect configuration
mode. To remove the configured identifiers for local and remote sessions, use the no form of this
command.
l2tp id local-session-ID remote-session-ID
no l2tp id local-session-ID remote-session-ID
Syntax Description
local-session-ID
The identifier used by the local PE router as its local session identifier.
remote-session-ID
The identifier used by the remote PE router as its local session identifier.
Command Default
No session identifiers are configured.
Command Modes
Xconnect configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The xconnect configuration that binds an attachment circuit to an L2TPv3 pseudowire is not complete
without configured values for the local-session-ID and remote-session-ID arguments.
Examples
The following example shows how to configure the identifiers named “222” for the local PE router and
“111” for the remote peer in an L2TPv3 session bound to an Ethernet circuit using the L2TPv3
configuration settings stored in the pseudowire class named” ether-pw”:
Router(config)# interface Ethernet 0/0
Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
Router(config-if-xconn)# l2tp id 222 111
Related Commands
Command
Description
l2tp cookie local
Configures the size of the cookie field used in the L2TPv3 headers of
incoming (received) packets from the remote PE peer router.
l2tp cookie remote
Configures the size of the cookie field used in the L2TPv3 headers of
outgoing (transmitted) packets from the remote PE peer router.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
159
Layer 2 Tunnel Protocol Version 3
l2tp id
Command
Description
l2tp hello
Configures the interval between hello keepalive messages.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
160
Layer 2 Tunnel Protocol Version 3
match fr-de
match fr-de
To match packets with the Frame Relay discard eligibility (DE) bit set, use the match fr-de command
in class-map configuration mode. To remove the match criteria, use the no form of this command.
match fr-de
no match fr-de
Syntax Description
This command has no arguments or keywords.
Command Default
Packets are not matched with the DE bit set.
Command Modes
Class-map configuration
Command History
Release
Modification
12.0(25)S
This command was introduced for the Cisco 7500 series router.
12.0(26)S
This command was implemented on the Cisco 7200 series router.
Examples
The following example creates a class called match-fr-de and matches packets with the Frame Relay DE
bit set.
Router(config)# class-map match-fr-de
Router(config-cmap)# match fr-de
Router(config)# exit
Related Commands
Command
Description
set fr-de
Changes the DE bit setting in the address field of a Frame Relay frame to 1
for all traffic leaving an interface.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
161
Layer 2 Tunnel Protocol Version 3
match protocol (L2TPv3)
match protocol (L2TPv3)
To configure protocol demultiplexing, use the match protocol command in xconnect configuration
mode. To disable protocol demultiplexing, use the no form of this command.
match protocol ipv6
no match protocol ipv6
Syntax Description
ipv6
Command Default
IPv6 protocol demultiplexing is disabled by default.
Command Modes
Xconnect configuration
Command History
Release
Modification
12.0(29)S
This command was introduced.
12.2(27)SBA
This command was integrated into Cisco IOS Release 12.2(27)SBA.
Usage Guidelines
Specifies IPv6 as the protocol to demultiplex.
Protocol demultiplexing is supported only for Ethernet and terminated data-link connection identifier
(DLCI) Frame Relay traffic in Cisco IOS Release 12.0(29)S, Cisco IOS Release 12.2(27)SBA, and later
releases.
Protocol demultiplexing requires supporting the combination of an IP address and an xconnect
command configuration on the IPv4 provider edge (PE) interface. This combination of configurations is
not allowed without enabling protocol demultiplexing, with the exception of switched Frame Relay
permanent virtual circuits (PVCs). If no IP address is configured, the protocol demultiplexing
configuration is rejected. If an IP address is configured, the xconnect command configuration is rejected
unless protocol demultiplexing is enabled in xconnect configuration mode before exiting that mode. If
an IP address is configured with an xconnect command configuration and protocol demultiplexing
enabled, the IP address cannot be removed. To change or remove the configured IP address, the xconnect
command configuration must first be disabled.
Table 16 shows the valid combinations of configurations.
Table 16
Support for the ATM Cell Relay Features
Scenario
IP Address
xconnect Configuration
Protocol Demultiplexing
Configuration
Routing
Yes
No
—
L2VPN
No
Yes
No
IPv6 Protocol
Demultiplexing
Yes
Yes
Yes
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
162
Layer 2 Tunnel Protocol Version 3
match protocol (L2TPv3)
Examples
The following example configures IPv6 protocol demultiplexing in an xconnect configuration:
xconnect 10.0.3.201 888 pw-class demux
match protocol ipv6
Related Commands
Command
Description
xconnect
Binds an attachment circuit to a Layer 2 pseudowire and enters xconnect
configuration mode
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
163
Layer 2 Tunnel Protocol Version 3
oam-ac emulation-enable
oam-ac emulation-enable
To enable Operation, Administration, and Maintenance (OAM) cell emulation on ATM adaptation
layer 5 (AAL5) over Multiprotocol Label Switching (MPLS) or Layer 2 Tunnel Protocol Version 3
(L2TPv3), use the oam-ac emulation-enable command in the appropriate configuration mode on both
provider edge (PE) routers. To disable OAM cell emulation, use the no form of this command on both
routers.
oam-ac emulation-enable [ais-rate]
no oam-ac emulation-enable [ais-rate]
Syntax Description
ais-rate
Command Default
By default OAM cell emulation is disabled.
Command Modes
L2transport VC configuration mode for an ATM PVC
VC class configuration mode for a VC class
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.2(14)S
This command was integrated into Cisco IOS Release 12.2(14)S.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.0(30)S
This command was updated to enable OAM cell emulation as part of a VC
class.
(Optional) The rate (in seconds) at which the alarm indication signal (AIS) cells
should be sent. The range is 0 to 60 seconds. If you specify 0, no AIS cells are sent.
The default AIS rate is 1 second.
Usage Guidelines
This command is applicable only to AAL5 over MPLS or L2TPv3 and is not supported with ATM Cell
Relay over MPLS or L2TPv3.
Examples
The following example shows how to enable OAM cell emulation on an ATM PVC:
Router# interface ATM 1/0/0
Router(config-if)# pvc 1/200 l2transport
Router(config-if-atm-l2trans-pvc)# oam-ac emulation-enable
The following example shows how to set the rate at which an AIS cell is sent to every 30 seconds:
Router# interface ATM 1/0/0
Router(config-if)# pvc 1/200 l2transport
Router(config-if-atm-l2trans-pvc)# oam-ac emulation-enable 30
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
164
Layer 2 Tunnel Protocol Version 3
oam-ac emulation-enable
The following example configures OAM cell emulation for ATM AAL5 over MPLS in VC class
configuration mode. The VC class is then applied to an interface.
Router> enable
Router# configure terminal
Router(config)# vc-class atm oamclass
Router(config-vc-class)# encapsulation aal5
Router(config-vc-class)# oam-ac emulation-enable 30
Router(config-vc-class)# oam-pvc manage
Router(config)# interface atm1/0
Router(config-if)# class-int oamclass
Router(config-if)# pvc 1/200 l2transport
Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation mpls
Related Commands
Command
Description
show atm pvc
Displays all ATM PVCs and traffic information.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
165
Layer 2 Tunnel Protocol Version 3
password (L2TP)
password (L2TP)
To configure the password used by a provider edge (PE) router for Layer 2 authentication, use the
password command in L2TP class configuration mode. To disable a configured password, use the no
form of this command.
password [encryption-type] password
no password [encryption-type] password
Syntax Description
encryption-type
(Optional) Specifies the type of encryption to use. The valid values are from
0 to 7. Currently defined encryption types are 0 (no encryption) and 7 (text
is encrypted using an algorithm defined by Cisco). The default encryption
type is 0.
password
Specifies the password used for L2TPv3 authentication.
Command Default
If a password is not configured for the L2TP class with the password command, the password
configured with the username command in global configuration mode is used.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The password that you define with the password command is also used for attribute-value pair (AVP)
hiding.
The password hierarchy sequence used for a local and remote peer PE for L2TPv3 authentication is as
follows:
Examples
•
The L2TPv3 password (configured with the password command) is used first.
•
If no L2TPv3 password exists, the globally configured password (configured with the username
password command) for the router is used.
The following example sets the password named “tunnel2” to be used to authenticate an L2TPv3 session
between the local and remote peers in L2TPv3 pseudowires that has been configured with the L2TP class
configuration named “l2tp-class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# authentication
Router(config-l2tp-class)# password tunnel2
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
166
Layer 2 Tunnel Protocol Version 3
password (L2TP)
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
username
Establishes a username-based authentication system.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
167
Layer 2 Tunnel Protocol Version 3
protocol (L2TP)
protocol (L2TP)
To specify the signaling protocol to be used to manage the pseudowires created from a pseudowire class
for a Layer 2 session and to cause control plane configuration settings to be taken from a specified L2TP
class, use the protocol command in pseudowire class configuration mode. To remove the signaling
protocol (and the control plane configuration to be used) from a pseudowire class, use the no form of
this command.
protocol {l2tpv2 | l2tpv3 | none} [l2tp-class-name]
no protocol {l2tpv2 | l2tpv3 | none} [l2tp-class-name]
Syntax Description
l2tpv2
Specifies that the Layer 2 Tunnel Protocol (L2TP) signaling protocol will
be used.
l2tpv3
Specifies that the L2TPv3 signaling protocol will be used. This is the
default.
none
Specifies that no signaling protocol will be used in L2TPv3 sessions.
l2tp-class-name
(Optional) The name of the L2TP class whose control plane configuration
is to be used for pseudowires set up from a specified pseudowire class. If
you do not enter a value for the l2tp-class-name argument, the default
control plane configuration settings in the L2TP signaling protocol are
used.
Command Default
The default protocol is l2tpv3.
Command Modes
Pseudowire class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use the protocol (L2TP) command to configure the signaling protocol to use in sessions created from
the specified pseudowire class. In addition, you can use this command to specify the L2TP class from
which the control plane configuration settings are to be taken.
Use the protocol none command to specify that no signaling will be used in L2TPv3 sessions created
from the specified pseudowire class. This configuration is required for interoperability with a remote
peer running the Universal Tunnel Interface (UTI).
Do not use this command if you want to configure a pseudowire class that will be used to create manual
L2TPv3 sessions.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
168
Layer 2 Tunnel Protocol Version 3
protocol (L2TP)
Examples
The following example shows how to enter pseudowire class configuration mode and how to configure
L2TPv3 as the signaling protocol. The control plane configuration used in the L2TP class named
“class1” will be used to create dynamic L2TPv3 sessions for a VLAN xconnect interface.
Router(config)# pseudowire-class vlan-xconnect
Router(config-pw)# protocol l2tpv3 class1
Related Commands
Command
Description
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
169
Layer 2 Tunnel Protocol Version 3
pseudowire-class
pseudowire-class
To specify the name of a Layer 2 pseudowire class and enter pseudowire class configuration mode, use
the pseudowire-class command in global configuration mode. To remove a pseudowire class
configuration, use the no form of this command.
pseudowire-class [pw-class-name]
no pseudowire-class [pw-class-name]
Syntax Description
pw-class-name
Command Default
No pseudowire classes are defined.
Command Modes
Global configuration
Command History
Release
Usage Guidelines
(Optional) The name of a Layer 2 pseudowire class. If you want to configure
more than one pseudowire class, you must enter a value for the
pw-class-name argument.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
The pseudowire-class command allows you to configure a pseudowire class template that consists of
configuration settings used by all attachment circuits bound to the class. A pseudowire class includes the
following configuration settings:
•
Data encapsulation type
•
Control protocol
•
Sequencing
•
IP address of the local Layer 2 interface
•
Type of service (ToS) value in IP headers
After you enter the pseudowire-class command, the router switches to pseudowire class configuration
mode, where pseudowire settings may be configured.
Examples
The following example shows how to enter pseudowire class configuration mode to configure a
pseudowire configuration template named “ether-pw”:
Router(config)# pseudowire-class ether-pw
Router(config-pw)#
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
170
Layer 2 Tunnel Protocol Version 3
pseudowire-class
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
pseudowire
Binds an attachment circuit to a Layer 2 pseudowire for xconnect service.
xconnect
Binds an attachment circuit to an L2TPv3 pseudowire for xconnect service
and enters xconnect configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
171
Layer 2 Tunnel Protocol Version 3
receive-window
receive-window
To configure the packet size of the receive window on the remote provider edge router at the other end
of a Layer 2 control channel, use the receive-window command in L2TP class configuration mode. To
disable the configured value, use the no form of this command.
receive-window number
no receive-window number
Syntax Description
number
Command Default
The default packet size of the receive window is the upper limit that the remote peer has for receiving
packets.
Command Modes
L2TP class configuration
Command History
Release
The number of packets that can be received by the remote peer before
backoff queueing occurs. The valid values range from 1 to the upper limit
the peer has for receiving packets. The default value is the upper limit that
the remote peer has for receiving packets.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
To determine the upper limit for the number argument, refer to the platform-specific documentation for
the peer router.
Examples
The following example sets a receive window of 30 packets to the remote peer in Layer 2 pseudowires
that have been configured with the L2TP class named” l2tp-class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# receive-window 30
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
172
Layer 2 Tunnel Protocol Version 3
retransmit
retransmit
To configure the retransmission settings of control packets, use the retransmit command in L2TP class
configuration mode. To disable the configured values, use the no form of this command.
retransmit {initial retries initial-retries | retries retries | timeout {max | min} seconds}
no retransmit {initial retries initial-retries | retries retries | timeout {max | min} seconds}
Syntax Description
initial retries
initial-retries
Specifies how many start control channel requests (SCCRQs) are re-sent
before giving up on the session. Valid values for the initial-retries argument
range from 1 to 1000. The default value is 2
retries retries
Specifies how many retransmission cycles occur before determining that the
peer provider edge (PE) router does not respond. Valid values for the retries
argument range from 1 to 1000. The default value is 15.
timeout {max | min}
seconds
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.
Command Default
The default values of the retransmission settings are used.
Command Modes
L2TP class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use this command to configure the amount of time spent trying to establish or maintain a control
channel.
Examples
The following example configures ten retries for sending tunneled packets to a remote peer in Layer 2
pseudowires that have been configured with the Layer 2 Tunnel Protocol (L2TP) class named
“l2tp-class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# retransmit retries 10
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
173
Layer 2 Tunnel Protocol Version 3
retransmit
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
174
Layer 2 Tunnel Protocol Version 3
sequencing
sequencing
To configure the direction in which sequencing is enabled for data packets in a Layer 2 pseudowire, use
the sequencing command in pseudowire class configuration mode. To remove the sequencing
configuration from the pseudowire class, use the no form of this command.
sequencing {transmit | receive | both | resync {number}}
no sequencing {transmit | receive | both | resync {number}}
Syntax Description
transmit
Updates the Sequence Number field in the headers of data packets sent over
the pseudowire according to the data encapsulation method that is used.
receive
Keeps the value in the Sequence Number field in the headers of data packets
received over the pseudowire. Out-of-order packets are dropped.
both
Enables both the transmit and receive options.
resync
Enables the reset of packet sequencing after the disposition router receives
a specified number of out-of-order packets.
number
The number of out-of-order packets that cause a reset of packet sequencing.
The range is 5 to 65535.
Command Default
Sequencing is disabled.
Command Modes
Pseudowire class configuration
Command History
Release
Modification
12.0(23)S
This command was introduced for Layer 2 Tunnel Protocol Version 3
(L2TPv3).
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.0(29)S
This command was updated to support Any Transport over MPLS (AToM).
12.0(30)S
The resync keyword was added.
Usage Guidelines
•
When you enable sequencing using any of the available options, the sending of sequence numbers
is automatically enabled and the remote provider edge (PE) peer is requested to send sequence
numbers. Out-of-order packets received on the pseudowire are dropped only if you use the
sequencing receive or sequencing both command.
•
If sequencing is enabled for Layer 2 pseudowires on the Cisco 7500 series, all traffic on the
pseudowires is switched through the Route Switch Processor (RSP) regardless of the setting
configured with the ip cef distributed command.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
175
Layer 2 Tunnel Protocol Version 3
sequencing
Examples
•
It is useful to specify the resync keyword for situations when the disposition router receives many
out-of-order packets. It allows the router to recover from situations where too many out-of-order
packets are dropped.
•
Set the sequence number to 0 in the slow path before packets are punted to the local CPU, because
packets may become out of order.
The following example shows how to enable sequencing in data packets in Layer 2 pseudowires that
were created from the pseudowire class named “ether-pw” so that the Sequence Number field is updated
in tunneled packet headers for data packets that are both sent and received over the pseudowire:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# encapsulation mpls
Router(config-pw)# sequencing both
The following example shows how to enable the disposition router to reset packet sequencing after it
receives 1000 out-of-order packets:
Router(config)# pseudowire-class ether-pw
Router(config-pw)# encapsulation mpls
Router(config-pw)# sequencing both
Router(config-pw)# sequencing resync 1000
Related Commands
Command
Description
ip cef
Enables CEF on the Route Processor card.
pseudowire-class
Specifies the name of an L2TP pseudowire class and enters pseudowire
class configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
176
Layer 2 Tunnel Protocol Version 3
show atm cell-packing
show atm cell-packing
To display information about the virtual circuits (VCs) and virtual paths (VPs) that have ATM cell relay
cell packing enabled, use the show atm cell-packing command in privileged EXEC mode.
show atm cell-packing
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(25)S
This command was introduced.
Usage Guidelines
Examples
The number of packed cells need not match between the provider edge (PE) routers. The two PE routers
agree on the lower of the two values. For example, if PE1 is allowed to pack 10 cells per Multiprotocol
Label Switching (MPLS) packet and PE2 is allowed to pack 20 cells per MPLS packet, the two PE
routers would agree to send no more than 10 cells per packet.
The following show atm cell-packing command displays VCs and VPs that have cell packing enabled:
Router# show atm cell-packing
average
average
circuit local nbr of cells
peer
nbr of cells
MCPT
type
MNCP
rcvd in one pkt MNCP
sent in one pkt (us)
==============================================================================
atm 1/0 vc 1/200 20
15
30
20
60
Table 17 describes the significant fields shown in the display.
Table 17
show atm cell-packing Field Descriptions
Field
Description
circuit type
Interface and VC or VP designators.
local MNCP
Maximum number of cells packed (MNCP) on the local PE
router.
average nbr of cells rcvd in one pkt
Average number of cells that the PE router receives.
peer MNCP
MNCP of the peer PE router.
average nbr of cells sent in one pkt
Average number of cells that the PE router sends.
MCPT (us)
Maximum cell packing timeout (MCPT). This is the
number of microseconds that the PE router allows for cell
packing. If the specified number of cells does not get
packed within the allowed time, the packet is sent anyway.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
177
Layer 2 Tunnel Protocol Version 3
show atm cell-packing
Related Commands
Command
Description
atm mcpt-timers
Creates cell-packing timers, which specify how long the PE router can wait
for cells to be packed into an MPLS or L2TPv3 packet.
cell-packing
Enables ATM cell relay to pack multiple ATM cells into each MPLS or
L2TPv3 packet.
show atm cell-packing Displays information about the VCs and VPs that have ATM cell relay over
MPLS or L2TPv3 cell packing enabled.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
178
Layer 2 Tunnel Protocol Version 3
show l2tun
show l2tun
To display general information about Layer 2 tunnels and sessions, use the show l2tun command in
privileged EXEC mode.
show l2tun
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The show l2tun command displays general information about all active Layer 2 tunnels and sessions.
Use the show l2tun tunnel command or the show l2tun session command to display more detailed
information about Layer 2 tunnels or sessions.
Examples
The following example shows the display of information about all currently active Layer 2 tunnels and
sessions:
Router# show l2tun
L2TP Tunnel and Session Information Total tunnels 1 sessions 1
LocID RemID Remote Name
State
Remote Address
45795 43092 PE1
est
10.1.1.1
LocID
RemID
TunID
42410
0
45795
Port
0
Username, Intf/
Vcid, Circuit
123456789, Fa4/1/1
Sessions L2TP Class/
VPDN Group
1
generic
State
Last Chg Uniq ID
idle
00:00:24 1
Table 21 describes the significant fields shown in the display.
Table 18
show l2tun Field Descriptions
Field
Description
Total tunnels
Total number of tunnels established on the router.
sessions
Total number of sessions established on the router.
LocID
Local ID of the tunnel.
RemID
Remote ID of the tunnel.
Remote Name
Hostname of the remote tunnel endpoint.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
179
Layer 2 Tunnel Protocol Version 3
show l2tun
Table 18
Related Commands
show l2tun Field Descriptions (continued)
Field
Description
State
State of the tunnel.
Remote Address
IP address of the remote tunnel endpoint.
Port
Port number used by the remote tunnel endpoint.
Sessions
Number of sessions established in the tunnel.
L2TP class
Name of the L2TP class the tunnel parameters are derived from.
VPDN group
Name of the virtual private dialup network (VPDN) group the tunnel belongs
to.
LocID
Local ID of the session.
RemID
Remote ID of the session.
TunID
Tunnel ID of the tunnel the session is in.
Username, Intf/Vcid,
Circuit
The sessions username, interface, virtual circuit identifier (VCID), and
circuit.
Last Chg
Time since the last change in the tunnel state, in hh:mm:ss.
Uniq ID
The tunnel session ID.
Command
Description
clear l2tun tunnel
counters
Clears L2TP control channel authentication counters.
show l2tun session
Displays the current state of Layer 2 sessions and displays protocol
information about L2TP control channels.
show l2tun tunnel
Displays the current state of a Layer 2 tunnel and displays information
about currently configured tunnels.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
180
Layer 2 Tunnel Protocol Version 3
show l2tun session
show l2tun session
To display the current state of Layer 2 sessions and protocol information about Layer 2 Tunnel Protocol
(L2TP) control channels, use the show l2tun session command in privileged EXEC mode.
show l2tun session [all [ip-addr ip-address [vcid number] | username name | vcid number] | brief
[ip-addr ip-address [vcid number] | username name | vcid number] [hostname] | circuit
[ip-addr ip-address [vcid number] | username name | vcid number] [hostname] |
interworking [ip-addr ip-address [vcid number] | username name | vcid number] [hostname]
| packets [ip-addr ip-address [vcid number] | username name | vcid number] | sequence
[ip-addr ip-address [vcid number] | username name | vcid number] | state [ip-addr ip-address
[vcid number] | username name | vcid number]]
Syntax Description
all
(Optional) Displays information about all current L2TP sessions on the
router.
ip-addr ip-address
(Optional) Displays information about L2TP sessions associated with the IP
address of the interface of the peer router.
vcid number
(Optional) Displays information about L2TP sessions associated with the
32-bit virtual circuit identifier (VCID) shared between the peer router and
the local router at each end of the control channel.
username name
(Optional) Displays information about the session that is associated with
this username.
brief
(Optional) Displays information about all current L2TP sessions, including
peer ID address and circuit status of the L2TP sessions.
hostname
(Optional) Specifies that the peer hostname will be displayed in the output.
circuit
(Optional) Displays information about all current L2TP sessions, including
circuit status (up or down).
interworking
(Optional) Displays information about Layer 2 Virtual Private Network
(L2VPN) interworking.
packets
(Optional) Displays information about the packet counters (in and out)
associated with current L2TP sessions.
sequence
(Optional) Displays sequencing information about each L2TP session,
including number of out-of-order and returned packets.
state
(Optional) Displays information about all current L2TP sessions and their
protocol state, including remote VCIDs.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(27)SBA
Support was added for the hostname keyword.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
181
Layer 2 Tunnel Protocol Version 3
show l2tun session
Usage Guidelines
Examples
When you use the show l2tun session command to display information about current L2TP sessions on
the router, you can filter the output as follows:
•
To filter the output to include only L2TP sessions set up for a specific IP address, enter ip-addr
ip-address in the command.
•
To filter the output to include only the L2TP session that matches the specified remote IP address
and VCID, enter ip-addr ip-address vcid number in the command.
•
To filter the output to include only L2TP sessions set up for a specific VCID, enter vcid number in
the command.
The following example shows how to display detailed information about all current L2TP sessions:
Router# show l2tun session all
Session Information Total tunnels 0 sessions 1
Session id 42438 is down, tunnel id 45795
Remote session id is 0, remote tunnel id 43092
Session Layer 2 circuit, type is Ethernet, name is FastEthernet4/1/1
Session vcid is 123456789
Circuit state is DOWN
Local circuit state is DOWN
Remote circuit state is DOWN
Call serial number is 1463700128
Remote tunnel name is PE1
Internet address is 10.1.1.1
Local tunnel name is PE1
Internet address is 10.1.1.2
IP protocol 115
Session is L2TP signalled
Session state is idle, time since change 00:00:26
0 Packets sent, 0 received
0 Bytes sent, 0 received
Last clearing of "show vpdn" counters never
Receive packets dropped:
out-of-order:
0
total:
0
Send packets dropped:
exceeded session MTU:
0
total:
0
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
No session cookie information available
UDP checksums are disabled
L2-L2 switching enabled
No FS cached header information available
Sequencing is off
Unique ID is 1
The following example shows how to display information only about the L2TP session set up on a peer
router with an IP address of 172.18.184.142 and a VCID of 300:
Router# show l2tun session all ip-addr 172.18.184.142 vcid 300
L2TP Session
Session id 32518 is up, tunnel id 35217
Call serial number is 2074900020
Remote tunnel name is tun1
Internet address is 172.18.184.142
Session is L2TP signalled
Session state is established, time since change 03:06:39
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
182
Layer 2 Tunnel Protocol Version 3
show l2tun session
9932 Packets sent, 9932 received
1171954 Bytes sent, 1171918 received
Session vcid is 300
Session Layer 2 circuit, type is Ethernet Vlan, name is FastEthernet0/1/0.3:3
Circuit state is UP
Remote session id is 18819, remote tunnel id 37340
Set DF bit to 0
Session cookie information:
local cookie, size 4 bytes, value CF DC 5B F3
remote cookie, size 4 bytes, value FE 33 56 C4
SSS switching enabled
Sequencing is on
Ns 9932, Nr 10001, 0 out of order packets discarded
Table 19 describes the significant fields shown in the displays.
Table 19
show l2tun session Field Descriptions
Field
Description
Total tunnels
Total number of L2TP tunnels currently established on the router.
sessions
Number of L2TP sessions currently established on the router.
Session id
Session ID for established sessions.
is
Session state.
tunnel id
Tunnel ID for established tunnels.
Remote session id
Session ID for the remote session.
Remote tunnel id
Tunnel ID for the remote tunnel.
Session Layer 2
Type and name of the interface used for the Layer 2 circuit.
circuit type is, name is
Session vcid is
VCID of the session.
Circuit state is
State of the Layer 2 circuit.
Local circuit state is
State of the local circuit.
Remote circuit state is State of the remote circuit.
Call serial number is
Call serial number.
Remote tunnel name
is
Name of the remote tunnel.
Internet address is
IP address of the remote tunnel.
Local tunnel name is
Name of the local tunnel.
Internet address is
IP address of the local tunnel.
IP protocol
The IP protocol used.
Session is
Signaling type for the session.
Session state is
Session state for the session.
time since change
Time since the session state last changed, in the format hh:mm:ss.
Packets sent, received Number of packets sent and received since the session was established.
Bytes sent, received
Number of bytes sent and received since the session was established.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
183
Layer 2 Tunnel Protocol Version 3
show l2tun session
Table 19
show l2tun session Field Descriptions (continued)
Field
Description
Last clearing of “show Time elapsed since the last clearing of the counters displayed with the show
vpdn” counters
vpdn command. Time will be displayed in one of the following formats:
Receive packets
dropped:
•
hh:mm:ss—Hours, minutes and seconds.
•
dd:hh—Days and hours.
•
WwDd—Weeks and days, where W is the number of weeks and D is the
number of days.
•
YyWw—Years and weeks, where Y is the number of years and W is the
number of weeks.
•
never—The timer has not been started.
Number of received packets that were dropped since the session was
established.
•
out-of-order—Number of received packets that were dropped because
they were out of order.
•
total—Total number of received packets that were dropped.
Send packets dropped: Number of sent packets that were dropped since the session was established.
•
exceeded session MTU—Number of sent packets that were dropped
because the session maximum transmission unit (MTU) was exceeded.
•
total—Total number of sent packets that were dropped.
DF bit
Status of the Don’t Fragment (DF) bit option. The DF bit can be on or off.
ToS reflect
Status of the type of service (ToS) reflect option. ToS reflection can be
enabled or disabled.
ToS value
Value of the ToS byte in the L2TP header.
TTL value
Value of the time-to-live (TTL) byte in the L2TP header.
local cookie
Size (in bytes) and value of the local cookie.
remote cookie
Size (in bytes) and value of the remote cookie.
UDP checksums are
Status of User Datagram Protocol (UDP) checksum configuration.
switching
Status of switching.
No FS cached header
information available
Fast Switching (FS) cached header information. If an FS header is configured,
the encapsulation size and hexadecimal contents of the FS header will be
displayed. The FS header is valid only for IP virtual private dialup network
(VPDN) traffic from a tunnel server to a network access server (NAS).
Sequencing is
Status of sequencing. Sequencing can be on or off.
Ns
Sequence number for sending.
Nr
Sequence number for receiving.
Unique ID is
Global user ID correlator.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
184
Layer 2 Tunnel Protocol Version 3
show l2tun session
The following example shows how to display information about the circuit status of L2TP sessions on a
router:
Router# show l2tun session circuit
Session Information Total tunnels 3 sessions 3
LocID
TunID
Peer-address
32517
32519
32518
26515
30866
35217
172.18.184.142
172.18.184.142
172.18.184.142
Type Stat Username, Intf/
Vcid, Circuit
VLAN UP
100, Fa0/1/0.1:1
VLAN UP
200, Fa0/1/0.2:2
VLAN UP
300, Fa0/1/0.3:3
The following example shows how to display information about the circuit status of L2TP sessions and
the hostnames of remote peers:
Router# show l2tun session circuit hostname
Session Information Total tunnels 3 sessions 3
LocID
TunID
32517
32519
32518
26515
30866
35217
Peer-hostname Type Stat Username, Intf/
Vcid, Circuit
<unknown>
VLAN UP
100, Fa0/1/0.1:1
router32
VLAN UP
200, Fa0/1/0.2:2
access3
VLAN UP
300, Fa0/1/0.3:3
Table 20 describes the significant fields shown in the displays.
Table 20
Related Commands
show l2tun session circuit Field Descriptions
Field
Description
LocID
Local session ID.
TunID
Tunnel ID.
Peer-address
IP address of the peer.
Peer-hostname
Hostname of the peer.
Type
Session type.
Stat
Session status.
Username, Intf/Vcid,
Circuit
Username, interface name/VCID, and circuit number of the session.
Command
Description
show l2tun
Displays general information about Layer 2 tunnels and sessions.
show l2tun tunnel
Displays the current state of Layer 2 tunnels and information about
configured tunnels.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
185
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
show l2tun tunnel
To display the current state of Layer 2 tunnels and information about configured tunnels, including local
and remote Layer 2 Tunneling Protocol (L2TP) hostnames, aggregate packet counts, and control channel
information, use the show l2tun tunnel command in privileged EXEC mode.
show l2tun tunnel [all [id identifier | local-name local-name remote-name | remote-name
remote-name local-name] | packets [id identifier | local-name local-name remote-name |
remote-name remote-name local-name] | state [id identifier | local-name local-name
remote-name | remote-name remote-name local-name] | summary [id identifier | local-name
local-name remote-name | remote-name remote-name local-name] | transport [id identifier |
local-name local-name remote-name | remote-name remote-name local-name] |
authentication]
Syntax Description
all
(Optional) Displays information about all current L2TP sessions configured
on the router.
id identifier
(Optional) Displays information about L2TP sessions with the specified
local tunnel ID number.
local-name local-name (Optional) Displays information about L2TP sessions with the specified
remote-name
local and remote names.
remote-name
remote-name
local-name
(Optional) Displays information about L2TP sessions with the specified
remote and local names.
packets
(Optional) Displays aggregate packet counts for all negotiated L2TP
sessions.
state
(Optional) Displays information about the current state of L2TP sessions,
including the local and remote hostnames for each control channel.
summary
(Optional) Displays a summary of L2TP sessions on the router and their
current state, including the number of virtual private dialup network
(VPDN) sessions associated with each control channel.
transport
(Optional) Displays information about the L2TP control channels used in
each session and the local and remote IP addresses at each end of the control
channel.
authentication
(Optional) Displays global information about L2TP control channel
authentication attribute-value pairs (AV pairs).
Command Modes
Privileged EXEC
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
186
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
Usage Guidelines
Examples
Release
Modification
12.0(30)S
This command was enhanced to display information about pseudowire
control channel authentication passwords.
12.2(27)SBA
Support for the authentication keyword was added and the output of the
show l2tun tunnel all command was enhanced to display per-tunnel
authentication failure counters.
When you use the show l2tun tunnel command to display information about configured L2TP sessions
on the router, you can filter the output as follows:
•
To filter the output to include only L2TP sessions set up using the local tunnel ID, enter id identifier
in the command.
•
To filter the output to include only the L2TP session that matches the specified local IP name and
remote name, enter either local-name local-name remote-name or remote-name remote-name
local-name in the command.
The following example shows how to display detailed information about all L2TP tunnels:
Router# show l2tun tunnel all
Tunnel Information Total tunnels 1 sessions 1
Tunnel id 26515 is up, remote id is 41814, 1 active sessions
Tunnel state is established, time since change 03:11:50
Tunnel transport is IP (115)
Remote tunnel name is tun1
Internet Address 172.18.184.142, port 0
Local tunnel name is Router
Internet Address 172.18.184.116, port 0
Tunnel domain is
VPDN group for tunnel is
L2TP class for tunnel is
0 packets sent, 0 received
0 bytes sent, 0 received
Control Ns 11507, Nr 11506
Local RWS 2048 (default), Remote RWS 800
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 1, max 1
Total resends 0, ZLB ACKs sent 11505
Total peer authentication failures 8
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
The following example shows the display of pseudowire control channel password information:
Router# show l2tun tunnel all
!
Control message authentication is on, 2 secrets configured
Last message authenticated with first digest secret
!
Table 21 describes the significant fields shown in the displays.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
187
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
Table 21
show l2tun tunnel all Field Descriptions
Field
Description
Total tunnels
Total number of L2TP tunnels currently established on the router.
sessions
Number of L2TP sessions currently established on the router.
Tunnel id is up
Tunnel ID and tunnel status.
remote id is
Remote ID.
active sessions
Number of active sessions.
Tunnel state is
State of the tunnel.
time since change
Time since the tunnel state last changed, in the format hh:mm:ss.
Tunnel transport is
Tunnel transport protocol.
Remote tunnel name
is
Name of the remote tunnel endpoint.
Internet Address
IP address of the remote tunnel endpoint.
port
Port number used by the remote tunnel endpoint.
Local tunnel name is
Name of the local tunnel endpoint.
Internet Address
IP address of the local tunnel endpoint.
port
Port number used by the local tunnel endpoint.
Tunnel domain is
Domain information for the tunnel.
VPDN group for
tunnel is
Name of the VPDN group associated with the tunnel.
L2TP class for tunnel
is
Name of the L2TP class associated with the tunnel.
packets sent, received Number of packets sent and received since the tunnel was established.
bytes sent, received
Number of bytes sent and received since the tunnel was established.
Control Ns, Nr
Sequence number for control packets sent and received.
Local RWS
Local receiving window size, in packets.
Remote RWS
Remote receiving window size, in packets.
Tunnel PMTU
checking
Status of the tunnel path maximum transmission unit (MTU) checking option.
It may be enabled or disabled.
Retransmission time,
max
Current time, in seconds, required to resend a packet and maximum time, in
seconds, that was required to resend a packet since tunnel establishment.
Unsent queuesize,
max
Current size of the unsent queue and maximum size of the unsent queue since
tunnel establishment.
Resend queuesize,
max
Current size of the resend queue and maximum size of the resend queue since
tunnel establishment.
Total resends
Total number of packets re-sent since tunnel establishment.
Total peer
The total number of times peer authentication has failed.
authentication failures
ZLB ACKs sent
Number of zero length body acknowledgment messages sent.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
188
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
Table 21
show l2tun tunnel all Field Descriptions (continued)
Field
Description
Current nosession
queue check
Number of tunnel timeout periods since the last session ended. Up to five
tunnel timeouts are used if there are outstanding control packets on the unsent
or resend queue. Otherwise, the tunnel is dropped after one tunnel timeout.
Retransmit time
distribution
Histogram showing the number of retransmissions at 0, 1, 2,..., 8 seconds,
respectively.
Sessions disconnected Number of sessions disconnected because of a lack of available resources.
due to lack of
resources
Control message
authentication is
Specifies whether pseudowire control message authentication is on or off for
the tunnel.
secrets configured
The number of pseudowire control channel authentication passwords that are
configured for the tunnel. One or two passwords may be configured.
Last message
authenticated with
The password that was used to authenticate the last pseudowire control
channel message. The control channel message may be authenticated with the
first digest secret or with the second digest secret.
The following example shows how to filter information to display L2TP control channel details only for
the sessions configured with the local name Router and the remote name tun1:
Router# show l2tun tunnel transport local-name Router tun1
Tunnel Information Total tunnels 3 sessions 3
LocID
26515
30866
35217
Type
IP
IP
IP
Prot
115
115
115
Local Address
172.18.184.116
172.18.184.116
172.18.184.116
Port
0
0
0
Remote Address
172.18.184.142
172.18.184.142
172.18.184.142
Port
0
0
0
Table 22 describes the significant fields shown in the display.
Table 22
show l2tun tunnel transport Field Descriptions
Field
Description
Total tunnels
Total number of tunnels currently established.
sessions
Number of sessions currently established.
LocID
Local session ID.
Type
Session type.
Prot
Protocol type used by the tunnel.
Local Address
IP address of the local tunnel endpoint.
Port
Port used by the local tunnel endpoint.
Remote Address
IP address of the remote tunnel endpoint.
Port
Port used by the remote tunnel endpoint.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
189
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
The following example shows how to display information about the current state of L2TP sessions with
the local and remote hostnames of each session:
Router# show l2tun tunnel state
LocID
26515
30866
35217
RemID
41814
6809
37340
Local Name
Router
Router
Router
Remote Name State Last-Chg
tun1
est
03:13:15
tun1
est
03:13:15
tun1
est
03:13:15
Table 23 describes the significant fields shown in the display.
Table 23
show l2tun tunnel state Field Descriptions
Field
Description
LocID
Local session ID.
RemID
Remote session ID.
Local Name
Name of the local tunnel endpoint.
Remote Name
Name of the remote tunnel endpoint.
State
Current state of the tunnel.
Last-Chg
Time since the state of the tunnel last changed, in the format hh:mm:ss.
The following example shows the display of all possible L2TP control channel authentication AV pair
statistics. AV pair statistic fields are displayed only if they are nonzero. For the purposes of this example,
all possible output fields are displayed in the sample output.
Router# show l2tun tunnel authentication
L2TPv3 Tunnel Authentication Statistics:
Nonce AVP Statistics:
Ignored
Missing
All Digests Statistics:
Unexpected
Unexpected ZLB
Primary Digest AVP Statistics:
Validate fail
Hash invalid
Length invalid
Missing
Ignored
Passed
Failed
Secondary Digest AVP Statistics:
Validate fail
Hash invalid
Length invalid
Missing
Ignored
Passed
Failed
Integrity Check Statistics:
Validate fail
Length invalid
Passed
Failed
Local Secret Statistics:
Missing
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
190
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
Challenge AVP Statistics:
Generate response fail
Ignored
Challenge/Response AVP Statistics:
Generate response fail
Missing
Ignored
Passed
Failed
Overall Statistics:
Passed
Skipped
Ignored
Failed
0
0
0
0
0
0
0
0
0
0
0
Table 24 describes the significant fields shown in the display.
Table 24
show l2tun tunnel authentication Field Descriptions
Field
Description
Nonce AVP Statistics
Counters for the nonce AV pair.
Ignored
Number of AV pair messages that were ignored.
Missing
Number of AV pair messages that were missing.
All Digests Statistics
Statistics for all configured digest passwords.
Unexpected
Digest information was received but the router is not configured for it.
Unexpected ZLB
A Zero Length Body (ZLB) message was received while control message
authentication is enabled. ZLB messages are permitted only when control
message authentication is disabled.
Primary Digest AVP
Statistics
Statistics for AV pair messages exchanged using the primary L2TP Version 3
(L2TPv3) control message digest password.
Validate fail
Number of AV pair messages that failed to validate.
Hash invalid
Number of AV pair messages with an invalid hash.
Length invalid
Number of AV pair messages with an invalid length.
Passed
Number of AV pair messages successfully exchanged.
Failed
Number of AV pair messages that have failed to authenticate.
Secondary Digest
AVP Statistics
Statistics for AV pair messages exchanged using the secondary L2TPv3
control message digest password.
Integrity Check
Statistics
Statistics for AV pair messages exchanged when integrity checking is
enabled.
Local Secret Statistics Statistics for AV pair messages related to the local secret.
Challenge AVP
Statistics
Statistics for AV pair messages related to Challenge Handshake
Authentication Protocol (CHAP) style authentication challenges.
Generate response fail Number of AV pair messages that did not generate a response.
Challenge/Response
AVP Statistics
Statistics for AV pair messages exchanged when CHAP-style authentication
is configured.
Overall Statistics
Summary of the statistics for all authentication AV pair messages.
Skipped
The number of AV pair messages that authentication was not performed on.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
191
Layer 2 Tunnel Protocol Version 3
show l2tun tunnel
Related Commands
Command
Description
clear l2tun tunnel
counters
Clears L2TP control channel authentication counters.
show l2tun
Displays general information about Layer 2 tunnels and sessions.
show l2tun session
Displays the current state of Layer 2 sessions and displays protocol
information about L2TP control channels.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
192
Layer 2 Tunnel Protocol Version 3
show xconnect
show xconnect
To display information about xconnect attachment circuits and pseudowires, use the show xconnect
command in privileged EXEC mode.
show xconnect {all | interface interface | peer ip-address {all | vcid vcid}} [detail]
Syntax Description
all
Displays information about all xconnect attachment circuits and
pseudowires.
interface interface
Displays information about xconnect attachment circuits and pseudowires
on the specified interface. Valid values for the interface argument are as
follows:
peer ip-address {all |
vcid vcid}
detail
•
ethernet number—Displays port-mode xconnect information for a
specific Ethernet interface or subinterface.
•
fastethernet number—Displays port-mode xconnect information for a
specific FastEthernet interface or subinterface.
•
serial number—Displays xconnect information for a specific serial
interface.
•
serial number dlci-number—Displays xconnect information for a
specific Frame Relay data-link connection identifier (DLCI).
•
atm number—Displays xconnect information for a specific ATM
interface or subinterface.
•
atm number vp vpi-value—Displays virtual path (VP) xconnect
information for a specific ATM virtual path identifier (VPI). This
command will not display information about virtual circuit (VC)
xconnects using the specified VPI.
•
atm number vp vpi-value/vci-value—Displays VC xconnect
information for a specific ATM VPI and virtual circuit identifier (VCI)
combination.
Displays information about xconnect attachment circuits and pseudowires
associated with the specified peer IP address.
•
all—Displays all xconnect information associated with the specified
peer IP address.
•
vcid vcid—Displays xconnect information associated with the specified
peer IP address and the specified VCID.
(Optional) Displays detailed information about the specified xconnect
attachment circuits and pseudowires.
Command Modes
Privileged EXEC
Command History
Release
Modification
12.2(27)SBA
This command was introduced.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
193
Layer 2 Tunnel Protocol Version 3
show xconnect
Usage Guidelines
The show xconnect command can be used to display, sort, and filter basic information about all xconnect
attachment circuits and pseudowires.
You can use the show xconnect command output to help determine the appropriate steps to take to
troubleshoot an xconnect configuration problem. More specific information about a particular type of
xconnect can be displayed using the commands listed in the “Related Commands” table.
Examples
The following example shows show xconnect all command output in the brief (default) display format:
Router# show xconnect all
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST
Segment 1
S1 Segment 2
S2
------+---------------------------------+--+---------------------------------+-UP
ac
Et0/0(Ethernet)
UP mpls 10.55.55.2:1000
UP
UP
ac
Se7/0(PPP)
UP mpls 10.55.55.2:2175
UP
UP pri ac
Se6/0:230(FR DLCI)
UP mpls 10.55.55.2:2230
UP
IA sec ac
Se6/0:230(FR DLCI)
UP mpls 10.55.55.3:2231
DN
UP
ac
Se4/0(HDLC)
UP mpls 10.55.55.2:4000
UP
UP
ac
Se6/0:500(FR DLCI)
UP l2tp 10.55.55.2:5000
UP
UP
ac
Et1/0.1:200(Eth VLAN)
UP mpls 10.55.55.2:5200
UP
UP pri ac
Se6/0:225(FR DLCI)
UP mpls 10.55.55.2:5225
UP
IA sec ac
Se6/0:225(FR DLCI)
UP mpls 10.55.55.3:5226
DN
IA pri ac
Et1/0.2:100(Eth VLAN)
UP ac
Et2/0.2:100(Eth VLAN)
UP
UP sec ac
Et1/0.2:100(Eth VLAN)
UP mpls 10.55.55.3:1101
UP
UP
ac
Se6/0:150(FR DLCI)
UP ac
Se8/0:150(FR DLCI)
UP
Table 25 describes the significant fields shown in the display.
Table 25
show xconnect Field Descriptions
Field
Description
XC ST
State of the xconnect attachment circuit or pseudowire. Valid
states are:
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
194
•
UP—The xconnect attachment circuit or pseudowire is
up. Both segment 1 and segment 2 must be up for the
xconnect to be up.
•
DN—The xconnect attachment circuit or pseudowire is
down. Either segment 1, segment 2, or both segments are
down.
•
IA—The xconnect attachment circuit or pseudowire is
inactive. This state is valid only when pseudowire
redundancy is configured.
•
NH—One or both segments of this xconnect no longer
has the required hardware resources available to the
system.
Layer 2 Tunnel Protocol Version 3
show xconnect
Table 25
show xconnect Field Descriptions (continued)
Field
Description
Segment1
Information about the type of xconnect, the interface type,
and the IP address the segment is using. Types of xconnects
are as follows:
or
Segment2
S1
•
ac—Attachment circuit.
•
pri ac—Primary attachment circuit.
•
sec ac—Secondary attachment circuit.
•
mpls—Multiprotocol Label Switching.
•
l2tp—Layer 2 Tunnel Protocol.
State of the segment. Valid states are:
or
•
UP—The segment is up.
S2
•
DN—The segment is down.
•
AD—The segment is administratively down.
The following example shows show xconnect all command output in the detailed display format:
Router# show xconnect all detail
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No HardwareXC
ST
Segment 1
S1 Segment 2
S2
------+---------------------------------+--+---------------------------------+-UP
ac
Et0/0(Ethernet)
UP mpls 10.55.55.2:1000
UP
Interworking: ip
Local VC label 16
Remote VC label 16
pw-class: mpls-ip
UP
ac
Se7/0(PPP)
UP mpls 10.55.55.2:2175
UP
Interworking: ip
Local VC label 22
Remote VC label 17
pw-class: mpls-ip
UP pri ac
Se6/0:230(FR DLCI)
UP mpls 10.55.55.2:2230
UP
Interworking: ip
Local VC label 21
Remote VC label 18
pw-class: mpls-ip
IA sec ac
Se6/0:230(FR DLCI)
UP mpls 10.55.55.3:2231
DN
Interworking: ip
Local VC label unassigned
Remote VC label 19
pw-class: mpls-ip
UP
ac
Se4/0(HDLC)
UP mpls 10.55.55.2:4000
UP
Interworking: none
Local VC label 18
Remote VC label 19
pw-class: mpls
UP
ac
Se6/0:500(FR DLCI)
UP l2tp 10.55.55.2:5000
UP
Interworking: none
Session ID: 34183
Tunnel ID: 62083
Peer name: pe-iou2
Protocol State: UP
Remote Circuit State: UP
pw-class: l2tp
UP
ac
Et1/0.1:200(Eth VLAN)
UP mpls 10.55.55.2:5200
UP
Interworking: ip
Local VC label 17
Remote VC label 20
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
195
Layer 2 Tunnel Protocol Version 3
show xconnect
UP pri ac
Se6/0:225(FR DLCI)
Interworking: none
IA sec ac
Se6/0:225(FR DLCI)
Interworking: none
IA pri ac
Et1/0.2:100(Eth VLAN)
Interworking: none
Et1/0.2:100(Eth VLAN)
Interworking: none
UP sec ac
UP
ac
Se6/0:150(FR DLCI)
Interworking: none
pw-class: mpls-ip
UP mpls 10.55.55.2:5225
Local VC label 19
Remote VC label 21
pw-class: mpls
UP mpls 10.55.55.3:5226
Local VC label unassigned
Remote VC label 22
pw-class: mpls
UP ac
Et2/0.2:100(Eth VLAN)
Interworking: none
UP mpls 10.55.55.3:1101
Local VC label 23
Remote VC label 17
pw-class: mpls
UP ac
Se8/0:150(FR DLCI)
Interworking: none
UP
DN
UP
UP
UP
The additional fields displayed in the detailed output are self-explanatory.
Related Commands
Command
Description
show atm pvc
Displays all ATM PVCs and traffic information.
show atm vc
Displays all ATM PVCs and SVCs and traffic information.
show atm vp
Displays the statistics for all VPs on an interface or for a specific VP.
show connect
Displays configuration information about drop-and-insert connections that
have been configured on a router.
show frame-relay pvc
Displays statistics about PVCs for Frame Relay interfaces.
show interfaces
Displays statistics for all interfaces configured on the router or access server.
show l2tun session
Displays the current state of Layer 2 sessions and protocol information about
L2TP control channels.
show mpls l2transport Displays VC label binding information.
binding
show mpls l2transport Displays information about AToM VCs that have been enabled to route
vc
Layer 2 packets on a router.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
196
Layer 2 Tunnel Protocol Version 3
snmp-server enable traps l2tun session
snmp-server enable traps l2tun session
To enable Simple Network Management Protocol (SNMP) notifications (traps or inform requests) for
Layer 2 Tunnel Protocol Version 3 (L2TPv3) sessions, use the snmp-server enable traps l2tun session
command in global configuration mode. To disable SNMP notifications, use the no form of this
command.
snmp-server enable traps l2tun session
no snmp-server enable traps l2tun session
Syntax Description
This command has no arguments or keywords.
Command Default
SNMP notifications for L2TPv3 sessions are disabled.
Command Modes
Global configuration
Command History
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
The l2tun keyword indicates “layer 2 tunneling.” Layer 2 tunneling session notifications are defined by
the cvpdnNotifSession object { ciscoVpdnMgmtMIBNotifs 3 } in the Cisco VPDN Management MIB
(CISCO-VPDN-MGMT-MIB.my). MIB files are available from Cisco.com at
http://www.cisco.com/go/mibs.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform
requests for L2TP sessions. To specify whether the notifications should be sent as traps or informs, and
to specify which host or hosts receive SNMP notifications, use the snmp-server host [traps | informs]
command.
Use the snmp-server enable traps command without any additional syntax to disable all SNMP
notification types supported on your system.
Examples
The following example enables the router to send L2TP session traps to the host specified by the name
myhost.example.com, using the community string defined as public:
Router(config)# snmp-server enable traps l2tun session
Router(config)# snmp-server host myhost.example.com public l2tun-session
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
197
Layer 2 Tunnel Protocol Version 3
snmp-server enable traps l2tun session
Related Commands
Command
Description
snmp-server enable
traps
Enables all SNMP notifications (traps or informs) available on your system.
snmp-server host
Specifies whether you want the SNMP notifications sent as traps or informs,
the version of SNMP to use, the security level of the notifications (for
SNMPv3), and the recipient (host) of the notifications.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
198
Layer 2 Tunnel Protocol Version 3
snmp-server enable traps l2tun pseudowire status
snmp-server enable traps l2tun pseudowire status
To enable the sending of Simple Network Management Protocol (SNMP) notifications when a
pseudowire changes state, use the snmp-server enable traps l2tun pseudowire status command in
global configuration mode. To disable SNMP notifications of pseudowire state changes, use the no form
of this command.
snmp-server enable traps l2tun pseudowire status
no snmp-server enable traps l2tun pseudowire status
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Release
Modification
12.2(27)SBA
This command was introduced.
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform
requests.
This command controls (enables or disables) notification of pseudowire state changes. For a complete
description of these notification types, and for information about the other MIB functions, see the VPDN
MIB, available through the Cisco Technical Assistance Center (TAC) SNMP Object Navigator tool at
http://www.cisco.com/go/mibs.
The snmp-server enable traps l2tun pseudowire status command is used in conjunction with the
snmp-server host command. Use the snmp-server host command to specify which host or hosts receive
SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host
command.
Use the snmp-server enable traps command without any additional syntax to disable all SNMP
notification types supported on your system.
Examples
The following example enables the router to send pseudowire state change informs to the host at the
address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps l2tun pseudowire status
Router(config)# snmp-server host myhost.cisco.com informs version 2c public
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
199
Layer 2 Tunnel Protocol Version 3
snmp-server enable traps l2tun pseudowire status
Related Commands
Command
Description
snmp-server enable
traps
Enables all SNMP notifications (traps or informs) available on your system.
snmp-server host
Specifies the recipient of an SNMP notification operation.
xconnect logging
pseudowire status
Enables syslog reporting of pseudowire status events.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
200
Layer 2 Tunnel Protocol Version 3
snmp-server host
snmp-server host
To specify the recipient of a Simple Network Management Protocol (SNMP) notification operation, use
the snmp-server host command in global configuration mode. To remove the specified host from the
configuration, use the no form of this command.
snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]}] community-string [udp-port port] [notification-type]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]}] community-string [udp-port port] [notification-type]
Syntax Description
hostname | ip-address
Name or IP address of the SNMP notification host. The ip-address can be an
IP or IPv6 address.
The SNMP notification host is typically a network management station
(NMS or SNMP manager). This host is the recipient of the SNMP traps or
informs.
vrf vrf-name
(Optional) Specifies the Virtual Private Network (VPN) routing and
forwarding (VRF) instance that should be used to send SNMP notifications.
traps
(Optional) Specifies that notifications should be sent as traps. This is the
default.
informs
(Optional) Specifies that notifications should be sent as informs.
version
(Optional) Version of the SNMP used to send the traps. If you use the
version keyword, one of the following keywords must be specified:
•
1 —SNMPv1. This option is not available with informs.
•
2c —SNMPv2C.
•
3 —SNMPv3. The most secure model, because it allows packet
encryption with the priv keyword. One of the following three optional
security level keywords can follow the 3 keyword:
– auth—Enables Message Digest 5 (MD5) and Secure Hash
Algorithm (SHA) packet authentication.
– noauth—Specifies that the noAuthNoPriv security level applies to
this host. This is the default security level for SNMPv3.
– priv—Enables Data Encryption Standard (DES) packet encryption
(also called “privacy”).
community-string
Password-like community string sent with the notification operation.
Note
udp-port port
You can set this string using the snmp-server host command by
itself, but we recommend that you define the string using the
snmp-server community command prior to using the
snmp-server host command.
(Optional) User Datagram Protocol (UDP) port number of the NMS host to
which SNMP notifications or informs are to be sent. The default is 162.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
201
Layer 2 Tunnel Protocol Version 3
snmp-server host
notification-type
(Optional) Type of notification to be sent to the host. If no type is specified,
all available notifications are sent. The notification type can be one or more
of the following keywords:
•
bgp—Sends Border Gateway Protocol (BGP) state change notifications.
•
calltracker—Sends Call Tracker call-start/call-end notifications.
•
config—Sends configuration change notifications.
•
cpu—Sends CPU-related notifications.
•
director—Sends Distributed Director-related notifications.
•
dspu—Sends downstream physical unit (DSPU) notifications.
•
entity—Sends Entity MIB modification notifications.
•
envmon—Sends Cisco enterprise-specific environmental monitor
notifications when an environmental threshold is exceeded.
•
flash—Sends Flash media insertion and removal notifications.
•
frame-relay—Sends Frame Relay notifications.
•
hsrp—Sends Hot Standby Routing Protocol (HSRP) notifications.
•
iplocalpool—Sends IP local pool notifications.
•
ipmobile—Sends Mobile IP notifications.
•
ipsec—Sends IP Security (IPSec) notifications.
•
isdn—Sends ISDN notifications.
•
l2tun-session—Sends Layer 2 tunneling session notifications.
•
l2tun-pseudowire-status—Sends pseudowire state change
notifications.
•
llc2—Sends Logical Link Control, type 2 (LLC2) notifications.
•
memory—Sends memory pool and memory buffer pool notifications.
•
mpls-ldp—Sends Multiprotocol Label Switching (MPLS) Label
Distribution Protocol (LDP) notifications indicating status changes in
LDP sessions.
•
mpls-traffic-eng—Sends MPLS traffic engineering notifications
indicating changes in the status of MPLS traffic engineering tunnels.
•
mpls-vpn—Sends MPLS VPN notifications.
•
pim—Sends Protocol Independent Multicast (PIM) notifications.
•
repeater—Sends standard repeater (hub) notifications.
•
rsrb—Sends remote source-route bridging (RSRB) notifications.
•
rsvp—Sends Resource Reservation Protocol (RSVP) notifications.
•
rtr—Sends Service Assurance Agent (RTR) notifications.
•
sdlc—Sends Synchronous Data Link Control (SDLC) notifications.
•
sdllc—Sends SDLC Logical Link Control (SDLLC) notifications.
•
snmp—Sends any enabled RFC 1157 SNMP linkUp, linkDown,
authenticationFailure, warmStart, and coldStart notifications.
Note
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
202
To enable RFC 2233 compliant link up/down notifications, you
should use the snmp server link trap command.
Layer 2 Tunnel Protocol Version 3
snmp-server host
Defaults
•
srp—Sends Spatial Reuse Protocol (SRP) notifications.
•
stun—Sends serial tunnel (STUN) notifications.
•
syslog—Sends error message notifications (Cisco Syslog MIB). Specify
the level of messages to be sent with the logging history level
command.
•
tty—Sends Cisco enterprise-specific notifications when a TCP
connection closes.
•
voice—Sends SNMP poor quality of voice traps, when used with the
snmp enable peer-trap poor qov command.
•
vrrp—Sends Virtual Router Redundancy Protocol (VRRP)
notifications.
•
vsimaster—Sends Virtual Switch Interface (VSI) Master notifications.
•
x25—Sends X.25 event notifications.
This command is disabled by default. No notifications are sent.
If you enter this command with no keywords, the default is to send all trap types to the host. No informs
will be sent to this host.
If no version keyword is specified, the default is version 1. If version 3 is specified but the security level
is not specified, the default security level is noauth.
The no snmp-server host command with no keywords will disable traps, but not informs, to the host. In
order to disable informs, use the no snmp-server host informs command.
The default UDP port is 162.
Note
If the community string is not defined using the snmp-server community command prior to using this
command, the default form of the snmp-server community command will automatically be inserted
into the configuration. The password (community string) used for this automatic configuration of the
snmp-server community will be the same as specified in the snmp-server host command. This is the
default behavior for Cisco IOS Release 12.0(3) and later releases.
Command Modes
Global configuration
Command History
Release
Modification
10.0
This command was introduced.
Release 12 Mainline/T Train
12.0(3)T
12.1(3)T
•
The version 3 [auth | noauth | priv] syntax was added as part of the
SNMPv3 Support feature.
•
The hsrp notification-type keyword was added.
•
The voice notification-type keyword was added.
The calltracker notification-type keyword was added for the Cisco AS5300
and AS5800 platforms.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
203
Layer 2 Tunnel Protocol Version 3
snmp-server host
Release
12.2(2)T
12.2(4)T
12.2(8)T
12.2(13)T
12.3(2)T
12.3(4)T
Modification
•
The vrf vrf-name keyword and argument combination was added.
•
The ipmobile notification-type keyword was added.
•
Support for the vsimaster notification-type keyword was added for the
Cisco 7200 and Cisco 7500 series.
•
The pim notification-type keyword was added.
•
The ipsec notification-type keyword was added.
•
The mpls-traffic-eng notification-type keyword was added.
•
The director notification-type keyword was added.
•
The srp notification-type keyword was added.
•
The mpls-ldp notification-type keyword was added.
•
The flash notification-type keyword was added.
•
The l2tun-session notification-type keyword was added.
•
The cpu notification-type keyword was added.
•
The memory notification-type keyword was added.
12.3(8)T
The iplocalpool notification-type keyword was added for the Cisco 7200 and
7301 series routers.
12.3(11)T
The vrrp keyword was added.
Release 12.0S
12.0(17)ST
The mpls-traffic-eng notification-type keyword was integrated into the
12.0ST train.
12.0(21)ST
The mpls-ldp notification-type keyword was integrated into the 12.0ST
train.
12.0(22)S
•
All features in the 12.0ST train were integrated into Release 12.0S.
•
The mpls-vpn notification-type keyword was added.
12.0(23)S
The l2tun-session notification-type keyword was added.
12.0(26)S
The memory notification-type keyword was added.
12.0(27)S
•
Support for SNMP over IPv6 transport was added. Either an IP or IPv6
Internet address can be specified as the hostname argument.
•
The vrf vrf-name keyword argument pair was integrated into Cisco IOS
Release 12.0(27)S to support multiple LDP contexts for VPNs.
Release 12.2S
12.2(18)S
12.2(25)S
12.2(27)SBA
Usage Guidelines
This command was integrated into Cisco IOS Release 12.2(18)S.
•
The cpu notification-type keyword was added.
•
The memory notification-type keyword was added.
The l2tun-pseudowire-status notification-type keyword was added.
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver
does not send acknowledgments when it receives traps. The sender cannot determine if the traps were
received. However, an SNMP entity that receives an inform request acknowledges the message with an
SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request
can be sent again. Thus, informs are more likely to reach their intended destination.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
204
Layer 2 Tunnel Protocol Version 3
snmp-server host
However, informs consume more resources in the agent and in the network. Unlike a trap, which is
discarded as soon as it is sent, an inform request must be held in memory until a response is received or
the request times out. Also, traps are sent only once; an inform may be retried several times. The retries
increase traffic and contribute to a higher overhead on the network.
If you do not enter an snmp-server host command, no notifications are sent. In order to configure the
router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter
the command with no keywords, all trap types are enabled for the host.
To enable multiple hosts, you must issue a separate snmp-server host command for each host. You can
specify multiple notification types in the command for each host.
When multiple snmp-server host commands are given for the same host and kind of notification (trap
or inform), each succeeding command overwrites the previous command. Only the last snmp-server
host command will be in effect. For example, if you enter an snmp-server host inform command for a
host and then enter another snmp-server host inform command for the same host, the second command
will replace the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Use
the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to
receive most notifications, at least one snmp-server enable command and the snmp-server host
command for that host must be enabled.
However, some notification types cannot be controlled with the snmp-server enable command. For
example, some notification types are always enabled. Other notification types are enabled by a different
command. For example, the linkUpDown notifications are controlled by the snmp trap link-status
command. These notification types do not require an snmp-server enable command.
A notification-type option’s availability depends on the router type and Cisco IOS software features
supported on the router. For example, the envmon notification type is available only if the environmental
monitor is part of the system. To see what notification types are available on your system, use the
command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a
specific VRF. The VRF defines a VPN membership of a customer so data is stored using the VPN.
Regarding Notification-Type Keywords
The notification-type keywords used in the snmp-server host command do not always match the
keywords used in the corresponding snmp-server enable traps command. For example, the notification
keyword applicable to MPLS traffic engineering tunnels is specified as mpls-traffic-eng (containing two
hyphens and no intervening spaces). The corresponding parameter in the snmp-server enable traps
command is specified as mpls traffic-eng (containing an intervening space and a hyphen).
This syntax difference is necessary to ensure that the command-line interface (CLI) interprets the
notification-type keyword of the snmp-server host command as a unified, single-word construct, which
preserves the capability of the snmp-server host command to accept multiple notification-type
keywords in the command line. The snmp-server enable traps commands, however, often use two-word
constructs in order to provide hierarchical configuration options and to maintain consistency with the
command syntax of related commands. Table 26 maps some examples of snmp-server enable traps
commands to the keywords used in the snmp-server host command.
Table 26
Notification Keywords and Corresponding SNMP Enable Traps Commands
SNMP Enable Traps Command
SNMP Host Command Keyword
snmp-server enable traps l2tun session
l2tun-session
snmp-server enable traps mpls ldp
mpls-ldp
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
205
Layer 2 Tunnel Protocol Version 3
snmp-server host
Table 26
Notification Keywords and Corresponding SNMP Enable Traps Commands (continued)
SNMP Enable Traps Command
snmp-server enable traps mpls traffic-eng
snmp-server enable traps mpls vpn
SNMP Host Command Keyword
1
mpls-traffic-eng
mpls-vpn
1. See the Cisco IOS Multiprotocol Label Switching Command Reference for documentation of this command.
Examples
If you want to configure a unique SNMP community string for traps, but you want to prevent SNMP
polling access with this string, the configuration should include an access list. In the following example,
the community string is named comaccess and the access list is numbered 10:
Router(config)# snmp-server community comaccess ro 10
Router(config)# snmp-server host 172.20.2.160 comaccess
Router(config)# access-list 10 deny any
The following example shows how to send RFC 1157 SNMP traps to the host specified by the name
myhost.cisco.com. Other traps are enabled, but only SNMP traps are sent because only snmp is specified
in the snmp-server host command. The community string is defined as comaccess.
Router(config)# snmp-server enable traps
Router(config)# snmp-server host myhost.cisco.com comaccess snmp
The following example shows how to send the SNMP and Cisco environmental monitor
enterprise-specific traps to address 172.30.2.160 using the community string public:
Router(config)# snmp-server enable traps snmp
Router(config)# snmp-server enable traps envmon
Router(config)# snmp-server host 172.30.2.160 public snmp envmon
The following example shows how to enable the router to send all traps to the host myhost.cisco.com
using the community string public:
Router(config)# snmp-server enable traps
Router(config)# snmp-server host myhost.cisco.com public
The following example will not send traps to any host. The BGP traps are enabled for all hosts, but only
the ISDN traps are enabled to be sent to a host. The community string is defined as public.
Router(config)# snmp-server enable traps bgp
Router(config)# snmp-server host myhost.cisco.com public isdn
The following example shows how to enable the router to send all inform requests to the host
myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps
Router(config)# snmp-server host myhost.cisco.com informs version 2c public
The following example shows how to send Hot Standby Router Protocol (HSRP) MIB informs to the
host specified by the name myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable traps hsrp
Router(config)# snmp-server host myhost.cisco.com informs version 2c public hsrp
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
206
Layer 2 Tunnel Protocol Version 3
snmp-server host
The following example shows how to send all SNMP notifications to company.com over the VRF named
trap-vrf using the community string public:
Router(config)# snmp-server host company.com vrf public trap-vrf
The following example shows how to configure an IPv6 SNMP notification server with the IPv6 address
2322:34ab:23ef:2545:4545:3535 using the community string public:
Router(config)# snmp-server host 2322:34ab:23ef:2545:4545:3535 version 2c public udp-port
2012
The following example shows how to specify VRRP as the protocol using the community string public:
Router(config)# snmp-server enable traps vrrp
Router(config)# snmp-server host myhost.cisco.com traps version 2c public vrrp
Related Commands
Command
Description
snmp-server enable
peer-trap poor qov
Enables poor quality of voice notifications for applicable calls
associated with a specific voice dial peer.
snmp-server enable traps
Enables SNMP notifications (traps and informs).
snmp-server informs
Specifies inform request options.
snmp-server link trap
Enables linkUp/linkDown SNMP traps that are compliant with
RFC 2233.
snmp-server trap-source
Specifies the interface (and hence the corresponding IP address) that an
SNMP trap should originate from.
snmp-server trap-timeout
Defines how often to try resending trap messages on the retransmission
queue.
snmp trap link-status
Enables SNMP link trap generation.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
207
Layer 2 Tunnel Protocol Version 3
timeout setup
timeout setup
To configure the amount of time allowed to set up a control channel with a remote provider edge (PE)
router at the other end of a Layer 2 pseudowire, use the timeout setup command in L2TP class
configuration mode. To disable the configured value, use the no form of this command.
timeout setup seconds
no timeout setup seconds
Syntax Description
seconds
Command Default
The default number of seconds allowed to set up a control channel is 300.
Command Modes
L2TP class configuration
Command History
Release
The number of seconds allowed to set up a Layer 2 control channel. The
valid values range from 60 to 6000. The default value is 300 seconds.
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
Usage Guidelines
Use this command to configure the amount of time that can be spent attempting to establish a control
channel.
Examples
The following example sets a timeout period of 200 seconds to establish a control channel with a remote
peer in Layer 2 pseudowires that have been configured with the L2TP class named “l2tp-class1”:
Router(config)# l2tp-class l2tp-class1
Router(config-l2tp-class)# timeout setup 200
Related Commands
Command
Description
l2tp-class
Creates a template of L2TP control plane configuration settings that can be
inherited by different pseudowire classes and enters L2TP class
configuration mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
208
Layer 2 Tunnel Protocol Version 3
xconnect
xconnect
To bind an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to a Layer 2 Tunnel Protocol
Version 3 (L2TPv3) pseudowire for xconnect service and enter xconnect configuration mode, use the
xconnect command in interface configuration mode. To restore the default values, use the no form of
this command.
xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]
no xconnect
Syntax Description
peer-ip-address
IP address of the remote provider edge (PE) peer.
vcid
The 32-bit identifier of the virtual circuit between the routers at each end of
the L2TPv3 control channel.
pseudowire-parameters Encapsulation and pseudowire class parameters to be used for the L2TPv3
control channel. At least one of the following pseudowire parameters must
be configured:
•
encapsulation {l2tpv3 [manual] | mpls}—The encapsulation
pseudowire class parameter specifies the tunneling method used to
encapsulate data in the pseudowire:
– l2tpv3—L2TPv3 is the tunneling method to be used.
– manual—(Optional) No signaling is to be used in the L2TPv3
control channel. This command places the router in xconnect
configuration mode for manual configuration of L2TPv3
parameters for the attachment circuit.
– mpls—Multiprotocol Label Switching (MPLS) is the tunneling
method to be used.
•
pw-class pw-class-name—The pseudowire class configuration from
which the data encapsulation type (L2TPv3) will be taken. This option
is mandatory if you select L2TPv3 as your data encapsulation method.
sequencing
(Optional) Sets the sequencing method to be used for packets received or
sent in L2TP sessions.
transmit
Sequencing of L2TP data packets received from the L2TPv3 session.
receive
Sequencing of L2TP data packets sent into the L2TPv3 session.
both
Sequencing of L2TP data packets that are both sent and received from the
L2TPv3 session.
Command Default
L2TPv3 is the data encapsulation method.
Sequencing is off.
Command Modes
Interface configuration
l2transport PVP configuration (for ATM)
Frame Relay DLCI interface configuration mode
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
209
Layer 2 Tunnel Protocol Version 3
xconnect
Command History
Usage Guidelines
Note
Release
Modification
12.0(23)S
This command was introduced.
12.3(2)T
This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
The combination of the peer-ip-address and vcid arguments must be unique on the router. Each xconnect
configuration must have a unique combination of peer-ip-address and vcid configuration.
If the remote router is a Cisco 12000 series Internet router, the peer-ip-address argument must specify a
loopback address on that router.
The same vcid value that identifies the attachment circuit must be configured using the xconnect
command on the local and remote PE router at each end of an L2TPv3 session. The virtual circuit
identifier creates the binding between a pseudowire and an attachment circuit.
To manually configure the L2TP settings used in the attachment circuit, enter encapsulation l2tpv3
manual in the xconnect command. This configuration is called a static L2TPv3 session. The router is
placed in xconnect configuration mode, and you can then configure the following options:
•
Local and remote session identifiers (using the l2tp id command) for local and remote PE routers at
each end of the session.
•
Size of the cookie field used in the L2TPv3 headers of incoming (sent) packets from the remote PE
peer router (using the l2tp cookie local command).
•
Size of the cookie field used in the L2TPv3 headers of outgoing (received) L2TP data packets (using
the l2tp cookie remote command).
•
Interval used between sending hello keepalive messages (using the l2tp hello command).
If you do not enter encapsulation l2tpv3 manual in the xconnect command, the data encapsulation type
for the L2TPv3 session is taken from the encapsulation type configured for the pseudowire class
specified with the pseudowire-class pw-class-name command.
The pw-class pw-class-name value binds the xconnect configuration of an attachment circuit to a
specific pseudowire class. In this way, the pseudowire class configuration serves as a template that
contains settings used by all attachment circuits bound to it with the xconnect command.
Note
Examples
If you specify the encapsulation l2tpv3 keyword, you must specify the pw-class keyword.
The following example configures xconnect service for an Ethernet interface by binding the Ethernet
circuit to the L2TPv3 pseudowire named “123 with a remote peer 10.0.3.201. The L2TP configuration
settings in the pseudowire class named “vlan-xconnect” will be used.
Router(config)# interface Ethernet0/0.1
Router(config-if)# xconnect 10.0.3.201 123 pw-class vlan-xconnect
The following example enters xconnect configuration mode and manually configures L2TPv3
parameters for the attachment circuit:
Router(config)# interface Ethernet 0/0
Router(config-if)# xconnect 10.0.3.201 123 encapsulation l2tpv3 manual pw-class ether-pw
Router(config-if-xconn) l2tp id 222 111
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
210
Layer 2 Tunnel Protocol Version 3
xconnect
Router(config-if-xconn) l2tp cookie local 4 54321
Router(config-if-xconn) l2tp cookie remote 4 12345
Router(config-if-xconn) l2tp hello l2tp-defaults
Related Commands
Command
Description
l2tp-class
Configures a template of L2TP control plane configuration settings that can
be inherited by different pseudowire classes.
l2tp cookie local
Configures the size of the cookie field used in the L2TPv3 headers of
incoming packets received from the remote PE peer router.
l2tp cookie remote
Configures the size of the cookie field used in the L2TPv3 headers of
outgoing packets sent from the local PE peer router.
l2tp hello
Specifies the use of a hello keepalive setting contained in a specified L2TP
class configuration for a static L2TPv3 session.
l2tp id
Configures the identifiers used by the local and remote provider edge
routers at each end of an L2TPv3 session.
pseudowire-class
Configures a template of pseudowire configuration settings used by the
attachment circuits transported over a pseudowire.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
211
Layer 2 Tunnel Protocol Version 3
xconnect logging pseudowire status
xconnect logging pseudowire status
To enable system logging (syslog) reporting of pseudowire status events, use the xconnect logging
pseudowire status command in global configuration mode. To disable syslog reporting of pseudowire
status events, use the no form of this command.
xconnect logging pseudowire status
no xconnect logging pseudowire status
Syntax Description
This command has no arguments or keywords.
Defaults
Syslog reporting of pseudowire status events is off.
Command Modes
Global configuration
Command History
Release
Modification
12.2(27)SBA
This command was introduced.
Usage Guidelines
Use this command to enable syslog reporting of pseudowire status events.
Examples
The following example enables syslog reporting of pseudowire status events:
xconnect logging pseudowire status
Related Commands
Command
Description
xconnect
Binds an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to a
L2TPv3 pseudowire for xconnect service and enters xconnect configuration
mode.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
212
Layer 2 Tunnel Protocol Version 3
Glossary
Glossary
AVPs—attribute-value pairs.
BECN—backward explicit congestion notification. Bit set by a Frame Relay network in frames traveling
in the opposite direction of frames encountering a congested path. DTE receiving frames with the BECN
bit set can request that higher-level protocols take flow control action as appropriate.
CE—customer edge (Frame Relay switch or user device).
CIR—committed information rate. Rate at which a Frame Relay network agrees to transfer information
under normal conditions, averaged over a minimum increment of time. CIR, measured in bits per second,
is one of the key negotiated tariff metrics.
data-link control layer—Layer 2 in the SNA architectural model. Responsible for the transmission of
data over a particular physical link. Corresponds approximately to the data link layer of the OSI model.
DCE—data circuit-terminating equipment (ITU-T expansion). Devices and connections of a
communications network that comprise the network end of the user-to-network interface.
dCEF—distributed Cisco Express Forwarding.
DLCI—data-link connection identifier. A unique number assigned to a PVC endpoint in a Frame Relay
network. Identifies a particular PVC endpoint within an access channel in a Frame Relay network and
has local significance only to that channel.
DTE—data terminal equipment. Device at the user end of a user-network interface that serves as a data
source, destination, or both.
FECN—forward explicit congestion notification. Bit set by a Frame Relay network to inform DTE
receiving the frame that congestion was experienced in the path from source to destination. DTE
receiving frames with the FECN bit set can request that higher-level protocols take flow-control action
as appropriate.
HDLC—High-Level Data Link Control. A generic link-level communications protocol developed by the
International Organization for Standardization (ISO). HDLC manages synchronous, code-transparent,
serial information transfer over a link connection.
ICMP—Internet Control Message Protocol. A network protocol that handles network errors and error
messages.
IDB—interface descriptor block.
IS-IS—Intermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol based
on DECnet Phase V routing, whereby ISs (routers) exchange routing information based on a single
metric to determine network topology.
L2TP—An extension to PPP merging features of two tunneling protocols: Layer 2 Forwarding (L2F)
from Cisco Systems and Point-to-Point Tunneling (PPTP) from Microsoft. L2TP is an Internet
Engineering Task Force (IETF) standard endorsed by Cisco Systems, and other networking industry
leaders.
L2TPv3—Draft version of L2TP that enhances functionality in RFC 2661 (L2TP).
LMI—Local Management Interface.
MPLS—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
label instructs the routers and the switches in the network where to forward the packets based on
preestablished IP routing information.
MQC—modular quality of service command-line interface.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
213
Layer 2 Tunnel Protocol Version 3
Glossary
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can
handle.
NNI—Network-to-Network Interface. ATM Forum standard that defines the interface between two ATM
switches that are both located in a private network or are both located in a public network. The UNI
standard defines the interface between a public switch and a private one. Also, the standard interface
between two Frame Relay switches meeting the same criteria.
PE—Provider edge router providing Frame Relay over L2TPv3 functionality.
PPP—Point-to-Point Protocol. A link-layer encapsulation method for dialup or dedicated circuits. A
successor to Serial Line IP (SLIP), PPP provides router-to-router and host-to-network connections over
synchronous and asynchronous circuits.
PVC—permanent virtual circuit. A virtual circuit that is permanently established. A Frame Relay logical
link, whose endpoints and class of service are defined by network management. Analogous to an X.25
permanent virtual circuit, a PVC consists of the originating Frame Relay network element address,
originating data-link control identifier, terminating Frame Relay network element address, and
termination data-link control identifier. Originating refers to the access interface from which the PVC is
initiated. Terminating refers to the access interface at which the PVC stops. Many data network
customers require a PVC between two points. PVCs save bandwidth associated with circuit
establishment and tear down in situations where certain virtual circuits must exist all the time. Data
terminating equipment with a need for continuous communication uses PVCs.
PW—pseudowire.
SNMP—Simple Network Management Protocol. Network management protocol used almost
exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and
to manage configurations, statistics collection, performance, and security.
tunneling—Architecture that is designed to provide the services necessary to implement any standard
point-to-point encapsulation scheme.
UNI—User-Network Interface.
UTI—Universal Transport Interface.
VPDN—virtual private dialup network. A network that allows separate and autonomous protocol
domains to share common access infrastructure, including modems, access servers, and ISDN routers.
A VPDN enables users to configure secure networks that take advantage of ISPs that tunnel remote
access traffic through the ISP cloud.
WAN—wide-area network. Data communications network that serves users across a broad geographic
area and often uses transmission devices provided by common carriers. Frame Relay, SMDS, and X.25
are examples of WANs.
Note
Refer to Internetworking Terms and Acronyms for terms not included in this glossary.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
214
Layer 2 Tunnel Protocol Version 3
Glossary
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco
Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient,
and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0711R)
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
215
Layer 2 Tunnel Protocol Version 3
Glossary
Cisco IOS Releases 12.0(30)S and 12.2(27)SBA
216