Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Figure 12-8. WAN Protocols over IP Case Study Topology

[View full size image]

Figure 12-9. HDLCoL2Tv3 Static Session Case Study Topology

[View full size image]

Figure 12-10. PPPoL2TPv3 Dynamic Session Case Study Topology

[View full size image]

Figure 12-11. L2TPv3 Control Connection (Tunnel) Establishment

[View full size image]

Figure 12-12. L2TPv3 Session Establishment

Table 12-1).

End Identifier 60 This is the VC ID configured.

Sequencing Required This indicates that sequencing for the pseudowire is on.

ICRP In the second part of the three-way handshake, the SanFran PE sends an Incoming-Call-Reply (ICRP) message to the NewYork PE, and the session state machine advances to the wait-connect state. This message includes SanFran's local session ID of 54459.

ICCN In the third part of the three-way handshake, the SanFran PE receives an Incoming-Call-Connected (ICCN) message from the NewYork PE, and the session state moves to established.

From the debug output and Figure 12-12, you can track the Ns and Nr values. Ns is always set to the previous Ns sent plus 1. For example, an ICRQ sent from NewYork contains Ns 2, and an ICCN sent from NewYork contains Ns 3. Nr is always set to the previous Ns received plus 1. For example, an ICRQ received in SanFran contains Ns 2, and an ICRP sent from SanFran contains Nr 3.

Data Plane Details

This section discusses some data plane details, such as encapsulation, imposition and disposition actions, and a data plane packet decode. You first see the PPPoL2TPv3 encapsulation details from the SanFran PE using the show sss circuits CLI command (see Example 12-19).

Example 12-19. PPPoL2TPv3 Encapsulation Details from SanFran

SanFran#show sss circuits
Current SSS Circuit Information: Total number of circuits 2
Common Circuit ID 0             Serial Num 2          Switch ID 18797112
---------------------------------------------------------------------------
Status  Encapsulation
UP flg  len dump
Y  AES  2   FF03 
Y  AES  32  45000000 00000000 FF73A5F7 0A0000C9 0A0000CB 
0000CA7D 9B16165E 00000000 
SanFran#

From Example 12-19, observe that the encapsulation of PPP frames into the tunnel is 32 bytes long, consisting of the following:

Delivery (IPv4) header This is the 20-byte IP header indicating IP protocol 115 (0x73) for L2TPv3.

L2TPv3 Session Header This is 8 bytes, including the following:

Remote Session ID 4 bytes equal to 0x0000CA7D or 51837. You can see this in Example 12-13 in the show l2tun command output, in addition to Example 12-18 debug output as rsid 51837.

Remote Cookie 4 bytes equal to 0x9B16165E. You can see this value in Example 12-15 in the output of the command show l2tun session all vcid 60 displaying session details, and in Example 12-18 debug output as the Assigned Cookie value in the Cisco AVP 5 in the ICRQ message that SanFran received.

L2-Specific Sublayer The Default L2-Specific Sublayer is used because sequencing has been configured. The show sss circuit command displays the 4 bytes as NULL and fills in the bytes for each packet with the appropriate value.

In Example 12-19, the PPP header address (0xFF) and control (0x03) fields are removed at imposition. Toward the attachment circuit, the encapsulation is 2 bytes long. It includes the following two fields that were removed at imposition and need to be prepended at disposition:

PPP Address 1 byte equal to 0xFF.

PPP Control 1 byte equal to 0x03.

To see the encapsulation in action, Example 12-20 captures two packets from the ping messages in Example 12-16. Use the two debug commands: debug vpdn packet and debug vpdn packet detail. The former one provides packet summary information, whereas the latter one displays a hexadecimal dump of the first bytes of the packet (see Example 12-20).

Example 12-20. Capturing and Decoding PPPoL2TPv3 Packets

SanFran#
00:17:15: L2TP:(Tnl0:Sn54459):FS/CEF Into tunnel (SSS): Sending pak
00:17:15: L2TP:(Tnl0:Sn54459):FS/CEF Into tunnel: Sending 134 byte pak      
contiguous pak, size 134
         45 00 00 86 01 D7 00 00 FF 73 A3 9A 0A 00 00 C9                    
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
IPv4 Delivery Header (IP protocol L2TPv3)
         0A 00 00 CB 00 00 CA 7D 9B 16 16 5E 40 00 00 A0                    
...^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^
IPv4 Delivery Header Rem. Sess Id Rem. Cookie L2-Specific Sublayer
^^^^^^^^^^^^^^^^^^^^^^^  S (Sequence flag) = 1
L2TP Session Header      Sequence Number = 160 (0xA0)
00 21 45 00 00 64 00 05 00 00 FF 01 70 3F C0 A8
^^^^^ ^^^^^...
|     Begins IP Packet
         PPP DLL Protocol Number - 0x0021 (IPv4)
65 01 C0 A8 65 02 08 00 9B 51 00 01 00 00 00 00
00 00 00 0F E2 E8 AB CD ...
00:17:15: L2TP:(Tnl0:Sn54459):CEF Into tunnel (SSS): Pak send successful
00:17:15: L2X:CEF From tunnel: Received 138 byte pak                        
contiguous pak, size 138
         0F 00 08 00 45 00 00 86 01 AC 00 00 FD 73 A5 C5                    
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
HDLC L2 IPv4 Delivery Header (IP protocol L2TPv3)
         0A 00 00 CB 0A 00 00 C9 00 00 D4 BB 5B AD 54 4D                    
...^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^
IPv4 Delivery Header Loc.Sess Id Cookie (Local)
^^^^^^^^^^^^^^^^^^^^^^^
L2TP Session Header
         40 00 00 A1 00 21 45 00 00 64 00 05 00 00 FF 01
^^^^^^^^^^^ ^^^^^ ^^^^^...
|           |     Begins IP Packet
         |           PPP DLL Protocol Number - 0x0021 (IPv4)
         L2-Specific Sublayer: S = 1; Sequence Number = 161 (0xA1)
70 3F C0 A8 65 02 C0 A8 65 01 00 00 A3 51 00 01
00 00 00 00 00 00 00 0F ...
00:17:15: L2TP:(Tnl0:Sn54459):CEF From tunnel: Pak send successful

Example 12-20 shows two packets captured in the SanFran PE. The highlighted portion of the hexadecimal dump indicates the overhead added to the PPP frames that are transported. The first packet labeled "Into tunnel" is an ICMP Echo that SanFran receives from Oakland and forwards into the L2TPv3 tunnel toward New York. The second packet labeled "From tunnel" is the ICMP Echo Reply received from Denver P and forwarded to Oakland CE. As before, the imposition packets (that is, the "Into tunnel" packets) display the IPv4 and L2TPv3 headers plus the PPP payload, whereas the disposition packets (that is, the "From Tunnel" packets) also include the data link layer header (HDLC in the case of the SanFran PE to the Denver P link).

The L2TPv3 portion of the first packet contains the following fields:

Layer 2 Tunneling Protocol version 3

Session ID: 51837

Cookie: 9B16165E

Default L2-Specific Sublayer

.1.. .... = S-bit: True

Sequence Number: 160

You can see that the payload contains part of the PPP frame, including the following:

PPP DLL Protocol Number 0x0021 for IPv4.

IPv4 Packet The PPP payload is the CE's IPv4 packet containing the ICMP Echo request.

However, the payload excludes the following:

Address 0xFF

Control 0x03

As shown in Example 12-19, the Address and Control fields with combined values of 0xFF03 are appended as a disposition encapsulation before the packet is forwarded onto the CE, and so are the 0x7E flag and recalculated FCS.

Case Study 12-3: Frame Relay DLCI over L2TPv3 with Dynamic Session

This case study covers the configuration and verification required to tunnel Frame Relay PVCs over L2TPv3. You learned a way to configure Frame Relay transport port-to-port using HDLCoL2TPv3 in Case Study 12-1. This case study deals with the DLCI-to-DLCI mode of FRoL2TPv3. Only two octet Frame Relay headers (that is, 10-bit DLCI) are supported in DLCI-to-DLCI mode. A requirement for 4-octet Frame Relay headers (that is, 23-bit DLCI) can be accommodated only in port mode using HDLCoL2TPv3. Cisco routers do not support Frame Relay extended addressing with 23-bit DLCIs as CE devices. The topology is shown in Figure 12-13.

You will be using different DLCIs at both ends to observe the DLCI rewrite.

Configuring FRoL2TPv3

The configuration for FRoL2TPv3 is slightly different from the other case studies. This is the first case in which the attachment circuit is a virtual circuit as opposed to an interface. The configuration of an attachment circuit in a PVC as opposed to an interface is accomplished by executing the xconnect command under a connect and not under the interface. In fact, after you set the encapsulation to frame-relay in a Serial or Packet over SONET (POS) interface, the interface no longer accepts the xconnect command. The attachment circuit occurs by creating the l2transport endpoint with the connect configuration command. This effectively generates a switched DLCI under the main interface with DLCI specified in the connect command. You can configure the switched DLCI by using the frame-relay interface-dlci command with the switched keyword.

This is also the first case study in which signaling messaging between PE and CE takes place. In particular, Frame Relay LMI runs on the links between PE and CE, providing a link keepalive mechanism and PVC status exchange. To achieve this, you configure the PE interfaces as Frame Relay LMI DCE after you enable the frame-relay switching command.

The configuration for the SanFran PE is included in Example 12-21.

Example 12-21. Configuring the Frame Relay DLCI over the L2TPv3 PE

!
hostname SanFran
!
frame-relay switching                            
l2tp-class l2tpv3-wan 
authentication
password 0 cisco
cookie size 4
!
pseudowire-class wan-l2tpv3-pw 
encapsulation l2tpv3
protocol l2tpv3 l2tpv3-wan
ip local interface Loopback0
!
interface Serial7/0
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
connect l2tpv3-fr-dlci Serial7/0 100 l2transport 
 xconnect 10.0.0.203 70 pw-class wan-l2tpv3-pw   
!
!

Note

Configuring the xconnect statement under a connect as opposed to under a new subinterface saves memory and enhances the scalability of DLCI-to-DLCI mode by not requiring a Cisco IOS Software interface descriptor block (IDB) for each attachment circuit pseudowire in the PE device. The same is true for ATM PVC and permanent virtual path (PVP) modes by configuring the xconnect command under the PVC and PVP configuration mode, respectively. That assumes that the PVC or PVP are on the main interface, but it is not true for VLAN transport, in which a new subinterface is needed for each VLAN.

The CE configuration is included in Example 12-22. It does not differ if the Oakland CE is connected to a traditional Frame Relay switch.

Example 12-22. Configuring the Frame Relay DLCI over the L2TPv3 CE

!
hostname Oakland
!
interface Serial7/0
no ip address
encapsulation frame-relay
!
interface Serial7/0.1 point-to-point 
ip address 192.168.102.1 255.255.255.252
 frame-relay interface-dlci 100             
!

Verifying FRoL2TPv3

For the Frame Relay DLCI over L2TPv3 (FR_DLCIoL2TPv3) verification, first check the connection in the SanFran PE (see Example 12-23).

Example 12-23. Verifying the FR_DLCIoL2TPv3 Connection

SanFran#show connection
ID   Name            Segment 1              Segment 2               State
===========================================================================
1    l2tpv3-fr-dlci  Se7/0 100              10.0.0.203 70           UP      
SanFran#show connection name l2tpv3-fr-dlci
FR/Pseudo-Wire Connection: 1 - l2tpv3-fr-dlci
Status - UP
  Segment 1 - Serial7/0 DLCI 100                                            
Segment status: UP
Line status: UP
PVC status: ACTIVE
NNI PVC status: ACTIVE
  Segment 2 - 10.0.0.203 70                                                 
Segment status: UP
Requested AC state: UP
PVC status: ACTIVE
NNI PVC status: ACTIVE
SanFran#

You can display the two connection segments or endpoints by using the show connection command. The first segment is the attachment circuit, and the second segment is the pseudowire remote endpoint identified by peer IPv4 address and VC ID. You can see that all respective statuses and states are ACTIVE and UP.

Next, you can verify the switched DLCI created in the PE devices by using the connect command (see Example 12-24).

Example 12-24. Verifying FR_DLCIoL2TPv3 DLCI

SanFran#show frame-relay pvc summary
Frame-Relay VC Summary
Active     Inactive     Deleted     Static
Local          0            0           0          0
Switched       1            0           0          0
Unused         0            0           0          0
SanFran#
SanFran#show frame-relay pvc 100
PVC Statistics for interface Serial7/0 (Frame Relay DCE)
DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial7/0  
input pkts 335           output pkts 335          in bytes 119650
out bytes 119320         dropped pkts 0           in FECN pkts 0
in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
in DE pkts 0             out DE pkts 0
out bcast pkts 0         out bcast bytes 0
switched pkts 335 
Detailed packet drop counters:
no out intf 0            out intf down 0          no out PVC 0
in PVC down 0            out PVC down 0           pkt too big 0
pvc create time 05:29:16, last time pvc status changed 05:27:13
SanFran#

In Example 12-24 using the summary keyword, you can see that one switched DLCI is in the active state. Using the DLCI of 100, the command displays Frame Relay PVC details, which enables you to see that the DLCI with switched usage is created in the main interface Serial 7/0. The rest of the command output includes comprehensive PVC counters.

The next step is to verify the FR_DLCIoL2TPv3 session. You use the same command, show l2tun session, introducing the brief keyword (see Example 12-25).

Example 12-25. Verifying the FR_DLCIoL2TPv3 Session

SanFran#show l2tun session brief
Session Information Total tunnels 1 sessions 3
Tunnel control packets dropped due to failed digest 0
LocID      TunID      Peer-address    State     Username, Intf/
sess/cir  Vcid, Circuit
54459      61936      10.0.0.203      est,UP    60, Se6/0
54467      61936      10.0.0.203      est,UP    70, Se7/0:100    
221        0          10.0.0.203      est,UP    50, Se5/0
SanFran#

You can see that the session is established, the circuit is UP, and it is displayed as Se7/0:100 because the attachment circuit is now the logical connection with DLCI 100 in interface Serial 7/0. The details of the L2TPv3 session are shown in Example 12-26.

Example 12-26. FR_DLCIoL2TPv3 Session Details

SanFran#show l2tun session all vcid 70
Session Information Total tunnels 1 sessions 3
Tunnel control packets dropped due to failed digest 0
Session id 54467 is up, tunnel id 61936                               
Call serial number is 3084400001
Remote tunnel name is New York
Internet address is 10.0.0.203
  Session is L2TP signalled                                            
 Session state is established, time since change 22:37:10
1365 Packets sent, 1365 received
491480 Bytes sent, 490120 received
Receive packets dropped:
out-of-order:             0
total:                    0
Send packets dropped:
exceeded session MTU:     0
total:                    0
  Session vcid is 70                                                   
  Session Layer 2 circuit, type is Frame Relay, name is Serial7/0:100  
Circuit state is UP
Remote session id is 51845, remote tunnel id 64821
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
  Session cookie information:                                         
    local cookie, size 4 bytes, value 58 47 4E 42                     
    remote cookie, size 4 bytes, value E6 FC CF 51                    
FS cached header information:
    encap size = 28 bytes                                             
00000000 00000000 00000000 00000000
00000000 00000000 00000000
Sequencing is off
SanFran#

You can see all the details of the session in Table 12-1.

Finally, you can test connectivity from the Oakland CE, highlighting successful pings (see Example 12-27).

Example 12-27. FR_DLCIoL2TPv3 Checking Connectivity from the CEs

Oakland#ping 192.168.102.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.102.2, timeout is 2 seconds:
!!!!!                                                                  
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/36 ms
Oakland#

Data Plane Details

To conclude the FRoL2TPv3 case study, this section explains FRoL2TPv3 data plane encapsulation details by capturing and decoding FRoL2TPv3 packets. However, before the actual packet decoding, you learn the details of the Frame Relay Q.922 encoding and its values as it pertain to this case study.

Figure 12-5 in a reorganized format. It also calculates the Q.922 header value for the two DLCI values used in this case studynamely 100 and 101.

From Figure 12-14, you can see that if the C/R, FECN, BECN, and DE bits are set to 0, the value for the Q.922 header with DLCI 100 is 0x1841. The value for the Frame Relay header with DLCI 101 is 0x1851. This is achieved by expressing the DLCI value as a 10-bit binary number and dragging the DLCI High and DLCI Low fields into their respective positions in the header.

You are now ready to capture FRoL2TPv3 packets from the ping shown in Example 12-27. To accomplish this capture, you use the commands debug vpdn packet and debug vpdn packet detail (see Example 12-28).

Example 12-28. Capturing and Decoding FR_DLCIoL2TPv3 Packets

SanFran#
*Jun 28 19:07:17.405: L2TP:(Tnl0:Sn54467):FS Into tunnel (SSS): Sending pak
*Jun 28 19:07:17.405: L2TP:(Tnl0:Sn54467):FS/CEF Into tunnel: Sending 132 byte pak   
contiguous pak, size 132
         45 00 00 84 1A 20 00 00 FF 73 8B 53 0A 00 00 C9                             
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
IPv4 Delivery Header (IP protocol L2TPv3)
0A 00 00 CB 00 00 CA 85 E6 FC CF 51 18 41 08 00
...^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^ ^^^^^
IPv4 Delivery Header Rem.Sess Id Rem. Cookie |     etype = IPv4
                     ^^^^^^^^^^^^^^^^^^^^^^^ Q.922 Header
                     L2TP Session Header     DLCI = 100
45 00 00 64 00 27 00 00 FF 01 6E 1D C0 A8 66 01
^^^^^...
Begins IP Packet
C0 A8 66 02 08 00 47 A0 00 07 00 04 00 00 00 00
09 07 2D 98 AB CD AB CD ...
*Jun 28 19:07:17.405: L2TP:(Tnl0:Sn54467):CEF Into tunnel (SSS): Pak send successful
*Jun 28 19:07:17.437: L2X:CEF From tunnel: Received 136 byte pak                     
contiguous pak, size 136
         0F 00 08 00 45 00 00 84 19 ED 00 00 FD 73 8D 86                             
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
HDLC L2     IPv4 Delivery Header (IP protocol L2TPv3)
         0A 00 00 CB 0A 00 00 C9 00 00 D4 C3 58 47 4E 42                             
...^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^
IPv4 Delivery Header Session Id Cookie (Local)
                                 ^^^^^^^^^^^^^^^^^^^^^^^
                                 L2TP Session Header
18 51 08 00 45 00 00 64 00 27 00 00 FF 01 6E 1D
^^^^^ ^^^^^ ^^^^^...
|     |     Begins IP Packet
         |     etype = IPv4
         Q.922 Header: DLCI = 101
C0 A8 66 02 C0 A8 66 01 00 00 4F A0 00 07 00 04
00 00 00 00 09 07 2D 98 ...
*Jun 28 19:07:17.437: L2TP:(Tnl0:Sn54467):CEF From tunnel: Pak send successful
SanFran#

In Example 12-28, you can see two FRoL2TPv3 packets captured in the SanFran PE. The portion highlighted in the hexadecimal dump corresponds to the overhead added to the Frame Relay frames that are being transported.

Similarly to previous examples, the first packet labeled "Into tunnel" is an ICMP Echo that SanFran receives from Oakland and forwards to the L2TPv3 tunnel toward New York. The second packet labeled "From tunnel" is the ICMP Echo Reply that the Denver P receives and forwards to the Oakland CE. The imposition packet that is sent into the tunnel displays the IPv4 and L2TPv3 headers. In contrast, the disposition packet that is coming from the tunnel and is later sent out of the attachment circuit also includes the data link layer header, IPv4, and L2TPv3.

The L2TPv3 portion of the first packet contains the following fields:

Session ID: 51845

Cookie: E6FCCF51

You can see that the payload corresponds to the complete Frame Relay frames that in turn carry IPv4 traffic, containing the following:

Q.922 Header 2 bytes, including the following:

DLCI 10 bits with a value of 100 (Higher DLCI: 0x06; Lower DLCI: 0x04)

C/R 1 bit with a value of 0

BECN 1 bit with a value of 0

FECN 1 bit with a value of 0

DE 1 bit with a value of 0

EA Bits 2 bits with value of 0 for the first octet and 1 for the second octet.

Ethertype 0x0800 indicating IPv4

IPv4 Packet The IP packet from the CE being transported inside the Frame Relay encapsulation

Because you did not specify IETF Frame Relay encapsulation in the CE devices Oakland and Albany, the default of Cisco Frame Relay encapsulation is used (refer to Figure 12-5). The Ethertype is used as the upper-layer protocol identifier.

In the first packet sent out of SanFran toward New York, the Q.922 header equals 0x1841, indicating DLCI 100. The DLCI field is rewritten to 101 before the Frame Relay frame is sent out of the New York PE toward the Albany CE. In contrast, in the second packet received in the SanFran PE from the Denver P, the Q.922 header is 0x1851, designating a DLCI of 101 that the New York PE received from the Albany CE. The SanFran PE rewrites this DLCI field to a value of 100 before sending the frame to the Oakland CE.

Case Study 12-4: AAL5 SDU over L2TPv3 with Dynamic Session

Chapter 13, "Advanced L2TPv3 Case Studies," the implication of using different VPI/VCI pairs with AAL5 SDU mode is that you cannot transport OAM cells over the pseudowire, and you need to use OAM emulation.

Configuring AAL5_SDUoL2TPv3 with Dynamic Session

The configuration steps are similar to the ones from previous case studies. You apply the xconnect command under the L2transport ATM PVC configuration mode. To specify the AAL5 SDU mode of tunneling and transport, configure the encapsulation as aal5 (see Example 12-29).

Example 12-29. Configuring AAL5_SDUoL2TPv3 in the SanFran PE

!
hostname SanFran
!
pseudowire-class pw-l2tpv3-atm
encapsulation l2tpv3
ip local interface Loopback0
!
!
interface ATM5/0
no ip address
 pvc 0/100 l2transport                           
  encapsulation aal5                             
  xconnect 10.0.0.203 27 pw-class pw-l2tpv3-atm  
!
!

Example 12-29 uses the default l2tp-class (l2tp_default_class), which means no authentication and no cookie. However, because you are using AAL5 mode, the ATM-Specific Sublayer is mandatory.

Example 12-30 shows the normal configuration of the CE device from the Oakland CE. OAM management is disabled.

Example 12-30. Configuring the Oakland CE for the ATM PVC

!
hostname Oakland
!
interface ATM6/0.1 point-to-point
ip address 192.168.103.1 255.255.255.252
pvc 0/100
oam-pvc 0
encapsulation aal5snap
!
!

The configuration in the New York PE and the Albany CE is analogous to Examples 12-29 and 12-30, respectively.

Verifying AAL5_SDUoL2TPv3

To verify the status of the tunneling and transport of AAL5 SDU frames over L2TPv3, confirm the l2tun session using the summary and detailed versions of the show command (see Example 12-31).

Example 12-31. Verifying the AAL5_SDUoL2TPv3 Session

SanFran#show l2tun session
Tunnel and Session Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
LocID      RemID      TunID      Username, Intf/                         State
Vcid, Circuit
43729      28232       23520     27, AT5/0:0/100                         est   
SanFran#
SanFran#show l2tun session all
Session Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
Session id 43729 is up, tunnel id 23520                                        
Call serial number is 2763400000
Remote tunnel name is New York                                                 
Internet address is 10.0.0.203
  Session is L2TP signalled                                                    
Session state is established, time since change 00:57:57
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 27                                                           
Session Layer 2 circuit, type is ATM AAL5, name is ATM5/0:0/100 
  Circuit state is UP                                                          
Remote session id is 28232, remote tunnel id 60864
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
No session cookie information available
FS cached header information:
   encap size = 28 bytes                                                       
00000000 00000000 00000000 00000000
00000000 00000000 00000000
Sequencing is off
SanFran#

You can see that the session is established, and similar to Frame Relay DLCI mode, the attachment circuit is shown as interface:virtual_circuit (in this case AT5/0:0/100). The detailed information shows the tunnel signaled and established using VC ID 27. The type is ATM AAL5 using VC Type (PW Type) 0x0002 from Table 12-1 for ATM AAL5 SDU VCC. Finally, the encapsulation size is 28 bytes, which corresponds to the following:

Transport (IPv4) Header (20 bytes)

L2TPv3 Header including Session ID (4 bytes) and ATM-Specific Sublayer Header (mandatory 4 bytes)

As usual, the definitive test is CE-CE connectivity (see Example 12-32).

Example 12-32. Verifying CE-to-CE AAL5_SDUoL2TPv3 Connectivity

SanFran#ping 192.168.103.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.103.2, timeout is 2 seconds:
!!!!!                                                                  
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/24 ms
SanFran#

You can also display ATM PVC information. It is interesting to see how the ATM PVC information differs between the CE and PE routers (see Example 12-33).

Example 12-33. ATM PVC Summary in the Oakland CE and the SanFran PE

Oakland#show atm pvc interface ATM 6/0.1
VCD /                                    Peak   Avg/Min Burst
Interface      Name         VPI   VCI   Type   Encaps   Kbps      Kbps Cells   Sts
6/0.1          1              0   100   PVC    SNAP   149760      N/A          UP
Oakland#
SanFran#show atm pvc interface ATM 5/0
VCD /                                     Peak  Avg/Min Burst
Interface      Name         VPI   VCI   Type   Encaps    Kbps     Kbps Cells   Sts
5/0            1              0   100   PVC    AAL5    149760     N/A          UP
SanFran#

In the Oakland CE, the encapsulation is AAL5SNAP because you normally configure on an ATM PVC. However, in the SanFran side, the encapsulation is just AAL5, meaning AAL5 SDU L2Transport and tunneling. You can see the same distinction displaying PVC details in Example 12-34.

Example 12-34. ATM PVC Details in the Oakland CE and the SanFran PE

Oakland#show atm vc interface ATM 6/0.1 detail
ATM6/0.1: VCD: 1, VPI: 0, VCI: 100
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s)
InARP frequency: 15 minutes(s)
Transmit priority 4
InPkts: 5, OutPkts: 5, InBytes: 540, OutBytes: 540
InPRoc: 5, OutPRoc: 5
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 125
OAM cells sent: 125
Status: UP
Oakland#
SanFran#show atm vc interface ATM 5/0 detail
ATM5/0: VCD: 1, VPI: 0, VCI: 100
UBR, PeakRate: 149760
AAL5 L2transport, etype:0xF, Flags: 0x10000C2E, VCmode: 0x0
OAM Cell Emulation: not configured
Interworking Method: like to like 
Remote Circuit Status = No Alarm, Alarm Type = None
InPkts: 130, OutPkts: 5, InBytes: 17179869224, OutBytes: 540
InPRoc: 0, OutPRoc: 0
InFast: 5, OutFast: 5, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 125
OAM cells sent: 125
Status: UP
SanFran#

Chapter 13 describes OAM Cell Emulation. Chapter 14, "Layer 2 Interworking and Local Switching," covers interworking methods.

Control Plane Details

This section presents a complete session establishment control plane negotiation for L2TPv3 AA15 SDU transport. As before, the complete three-way handshake session establishment is shown highlighting the L2TPv3 control messages and AVPs that are specific to the pseudowire type. In all cases, all AVPs in the messages are parsed. Then the control message is accepted (see Example 12-35).

Example 12-35. ATM AAL5 over L2TPv3 Session Establishment Control Plane Details

SanFran#
SanFran#
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse ICRQ
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse AVP 15, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Serial Number -1531567296
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Local Session ID 28232
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Remote Session ID 0
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Pseudo Wire Type 2 
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse Cisco AVP 6, len 8, flag 0x0
*Jun 29 08:18:21.587: Tnl23520 L2TP: End Identifier 27 
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse Cisco AVP 9, len 14, flag 0x8000 (M)
*Jun 29 08:18:21.587: Tnl23520 L2TP: Session Tie Breaker
6A 57 1F 5A B3 1F 10 93
*Jun 29 08:18:21.587: Tnl23520 L2TP: Parse AVP 47, len 10, flag 0x0
*Jun 29 08:18:21.587: Tnl23520 L2TP: L2 Specific Sublayer 2 
*Jun 29 08:18:21.587: Tnl23520 L2TP: No missing AVPs in ICRQ
*Jun 29 08:18:21.587: Tnl23520 L2TP: I ICRQ, flg TLS, ver 3, len 90, tnl 23520, ns 2, nr 1 
*Jun 29 08:18:21.587: Tnl23520 L2TP: I ICRQ from New York tnl 60864                        
*Jun 29 08:18:21.587: Tnl/Sn23520/43729 L2TP: Session state change from idle to wait- 
 connect 
*Jun 29 08:18:21.587: Tnl/Sn23520/43729 L2TP: Accepted ICRQ, new session created           
*Jun 29 08:18:21.587: Tnl/Sn23520/43729 L2TP: Session state change from wait-connect
to wait-for-service-selection-icrq
*Jun 29 08:18:21.591: Tnl/Sn23520/43729 L2TP: Started service selection, peer IP
address 10.0.0.203, VCID 27
*Jun 29 08:18:21.591: Tnl/Sn23520/43729 L2TP: Session state change from wait-for-
service-selection-icrq to wait-connect 
*Jun 29 08:18:21.591: Tnl/Sn23520/43729 L2TP: O ICRP to New York 60864/28232               
*Jun 29 08:18:21.591: Tnl/Sn23520/43729 L2TP: O ICRP, flg TLS, ver 3, len 58, tnl 60864,   
  lsid 43729, rsid 28232, ns 1, nr 3                                                       
*Jun 29 08:18:21.591: Tnl23520 L2TP: Control channel retransmit delay set to 1 seconds
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse ICCN
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse AVP 24, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.607: Tnl23520 L2TP: Connect Speed 0
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.607: Tnl23520 L2TP: Cisco AVP 3 is not for ICCN
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M)
*Jun 29 08:18:21.607: Tnl23520 L2TP: Remote Session ID 43729
*Jun 29 08:18:21.607: Tnl23520 L2TP: Parse AVP 47, len 10, flag 0x0
*Jun 29 08:18:21.607: Tnl23520 L2TP: L2 Specific Sublayer 2
*Jun 29 08:18:21.607: Tnl23520 L2TP: No missing AVPs in ICCN
*Jun 29 08:18:21.607: Tnl/Sn23520/43729 L2TP: I ICCN, flg TLS, ver 3, len 60, tnl 23520,   
  lsid 43729, rsid 28232, ns 3, nr 2                                                       
*Jun 29 08:18:21.607: Tnl/Sn23520/43729 L2TP: I ICCN from New York tnl 60864, cl 28232     
*Jun 29 08:18:21.607: Tnl/Sn23520/43729 L2TP: Session state change from wait-connect       
to established 
SanFran#

Table 12-1).

End Identifier 27 is the VC ID that is configured.

Layer 2-Specific Sublayer 2 indicates the mandatory ATM-Specific Sublayer.

2 ICRP The second way in the three-way handshake. The SanFran PE sends an ICRP message to the New York PE, and the session state machine advances to a wait-connect state.

3 ICCN The third way in the three-way handshake. The New York PE sends the SanFran PE an ICCN message, and the session state moves to established. Again, the Layer 2-Specific Sublayer AVP contains a value of 2, indicating that the ATM Layer 2-Specific Sublayer is used.

Data Plane Details

This section includes the decode of AAL5oL2TPv3 packets captured in the SanFran PE using the commands debug vpdn packet and debug vpdn packet detail. Example 12-36 captures 36-byte pings to identify the end of the IPv4 packet.

Example 12-36. Capturing and Decoding AAL5_SDUoL2TPv3 Packets

SanFran#
*Jun 29 09:23:44.271: L2TP:(Tnl0:Sn43729):FS Into tunnel (SSS): Sending pak         
*Jun 29 09:23:44.271: L2TP:(Tnl0:Sn43729):FS/CEF Into tunnel: Sending 72 byte pak
particle pak, size 72
         45 00 00 48 02 D9 00 00 FF 73 A2 D6 0A 00 00 C9                            
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
IPv4 Delivery Header (IP protocol L2TPv3)
0A 00 00 CB 00 00 6E 48 00 00 00 00 AA AA 03 00
...^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^...
IPv4 Delivery Header Sess Hdr    |           SNAP: LLC: AAAA03
                     Sess Id     ATM-Specific Sublayer
00 00 08 00 45 00 00 24 00 19 00 00 FF 01 6C 6B
...^^^^^^^^^^^ ^^...
|           Begins IP Packet
         SNAP: OUI: 000000; etype: 0x0800 (IPv4)
C0 A8 67 01 C0 A8 67 02 08 00 78 3F 00 05 00 00
00 00 00 00 00 67 7F 54
^^^^^
Ends IP Packet
*Jun 29 09:23:44.271: L2TP:(Tnl0:Sn43729):CEF Into tunnel (SSS): Pak send successful
*Jun 29 09:23:44.283: L2X:CEF From tunnel: Received 76 byte pak
particle pak, size 76
         0F 00 08 00 45 00 00 48 02 DB 00 00 FE 73 A3 D4                            
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
HDLC L2     IPv4 Delivery Header (IP protocol L2TPv3)
         0A 00 00 CB 0A 00 00 C9 00 00 AA D1 00 00 00 00                            
...^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^
IPv4 Delivery Header Sess Id     ATM-Specific Sublayer
AA AA 03 00 00 00 08 00 45 00 00 24 00 19 00 00
^^^^^^^^^^^^^^^^^^^^^^^ ^^...
|                       Begins IP Packet
         SNAP: LLC: AAAA03; OUI: 000000; etype: 0x0800 (IPv4)
FF 01 6C 6B C0 A8 67 02 C0 A8 67 01 00 00 80 3F
00 05 00 00 00 00 00 00 00 ...
*Jun 29 09:23:44.283: L2TP:(Tnl0:Sn43729):CEF From tunnel: Pak send successful

Cells incoming to the SanFran PE from the Oakland CE are reassembled, and the AAL5 CPCS SDU (stripping the AAL5 CPCS-PDU trailer and padding) is encapsulated in L2TPv3, as shown in Figure 12-6, and sent over toward New York. You can see the ATM-Specific Sublayer Header being used with a NULL value because all significant ATM cell header bits are 0, and you have not enabled sequencing. You can also see the AAL5 LLC/SNAP encapsulation header, indicating an IPv4 packet. At disposition, the C-HDLC data-link layer encapsulation between the SanFran PE and the Denver P is included in the debug output.

The L2TPv3 portion of the first packet contains the following fields:

Layer 2 Tunneling Protocol Version 3Session ID: 28232

ATM-Specific Sublayer

.0.. .... = S-bit: False

.... 0... = T-bit: False

.... .0.. = G-bit: False

.... ..0. = C-bit: False

.... ...0 = U-bit: False

Sequence Number: 0

The payload shows part of the AAL5 frame including the LLC header:

Logical-Link Control

DSAP: SNAP (0xaa)

IG Bit: Individual

SSAP: SNAP (0xaa)

CR Bit: Command

Control Field: U, func=UI (0x03)

Organization Code: Encapsulated Ethernet (0x000000)

Type: IP (0x0800)

In contrast to transporting AAL5 frames over the AAL5PW, you enable OAM cell management in the Oakland CE by using the PVC configuration mode command oam-pvc manage and capture an OAM cell that is being transported (see Example 12-37).

Example 12-37. Capturing and Decoding OAM Cells over an AAL5_SDUoL2TPv3 Session

SanFran#
*Jun 29 10:25:16.719: L2TP:(Tnl0:Sn43729):FS Into tunnel (SSS): Sending pak             
*Jun 29 10:25:16.719: L2TP:(Tnl0:Sn43729):FS/CEF Into tunnel: Sending 80 byte pak
particle pak, size 80
         45 00 00 50 04 D3 00 00 FF 73 A0 D4 0A 00 00 C9                                
0A 00 00 CB 00 00 6E 48 08 00 00 00 00 00 06 4A
^^^^^^^^^^^ ^^^^^^^^^^^
| ATM Cell Header: VPI/VCI = 0/100; PTI: 101b
ATM-Specific Sublayer: T-bit = 1
18 01 00 00 00 01 FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF 6A 6A
6A 6A 6A 6A 6A 6A 6A 6A 6A ...
*Jun 29 10:25:16.719: L2TP:(Tnl0:Sn43729):CEF Into tunnel (SSS): Pak send successful

From Example 12-37, you can see that the OAM cell is encapsulated using Cell Relay over L2TPv3.

The ATM-Specific Sublayer has the Transport bit set, an indication that it is carrying an ATM cell.

An ATM Cell Header is included in the payload. The payload type identifier (PTI) value of 101 binary indicates an end-to-end OAM F5 flow cell.

Note

In AAL5 SDU mode, OAM cells that are received over the attachment circuit are sent immediately and might not maintain the relative cell order with respect to cells that comprise an AAL5 frame that is being reassembled.

The complete L2TPv3 encapsulation that indicates an admin cellincluding the T-bit in the ATM-Specific Sublayercontains the following fields:

Layer 2 Tunneling Protocol Version 3Session ID: 28232

ATM-Specific Sublayer

.0.. .... = S-bit: False

.... 1... = T-bit: True

.... .0.. = G-bit: False

.... ..0. = C-bit: False

.... ...0 = U-bit: False

Sequence Number: 0

The first two nibbles in the OAM cell payload are 0x18. The OAM type 0x1 indicates a Fault Management, and the OAM Function type 0x8 specifies an OAM Cell Loopback. The next byte is the loopback indicator (LBI), and a value of 0x01 indicates that the cell must be looped back. It contains a 4-byte correlation tag (CTag) of 1 because you captured the first OAM cell after enabling OAM management. It follows with 16 bytes of binary ones for the location ID, which designates an end-to-end loopback. Unused bytes are filled with a 0x6A padding. Refer to the ITU-T Recommendation I.610, "B-ISDN Operation and Maintenance Principles and Functions," for ATM OAM details.

Case Study 12-5: ATM Cell Relay over L2TPv3 with Dynamic Session

Case Study 12-5 concentrates on ATM Cell Relay over L2TPv3 (ATM_CRoL2TPv3). Using the topology shown in Figure 12-16, you learn to configure and verify the operation of ATM VCC Cell transport over L2TPv3.

As shown in Figure 12-16, the attachment circuits are now the PVCs with VPI/VCI pair of 0/200 in the ATM5/0 interfaces of the SanFran and New York PE routers.

Configuring ATM_CRoL2TPv3 with Dynamic Session

The configuration steps that are required to provision ATM_CRoL2TPv3 in VC mode are similar to the ones you just learned in Case Study 12-4. However, one difference is needed to specify ATM Cell Relay service as opposed to ATM AAL5 service. This difference involves specifying the encapsulation as aal0, meaning "no ATM Adaptation Layer," under the attachment circuit PVC (see Example 12-38).

Example 12-38. Configuring ATM_CRoL2TPv3 in the SanFran PE

!
hostname SanFran
!
interface ATM5/0
no ip address
pvc 0/200 l2transport
  encapsulation aal0                           
xconnect 10.0.0.203 28 pw-class pw-l2tpv3-atm
!

You can see that Example 12-38 uses the same pseudowire class for comparison. The CE router's configuration is analogous to the previous case study and is the same as normal ATM PVC configuration using VPI/VCI 0/200.

Verifying ATM_CRoL2TPv3

To verify the correct functioning of the L2TPv3 pseudowire, use the show l2tun session command (see Example 12-39).

Example 12-39. Verifying the ATM_CRoL2TPv3 Session

SanFran#show l2tun session all vcid 28
Session Information Total tunnels 1 sessions 2
Tunnel control packets dropped due to failed digest 0
Session id 43738 is up, tunnel id 23520
Call serial number is 2763400001
Remote tunnel name is New York
Internet address is 10.0.0.203
  Session is L2TP signalled                                          
  Session state is established, time since change 00:00:44
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 28                                                 
Session Layer 2 circuit, type is ATM VCC CELL, name is ATM5/0:0/200
Circuit state is UP
Remote session id is 28241, remote tunnel id 60864
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
SanFran#

The show l2tun session command for the session with the VC ID of 28 as configured in Table 12-1. The encapsulation size is now 24 bytes, which is the minimum possible encapsulation size. In ATM_CRoL2TPv3, you do not use the ATM-Specific Sublayer because the ATM cell headers are actually carried. The ATM L2TPv3 companion document specifies that, if needed, either the Default or the ATM Layer 2-Specific Sublayer can be used. Cisco IOS routers signal a request for the Default Layer 2-Specific Sublayer if sequencing is required.

You can also compare the ATM L2transport PVCs in the SanFran PE (see Example 12-40).

Example 12-40. Verifying ATM over L2TPv3 PVC

SanFran#show atm pvc interface ATM 5/0
VCD /                                     Peak   Avg/Min Burst
Interface      Name         VPI   VCI   Type   Encaps    Kbps      Kbps Cells   Sts
5/0            1              0   100   PVC    AAL5    149760       N/A         UP
5/0            2              0   200   PVC    AAL0    149760       N/A         UP
SanFran#

Using the show atm pvc command, the encapsulation is now shown as AAL0, meaning ATM Cell Relay. From the CE router standpoint, the PVCs that are transported as AAL5 or Cell are the same.

Example 12-41 displays the details of the Cell Relay PVC 0/200.

Example 12-41. ATM_CRoL2TPv3 PVC Details

SanFran#show atm vc interface aTM 5/0 detail
ATM5/0: VCD: 2, VPI: 0, VCI: 200
UBR, PeakRate: 149760
AAL0-Cell Relay, etype:0x10, Flags: 0x10000C2D, VCmode: 0x0
OAM Cell Emulation: not configured
Interworking Method: like to like
Remote Circuit Status = No Alarm, Alarm Type = None
InBytes: 17179868768, OutBytes: 0
Cell-packing Disabled
OAM cells received: 104
OAM cells sent: 104
Status: UP
SanFran#

The encapsulation is shown as AAL0-Cell Relay. Also note that the next three lines showing OAM cell emulation, interworking, and remote circuit status are specific to ATM pseudowires and do not appear for a PVC in a CE device.

Cell Relay Details

The ATM Cell Relay tunneling and transport using L2TPv3 encompass three operational modes:

VC mode

VP mode

Port mode

VP and Port mode do not support AAL5 transport because cells from different PVCs are interleaved and cannot be properly reassembled.

To configure the different ATM CR operational modes, use the same xconnect command with the same parameters and keywords. The difference is the context in which the command is applied, which in Cisco IOS CLI means the configuration mode. The configuration modes are as follows:

ATM CR VC Mode Create the xconnect under pvc l2transport configuration mode.

ATM CR VP Mode Create the xconnect under atm pvp l2transport configuration mode.

ATM CR Port Mode Create the xconnect under ATM interface configuration mode.

Example 12-42 shows an example of each case.

Example 12-42. Configuring Different ATM_CRoL2TPv3 Modes

! ATM Cell Relay VC Mode Configuration         
interface ATM5/0
 pvc 0/200 l2transport                         
  encapsulation aal0                           
xconnect 10.0.0.203 28 pw-class pw-l2tpv3-atm
!
! ATM Cell Relay VP Mode Configuration         
interface ATM5/0
 atm pvp 5 l2transport                         
xconnect 10.0.0.203 5 pw-class pw-l2tpv3-atm
!
! ATM Cell Relay Port Mode Configuration       
interface ATM3/0
xconnect 10.0.0.203 3 pw-class pw-l2tpv3-atm
!
!

One key configuration difference is that in VC mode, you need to specify the encapsulation as aal0 for Cell Relay, because AAL5 SDU is also supported on VC mode. This extra step is not needed in VP and Port modes.

By enabling the debug vpdn l2x-packets, you can see the control messages and parsed AVPs in the debug output. From here, you can compare the different pseudowire types used for the different CRoL2TPv3 modes by inspecting the Cisco AVP 7. Compare the values in Table 12-1:

Example 12-43. Pseudowire Type for Different ATM_CRoL2TPv3 Modes

! ATM Cell Relay VC Mode PW Type                                              
*Jun 29 10:32:00.071: Tnl23520 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Jun 29 10:32:00.071: Tnl23520 L2TP: Pseudo Wire Type 9
! ATM Cell Relay VP Mode PW Type                                              
*Jun 29 10:40:09.839: Tnl23520 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Jun 29 10:40:09.839: Tnl23520 L2TP: Pseudo Wire Type 10
! ATM Cell Relay Port Mode PW Type                                            
*Jun 29 10:43:29.767: Tnl23520 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Jun 29 10:43:29.767: Tnl23520 L2TP: Pseudo Wire Type 3

0x0009 ATM n-to-one VCC cell (ATMoL2TPv3 Cell VC mode)

0x000A ATM n-to-one VPC cell (ATMoL2TPv3 Cell VP mode)

0x0003 ATM Transparent cell (ATMoL2TPv3 Cell Port mode)

To conclude this section, Example 12-44 shows how these pseudowire types and attachment circuits for the different CRoL2TPv3 modes are displayed.

Example 12-44. Pseudowire Type Display for Different ATM_CRoL2TPv3 Modes

SanFran#show l2tun session
Session Information Total tunnels 1 sessions 4
Tunnel control packets dropped due to failed digest 0
LocID      RemID      TunID      Username, Intf/                            State
Vcid, Circuit
43729      28232      23520      27, AT5/0:0/100                            est
43739      28242      23520      28, AT5/0:0/200                            est
43746      28249      23520      5, AT5/0:5                                 est
43756      28259      23520      3, AT3/0:                                  est
SanFran#
SanFran#! ATM AAL5 SDU Mode
SanFran#show l2tun session all vcid 27 | include type is
Session Layer 2 circuit, type is ATM AAL5, name is ATM5/0:0/100
SanFran#
SanFran#! ATM Cell Relay VCC Mode
SanFran#show l2tun session all vcid 28 | include type is
Session Layer 2 circuit, type is ATM VCC CELL, name is ATM5/0:0/200
SanFran#
SanFran#! ATM Cell Relay VPC Mode
SanFran#show l2tun session all vcid 5 | include type is
Session Layer 2 circuit, type is ATM VPC CELL, name is ATM5/0:5
SanFran#
SanFran#! ATM Cell Relay Port Mode
SanFran#show l2tun session all vcid 3 | include type is
Session Layer 2 circuit, type is ATM CELL, name is ATM3/0:
SanFran#