Cisco IOS Wide-Area Networking Command Reference

de-bit

To set Frame Relay discard-eligible (DE) bit mapping for FRF.5 and FRF.8 network interworking, use the de-bit command in FRF.5 connect configuration mode or FRF.8 connect configuration mode. To disable or reset Frame Relay DE bit mapping, use the no form of this command.

de-bit {0 | 1 | map-clp}

no de-bit {0 | 1 | map-clp}

Syntax Description

Defaults

map-clp

Command Modes

FRF.5 connect configuration
FRF.8 connect configuration

Command History

Usage Guidelines

In the default state, the DE bit in the Frame Relay header is set to 1 when one or more ATM cells that belong to a frame have their cell loss priority (CLP) field set to 1 or when the DE field of the Frame Relay service-specific convergence sublayer (FR-SSCS) protocol data unit (PDU) is set to 1.

When the no de-bit command and map-clp keyword are entered, the FR-SSCS PDU DE field is copied unchanged to the Q.922 core frame DE field, independently of CLP indications received at the ATM layer.

Examples

The following example creates a connection between the virtual circuit (VC) group named "friends" and ATM PVC 0/32 and configures FR DE field mapping to match the ATM CLP field:

Router(config)# vc-group friends

Router(config-vc-group)# serial1/0 16 16

Router(config-vc-group)# serial1/0 17 17

Router(config-vc-group)# serial1/0 18 18

Router(config-vc-group)# serial1/0 19 19

Router(config)# interface atm3/0

Router(config-if)# pvc 0/32

Router(config-if-atm-vc)# encapsulation aal5mux frame-relay

Router (config-if-atm-vc)# exit

Router (config-if)# exit

Router(config)# connect vc-group friends atm3/0 0/32

Router(config-frf5)# de-bit map-clp

Related Commands

de-bit map-clp

To set Frame Relay discard eligible (DE) bit mapping for FRF.5 network interworking, use the de-bit map-clp command in FRF.5 connect mode. To disable or reset Frame Relay DE bit mapping, use the no form of this command.

de-bit map-clp

no de-bit map-clp

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values

Command Modes

FRF.5 connect configuration

Command History

Usage Guidelines

In the default state, the DE bit in the Frame Relay header is set to 1 when one or more ATM cells belonging to a frame have their cell loss priority (CLP) field set to 1, or when the DE field of the Frame Relay service specific convergence sublayer (FR-SSCS) protocol data unit (PDU) is set to 1.

When the no de-bit map-clp command is entered, the FR-SSCS PDU DE field is copied unchanged to the Q.922 core frame DE field, independent of CLP indications received at the ATM layer.

Examples

The following example creates a connection that connects the virtual circuit (VC) group named friends to ATM PVC 0/32 and configures FR DE field mapping to match the ATM CLP field:

Router(config)# vc-group friends

Router(config-vc-group)# serial0 16 16

Router(config-vc-group)# serial0 17 17

Router(config-vc-group)# serial0 18 18

Router(config-vc-group)# serial0 19 19

Router(config)# interface atm3/0

Router(config-if)# pvc 0/32

Router(config-if-atm-vc)# encapsulation aal5mux frame-relay

Router(config)# connect vc-group friends atm3/0 0/32

Router(config-frf5)# de-bit map-clp

Related Commands

debug frame-relay multilink

To display debug messages for multilink Frame Relay bundles and bundle links, use the debug frame-relay multilink command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug frame-relay multilink [control [mfr number | serial number]]

no debug frame-relay multilink

Syntax Description

Command Modes

Privileged EXEC (#)

Command History

Usage Guidelines

---

Caution Using the debug frame-relay multilink command without the control keyword could severely impact router performance and is not recommended.

---

Using the debug frame-relay multilink command without the MFR or serial keyword displays error conditions that occur at the bundle layer.

Examples

The following example shows output from the debug frame-relay multilink command for bundle "MFR0," which has three bundle links:

Router# debug frame-relay multilink control MFR0

00:42:54:Serial5/3(o):msg=Add_link, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3, 
BL state=Idle

E1 00 01 01 07 4D 46 52 30 00

00:42:54:Serial5/2(o):msg=Add_link, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2, 
BL state=Idle

E1 00 01 01 07 4D 46 52 30 00

00:42:54:Serial5/1(o):msg=Add_link, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, 
BL state=Idle

E1 00 01 01 07 4D 46 52 30 00

00:42:54:%LINK-3-UPDOWN:Interface MFR0, changed state to down

00:42:54:Serial5/3(i):msg=Add_link_ack, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3, 
BL state=Add_sent

E1 00 02 01 07 4D 46 52 30 00

00:42:54:Serial5/2(i):msg=Add_link_ack, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2, 
BL state=Add_sent

E1 00 02 01 07 4D 46 52 30 00

00:42:54:Serial5/1(i):msg=Add_link_ack, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, 
BL state=Add_sent

E1 00 02 01 07 4D 46 52 30 00

00:42:54:%SYS-5-CONFIG_I:Configured from console by console

00:43:00:Serial5/1(i):msg=Add_link, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, 
BL state=Ack_rx

E1 00 01 01 07 4D 46 52 30 00

00:43:00:Serial5/1(o):msg=Add_link_ack, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, 
BL state=Ack_rx

E1 00 02 01 07 4D 46 52 30 00

00:43:00:%LINK-3-UPDOWN:Interface MFR0, changed state to up

00:43:00:Serial5/1(i):msg=Hello, Link=Serial5/1, Bundle=MFR0, Linkid=Serial5/1, BL 
state=Up

E1 00 04 03 06 30 A7 E0 54 00

00:43:00:Serial5/1(o):msg=Hello_ack, Link=Serial5/1, Bundle=MFR0, Link id=Serial5/1, BL 
state=Up

E1 00 05 03 06 90 E7 0F C2 06

00:43:01:Serial5/2(i):msg=Add_link, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2, 
BL state=Ack_rx

E1 00 01 01 07 4D 46 52 30 00

00:43:01:Serial5/2(o):msg=Add_link_ack, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2, 
BL state=Ack_rx

E1 00 02 01 07 4D 46 52 30 00

00:43:01:Serial5/2(i):msg=Hello, Link=Serial5/2, Bundle=MFR0, Linkid=Serial5/2, BL 
state=Up

E1 00 04 03 06 30 A7 E0 54 00

00:43:01:Serial5/2(o):msg=Hello_ack, Link=Serial5/2, Bundle=MFR0, Link id=Serial5/2, 
BL state=Up

E1 00 05 03 06 90 E7 0F C2 06

00:43:01:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/1, changed state to up

00:43:01:Serial5/3(i):msg=Add_link, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3, 
BL state=Ack_rx

E1 00 01 01 07 4D 46 52 30 00

00:43:01:Serial5/3(o):msg=Add_link_ack, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3, 
BL state=Ack_rx

E1 00 02 01 07 4D 46 52 30 00

00:43:01:Serial5/3(i):msg=Hello, Link=Serial5/3, Bundle=MFR0, Linkid=Serial5/3, BL 
state=Up

E1 00 04 03 06 30 A7 E0 54 00

00:43:01:Serial5/3(o):msg=Hello_ack, Link=Serial5/3, Bundle=MFR0, Link id=Serial5/3, 
BL state=Up

E1 00 05 03 06 90 E7 0F C2 06

00:43:02:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/2 , changed state to up

00:43:02:%LINEPROTO-5-UPDOWN:Line protocol on Interface Serial5/3 , changed state to up

Table 2 describes the significant fields shown in the display.

Related Commands

debug l4f

To enable troubleshooting for Layer 4 Forwarding (L4F) flows, use the debug l4f command in privileged EXEC mode. To disable the troubleshooting, use the no form of this command.

debug l4f {api | flow-db | flows | packet {all | detail | injection | interception | proxying | spoofing} | test-app | trace-db-api | trace-db-flow | trace-engine}

no debug l4f {api | flow-db | flows | packet {all | detail | injection | interception | proxying | spoofing} | test-app | trace-db-api | trace-db-flow | trace-engine}

Syntax Description

Command Default

L4F debugging is off.

Command Modes

Privileged EXEC (#)

Command History

Examples

The following example shows how to enable debugging for L4F packets:

Router# debug l4f packet all

Usage Guidelines

Use this command to enable debugging for Layer 4 forwarding flows.

Related Commands

debug platform hardware qfp active interface frame-relay multilink

To debug the multilink frame-relay interfaces in the Cisco QuantumFlow Processor (QFP), use the debug platform hardware qfp interface frame-relay mulitlink command in the Privileged EXEC mode. To disable this form of debugging, use the no form of this command.

debug platform hardware qfp active interface frame-relay multilink {all | error | info | trace | warning}

no debug platform hardware qfp active interface frame-relay multilink {all | error | info | trace | warning}

Syntax Description

Command Default

No default behavior or values.

Command Modes

Privileged EXEC (#)

Command History

Examples

The following example shows how to debug the multilink frame relay client at all levels:

Router# debug platform hardware qfp active interface frame-relay multilink all

The selected MFR Client debugging is on

debug rgf detailed

To enable detailed debugging information about redundancy group facility (RGF) events that are sent and received on Multirouter Automatic Protection Switching (MR-APS)-enabled routers that support stateful Multilink PPP (MLPPP) sessions, use the debug rgf detailed command in privileged EXEC mode. To disable debugging, use the no form of this command.

debug rgf detailed

no debug rgf detailed

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC (#)

Command History

Examples

The following is sample output from the debug rgf detailed command. The fields in the display are self-explanatory.

Router# debug rgf detailed

RGF detailed event debugging is on

6d00h: RGF: Rcvd aps evt[4] aps_group_id:1

6d00h: RGF Event: Group[1] Got event[Go-Standby-cold] current state[Standby-bulk]

6d00h: RGF: Group [1] state[Standby-bulk] Sending [Init] to client Id[1]

6d00h: RGF: Group[1] Client [1] Sent OK for Init

6d00h: RGF State: Group[1] Old State [Standby-bulk] New State [Init] Event 
[Go-Standby-cold]

6d00h: RGF: Group[1] buffer app data len[20] len[44] allocated

6d00h: RGF: Sending data group[1] client[0] app data len[20]

6d00h: RGF: Sending data dump

6d00h: ICRM HEADER:

 30 2 0 28

6d00h: RGF HEADER:

 0 0 0 2 0 0 0 14 0 0 0 1 0 0 0 0 0 0 0 0

6d00h: PAYLOAD:

 0 0 0 0 0 0 0 1 0 0 0 2 0 0 0 4 0 0 0 0

6d00h: RGF: Sent msg_id 43317, 44 bytes to ICRM conn_hdl0xAD000000

6d00h: RGF[1]: Client [1] Done for Init Action Going Cold

6d00h: RGF: Group [1] state[Init] Sending [Standby cold] to client Id[1]

6d00h: RGF[1]: Client [1] Done for Standby cold Action Going Bulk

6d00h: RGF State: Group[1] Old State [Init] New State [Standby-cold] Event 
[Go-Standby-cold]

6d00h: RGF: Group[1] buffer app data len[20] len[44] allocated

6d00h: RGF: Sending data group[1] client[0] app data len[20]

6d00h: RGF: Sending data dump

6d00h: ICRM HEADER:

 30 2 0 28

6d00h: RGF HEADER:

 0 0 0 2 0 0 0 14 0 0 0 1 0 0 0 0 0 0 0 0

6d00h: PAYLOAD:

 0 0 0 0 0 0 0 3 0 0 0 2 0 0 0 1 0 0 0 0

6d00h: RGF: Sent msg_id 43318, 44 bytes to ICRM conn_hdl0xAD000000

6d00h: RGF[1]: Dint get go bulk from APS. Postponing

Related Commands

debug rgf errors

To enable redundancy group facility (RGF) error debugging on Multirouter Automatic Protection Switching (MR-APS)-enabled routers that support stateful Multilink PPP (MLPPP) sessions, use the debug rgf errors command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug rgf errors

no debug rgf errors

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC (#)

Command History

Examples

The following example shows how to use this command to display any RGF errors that may have occurred in the system:

Router# debug rgf errors

RGF Error debugging is on

You will receive an error debugging output only if there are any RGF errors in the system.

Related Commands

debug rgf events

To display all redundancy group facility (RGF) events on Multirouter Automatic Protection Switching (MR-APS)-enabled routers that support stateful Multilink PPP (MLPPP) sessions, use the debug rgf events command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug rgf events

no debug rgf events

Syntax Description

This command has no arguments or keywords.

Command Modes

Privileged EXEC (#)

Command History

Examples

The following is sample output from the debug rgf events command when the SONET controller is shut. The fields in the display are self-explanatory:

Router# debug rgf events

RGF event debugging is on

Router#

6d00h: RGF: Rcvd aps evt[4] aps_group_id:1

6d00h: RGF[1]: Got Standby cold from APS. Wait for Peer

6d00h: RGF: Group[1] buffer app data len[20] len[44] allocated

6d00h: RGF: Sending data group[1] client[0] app data len[20]

6d00h: RGF: Sent msg_id 43218, 44 bytes to ICRM conn_hdl0xAD000000

6d00h: RGF: Rcvd aps evt[5] aps_group_id:1

6d00h: RGF PR PROG: Group[1] state [Standby-cold] Sending [peer Standby Bulk] to Peer

6d00h: RGF: Group[1] buffer app data len[20] len[44] allocated

6d00h: RGF: Sending data group[1] client[0] app data len[20]

6d00h: RGF: Sent msg_id 43315, 44 bytes to ICRM conn_hdl0xAD000000

6d00h: RGF State: Group[1] Old State [Standby-cold] New State [Standby-bulk] Event 
[Go-Standby-bulk]

Related Commands

debug vpdn

To troubleshoot Layer 2 Forwarding (L2F) or Layer 2 Tunnel Protocol (L2TP) virtual private dial-up 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.

Note Effective with Cisco Release 12.4(11)T, the L2F protocol is not available in Cisco IOS software.

debug vpdn {call {event | fsm} | authorization {error | event} | error | event [disconnect] | l2tp-sequencing | l2x-data | l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event | fsm} | subscriber {error | event | fsm}}

no debug vpdn {call {event | fsm} | authorization {error | event} | error | event [disconnect] | l2tp-sequencing | l2x-data | l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event | fsm} | subscriber {error | event | fsm}}

Syntax Description

Command Modes

Privileged EXEC (#)

Command History

Usage Guidelines

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

•Displaying L2TP Congestion Avoidance Settings

•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

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

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 user6@cisco.com 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 3 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.

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 user's 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 user6@cisco.com

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 4 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.

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: L2TP: I SCCRQ from ts1 tnl 8

20:19:17: L2X: Never heard of ts1

20:19:17: Tnl 7 L2TP: New tunnel created for remote ts1, address 172.21.9.4

20:19:17: Tnl 7 L2TP: Got a challenge in SCCRQ, ts1

20:19:17: Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply

20:19:17: Tnl 7 L2TP: Got a Challenge Response in SCCCN from ts1

20:19:17: Tnl 7 L2TP: Tunnel Authentication success

20:19:17: Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established

20:19:17: Tnl 7 L2TP: SM State established

20:19:17: Tnl/Cl 7/1 L2TP: Session FS enabled

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel

20:19:17: Tnl/Cl 7/1 L2TP: New session created

20:19:17: Tnl/Cl 7/1 L2TP: O ICRP to ts1 8/1

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established

20:19:17: Vi1 VPDN: Virtual interface created for bum1@cisco.com

20:19:17: Vi1 VPDN: Set to Async interface

20:19:17: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking

20:19:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

20:19:18: Vi1 VPDN: Bind interface direction=2

20:19:18: Vi1 VPDN: PPP LCP accepting rcv CONFACK

20:19:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

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: %LINK-3-UPDOWN: Interface Async7, changed state to up

20:47:35: As7 VPDN: Looking for tunnel -- cisco.com --

20:47:35: As7 VPDN: Get tunnel info for cisco.com with NAS nas1, IP 172.21.9.13

20:47:35: As7 VPDN: Forward to address 172.21.9.13

20:47:35: As7 VPDN: Forwarding...

20:47:35: As7 VPDN: Bind interface direction=1

20:47:35: Tnl/Cl 8/1 L2TP: Session FS enabled

20:47:35: Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel

20:47:35: As7 8/1 L2TP: Create session

20:47:35: Tnl 8 L2TP: SM State idle

20:47:35: Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply

20:47:35: Tnl 8 L2TP: SM State wait-ctl-reply

20:47:35: As7 VPDN: bum1@cisco.com is forwarded

20:47:35: Tnl 8 L2TP: Got a challenge from remote peer, nas1

20:47:35: Tnl 8 L2TP: Got a response from remote peer, nas1

20:47:35: Tnl 8 L2TP: Tunnel Authentication success

20:47:35: Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established

20:47:35: Tnl 8 L2TP: SM State established

20:47:35: As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply

20:47:35: As7 8/1 L2TP: Session state change from wait-reply to established

20:47:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up

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 5 describes the fields shown in the displays.

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

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 6 describes the significant fields shown in the displays.

Displaying L2TP Congestion Avoidance Settings

The following partial example of the debug vpdn l2x-events command is useful for monitoring a network running the L2TP Congestion Avoidance feature. The report shows that the congestion window (CWND) window has been reset to 1 because of packet retransmissions:

Router# debug vpdn l2x-events

.

.

.

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Congestion Control event received is retransmission

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Congestion Window size, Cwnd 1

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Slow Start threshold, Ssthresh 2

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Remote Window size, 500

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Control channel retransmit delay set to 4 seconds

*Jul 15 19:03:01.607:  Tnl 47100 L2TP: Update ns/nr, peer ns/nr 2/5, our ns/nr 5/2

The following partial example shows that traffic has been restarted with L2TP congestion avoidance throttling traffic:

Router# debug vpdn l2x-events

.

.

.

*Jul 15 14:45:16.123:  Tnl 30597 L2TP: Control channel retransmit delay set to 2 seconds

*Jul 15 14:45:16.123:  Tnl 30597 L2TP: Tunnel state change from idle to wait-ctl-reply

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Control event received is positive 
acknowledgement

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Window size, Cwnd 2

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Slow Start threshold, Ssthresh 500

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Remote Window size, 500

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Ctrl Mode is Slow Start

Table 7 briefly describes the significant fields shown in the displays. See RFC 2661 for more details about the information in the reports for L2TP congestion avoidance.

Debugging Errors on the NAS—L2F Error Conditions

The following is sample output from the debug vpdn error command on a NAS when the L2F tunnel is not set up:

Router# debug vpdn error

%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 8 describes the significant fields shown in the display.

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 9 describes the significant fields shown in the display.

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 10 describes the significant fields shown in the display.

Debugging an L2TPv3 Xconnect Session—Normal Operations

The following example shows output from the debug vpdn l2x-events 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 

 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

The following debug messages show control channel authentication failure events in Cisco IOS Release 12.0(31)S:

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

debug waas

To display debugging information about WAAS Express modules, use the debug waas command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug waas {auto-discovery | aoim | cce | dre | infrastructure | lz | memory | management | tfo} {events | errors | operations [brief]}

no debug waas {auto-discovery | aoim | cce | dre | infrastructure | lz | memory | management | tfo} {events | errors | operations [brief]}

Syntax Description

Command Default

Debugging information is not displayed.

Command Modes

Privileged EXEC (#)

Command History

Usage Guidelines

Use this command to display debugging information about WAAS Express.

Examples

The following example shows how to enable debugging output in brief for WAAS Express infrastructure operations:

Router> enable

Router# debug waas infrastructure operations brief

Related Commands

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 [0 | 7] password [hash {md5 | sha}]]

Syntax Description

Command Default

L2TPv3 control channel authentication and integrity checking are disabled by default.

Command Modes

L2TP class configuration

Command History

Usage Guidelines

Beginning in Cisco IOS Release 12.0(29)S, 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 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 11 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.

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

dscp (Frame Relay VC-bundle-member)

To configure the differentiated services code point (DSCP) levels for a Frame Relay permanent virtual circuit (PVC) bundle member, use the dscp command in Frame Relay VC-bundle-member configuration mode. To remove the DSCP level configuration from the PVC, use the no form of this command.

dscp {level | other}

no dscp level

Syntax Description

Command Default

DSCP levels are not configured.

Command Modes

Frame Relay VC-bundle-member configuration

Command History

Usage Guidelines

Assignment of DSCP levels to PVC bundle members lets you create differentiated service, because you can distribute the DSCP levels over the various PVC bundle members. You can map a single DSCP level or range of levels to each discrete PVC in the bundle, which enables PVCs in the bundle to carry packets marked with different DSCP levels.

Use the dscp other command to configure a PVC to carry traffic marked with DSCP levels not specifically configured on other PVCs. Only one PVC in the bundle can be configured with the dscp other command.

This command is available only when the match type for the PVC bundle is set to dscp by using the match dscp command in Frame Relay VC-bundle configuration mode.

You can overwrite the DSCP level configuration on a PVC by reentering the dscp command with a new level value.

There is no default value for this command. When the PVC bundle is set to dscp using the match dscp command, all PVCs in the bundle are reset to remove any existing DSCP values. If one or more DSCP values are not specifically configured, the bundle will not come up.

However, a PVC may exist in a bundle but have no DSCP value associated with the bundle. As long as all valid DSCP values are handled by one or more of the other PVCs in the bundle, the bundle can come up, but the PVC that has no DSCP value configured will not participate in the bundle.

A DSCP level can be configured on one PVC bundle member per bundle. If you configure the same DSCP level on more than one PVC within a bundle, the following error warning appears on the console:

%Overlapping diff-serv code points

Examples

The following example assigns DSCP levels 0 through 9 to PVC bundle member 300 in a Frame Relay PVC bundle named MP-3-static:

interface Serial4/0

 encapsulation frame-relay

 frame-relay vc-bundle MP-3-static

  match dscp

  pvc 300

   dscp 0-9

 frame-relay map ip 10.2.2.2 vc-bundle MP-3-static

The following example changes the DSCP levels in the above example from 0 through 9 to 0, 9, and 20 through 29:

interface serial 1/4

 frame-relay map ip 10.2.2.2 vc-bundle MP-3-static

 frame-relay vc-bundle MP-3-static

  match dscp

  pvc 300

   dscp 0,9,20-29

Related Commands

efci-bit

To set the explicit forward congestion indication (EFCI) bit field in the ATM cell header for FRF.8 service interworking, use the efci-bit command in FRF.8 connect mode. To disable or reset this bit, use the no form of this command.

efci-bit {0 | map-fecn}

no efci-bit {0 | map-fecn}

Syntax Description

Defaults

The default is 0.

Command Modes

FRF.8 connect configuration

Command History

Usage Guidelines

This command maps from Frame Relay to ATM.

Examples

The following example creates a connection that connects Frame Relay DLCI 100 to ATM PVC 0/32, and sets the EFCI field in the ATM cell header to 1 when the FECN field in the Frame Relay header is set:

Router(config)# interface atm1/0

Router(config-if)# pvc 0/32

Router(config-if)# encapsulation aal5mux fr-atm-srv

Router(config)# connect serial0 100 atm1/0 0/32 service-interworking

Router(config-frf8)# efci-bit map-fecn

Related Commands

encapsulation (Any Transport over MPLS)

To configure the ATM adaptation layer (AAL) encapsulation for an Any Transport over MPLS (AToM), use the encapsulation command in the appropriate configuration mode. To remove the ATM encapsulation, use the no form of this command.

encapsulation layer-type

no encapsulation layer-type

Syntax Description

Command Default

The default encapsulation is AAL5.

Command Modes

L2transport VC configuration—for ATM PVCs
VC class configuration—for VC class

Command History

Usage Guidelines

In L2transport VC configuration mode, the pvc command and the encapsulation command work together. Use the commands for AToM differently than for all other applications. Table 12 shows the differences in how the commands are used.

The following list highlights the differences:

•pvc command: For most applications, you create a permanent virtual circuit (PVC) by using the pvc vpi/vci command. For AToM, you must add the l2transport keyword to the pvc command. The l2transport keyword enables the PVC to transport Layer 2 packets.

•encapsulation command: The encapsulation command for AToM has only two keyword values: aal5 or aal0. You cannot specify an encapsulation type, such as aal5snap. In contrast, the encapsulation aal5 command you use for most other applications requires you to specify the encapsulation type, such as aal5snap.

•You cannot create switched virtual circuits or VC bundles to transport Layer 2 packets.

When you use the aal5 keyword, incoming cells (except Operation, Administration, and Maintenance [OAM] cells) on that PVC are treated as AAL5 encapsulated packets. The router reassembles the packet from the incoming cells. The router does not check the contents of the packet, so it does not need to know the encapsulation type (such as aal5snap and aal5mux). After imposing the Multiprotocol Label Switching (MPLS) label stack, the router sends the reassembled packet over the MPLS core network.

When you use the aal0 keyword, the router strips the header error control (HEC) byte from the cell header and adds the MPLS label stack. The router sends the cell over the MPLS core network.

Examples

The following example shows how to configure a PVC to transport ATM cell relay packets for AToM:

Router> enable

Router# configure terminal

Router(config)# interface atm1/0

Router(config-if)# pvc 1/100 l2transport

Router(config-if-atm-l2trans-pvc)# encapsulation aal0 

Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation mpls

The following example shows how to configure ATM AAL5 over MPLS in VC class configuration mode. The VC class is applied to a PVC.

Router> enable

Router# configure terminal

Router(config)# vc-class atm aal5class

Router(config-vc-class)# encapsulation aal5

Router(config)# interface atm1/0

Router(config-if)# pvc 1/200 l2transport

Router(config-if-atm-l2trans-pvc)# class-vc aal5class

Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation mpls

Related Commands

encapsulation (Frame Relay VC-bundle)

To override the encapsulation for a point-to-point subinterface and configure Frame Relay encapsulation for an individual Frame Relay permanent virtual circuit (PVC) bundle, use the encapsulation command in Frame Relay VC-bundle configuration mode. To disable the encapsulation for the individual PVC bundle and revert to the encapsulation for the point-to-point subinterface, use the no form of this command.

encapsulation [cisco | ietf]

no encapsulation [cisco | ietf]

Syntax Description

Defaults

Encapsulation type that is configured on the main interface.

Command Modes

Frame Relay VC-bundle configuration

Command History

Usage Guidelines

Use this command to override the encapsulation at a point-to-point subinterface for an individual Frame Relay PVC bundle. This command is available for point-to-point subinterfaces only; it cannot be used on multipoint interfaces.

Examples

The following example configures RFC 1490 encapsulation for the Frame Relay PVC bundle named "P2P-5":

interface serial 1/4.2 point-to-point

 ip address 10.1.1.1 255.0.0.0

 frame-relay vc-bundle P2P-5

  encapsulation ietf 

Related Commands

encapsulation (L2TP)

To specify the Layer 2 data encapsulation method to be used for tunneling IP traffic over a pseudowire, use the encapsulation (L2TP) command in pseudowire class configuration mode. To remove the specified Layer 2 encapsulation method, use the no form of this command.

encapsulation {l2tpv2 | l2tpv3 [manual] | mpls}

no encapsulation {l2tpv2 | l2tpv3 [manual] | mpls}

Syntax Description

Defaults

No encapsulation method is specified.

Command Modes

Pseudowire class configuration

Command History

Usage Guidelines

This command must be configured if the pseudowire class will be referenced from an xconnect or pseudowire configured to forward Layer 2 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

Related Commands

encapsulation (Layer 2 local switching)

To configure the ATM adaptation layer (AAL) for a Layer 2 local switching ATM permanent virtual circuit (PVC), use the encapsulation command in ATM PVC L2transport configuration mode. To remove an encapsulation from a PVC, use the no form of this command.

encapsulation layer-type

no encapsulation layer-type

Syntax Description

Command Default

If you do not create a PVC, one is created for you. The default encapsulation types for autoprovisioned PVCs are as follows:

•For ATM-to-ATM local switching, the default encapsulation type for the PVC is AAL0.

•For ATM-to-Ethernet or ATM-to-Frame Relay local switching, the default encapsulation type for the PVC is AAL5 SNAP.

Command Modes

ATM PVC L2transport configuration

Command History

Usage Guidelines

The pvc command and the encapsulation command work together. The use of these commands with Layer 2 local switching is slightly different from the use of these commands with other applications. The following list highlights the differences:

•For Layer 2 local switching, you must add the l2transport keyword to the pvc command. The l2transport keyword enables the PVC to transport Layer 2 packets.

•The Layer 2 local switching encapsulation command works only with the pvc command. You cannot create switched virtual circuits or VC bundles to transport Layer 2 packets. You can use only PVCs to transport Layer 2 packets.

Table 13 shows the encapsulation types supported for each transport type:

Examples

The following example shows how to configure a PVC to transport AAL0 packets for Layer 2 local switching:

pvc 1/100 l2transport

 encapsulation aal0 

Related Commands

encapsulation default

To configure the default service instance on a port, use the encapsulation default command in the service instance mode. To delete the default service instance on a port, use the no form of this command.

encapsulation default

no encapsulation default

Syntax Description

This command has no arguments or keywords.

Command Default

No default service instance is configured on the port.

Command Modes

Service instance

Command History

Usage Guidelines

If the default service instance is the only one configured on a port, the encapsulation default command matches all ingress frames on that port. If the default service instance is configured on a port that has other non-default service instances, the encapsulation default command matches frames that are unmatched by those non-default service instances (anything that does not meet the criteria of other services instances on the same physical interface falls into this service instance).

Only a single default service instance can be configured per interface. If you attempt to configure more than one default service instance per interface, the encapsulation default command is rejected.

Only one encapsulation command must be configured per service instance.

Examples

The following example shows how to configure a service instance on a port:

Router(config-if-srv)# encapsulation default

Related Commands

encapsulation dot1q (service instance)

To define the matching criteria to map 802.1Q frames ingress on an interface to the appropriate service instance, use the encapsulation dot1q command in the service instance mode. To delete the matching criteria to map 802.1Q frames ingress on an interface to the appropriate service instance, use the no form of this command.

encapsulation dot1q vlan-id[,vlan-id[-vlain-id]] [native]

no encapsulation dot1q vlan-id[,vlan-id[-vlain-id]] [native]

Syntax Description

.

Command Default

No matching criteria are defined.

Command Modes

Service instance

Command History

Usage Guidelines

The criteria for this command are: single VLAN, range of VLANs, and lists of the previous two.

A single 802.1Q service instance, allows one VLAN, multiple VLANs, or a range of VLANs. The native keyword can only be set if a single VLAN tag has been specified.

Only a single service instance per port is allowed to have the native keyword.

Only one encapsulation command may be configured per service instance.

Examples

The following example shows how to map 802.1Q frames ingress on an interface to the appropriate service instance:

Router(config-if-srv)# encapsulation dot1q 10

Related Commands

encapsulation dot1q second-dot1q

To define the matching criteria to map Q-in-Q ingress frames on an interface to the appropriate service instance, use the encapsulation dot1q second-dot1q command in service instance mode. To delete the matching criteria to map Q-in-Q ingress frames on an interface to the appropriate service instance, use the no form of this command.

encapsulation dot1q vlan-id second-dot1q {any | vlan-id[,vlan-id[-vlan-id]]}

no encapsulation dot1q vlan-id second-dot1q {any | vlan-id[,vlan-id[-vlan-id]]}

Syntax Description

Command Default

No matching criteria are defined.

Command Modes

Service instance

Command History

Usage Guidelines

The criteria for this command are: the outer tag must be unique and the inner tag may be a single VLAN, a range of VLANs or lists of the previous two.

QinQ service instance, allows single, multiple or range on second-dot1q.

Only one encapsulation command must be configured per service instance.

Examples

The following example shows how to map ingress frames to a service instance:

Router(config-if-srv)# encapsulation dot1q second-dot1q 20

Related Commands

encapsulation frame-relay

To enable Frame Relay encapsulation, use the encapsulation frame-relay command in interface configuration mode. To disable Frame Relay encapsulation, use the no form of this command.

encapsulation frame-relay [cisco | ietf]

no encapsulation frame-relay [ietf]

Syntax Description

Defaults

The default is Cisco's own encapsulation.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use this command with no keywords to restore the default Cisco encapsulation, which is a 4-byte header with 2 bytes for the DLCI and 2 bytes to identify the packet type.

You should shut down the interface prior to changing encapsulation types. Although this is not required, shutting down the interface ensures that the interface is reset for the new encapsulation.

Examples

The following example configures Cisco Frame Relay encapsulation on interface serial 1:

interface serial 1

 encapsulation frame-relay

Use the ietf keyword if your router or access server is connected to another vendor's equipment across a Frame Relay network to conform with RFC 1490:

interface serial 1

 encapsulation frame-relay ietf

encapsulation frame-relay mfr

To create a multilink Frame Relay (MFR) bundle link and to associate the link with a bundle, use the encapsulation frame-relay mfr command in interface configuration mode. To remove the bundle link from the bundle, use the no form of this command.

encapsulation frame-relay mfr number [name]

no encapsulation frame-relay mfr number [name]

Syntax Description

Command Default

Frame Relay encapsulation is not enabled.

Command Modes

Interface configuration (config-if)

Command History

Usage Guidelines

Use the name argument to assign a LID name to a bundle link. This name will be used to identify the bundle link to peer devices and to enable the devices to determine which bundle links are associated with which bundles. The LID name can also be assigned or changed by using the frame-relay multilink lid command on the bundle link interface. If the LID name is not assigned, the default name is the name of the physical interface.

Tips To minimize latency that results from the arrival order of packets, we recommend bundling physical links of the same line speed in one bundle.

To remove a bundle link from a bundle, use the no encapsulation frame-relay mfr command or configure a new type of encapsulation on the interface by using the encapsulation command.

Examples

The following example shows serial interface 0 being associated as a bundle link with bundle interface "MFR0." The bundle link identification name is "BL1."

interface MFR0

!

interface serial 0

 encapsulation frame-relay MFR0 BL1

Related Commands

encapsulation l2tpv3

To specify that Layer 2 Tunnel Protocol Version 3 (L2TPv3) is used as the data encapsulation method for tunneling IP traffic over the pseudowire, use the encapsulation l2tpv3 command in pseudowire class or VC class configuration mode. To remove L2TPv3 as the encapsulation method, use the no pseudowire-class command (see the Usage Guidelines for more information).

encapsulation l2tpv3

no pseudowire-class

Syntax Description

This command has no arguments or keywords.

Command Default

No encapsulation method is specified.

Command Modes

Pseudowire class configuration
VC class configuration

Command History

Usage Guidelines

This command must be configured if the pseudowire class will be referenced from an Xconnect configured to forward L2TPv3 traffic.

Once you specify the encapsulation l2tpv3 command, you cannot remove it using the no encapsulation l2tpv3 command. Nor can you change the command's setting using the encapsulation mpls command. Those methods result in the following error message:

Encapsulation changes are not allowed on an existing pw-class.  

To remove the command, you must delete the pseudowire with the no pseudowire-class command. To change the type of encapsulation, remove the pseudowire with the no pseudowire-class command and re-establish the pseudowire and specify the new encapsulation type.

Examples

The following example shows how to configure L2TPv3 as the data encapsulation method for the pseudowire class named ether-pw:

Router(config)# pseudowire-class ether-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

encapsulation lapb

To exchange datagrams over a serial interface using Link Access Procedure, Balanced (LAPB) encapsulation, use the encapsulation lapb command in interface configuration mode.

encapsulation lapb [dte | dce] [multi | protocol]

Syntax Description

Defaults

The default serial encapsulation is High-Level Data Link Control (HDLC). You must explicitly configure a LAPB encapsulation method.

DTE operation is the default LAPB mode. IP is the default protocol.

Command Modes

Interface configuration

Command History

Usage Guidelines

LAPB encapsulations are appropriate only for private connections, where you have complete control over both ends of the link. Connections to X.25 networks should use an X.25 encapsulation configuration, which operates the X.25 Layer 3 protocol above a LAPB Layer 2.

One end of the link must be a logical DCE device, and the other end a logical DTE device. (This assignment is independent of the interface's hardware DTE or DCE identity.)

Both ends of the LAPB link must specify the same protocol encapsulation.

LAPB encapsulation is supported on serial lines configured for dial-on-demand routing (DDR). It can be configured on DDR synchronous serial and ISDN interfaces and on DDR dialer rotary groups. It is not supported on asynchronous dialer interfaces.

A single-protocol LAPB encapsulation exchanges datagrams of the given protocol, each in a separate LAPB information frame. You must configure the interface with the protocol-specific parameters needed—for example, a link that carries IP traffic will have an IP address defined for the interface.

A multiprotocol LAPB encapsulation can exchange any or all of the protocols allowed for a LAPB interface. It exchanges datagrams, each in a separate LAPB information frame. Two bytes of protocol identification data precede the protocol data. You need to configure the interface with all the protocol-specific parameters needed for each protocol carried.

Multiprotocol LAPB encapsulation supports transparent bridging. This feature requires use of the encapsulation lapb multi command followed by the bridge-group command, which identifies the bridge group associated with multiprotocol LAPB encapsulation. This feature does not support use of the encapsulation lapb protocol command with a bridge keyword.

LAPB encapsulation supports the priority and custom queueing features.

Examples

The following example sets the operating mode as DTE and specifies that AppleTalk protocol traffic will be carried on the LAPB line:

interface serial 1

 encapsulation lapb dte appletalk

Related Commands

encapsulation smds

To enable Switched Multimegabit Data Service (SMDS) on the desired interface, use the encapsulation smds interface configuration command.

encapsulation smds

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Interface configuration

Command History

Usage Guidelines

The interface to which this command applies must be a serial interface. All subsequent SMDS configuration commands apply only to an interface with encapsulation SMDS.

Note The maximum packet size allowed in the SMDS specifications (TA-772) is 9188. This is larger than the packet size used by servers with most media. The Cisco default maximum transmission unit (MTU) size is 1500 bytes to be consistent with Ethernet. However, on the High Speed Serial Interface (HSSI), the default MTU size is 4470 bytes. If a larger MTU is used, the mtu command must be entered before the encapsulation smds command.

Caution The Cisco MCI card has buffer limitations that prevent setting the MTU size higher than 2048, and the HSSI card has buffer limitations that prevent setting the MTU size higher than 4500. Configuring higher settings can cause inconsistencies and performance problems.

Examples

The following example shows how to configure the SMDS service on serial interface 0:

interface serial 0

 encapsulation smds

Related Commands

encapsulation untagged

To define the matching criteria to map untagged ingress Ethernet frames on an interface to the appropriate service instance, use the encapsulation untagged command in the service instance mode. To delete the matching criteria to map untagged ingress Ethernet frames on an interface to the appropriate service instance, use the no form of this command.

encapsulation untagged

no encapsulation untagged

Syntax Description

This command has no arguments or keywords.

Command Default

No matching criteria are defined.

Command Modes

Service instance mode

Command History

Usage Guidelines

Only one service instance per port is allowed to have untagged encapsulation. The reason is to be able to unambiguously map the incoming frames to the service instance. However, it is possible for a port that hosts an service instance matching untagged traffic to host other service instances that match tagged frames.

Only one encapsulation command may be configured per service instance.

Examples

The following example shows how to map untagged ingress Ethernet frames to a service instance:

Router(config-if-srv)# encapsulation untagged

Related Commands

encapsulation x25

To specify a serial interface's operation as an X.25 device, use the encapsulation x25 command in interface configuration mode. To remove the specification, use the no form of this command.

encapsulation x25 [dte | dce] [ddn | bfe | ietf]

no encapsulation x25 [dte | dce] [ddn | bfe | ietf]

Syntax Description

Defaults

The default serial encapsulation is High-Level Data Link Control (HDLC). You must explicitly configure an X.25 encapsulation method.

DTE operation is the default X.25 mode. Cisco's traditional X.25 encapsulation method is the default.

Command Modes

Interface configuration

Command History

Usage Guidelines

One end of an X.25 link must be a logical DCE device and the other end a logical DTE device. (This assignment is independent of the interface's hardware DTE or DCE identity.) Typically, when connecting to a public data network (PDN), the customer equipment acts as the DTE device and the PDN attachment acts as the DCE.

Cisco has long supported the encapsulation of a number of datagram protocols, using a standard means when available and a proprietary means when necessary. The IETF adopted a standard, RFC 1356, for encapsulating most types of datagram traffic over X.25. X.25 interfaces use Cisco's traditional method unless explicitly configured for IETF operation; if the ietf keyword is specified, that standard is used unless Cisco's traditional method is explicitly configured. For details see the x25 map command.

You can configure a router attaching to the DDN or to a BFE device to use their respective algorithms to convert between IP and X.121 addresses by using the ddn or bfe option, respectively. An IP address must be assigned to the interface, from which the algorithm will generate the interface's X.121 address. For proper operation, this X.121 address must not be modified.

A router DDN attachment can operate as either a DTE or a DCE device. A BFE attachment can operate only as a DTE device. The ietf option is not available if either the ddn or bfe option is selected.

Examples

The following example configures the interface for connection to a BFE device:

interface serial 0

 encapsulation x25 bfe

Related Commands

ethernet evc

To define an Ethernet virtual connection (EVC) and to enter EVC configuration mode, use the ethernet evc command in global configuration mode. To delete the EVC, use the no form of this command.

ethernet evc evc-id

no ethernet evc evc-id

Syntax Description

Command Default

No EVCs are defined.

Command Modes

Global configuration

Command History

Usage Guidelines

After you enter the ethernet evc command, the device enters EVC configuration mode and the following configuration commands are available:

•default—Sets the EVC to its default states.

•exit—Exits EVC configuration mode and returns the CLI to global configuration mode.

•no—Negates a command or returns a command to its default setting.

•oam protocol—Configures the Ethernet operations, administration, and maintenance (OAM) protocol and sets parameters.

•uni count—Configures a UNI count for the EVC.

Examples

The following example shows how to define an EVC named test1 and to enter EVC configuration mode:

Router(config)# ethernet evc test1

Router(config-evc)# 

Related Commands

exp

To configure Multiprotocol Label Switching (MPLS) experimental (EXP) levels for a Frame Relay permanent virtual circuit (PVC) bundle member, use the exp command in Frame Relay VC-bundle-member configuration mode. To remove the EXP level configuration from the PVC, use the no form of this command.

exp {level | other}

no exp

Syntax Description

Defaults

EXP levels are not configured.

Command Modes

Frame Relay VC-bundle-member configuration

Command History

Usage Guidelines

Assignment of MPLS EXP levels to Frame Relay PVC bundle members lets you create differentiated services, because you can distribute the levels over the various PVC bundle members. You can map a single level or a range of levels to each discrete PVC in the bundle, which enables PVCs in the bundle to carry packets marked with different levels.

Use the exp other command to indicate that a PVC can carry traffic marked with EXP levels not specifically configured for other PVCs. Only one PVC in the bundle can be configured using the exp other command.

All EXP levels must be accounted for in the PVC bundle configuration, or the bundle will not come up. However, a PVC can be a bundle member but have no EXP level associated with it. As long as all valid EXP levels are handled by other PVCs in the bundle, the bundle can come up, but the PVC that has no EXP level configured will not participate in it.

The exp command is available only when MPLS is configured on the interface with the mpls ip command.

You can overwrite the EXP level configuration on a PVC by reentering the exp command with a new value.

The MPLS experimental bits are a bit-by-bit copy of the IP precedence bits. When Frame Relay PVC bundles are configured for IP precedence and MPLS is enabled, the precedence command is replaced by the exp command. When MPLS is disabled, the exp command is replaced by the precedence command.

Examples

The following example shows the configuration of four Frame Relay PVC bundle members in PVC bundle bundle1 configured with MPLS EXP level support:

interface serial 0.1 point-to-point

 encapsulation frame-relay

 ip address 10.1.1.1

 mpls ip

 frame-relay vc-bundle bundle1

 pvc 100 ny-control

 class control

 exp 7

 protect vc

 pvc 101 ny-premium

 class premium

 exp 6-5

 protect group

 no bump traffic

 bump explicit 7

 pvc 102 my-priority

 class priority

 exp 4-2

 protect group