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

LAN Protocols over L2TPv3 Case Studies

Now that you understand some of the CLI concepts, the subsequent sections examine how to use these CLI components to provide an L2TPv3 Layer 2 VPN service focusing on two specific types of Ethernet pseudowire transport:

Ethernet port-to-port emulation

Ethernet VLAN-to-VLAN emulation

Some optional L2TPv3 concepts will be introduced in various case studies to reinforce your understanding of their functionality.

To help explain some of the concepts in an L2TPv3 LAN environment, each case study in this chapter is based on a single IP lab topology shown in Figure 11-2. The service provider has chosen a pure IP-based packet switched network (PSN) to provide Layer 2 services to its customer. The IP PSN consists of two PE routers called SanFran and NewYork and a P router called Denver. The PE and P routers are connected to each other via Cisco-HDLC (C-HDLC) Serial links addressed with a /30 prefix. Each core device also has a /32 loopback configured.

Table 11-1 lists the relevant addressing for the case study.

Device

Site

Subnet

The following list describes the required steps in establishing the IP PSN core:

Example 11-1 includes the base configuration of the SanFran PE router. Denver and NewYork are configured equivalently to the SanFran router, with adjustments to the interface IP addressing.

Example 11-1. SanFran Required Preconfiguration

hostname SanFran
!
ip cef
!
interface Loopback0
 ip address 10.1.1.102 255.255.255.255
!
interface Serial6/0
 ip address 10.1.2.1 255.255.255.252  
!
router ospf 1
log-adjacency-changes
network 10.1.1.0 0.0.0.255 area 0
network 10.1.2.0 0.0.0.255 area 0
!

The highlighted lines indicate the relevant IP addressing specific to the SanFran router that would change in the respective configuration in the Denver and NewYork devices.

To confirm that the proper routes are being distributed, Example 11-2 captures the IP routing table of the IP PSN network.

Example 11-2. SanFran Preconfiguration Verification

SanFran#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C         10.1.2.0/30 is directly connected, Serial6/0
O         10.1.2.4/30 [110/96] via 10.1.2.2, 00:07:50, Serial6/0
C         10.1.1.102/32 is directly connected, Loopback0
O         10.1.1.103/32 [110/97] via 10.1.2.2, 00:07:50, Serial6/0            
O         10.1.1.101/32 [110/49] via 10.1.2.2, 00:07:50, Serial6/0            

The highlighted routes are NewYork and Denver loopback addresses that are learned through Open Shortest Path First (OSPF). Both addresses are reachable from SanFran via the Serial 6/0 interface.

The next sections present the following case studies:

Case Study 11-1: Ethernet Port-to-Port Manual Session

Case Study 11-2: Ethernet Port-to-Port Manual Session with Keepalive

Case Study 11-3: Ethernet Port-to-Port Dynamic Session

Case Study 11-4: Ethernet VLAN-to-VLAN Dynamic Session

Case Study 11-1: Ethernet Port-to-Port Manual Session

In this case study, the customer has requested that the service provider supply transparent Layer 2 Ethernet port-to-port connectivity between the Oakland and Albany routers, as shown in Figure 11-3. Because the service provider has chosen an IP-based core, L2TPv3 is used to meet the customer's requirements. In the section "xconnect Command Syntax," you learned about manual, manual with keepalive, and dynamic modes. These three modes are relevant and applicable to all L2TPv3 sessions emulating LAN or WAN protocols. However, because this section is the introduction to configuring these sessions, it examines each mode using Ethernet port-to-port emulation as an example starting with the simplest case: a manual L2TPv3 Ethernet port-to-port session, as illustrated in Figure 11-3.

The goal in this case study is to provide Layer 2 Ethernet port-to-port connectivity over an IP-based PSN between Oakland's CE router E0/0 interface and Albany's CE router E0/0 interface. The subsequent sections examine the necessary configuration, verification, and data plane details of this environment.

Ethernet Port-to-Port Manual Configuration

To provision an Ethernet port-to-port manual pseudowire, the SanFran and NewYork PE devices will configure the following to act as L2TPv3 endpoints for the customer:

Define a pseudowire-class template.

Define an xconnect on the appropriate interface with the necessary preconfigured manual attributes.

Example 11-3 shows the relevant configuration for the SanFran PE device.

Example 11-3. Ethernet Port-to-Port Manual Session Configuration on SanFran

hostname SanFran
!
pseudowire-class pw-manual
encapsulation l2tpv3
 protocol none                                                            
ip local interface Loopback0
!
interface Loopback0
ip address 10.1.1.102 255.255.255.255
!
interface Ethernet0/0
no ip address
no cdp enable
xconnect 10.1.1.103 33  encapsulation l2tpv3 manual  pw-class  pw-manual 
  l2tp id 245 329                                                         
  l2tp cookie local 8 957344 9379092                                      
  l2tp cookie remote 8 76429 945                                          

Example 11-4 shows the equivalent configuration for NewYork.

Example 11-4. Ethernet Port-to-Port Manual Session Configuration on NewYork

hostname NewYork
ip cef
!
pseudowire-class pw-manual
encapsulation l2tpv3
 protocol none                                                          
ip local interface Loopback0
!
interface Loopback0
ip address 10.1.1.103 255.255.255.255
!
interface Ethernet0/0
no ip address
no cdp enable
xconnect 10.1.1.102 33 encapsulation l2tpv3 manual pw-class pw-manual 
  l2tp id 329 245                                                      
  l2tp cookie local 8 76429 945                                        
  l2tp cookie remote 8 957344 9379092                                  

As mentioned earlier in the section, both PE routers should configure a pseudowire-class template first. San Francisco's and New York's pseudowire-class template is called pw-manual, as highlighted in the example. Although defining a pseudowire-class is an optional step, it is a highly recommended best practice at least to define the L2TPv3 local interface to a loopback interface. This forces the source address for the L2TPv3 session to use a virtual interface that otherwise would never go down unless it was shut administratively.

In the case of the pw-manual template, both PE routers tie the local interface to their respective Loopback 0. Because you are configuring a manual L2TPv3 session, the template also defines protocol none to disable L2TPv3 from initiating a control channel connection to the peer. Keep in mind that this pw-manual template can be referenced from multiple xconnect statements. This example happens to have only one xconnect defined.

The second major configuration task is defining the xconnect statement. In SanFran's configuration, the xconnect command is defined underneath the relevant attachment circuit, which is the Ethernet major interface, Ethernet 0/0, because this example uses Ethernet port-to-port emulation. The xconnect statement defines the peer address as NewYork's loopback address of 10.1.1.103 and defines a virtual circuit (VC) ID of 33. The VC ID uniquely identifies the attachment circuit on a per-peer basis. Equivalently, NewYork's xconnect statement defines the peer address to be SanFran's loopback address of 10.1.1.102. You must use the VC ID value of 33 on NewYork so that the pseudowire session between the PEs can identify which AC to bind to.

As highlighted in the xconnect configuration line in both PE router examples, the manual keyword after the encapsulation l2tpv3 syntax defines this pseudowire as a manually defined session and references the pw-manual pseudowire-class template via the pw-class pw-manual configuration. After you enter the xconnect command with the manual keyword, the configuration is placed into config-if-xconn submode configuration, which requires the user to manually define the necessary attributes of the session. Table 11-2 summarizes the manually defined session and cookie values in decimal and hexadecimal format from SanFran's perspective. These hexadecimal values are referenced later in the verification and data plane examination of this case study to assist in decoding captured output.

Local

Remote

Because every session requires a Session ID, the SanFran router defines the local Session ID as 245 and the remote Session ID as 329. Optionally, this example uses L2TPv3 cookies to protect the pseudowire session from blind insertion attacks. Preconfigure the Session ID and optionally the cookie definition and use agreed upon values; otherwise, the far-end peer will not recognize the L2TPv3 encapsulation. The NewYork configuration, as highlighted in Example 11-4 underneath the xconnect command, configures the identical values in the reverse position to appropriately match the local and remote values from NewYork's perspective.

The two CE routers, Oakland and Albany, are configured without knowledge that the Ethernet port connectivity is provided over an L2TPv3 service. Figure 11-4 illustrates that the Layer 3 CE-to-CE connectivity exists between Oakland and Albany as if their Ethernet ports were connected back to back.

Verifying Ethernet Port-to-Port Manual Session

Several show commands are useful for determining the state of the manual Ethernet port-to-port L2TPv3 session. This section describes the following:

show l2tun

show l2tun session all

show sss circuits

The show l2tun command shows summarized information regarding all defined tunnels and sessions on the local device, as demonstrated in Chapter 10, the term L2TP tunnel refers to the L2TPv3 control connection. As highlighted in Example 11-5, you can see the term tunnel in this context. Because this case study configures a manual session, no L2TPv3 control connection is established, and the total tunnels is 0. However, one session does exist, which happens to be the Ethernet port-to-port manual session defined between Oakland and Albany.

Example 11-5. SanFran show l2tun Output

SanFran#show l2tun
Tunnel and Session Information Total tunnels 0 sessions 1 
Tunnel control packets dropped due to failed digest 0
LocID     RemID       TunID      Username, Intf/             State
Vcid, Circuit
245       329         0          33, Et0/0                   est  

The final line of the Chapter 10. Normally, this would be a negotiated value; however, because the pseudowire session is in manual mode, no control channel is used and no control connection ID is necessary. Finally, the state of the session shows established (est), indicating that this pseudowire session is active.

You can glean additional session attributes from the show l2tun session all output shown in Example 11-6.

Example 11-6. SanFran show l2tun all Output

SanFran#show l2tun session all
Session Information Total tunnels 0 sessions 1
Tunnel control packets dropped due to failed digest 0
Session id 245 is up, tunnel id 0                                
Call serial number is 0
Remote tunnel name is
Internet address is 10.1.1.103 
  Session is manually signalled                                  
  Session state is established, time since change 00:53:09       
    692 Packets sent, 693 received                               
    66992 Bytes sent, 66981 received                             
Receive packets dropped:
out-of-order:             0
total:                    0
Send packets dropped:
exceeded session MTU:     0
total:                    0
  Session vcid is 33                                             
Session Layer 2 circuit, type is Ethernet, name is Ethernet0/0 
Circuit state is UP
    Remote session id is 329, remote tunnel id 0                 
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
Session cookie information:
    local cookie, size 8 bytes, value 00 8F 1D 14 00 0E 9B A0    
    remote cookie, size 8 bytes, value 00 00 03 B1 00 01 2A 8D   
FS cached header information:
    encap size = 32 bytes                                        
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Sequencing is off

Chapter 10's "L2TPv3 Data Encapsulation" section, the L2TPv3 overhead is composed of a 20-byte IP header, a 4-byte session ID, an optional and variable-length cookie, and an optional L2-Specific Sublayer. In this case study, an 8-byte cookie is defined on both PE routers, and no L2-Specific Sublayer is used. (Sequencing is not enabled.) Therefore, the 32-byte encapsulation is derived from the 20-byte IP header, the 4-byte remote session ID of 329, and the 8-byte remote cookie.

The encapsulation details are further highlighted in the show sss circuits output listed in Example 11-7.

Example 11-7. SanFran show sss circuits Output

SanFran#show sss circuits
Current SSS Circuit Information: Total number of circuits 1
Common Circuit ID 0             Serial Num 5      Switch ID 22074136
---------------------------------------------------------------------------
Status  Encapsulation
UP flg  len dump
Y  AES  0
   Y  AES  32  45000000 00000000 FF73A4BC 0A010166 0A010167                  
                   00000149 000003B1 00012A8D                                

The first 20 bytes are the IP packet header with a source address of SanFran's loopback of 10.1.1.102 (0x0A010166) and a destination address of 10.1.1.103 (0x0A010167). The IP header is then followed by the remote session ID of 329 (0x00000149) and the 8-byte remote cookie (cookie value high = 0x000003B1, cookie value low = 00012A8D).

You can perform a final verification by passing traffic between the CE routers to the next-hop interface address. As shown in Example 11-8, a ping is executed from the Oakland CE router to the E0/0 IP address on the Albany CE router of 192.168.2.2, indicating successful connectivity.

Example 11-8. Ethernet Port-to-Port Manual Session CE Verification

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

Ethernet Port-to-Port L2TPv3 Data Plane Details

Chapter 10 discussed at length the L2TPv3 encapsulation format for encapsulating data. In this case study, correlating the encapsulated packet with the preconfigured details for the pseudowire session should be fairly simple. An L2TPv3 frame that is captured in the IP PSN core is shown in Example 11-9.

Example 11-9. Ethereal Decode and Capture of Oakland to Albany ICMP Ping

Cisco HDLC                                                                             
Address: Unicast (0x0f)
Protocol: IP (0x0800)
Internet Protocol, Src Addr: 10.1.1.102 (10.1.1.102), Dst Addr: 10.1.1.103 (10.1.1.103)
Version: 4
Header length: 20 bytes
! IP header DSCP, Flags detail, Fragment offset and TTL omitted for brevity
Protocol: Layer 2 Tunneling (0x73)
Header checksum: 0x6858 (correct)
Source: 10.1.1.102 (10.1.1.102)
Destination: 10.1.1.103 (10.1.1.103)
Layer 2 Tunneling Protocol version 3                                                   
Session ID: 329
Cookie: 000003B100012A8D
Ethernet II, Src: 00:00:0c:00:6c:00, Dst: 00:00:0c:00:6f:00
Destination: 00:00:0c:00:6f:00 (00:00:0c:00:6f:00)
Source: 00:00:0c:00:6c:00 (00:00:0c:00:6c:00)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.2.1 (192.168.2.1), Dst Addr: 192.168.2.2
(192.168.2.2)
Version: 4
Header length: 20 bytes
! IP header DSCP, Flags detail, Fragment offset and TTL omitted for brevity
Protocol: ICMP (0x01)
Header checksum: 0x31d7 (correct)
Source: 192.168.2.1 (192.168.2.1)
Destination: 192.168.2.2 (192.168.2.2)
Internet Control Message Protocol                                                      
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x9d07 (correct)
Identifier: 0x0009
Sequence number: 0x0000
Data (72 bytes)
0000  0f 00 08 00 45 00 00 92 3b d2 00 00 ff 73 68 58 
^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cisco HDLC IPv4 Delivery Header (IP Protocol L2TPv3)
0010  0a 01 01 66 0a 01 01 67 00 00 01 49 00 00 03 b1 
^^^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^^^^^^^
IPv4 Delivery Header        L2TPv3 Header
0020  00 01 2a 8d 00 00 0c 00 6f 00 00 00 0c 00 6c 00 
^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
L2TPv3 Header L2TPv3 Payload (Ethernet II Frame)
0030  08 00 45 00 00 64 04 6e 00 00 ff 01 31 d7 c0 a8 
^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ethertype         IPv4 Hdr (ICMP packet)
0040  02 01 c0 a8 02 02 08 00 9d 07 00 09 00 00 00 00 
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IPv4 Hdr (ICMP packet)        ICMP packet
!remainder omitted for brevity

Note

Note that in Examples 11-9, the offline hand decoding of the packets is shown in bold font.

Example 11-9 includes the full Ethereal decode of the packet followed by the hexadecimal capture of the frame. Each highlighted section of the Ethereal decode corresponds to a highlighted hexadecimal field. The decode captures a Cisco-HDLC frame between the SanFran PE router and the Denver P router that contains an L2TPv3 packet. This L2TPv3 packet payload contains an Ethernet frame from the previous CE verification ICMP ping executed from Oakland's E0/0 interface to Albany's E0/0 interface.

Notice that the capture has two Layer 2 frame headers. The first Layer 2 frame is the Cisco-HDLC frame between the SanFran and Denver routers. This is followed by the IP delivery header that is part of the L2TPv3 packet. Because the L2TPv3 endpoints are the PE routers, the source and destination IP addresses in the outer IP delivery header are SanFran and NewYork's Loopback 0 addresses, respectively. An IP protocol type of 0x73, 115, indicates that the IP payload is an L2TPv3 packet. The session ID is 0x00000149, which in decimal is 329 and is equal to the remote session ID configured on SanFran that uniquely identifies the session on NewYork. Following the session ID is the 8-byte remote cookie value, 0x000003B100012A8D, which was configured on SanFran as the remote cookie value.

The L2TPv3 payload follows the L2TPv3 header and is the second Layer 2 frame header. In this case, the L2TPv3 payload is a standard Ethernet Version II untagged frame minus the frame check sequence (FCS) sent to Albany's Ethernet port, MAC address 0000.0c00.6f00, from Oakland's Ethernet port, MAC address 0000.0c00.6c00. Further inspection shows that this Ethernet frame is carrying an IP payload that is sourced from Oakland's E0/0 interface, whose IP address is 192.168.2.1 (0xc0a80201), to Albany's E0/0 interface, whose IP address is 192.168.2.2 (0xc0a80202).

When the NewYork router receives this L2TPv3 frame, the outer IP header and L2TPv3 header are stripped off. The session ID and cookie value in the L2TPv3 header provide the NewYork router with enough information to properly demultiplex the frame and associate it with the appropriate egress attachment circuit. In this case, the Ethernet frame is forwarded out of NewYork's Ethernet 0/0 interface and destined to Albany's Ethernet port.

The nature of the Ethernet port-to-port session is that any valid Ethernet frame minus the FCS is transported across the pseudowire to be replayed on the far-end attachment circuit. Because of this, the Ethernet port-to-port session is oblivious to the fact that tagged or untagged frames might be received on Oakland's E0/0 interface. In an alternate scenario in which the Oakland and Albany routers are sending 802.1q tagged frames, the Ethernet port-to-port emulation would be oblivious to the 802.1q tag. It would transport the tagged Ethernet II frame across the pseudowire transparently, leaving the 802.1q tag untouched.

Case Study 11-2: Ethernet Port-to-Port Manual Session with Keepalive

Although a manually defined Ethernet port-to-port session fulfills the original goal for Layer 2 connectivity, one of the disadvantages is that the PE devices cannot detect whether the remote peer is responding. If connectivity is lost to the NewYork PE, the SanFran router would not tear down the pseudowire; it would continue sending data packets on the session. In fact, the pseudowire session state for a manual session always shows established, as shown in the show l2tun session output, regardless of the state of the peer PE router.

This case study explores the configuration, verification, and control plane details for an Ethernet port-to-port manual session with keepalives. Because the addition of the keepalives affects only the control plane, the data plane details are the same as in Case Study 11-1 and are not reexamined.

Ethernet Port-to-Port Manual Session with Keepalive Configuration

Recognizing the drawback of no peer detection, the service provider has decided to adjust the original configuration to support a simple keepalive mechanism. This keepalive mechanism is essentially an L2TPv3 control channel maintained between the PE devices. This case study adjusts the control connection and management timers so that you can understand how they function. To provision this service, Example 11-10 contains the new configuration applied to the SanFran PE router.

Example 11-10. Ethernet Port-to-Port Manual Session with Keepalive Configuration on SanFran

hostname SanFran
!
l2tp-class l2-keepalive 
 hello 30                                                            
 retransmit retries 5                                                
 retransmit timeout max 4                                            
 retransmit timeout min 2                                            
 retransmit initial retries 3                                        
 retransmit initial timeout max 7                                    
 retransmit initial timeout min 2                                    
!
pseudowire-class pw-manual
encapsulation l2tpv3
protocol none
ip local interface Loopback0
!
interface Ethernet0/0
no ip address
no cdp enable
xconnect 10.1.1.103 33 encapsulation l2tpv3 manual pw-class pw-manual
l2tp id 245 329
l2tp cookie local 8 957344 9379092
l2tp cookie remote 8 76429 945
  l2tp hello l2-keepalive                                            

Example 11-11 contains the new configuration applied to the SanFran PE router.

Example 11-11. Ethernet Port-to-Port Manual Session with Keepalive Configuration on NewYork

hostname NewYork
!
l2tp-class l2-keepalive 
 hello 30                                                            
 retransmit retries 5                                                
 retransmit timeout max 4                                            
 retransmit timeout min 2                                            
 retransmit initial retries 3                                        
 retransmit initial timeout max 7                                    
 retransmit initial timeout min 2                                    
!
pseudowire-class pw-manual
encapsulation l2tpv3
protocol none
ip local interface Loopback0
!
interface Ethernet0/0
no ip address
no cdp enable
xconnect 10.1.1.102 33 encapsulation l2tpv3 manual pw-class pw-manual
l2tp id 329 245
l2tp cookie local 8 76429 945
l2tp cookie remote 8 957344 9379092
  l2tp hello l2-keepalive                                            

Note

Although the ip cef and interface Loopback 0 definitions are not shown, these commands are still required in the configuration. They were removed from the example to reduce the redundancy in the example configurations.

Following are the primary steps involved in defining an L2TPv3 manual session with keepalives:

The first step to enabling a manual session with keepalives involves defining an l2tp-class. In this example, an l2tp-class was defined named l2-keepalive that consists of a series of timer modifications. The Hello message keepalive timer was modified from the default 60 seconds to 30 seconds via the hello 30 syntax. If a Hello message is not acknowledged, the control channel attempts five retries per the retransmit retries configuration. The retransmit retries min configuration defines the first retry interval at 2 seconds and doubles per interval up to the retransmit retries max value. After the pseudowire session fails, the L2TPv3 endpoints try to restore the control channel by sending the initial SCCRQ message. In the same manner, the number of SCCRQ retries and time between retry attempts are dictated by the retransmit initial retries, retransmit initial min, and retransmit initial max configured values.

The pseudowire-class pw-manual definition is reused from the previous "Ethernet Port-to-Port Manual Session" section of Case Study 11-1. As mentioned in that case study, defining a pseudowire-class template is a highly recommended best practice to make the source address of L2TPv3 packets deterministic.

The xconnect configuration then references this l2tp-class by name in the config-if-xconn submode as a template to use for its keepalive mechanism via the l2tp hello l2-keepalive command. The control channel negotiation and keepalive are examined in more detail in the subsequent "Ethernet Port-to-Port Manual Session with Keepalive Control Plane Details" section.

Ethernet Port-to-Port Manual Session with Keepalive Verification

Because of the use of the control channel in this case study, additional output is available from several show commands used to monitor the health of the L2TPv3 control channel and sessions. They include the following commands:

show l2tun

show l2tun tunnel all

Example 11-12 lists the output for the show l2tun command.

Example 11-12. SanFran show l2tun Output

SanFran#show l2tun
Tunnel and Session Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
LocID RemID Remote Name State Remote Address  Port  Sessions L2TPclass
37528 27854 NewYork     est   10.1.1.103      0     0        l2-keepalive 
LocID      RemID      TunID   Username, Intf/                         State
Vcid, Circuit
245        329        37528   33, Et0/0                               est

The show l2tun tunnel command displays three sections of output:

Total tunnel and session information

Tunnel summary information

Session summary information

When comparing the Example 11-12 output to the Example 11-5 output in "Case Study 11-1: Ethernet Port-to-Port Manual Session," you notice that highlighted fields contain additional details that were not previously shown in manually defined sessions. In the first section of output, referred to as the total tunnel and session information section, the total tunnels value is now 1. Configuring a manual session with keepalive initiates an L2TPv3 tunnel, also referred to as an L2TPv3 control channel, which explains the one tunnel count.

In the second portion of the show l2tun output, described as the tunnel summary section, the L2TP class field refers to the l2-keepalive template for this L2TPv3 tunnel. Also note that the tunnel ID, also referred to as the control connection ID, in the session summary section is now a nonzero value of 37528 that was negotiated as part of the control channel establishment. The method by which the control channel is established and the way the tunnel ID is negotiated are explored in more detail in the "Ethernet Port-to-Port Manual Session with Keepalive Control Plane Details" section of this case study.

Note

In the first section of output from the show l2tun tunnel command, the total tunnels value is 1, as is the total sessions count. However, note that in tunnel summary information, the Sessions field is listed as 0 for the one tunnel in the case study with local tunnel ID 37528. The reason for this apparent discrepancy is that the first section of output lists the global session count, which consists of both manually and dynamically negotiated sessions. The Sessions field counts only dynamic sessions negotiated against that specific L2TPv3 tunnel. Because this case study examines a manually defined session, the Sessions field does not register it against the tunnel.

The show l2tun tunnel all output shown in Example 11-13 captures additional details for the L2TPv3 control channel.

Example 11-13. SanFran show l2tun tunnel all Output

SanFran#show l2tun tunnel all
Tunnel Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
Tunnel id 37528 is up, remote id is 27854, 0 active sessions
  Tunnel state is established, time since change 00:52:10             
Tunnel transport is IP (115) 
Remote tunnel name is NewYork 
Internet Address 10.1.1.103, port 0
Local tunnel name is SanFran 
Internet Address 10.1.1.102, port 0
Tunnel domain is
VPDN group for tunnel is -
  L2TP class for tunnel is l2-keepalive                               
0 packets sent, 0 received
0 bytes sent, 0 received
Control Ns 105, Nr 106
  Local RWS 1024 (default), Remote RWS 1024 (max)                     
Tunnel PMTU checking disabled
Retransmission time 1, max 2 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 0, ZLB ACKs sent 105
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
Control message authentication is disabled

Chapter 10.

Note

The show l2tun session all command output is essentially the same as in "Case Study 11-1: Ethernet Port-to-Port Manual Session." Therefore, it is not reviewed in this case study.

Ethernet Port-to-Port Manual Session with Keepalive Control Plane Details

As mentioned earlier, the use of keepalives for dead peer detection initiates a control connection between the L2TPv3 PE endpoints. Following are two debug commands that you can use to display the control connection establishment:

debug vpdn l2x-events

debug vpdn l2x-packets

debug vpdn l2x-events displays general L2TP protocol events, whereas debug vpdn l2xpackets displays parsed L2TP control packets. Example 11-14 captures the SanFran PE router debug output for the L2TPv3 control connection to NewYork.

Example 11-14. SanFran debug vpdn l2x-events Output on Control Connection Initialization

*Nov 17 11:27:42.460: L2X: Parse AVP 0, len 8, flag 0x8000 (M)
*Nov 17 11:27:42.460: L2X: Parse SCCRQ 
! AVP 2 Protocol Version, AVP 6 Firmware Version, Cisco AVP 8 Vendor Name, and
Cisco AVP 10 Vendor AVP version omitted for brevity
*Nov 17 11:27:42.460: L2X: Parse AVP 7, len 13, flag 0x8000 (M) 
*Nov 17 11:27:42.460: L2X: Hostname NewYork 
*Nov 17 11:27:42.460: L2X: Parse AVP 10, len 8, flag 0x8000 (M)
*Nov 17 11:27:42.460: L2X: Rx Window Size 1024 
*Nov 17 11:27:42.460: L2X: Parse Cisco AVP 1, len 10, flag 0x8000 (M) 
*Nov 17 11:27:42.460: L2X: Assigned Control Connection ID 27854  
*Nov 17 11:27:42.460: L2X: Parse Cisco AVP 2, len 22, flag 0x8000 (M)
*Nov 17 11:27:42.460: L2X: Pseudo Wire Capabilities List:
*Nov 17 11:27:42.460: L2X:   FR-DLCI [0001], ATM-AAL5 [0002], ATM-Cell [0003],
*Nov 17 11:27:42.460: L2X:   Ether-Vlan [0004], Ether [0005], HDLC [0006],
*Nov 17 11:27:42.460: L2X:   PPP [0007], ATM-VCC-Cell [0009],
*Nov 17 11:27:42.460: L2X:   ATM-VPC-Cell [000A], IP [000B]
*Nov 17 11:27:42.460: L2X: No missing AVPs in SCCRQ
*Nov 17 11:27:42.460: L2X: I SCCRQ, flg TLS, ver 3, len 122, tnl 0, ns 0, nr 0 
contiguous pak, size 122                                                         
*Nov 17 11:27:42.460: L2TP: I SCCRQ from NewYork tnl 27854
*Nov 17 11:27:42.460: Tnl37528 L2TP: Control connection authentication skipped/
passed.
*Nov 17 11:27:42.460: Tnl37528 L2TP: New tunnel created for remote NewYork,
  address 10.1.1.103                                                             
*Nov 17 11:27:42.460: Tnl37528 L2TP: O SCCRP  to NewYork tnlid 27854             
*Nov 17 11:27:42.460: Tnl37528 L2TP: O SCCRP, flg TLS, ver 3, len 122, tnl 27854,
  ns 0, nr 1                                                                     
*Nov 17 11:27:42.460: Tnl37528 L2TP: Control channel retransmit delay set to 2
seconds
*Nov 17 11:27:42.460: Tnl37528 L2TP: Tunnel state change from idle to wait-ctl-
reply
*Nov 17 11:27:42.536: Tnl37528 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Nov 17 11:27:42.536: Tnl37528 L2TP: Parse SCCCN
*Nov 17 11:27:42.536: Tnl37528 L2TP: No missing AVPs in SCCCN
*Nov 17 11:27:42.536: Tnl37528 L2TP: I SCCCN, flg TLS, ver 3, len 20, tnl 37528,
  ns 1, nr 1 contiguous pak, size 20                                            
*Nov 17 11:27:42.536: Tnl37528 L2TP: I SCCCN from NewYork tnl 27854
*Nov 17 11:27:42.536: Tnl37528 L2TP: Control connection authentication skipped/
passed.
*Nov 17 11:27:42.536: Tnl37528 L2TP: Tunnel state change from wait-ctl-reply to 
established                                                                     
*Nov 17 11:27:42.536: Tnl37528 L2TP: O ZLB ctrl ack, flg TLS, ver 3, len 12, tnl
  27854, ns 1, nr 2                                                             
*Nov 17 11:27:42.536: Tnl37528 L2TP: SM State established
! Debug output omitted for brevity
*Nov 17 11:28:12.552: Tnl37528 L2TP: O Hello to NewYork tnlid 27854             
*Nov 17 11:28:12.552: Tnl37528 L2TP: O Hello, flg TLS, ver 3, len 20, tnl 27854,
  ns 1, nr 3                                                                    
! Debug output omitted for brevity
*Nov 17 11:28:12.600: Tnl37528 L2TP: I ZLB ctrl ack, flg TLS, ver 3, len 12, tnl
37528, ns 3, nr 2
! Debug output omitted for brevity
*Nov 17 11:28:42.568: Tnl37528 L2TP: O Hello  to NewYork tnlid 27854             
*Nov 17 11:28:42.568: Tnl37528 L2TP: O Hello, flg TLS, ver 3, len 20, tnl 27854, 
  ns 2, nr 3                                                                     

Chapter 10. The SanFran router receives an inbound SCCRQ (I SCCRQ) from NewYork with multiple AVPs, such as Hostname and RWS. The control connection ID that NewYork allocates is 27854, which corresponds to the remote tunnel ID from the show l2tun tunnel all output demonstrated in the "Ethernet Port-to-Port Manual Session with Keepalive Verification" section of this case study. Also notice that the Pseudowire Capabilities List AVP includes Ethernet VLAN and Ethernet port pseudowires. Upon receipt of the SCCRQ, SanFran creates a new tunnel that has a local control connection ID of 37528 and replies with an SCCRP message. NewYork completes the negotiation of the control connection by sending an SCCCN message, which SanFran (I SCCCN) receives. SanFran acknowledges the SCCCN message with a Zero Length Body (ZLB) message.

After the control connection is established, Hello messages are sent periodically from each L2TPv3 endpoint and serve as a keepalive mechanism for dead peer detection. The Hello messages are acknowledged through the use of ZLB messages. Note that the time between the first Outbound Hello message (sent at 11:28:12) and the second Hello message (11:28:42) is 30 seconds. The 30-second interval coincides with the hello 30 configuration line defined in the SanFran PE router l2-keepalive template.

The purpose of configuring keepalives in this case study is to provide a means of detecting L2TPv3 peer loss. Whereas Example 11-14 illustrates control connection initialization, the next example demonstrates a control connection teardown for a different L2TPv3 tunnel with a local tunnel ID of 40786 and remote tunnel ID of 22379. More specifically, Example 11-15 shows the debug vpdn l2x-events output from the SanFran router during a core link failure, where it loses connectivity to its L2TPv3 peer, NewYork.

Example 11-15. SanFran debug vpdn l2x-events Output Control Connection Teardown

SanFran#
*Nov 20 15:11:55.979: Tnl40786 L2TP: O Hello to NewYork tnlid 22379             
*Nov 20 15:11:55.979: Tnl40786 L2TP: Control channel retransmit delay set to 2 
  seconds                                                                       
*Nov 20 15:11:57.999: Tnl40786 L2TP: O Resend Hello, flg TLS, ver 3, len 20, tnl
22379, ns 97, nr 98
*Nov 20 15:11:57.999: Tnl40786 L2TP: Control channel retransmit delay set to 4 
 seconds  
*Nov 20 15:12:01.999: Tnl40786 L2TP: O Resend Hello, flg TLS, ver 3, len 20, tnl
22379, ns 97, nr 98
*Nov 20 15:12:05.999: Tnl40786 L2TP: O Resend Hello, flg TLS, ver 3, len 20, tnl
22379, ns 97, nr 98
*Nov 20 15:12:10.019: Tnl40786 L2TP: O Resend Hello, flg TLS, ver 3, len 20, tnl
22379, ns 97, nr 98
*Nov 20 15:12:13.999: Tnl40786 L2TP: O Resend Hello, flg TLS, ver 3, len 20, tnl
22379, ns 97, nr 98
*Nov 20 15:12:17.999: Tnl40786 L2TP: O StopCCN to NewYork tnlid 22379            
*Nov 20 15:12:17.999: Tnl40786 L2TP: Tunnel state change from established to
shutting-down
*Nov 20 15:12:23.019: Tnl40786 L2TP: Shutdown tunnel 
*Nov 20 15:12:23.019: Tnl/Sn0/245 L2TP: Destroying session 
! Debug output omitted for brevity

Note

In Example 11-15, SanFran's Hello messages are unacknowledged via ZLB messages because of the loss of connectivity to NewYork. To display ZLB acknowledgements or the lack thereof, enable debug vpdn l2x-packets in Example 11-15.

Initially, SanFran sends a Hello at 15:11:55.979. Unfortunately, because of the link failure, the Hello message is not acknowledged via a ZLB message. As configured in retransmit retries 5, five retransmissions are sent at 15:11:57.999, 15:12.01.999, 15:12:05.999, 15:12:10.019, and 15:12:13.999. In SanFran's l2-keepalive template configuration, the retransmission intervals are bounded by the retransmit retries min 2 and retransmit retries max 4 values. Any subsequent retries use the max value when it is reached. After the final retransmission, the control channel is torn down and a Stop-Control-Connection-Notification (STOPCCN) message is sent at 15:12:17.999. Because the loss of connectivity to NewYork is detected, not only is the tunnel shut down, but its associated sessions are, too.

Example 11-16 captures the debug vpdn l2x-events output for SanFran's attempt to reinitialize the L2TPv3 control connection after it detects peer loss.

Example 11-16. SanFran debug vpdn l2x-events Output on Control Connection Reinitialization

*Nov 20 15:12:33.099: Tnl/Sn0/245 L2TP: Create session
*Nov 20 15:12:33.099: Tnl52029 L2TP: SM State idle
*Nov 20 15:12:33.099: Tnl52029 L2TP: O SCCRQ                                           
*Nov 20 15:12:33.099: Tnl52029 L2TP: Control channel retransmit delay set to 2 seconds 
*Nov 20 15:12:33.099: Tnl52029 L2TP: Tunnel state change from idle to wait-ctl-reply
*Nov 20 15:12:33.099: Tnl52029 L2TP: SM State wait-ctl-reply
*Nov 20 15:12:33.099: Tnl/Sn0/245 L2TP: L2TP: INSTALL: Manually configured
session using tunnel 52029 for keepalive support
*Nov 20 15:12:33.099: Tnl/Sn0/245 L2TP: Session state change from idle to wait-
for-tunnel
*Nov 20 15:12:35.119: Tnl52029 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 122,
tnl 0, ns 0, nr 0
*Nov 20 15:12:35.119: Tnl52029 L2TP: Control channel retransmit delay set to 4 seconds 
*Nov 20 15:12:39.119: Tnl52029 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 122, tnl
0, ns 0, nr 0
*Nov 20 15:12:39.119: Tnl52029 L2TP: Control channel retransmit delay set to 7 seconds 
*Nov 20 15:12:46.119: Tnl52029 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 122,
tnl 0, ns 0, nr 0
*Nov 20 15:12:53.119: Tnl52029 L2TP: O StopCCN                                         
*Nov 20 15:12:53.119: Tnl52029 L2TP: Tunnel state change from wait-ctl-reply to
shutting-down
*Nov 20 15:12:58.139: Tnl52029 L2TP: Shutdown tunnel
*Nov 20 15:12:58.139: Tnl/Sn0/245 L2TP: Destroying session

In Example 11-16, SanFran attempts to reinitialize the control channel by sending an SCCRQ request at 15:12:33.099. Although this is the continuation of the debug output from Example 11-15 where SanFran's local tunnel ID is 40786, the SanFran PE router is attempting to initialize a new control connection and has allocated a new local tunnel ID of 52029. Unfortunately, because connectivity to NewYork has not been restored yet, the SCCRQ is not acknowledged, and three SCCRQ attempts are sent at 15:12:35.119, 15:12:39.119, and 15:12:46.119 based on the retransmit retries initial 3 configuration. These retransmissions begin with the retransmit retries initial min 2 and double per retransmission up to the retransmit retries initial max 7. Because all three attempts fail, a STOPCCN is sent to tear down the control channel at 15:12:53.119.

Case Study 11-3: Ethernet Port-to-Port Dynamic Session

Although a manually defined session with keepalive provides some added benefit, this method still has some drawbacks. From a management perspective, manual sessions require the administrator to predefine the session IDs and cookies on each peer, whereas dynamic sessions automatically negotiate them. Furthermore, dynamic sessions can signal individual pseudowire session states.

This case study covers the configuration, verification, and control plane details of an Ethernet port-to-port dynamic session. Because the change from a manual to dynamic session primarily affects the control plane, the data plane details are the same as in Case Study 11-1 and are not reexamined.

Note

Although L2TPv3 dynamic sessions could signal the session state, the attachment circuit must have some management mechanism to indicate the health of its circuit to the CE device. Unfortunately, Ethernet presently does not have a management mechanism to signal individual Ethernet VLAN failures or Ethernet port failures outside of disabling the port, unlike Frame Relay or ATM. Therefore, although a pseudowire might have failed with dynamically negotiated sessions, the attachment circuits would not fail because Ethernet inherently does not support this capability.

Ethernet Port-to-Port Dynamic Configuration

This case study modifies the L2TPv3 configurations to dynamically negotiate the pseudowire sessions. The SanFran router configuration is shown in Example 11-17. A similar configuration exists on NewYork.

Example 11-17. SanFran Configuration

hostname SanFran
!
l2tp-class l2-dyn
authentication
password i8spr42
cookie size 8
!
pseudowire-class pw-dynamic
encapsulation l2tpv3
protocol l2tpv3 l2-dyn
ip local interface Loopback0
!
interface Ethernet0/0
no ip address
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.103 33 pw-class pw-dynamic

The general steps to provisioning a dynamic L2TPv3 session are similar to those in Ethernet port-to-port manual session with keepalives. However, a few differences are worth highlighting. Because the session is no longer manual, config-if-xconn submode configuration is not required. Instead, the xconnect command references a pseudowire-class called pw-dynamic in this example. Whereas previously the protocol type was none, it is now configured as protocol l2tpv3, which indicates that an L2TPv3 control channel is requested with dynamic session negotiation. Optionally, the protocol l2tpv3 command can also reference an l2tp-class template. In this case, because the service provider wants to implement an 8-byte L2TPv3 cookie, an l2tp-class called l2-dyn is defined with those characteristics. To revert to the default control channel timers, the explicit timer commands for Hello messages and control message retransmits have been removed. Another difference with the l2-dyn template is the use of authentication. To provide control channel authentication, this case study employs a shared secret by enabling the authentication keyword and defining a shared secret via the password shared-secret configuration.

Ethernet Port-to-Port Dynamic Session Verification

The same show commands that were used in the verification of manual session case studies are reused in this example. The show commands include the following:

show l2tun

show l2tun tunnel all

show l2tun session all

In fact, the majority of the output of the show l2tun and show l2tun tunnel all commands is similar, with only a few minor differences. Example 11-18 captures the output from the show l2tun command.

Example 11-18. SanFran show l2tun Output

SanFran#show l2tun
Tunnel and Session Information Total tunnels 1 sessions 1 
Tunnel control packets dropped due to failed digest 0
LocID RemID Remote Name   State  Remote Address Port Sessions L2TPclass
33819 41993 NewYork       est    10.1.1.103     0    1        l2-dyn
LocID      RemID     TunID       Username, Intf/                        State
Vcid, Circuit
23878      36820     33819       33, Et0/0                              est

One of the differences with the previous case is the session count. As in Example 11-12, both the total tunnels and sessions values are equal to 1 in the first line of output. However, in the tunnel summary information, the Sessions field is also 1. That is because this pseudowire session is negotiated dynamically against the L2TPv3 tunnel. Also notice that in the session summary information, the local LocID and RemID fields represent the local and remote session IDs. Unlike the manual session case studies, in which session IDs were configured explicitly under the xconnect command in the config-if-xconn submode, these values were negotiated dynamically via the control channel. The dynamic creation of the session and the negotiation of the session ID are examined in detail in the control plane negotiation.

Example 11-19 captures the output from the show l2tun tunnel all command.

Example 11-19. SanFran show l2tun all Output

SanFran#show l2tun tunnel all
Tunnel Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
Tunnel id 33819 is up, remote id is 41993, 1 active sessions 
Tunnel state is established, time since change 00:02:05
Tunnel transport is IP (115)
Remote tunnel name is NewYork
Internet Address 10.1.1.103, port 0
Local tunnel name is SanFran
Internet Address 10.1.1.102, port 0
Tunnel domain is
VPDN group for tunnel is -
L2TP class for tunnel is l2-dyn
38 packets sent, 37 received
3720 bytes sent, 3556 received
Control Ns 6, Nr 4
Local RWS 1024 (default), Remote RWS 1024 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 2
Total resends 0, ZLB ACKs sent 2
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
  Control message authentication is disabled                 

As highlighted in Example 11-19, because the pseudowire session is negotiated dynamically in the tunnel, one session is listed as active. The last line indicates that control message authentication is disabled. As described in the section "l2tp-class Command Syntax," the two methods of control channel authentication are an old style using a CHAP-like mechanism and a new style using message digests. The last line of highlighted output refers to the new style. Because the case study implements the old style of control channel authentication, the message shows the authentication as disabled.

The major differences in output between the manual and dynamic session case studies are reflected in the show l2tun session all command. Example 11-20 captures the output from the show l2tun session all command on the SanFran PE router.

Example 11-20. SanFran show l2tun session all Output

SanFran#show l2tun session all
Session Information Total tunnels 1 sessions 1
Tunnel control packets dropped due to failed digest 0
Session id 23878 is up, tunnel id 33819
Call serial number is 2931100006                                      
Remote tunnel name is NewYork
Internet address is 10.1.1.103
Session is L2TP signalled
Session state is established, time since change 00:02:11
39 Packets sent, 38 received
3780 Bytes sent, 3616 received
Receive packets dropped:
out-of-order:             0
total:                    0
Send packets dropped:
exceeded session MTU:     0
total:                    0
Session vcid is 33
Session Layer 2 circuit, type is Ethernet, name is Ethernet0/0
Circuit state is UP
    Remote session id is 36820, remote tunnel id 41993
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
  Session cookie information:                                         
    local cookie, size 8 bytes, value 34 D4 9E 24 6B AF AF CE         
    remote cookie, size 8 bytes, value F5 6A 1F 7F 1A 7B 12 BF        
FS cached header information:
encap size = 32 bytes
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Sequencing is off

The local session ID of 23878 and the remote session ID of 36820 is shown in the output. The second highlighted line in Example 11-20 lists the call serial number of 2931100006, which is a shared value between the L2TPv3 endpoints that uniquely references this pseudowire session. Finally, you can see that 8-byte session cookies are negotiated per the cookie size 8 command in the l2-dyn template. The session IDs, call serial number, and cookie values are also negotiated dynamically during session negotiation.

Ethernet Port-to-Port Dynamic Session Control Plane Details

Dynamic negotiation of the control plane takes place in two phases:

Control connection (tunnel) establishment

Session (pseudowire) establishment

Although the debug vpdn l2x-events command displays these events, you can obtain further detail with the debug vpdn l2x-packets command, which displays the AVPs contained in each control message. The debug output from the control connection establishment phase is captured on the SanFran router and displayed in Example 11-21.

Example 11-21. SanFran debug vpdn l2x-events and debug vpdn l2x-packet Output for Control Connection Establishment Phase

SanFran#
*Nov 22 07:34:46.445: Tnl33819 L2TP: O SCCRQ  
*Nov 22 07:34:46.445: Tnl33819 L2TP: O SCCRQ, flg TLS, ver 3, len 144, tnl 0,
  ns 0, nr 0                                                                      
*Nov 22 07:34:46.445: Tnl33819 L2TP: Control channel retransmit delay set to
1 seconds
*Nov 22 07:34:46.445: Tnl33819 L2TP: Tunnel state change from idle to wait-ctl-
reply
*Nov 22 07:34:46.445: Tnl33819 L2TP: SM State wait-ctl-reply
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse SCCRP 
! AVP 2 Protocol Version, AVP 6 Firmware Version, AVP 10 Rx Window Size, Cisco AVP
8 Vendor Name, and Cisco AVP 10 Vendor AVP version omitted for brevity
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse AVP 7, len 13, flag 0x8000 (M)
*Nov 22 07:34:46.525: Tnl33819 L2TP: Hostname NewYork
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse AVP 11, len 22, flag 0x8000 (M) 
*Nov 22 07:34:46.525: Tnl33819 L2TP: Chlng  
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse AVP 13, len 22, flag 0x8000 (M) 
*Nov 22 07:34:46.525: Tnl33819 L2TP: Chlng Resp 
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse Cisco AVP 1, len 10, flag 0x8000 (M)
*Nov 22 07:34:46.525: Tnl33819 L2TP: Assigned Control Connection ID 41993
*Nov 22 07:34:46.525: Tnl33819 L2TP: Parse Cisco AVP 2, len 22, flag 0x8000 (M)
*Nov 22 07:34:46.525: Tnl33819 L2TP: Pseudo Wire Capabilities List:
! Pseudo Wire Capabilities List omitted for brevity
*Nov 22 07:34:46.525: Tnl33819 L2TP: No missing AVPs in SCCRP
*Nov 22 07:34:46.525: Tnl33819 L2TP: I SCCRP, flg TLS, ver 3, len 166, tnl 33819,
  ns 0, nr 1 contiguous pak, size 166                                             
*Nov 22 07:34:46.525: Tnl33819 L2TP: I SCCRP from NewYork 
*Nov 22 07:34:46.525: Tnl33819 L2TP: Got a challenge in SCCRP, NewYork
*Nov 22 07:34:46.525: Tnl33819 L2TP: Got a response in SCCRP, from remote peer
NewYork
*Nov 22 07:34:46.525: Tnl33819 L2TP: Tunnel Authentication success
*Nov 22 07:34:46.525: Tnl33819 L2TP: Control connection authentication skipped/
passed.
*Nov 22 07:34:46.525: Tnl33819 L2TP: Tunnel state change from wait-ctl-reply to
established
*Nov 22 07:34:46.525: Tnl33819 L2TP: O SCCCN to NewYork tnlid 41993 
*Nov 22 07:34:46.525: Tnl33819 L2TP: O SCCCN, flg TLS, ver 3, len 42, tnl 41993, 
  ns 1, nr 1                                                                      
*Nov 22 07:34:46.525: Tnl33819 L2TP: Control channel retransmit delay set to
1 seconds
*Nov 22 07:34:46.525: Tnl33819 L2TP: SM State established

In this case, SanFran initiates the control channel request by sending out an SCCRQ. SanFran's debug output shows the outbound SCCRQ request in addition to the dynamically chosen tunnel ID of 33819. Although it is not shown in this outbound message, the SCCRQ contains SanFran's Challenge AVP sent to NewYork. The Challenge AVP contains a random value used in the CHAP-like control channel authentication mechanism. In response to the SCCRQ, NewYork sends an SCCRP message. SanFran receives this message, and the debug output lists the various AVPs contained in the message. Two notable AVPs include NewYork's Challenge AVP and NewYork's Challenge Response AVP. In this case, NewYork's Challenge Response AVP contains the output of the hashing function performed against SanFran's Challenge AVP value and the shared secret. For the control channel message to be validated properly, the SanFran router performs the same hashing mechanism and compares the output to the received Challenge Response AVP value. If the shared secret from both peers is equal, the two values are equivalent. Another AVP that is sent in the SCCRP is NewYork's Control Connection ID value of 41993, which matches the output from the show l2tun tunnel command. To complete the three-way handshake, SanFran responds with an SCCCN. The SCCCN contains a Challenge Response AVP that is not shown in outbound debugs. The SCCCN Challenge Response AVP is sent in reply to NewYork's Challenge AVP sent in the SCCRP.

Example 11-22 contains the debug output from the second part of the negotiation: the session establishment phase.

Example 11-22. SanFran debug vpdn l2x-events and debug vpdn l2x-packet Output for Session Establishment Phase

SanFran#
*Nov 22 07:34:46.525:  Tnl/Sn33819/23878 L2TP: O  ICRQ to NewYork 41993/0 
*Nov 22 07:34:46.525: Tnl/Sn33819/23878 L2TP: O ICRQ, flg TLS, ver 3, len 94, tnl 41993,
lsid 23878, rsid 0, ns  2, nr 1                                                          
*Nov 22 07:34:46.525: Tnl/Sn33819/23878 L2TP: Session state change from wait-for-tunnel
to wait-reply
*Nov 22 07:34:46.573:  Tnl33819 L2TP: Early authen passing ZLB
*Nov 22 07:34:46.573: Tnl33819 L2TP: I ZLB ctrl ack, flg TLS, ver 3, len 12, tnl 33819,
ns 1, nr  3
*Nov 22 07:34:46.665: Tnl33819 L2TP: Perform early message digest validation for ICRP
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M) 
*Nov 22 07:34:46.665: Tnl33819 L2TP: Local Session ID 36820 
*Nov 22 07:34:46.665: Tnl33819 L2TP: Control connection authentication skipped/passed.
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse AVP 0, len 8,  flag 0x8000 (M)
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse ICRP  
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M)
*Nov 22 07:34:46.665: Tnl33819 L2TP: Local Session ID 36820  
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M)
*Nov 22 07:34:46.665: Tnl33819 L2TP: Remote Session ID 23878 
*Nov 22 07:34:46.665: Tnl33819 L2TP: Parse Cisco AVP 5, len 14, flag 0x8000 (M)
*Nov 22 07:34:46.665: Tnl33819 L2TP: Assigned Cookie      
         F5 6A 1F 7F  1A 7B 12 BF                                                        
*Nov 22 07:34:46.665:  Tnl33819 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Nov 22 07:34:46.665:  Tnl33819 L2TP: Pseudo Wire Type 5  
*Nov 22 07:34:46.665:  Tnl33819 L2TP: No missing AVPs in ICRP
*Nov 22 07:34:46.665: Tnl/Sn33819/23878 L2TP: I ICRP, flg TLS, ver 3, len 62, tnl 33819, 
lsid 23878, rsid 0, ns  1, nr 3 contiguous pak, size  62                                 
*Nov 22 07:34:46.665:  Tnl/Sn33819/23878 L2TP: O ICCN to NewYork 41993/36820 
*Nov 22 07:34:46.665: Tnl/Sn33819/23878 L2TP: O ICCN, flg TLS, ver 3, len 50, tnl 41993,
lsid 23878, rsid  36820, ns 3, nr 2                                                      
*Nov 22 07:34:46.665: Tnl33819 L2TP: Control channel retransmit delay set to 1 seconds
*Nov 22 07:34:46.665: Tnl/Sn33819/23878 L2TP: Session state change from wait-reply to 
established                                                                              

After successfully initiating a control channel, the session negotiation begins. SanFran sends an Incoming-Call Request (ICRQ), which contains several AVPs, including a dynamically assigned Session ID of 23878, Cookie, End Identifier, and Serial Number AVP that is not shown in the outbound debug output. The End Identifier AVP equals the VC ID that is configured on the xconnect command, 33. This AVP allows the pseudowire to associate itself to the necessary attachment circuit. The Serial Number is equivalent to the Call Serial Number field identified in the show l2tunn sess all output. It serves as an identifier for the session that is consistent on both peers.

In response to the ICRQ, NewYork sends an Incoming-Call Reply (ICRP) message with several AVPs. The ICRP contains a Local Session ID AVP of 36820, a Remote Session ID AVP of 23878, an Assigned Cookie AVP of 0xF56A1F7F1A7B12BF, and a Pseudowire Type AVP. A Pseudowire Type AVP is included to identify the type of pseudowire that is being negotiated, which in this case is 0x0005 for type Ethernet. Keep in mind that the Local and Remote Session ID values and the Assigned Cookies in the ICRP message are from NewYork's perspective. When you compare them to SanFran's show l2tunn sess all output in Example 11-20, the values correspond to appropriate SanFran fields (that is, SanFran's Local Session ID equals NewYork's Remote Session ID). Finally, SanFran completes this three-way handshake with the Incoming-Call Connected (ICCN) message. After the ICCN message is sent, the pseudowire session is fully established.

Case Study 11-4: Ethernet VLAN-to-VLAN Dynamic Session

In this case study, the customer has modified his design. The Oakland hub site now needs to have connectivity to branch offices in Albany and Hudson. The customer would like to use a dot1Q trunk from the Oakland router to connect a separate VLAN to each branch office site.

To meet the customer requirements, the service provider has decided to utilize L2TPv3 to transport the necessary VLANs. You can see an illustration of the new design in Figure 11-5. Oakland's VLAN 201 attachment circuit is connected via a pseudowire session to VLAN 201 at Albany. Similarly, Oakland's VLAN 200 attachment circuit is connected to VLAN 140 at Hudson. In the latter case, the NewYork router must rewrite the original VLAN header tag with the value of 140 so that the Ethernet frames are properly understood at Hudson.

This case study explores the configuration, verification, control plane details, and data plane details for an Ethernet VLAN-to-VLAN dynamic session.

Ethernet VLAN-to-VLAN Dynamic Configuration

Similar to "Case Study 11-3: Ethernet Port-to-Port Dynamic Session," the SanFran and NewYork PE routers use dynamically negotiated VLAN L2TPv3 sessions with 8-byte cookies. To introduce a new concept in this case study, the PE routers are configured to use the new control channel authentication by utilizing message digests.

Example 11-23 shows the relevant configuration in the SanFran routers.

Example 11-23. SanFran VLAN-to-VLAN Dynamic Configuration

hostname SanFran
!
l2tp-class l2-dyn
 digest secret p7jd8ge                           
cookie size 8
!
pseudowire-class pw-dynamic
encapsulation l2tpv3
protocol l2tpv3 l2-dyn
ip local interface Loopback0
interface Ethernet0/0
no ip address
no ip directed-broadcast
no cdp enable
interface Ethernet0/0.200                        
encapsulation dot1Q 200
no ip directed-broadcast
no cdp enable
 xconnect 10.1.1.103 33 pw-class pw-dynamic      
!
interface Ethernet0/0.201                        
encapsulation dot1Q 201
no ip directed-broadcast
no cdp enable
 xconnect 10.1.1.103 34 pw-class pw-dynamic      

Example 11-24 contains the configuration for the NewYork router.

Example 11-24. NewYork VLAN-to-VLAN Dynamic Configuration

hostname NewYork
!
l2tp-class l2-dyn
 digest secret p7jd8ge                           
cookie size 8
!
pseudowire-class pw-dynamic
encapsulation l2tpv3
protocol l2tpv3 l2-dyn
ip local interface Loopback0
!
interface Ethernet0/0
no ip address
no ip directed-broadcast
no cdp enable
!
interface Ethernet0/0.201                        
encapsulation dot1Q 201
no ip directed-broadcast
no cdp enable
 xconnect 10.1.1.102 34 pw-class pw-dynamic      
!
interface Ethernet1/0
no ip address
no ip directed-broadcast
no cdp enable
!
interface Ethernet1/0.140                        
encapsulation dot1Q 140
no ip directed-broadcast
no cdp enable
 xconnect 10.1.1.102 33 pw-class pw-dynamic      
!

The general steps to provisioning a dynamic Ethernet VLAN-to-VLAN session are similar to those in the Ethernet port-to-port dynamic session. The major difference is that the attachment circuit in this case study is the Ethernet VLAN. Therefore, the xconnect statements are configured under the appropriately tagged Ethernet subinterfaces, as highlighted in Example 11-23 and 11-24.

Because this case study introduces the new form of control channel authentication, the digest secret password configuration is applied underneath the l2tp-class command.

Ethernet VLAN-to-VLAN Dynamic Session Verification

The show l2tun tunnel and show l2tun session output is similar to the previous dynamic port-to-port session. Example 11-25 contains the show l2tun tunnel output detail for SanFran.

Example 11-25. SanFran VLAN-to-VLAN Dynamic Session show l2tun tunnel Output

SanFran#show l2tun tunnel
Tunnel Information Total tunnels 1 sessions 2 
Tunnel control packets dropped due to failed digest 0
LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TPclass
41796 8769  NewYork       est    10.1.1.103      0     2        l2-dyn

Notice in Example 11-25 that the number of sessions is two because of the two pseudowire sessions for the two VLANs in this case study. The two sessions are negotiated against the same tunnel; therefore, they are listed against the L2TPv3 tunnel with a local ID of 41796.

Example 11-26 captures the show l2tun session and show l2tunnel session all detail for VCID 34.

Example 11-26. SanFran VLAN-to-VLAN Dynamic Session show l2tun session Output

SanFran#show l2tun session
Session Information Total tunnels 1 sessions 2
Tunnel control packets dropped due to failed digest 0
LocID      RemID      TunID      Username,  Intf/                           State
Vcid,  Circuit
23944      36877      41796      34, Et0/0.201:201                          est
23945      36878      41796      33, Et0/0.200:200                          est
SanFran#show l2tun session all vcid 34
Session Information Total tunnels 1 sessions 2
Tunnel control packets dropped due to failed digest 5
Session id 23944 is up, tunnel id 41796
Call serial number is 2931100013
Remote tunnel name is NewYork
Internet address is 10.1.1.103
  Session is L2TP signalled                                                   
Session state is established, time since change 00:13:11
93 Packets sent, 91 received
9306 Bytes sent, 8950 received
Receive packets dropped:
out-of-order:             0
total:                    0
Send packets dropped:
exceeded session MTU:     0
total:                    0
Session vcid is 34
Session Layer 2 circuit, type is Ethernet Vlan, name is Ethernet0/0.201:201 
Circuit state is UP
Remote session id is 36877, remote tunnel id 8769
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
Session cookie information:
local cookie, size 8 bytes, value E9 B8 78 B2 C2 6C 8E 16
remote cookie, size 8 bytes, value 88 9E DD 75 03 A0 39 75
FS cached header information:
encap size = 32 bytes
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Sequencing is off

The primary differences in the output when compared to Case Study 11-3 are related to the attachment circuit type. In the show l2tun session output in Example 11-26, notice the two session lines for the two VCIDs 34 and 33 and their corresponding attachment circuits Et0/0.201 and Et0/0.200, respectively.

The show l2tun session all vcid 34 output includes more specific details about that particular attachment circuit. Unlike the manual case studies, Example 11-26 shows the session as L2TP signaled, indicating that the pseudowire was negotiated dynamically. Also, as highlighted midway in the show l2tun session all vcid 34 output, the type of pseudowire session is Ethernet VLAN, whereas in previous Ethernet port-to-port case studies, the pseudowire type was just Ethernet.

Ethernet VLAN-to-VLAN Dynamic Session Control Plane Details

As with any dynamically negotiated L2TPv3 session, the control channel setup and session negotiation can be monitored via debug vpdn l2x-events and debug vpdn l2x-packets. Example 11-27 captures this debug output for SanFran's control channel establishment phase.

Example 11-27. SanFran debug vpdn l2x-events and debug vpdn l2x-packets on Control Connection Initialization

SanFran#
*Nov 22 13:19:04.312: Tnl/Sn41796/23944 L2TP: Create session
*Nov 22 13:19:04.312: Tnl41796 L2TP: SM State idle
*Nov 22 13:19:04.312: Tnl41796 L2TP: O SCCRQ  
*Nov 22 13:19:04.312: Tnl41796 L2TP: O SCCRQ, flg TLS, ver 3, len 167, tnl 0, 
  ns 0, nr 0                                                                     
*Nov 22 13:19:04.312: Tnl41796 L2TP: Control channel retransmit delay set to
1 seconds
*Nov 22 13:19:04.312: Tnl41796 L2TP: Tunnel state change from idle to
wait-ctl-reply
*Nov 22 13:19:04.312: Tnl41796 L2TP: SM State wait-ctl-reply
*Nov 22 13:19:04.312: L2X: L2TP: Received L2TUN message <Connect>
*Nov 22 13:19:04.312: Tnl/Sn41796/23945 L2TP: Session state change from idle to
wait-for-tunnel
*Nov 22 13:19:04.312: Tnl/Sn41796/23945 L2TP: Create session
*Nov 22 13:19:04.312: Tnl41796 L2TP: SM State wait-ctl-reply
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse SCCRP 
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse Cisco AVP 12, len 23, flag 0x8000 (M) 
*Nov 22 13:19:04.372: Tnl41796 L2TP: Message Digest 
! Message Digest hex output omitted for brevity
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse Cisco AVP 13, len 22, flag 0x8000 (M) 
*Nov 22 13:19:04.372: Tnl41796 L2TP: CC Auth Nonce  
         D7 6E BB ED 3D 01 33 31 0E 45 1A E7 67 24 4E A1                            
! AVP 2 Protocol Version ,AVP 6 Firmware Version, AVP 10 Rx Window Size, Cisco
AVP 8 Vendor Name, and Cisco AVP 10 Vendor AVP version omitted for brevity
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse AVP 7, len 13, flag 0x8000 (M)
*Nov 22 13:19:04.372: Tnl41796 L2TP: Hostname NewYork
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse Cisco AVP 1, len 10, flag 0x8000 (M)
*Nov 22 13:19:04.372: Tnl41796 L2TP: Assigned Control Connection ID 8769 
*Nov 22 13:19:04.372: Tnl41796 L2TP: Parse Cisco AVP 2, len 22, flag 0x8000 (M)
*Nov 22 13:19:04.372: Tnl41796 L2TP: Pseudo Wire Capabilities List:
! Pseudo Wire Capabilities List omitted for brevity
*Nov 22 13:19:04.372: Tnl41796 L2TP: No missing AVPs in SCCRP
*Nov 22 13:19:04.372: Tnl41796 L2TP: I SCCRP, flg TLS, ver 3, len 167, tnl 41796, 
  ns 0, nr 1 contiguous pak, size 167                                               
*Nov 22 13:19:04.372: Tnl41796 L2TP: I SCCRP from NewYork 
*Nov 22 13:19:04.372: Tnl41796 L2TP: Message digest match performed, passed.
*Nov 22 13:19:04.372: Tnl41796 L2TP: Control connection authentication skipped/
passed.
*Nov 22 13:19:04.372: Tnl41796 L2TP: Tunnel state change from wait-ctl-reply to
established
*Nov 22 13:19:04.372: Tnl41796 L2TP: O SCCCN to NewYork tnlid 8769  
*Nov 22 13:19:04.372: Tnl41796 L2TP: O SCCCN, flg TLS, ver 3, len 43, tnl 8769,   
  ns 1, nr 1                                                                        
*Nov 22 13:19:04.372: Tnl41796 L2TP: Control channel retransmit delay set to
1 seconds
*Nov 22 13:19:04.372: Tnl41796 L2TP: SM State established

One notable difference in the control channel establishment is that a few additional AVPs are used during the SCCRQ/SCCRP/SCCCN three-way handshake. As is typical, the three-way handshake begins with SanFran sending an SCCRQ message. The SCCRQ contains a Message Digest and a Control Message Authentication Nonce AVP. As described in Chapter 10, these AVPs are used in control channel authentication. More specifically, they are used in the newer form of control channel authentication, unlike Case Study 11-3, which uses the CHAP-like mechanism.

The second step in the three-way handshake involves SanFran sending an SCCRP reply. This SCCRP message, like the SCCRQ message, contains a Message Digest and a Control Message Authentication Nonce AVP, as highlighted in Example 11-27. All subsequent control channel messages will contain the Message Digest AVP.

The third and final step in the control channel initialization is an SCCCN message sent from SanFran.

Example 11-28 captures this debug output for SanFran's session establishment phase.

Example 11-28. SanFran debug vpdn l2x-events and debug vpdn l2x-packets on Session Initialization

SanFran#
*Nov 22 13:19:04.372: Tnl/Sn41796/23944 L2TP: O ICRQ to NewYork 8769/0 
*Nov 22 13:19:04.372: Tnl/Sn41796/23944 L2TP: O ICRQ, flg TLS, ver 3, len 117, 
  tnl 8769, lsid 23944, rsid 0, ns 2, nr 1                                      
*Nov 22 13:19:04.372: Tnl/Sn41796/23944 L2TP: Session state change from
wait-for-tunnel to wait-reply
*Nov 22 13:19:04.420: Tnl41796 L2TP: Perform early message digest validation
for ACK
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 12, len 23, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Message Digest  
! Message Digest hex output omitted for brevity
*Nov 22 13:19:04.420: Tnl41796 L2TP: Message digest match performed, passed.
*Nov 22 13:19:04.420: Tnl41796 L2TP: Control connection authentication skipped/
passed.
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse ICRP  
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 12, len 23, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Local Session ID 36877 
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Remote Session ID 23944 
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 5, len 14, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Assigned Cookie
88 9E DD 75 03 A0 39 75
*Nov 22 13:19:04.420: Tnl41796 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Nov 22 13:19:04.420: Tnl41796 L2TP: Pseudo Wire Type 4 
*Nov 22 13:19:04.420: Tnl41796 L2TP: No missing AVPs in ICRP
*Nov 22 13:19:04.420: Tnl/Sn41796/23944 L2TP: I ICRP, flg TLS, ver 3, len 85, 
  tnl 41796, lsid 23944, rsid 0, ns 1, nr 3 contiguous pak, size 85               
*Nov 22 13:19:04.420: Tnl/Sn41796/23944 L2TP: O ICCN to NewYork 8769/36877    
*Nov 22 13:19:04.420: Tnl/Sn41796/23944 L2TP: O ICCN, flg TLS, ver 3, len 73, 
  tnl 8769, lsid 23944, rsid 36877, ns 4, nr 2                                    
*Nov 22 13:19:04.420: Tnl/Sn41796/23944 L2TP: Session state change from
wait-reply to established

After the control channel is authenticated, the session negotiation occurs. Because this case study utilizes two pseudowires, two three-way ICRQ/ICRP/ICCN phases are initiated. For the sake of brevity, Example 11-28 only captures the three-way session negotiation for VCID 34. As highlighted in the output, SanFran sends an ICRQ message for local session ID 23944. In response, SanFran receives an ICRP message from NewYork. The ICRP message contains NewYork's local session ID of 36877. The pseudowire type is type 4 for Ethernet VLAN. Also notice that the Message Digest AVP is contained in the ICRP message. In fact, the Message Digest AVP is also contained in the ICRQ and ICCN messages, but the debug output does not show this level of detail for outbound messages. Finally, SanFran sends an ICCN to NewYork to fully establish the pseudowire session.

Ethernet VLAN-to-VLAN Frame Encapsulation

The L2TPv3 data frame encapsulation for a VLAN-emulated session is comparable to the port-emulated session except that the Ethernet frame carries the Ethernet frames that are specific to the attachment circuit VLAN ID. Example 11-29 captures an Ethereal decode and the hexadecimal capture of an L2TPv3 frame from the Oakland Ethernet subinterface E0/0.201 to Albany E0/0.201.

Example 11-29. Ethereal Decode and Capture of Oakland to Albany ICMP Ping

Cisco HDLC                                                                             
Address: Unicast (0x0f)
Protocol: IP (0x0800)
Internet Protocol, Src Addr: 10.1.1.102 (10.1.1.102), Dst Addr: 10.1.1.103 (10.1.1.103)
Version: 4
Header length: 20 bytes
! IP header DSCP, Flags detail, Fragment offset and TTL omitted for brevity
Protocol: Layer 2 Tunneling (0x73)
Header checksum: 0x3a3e (correct)
Source: 10.1.1.102 (10.1.1.102)
Destination: 10.1.1.103 (10.1.1.103)
Layer 2 Tunneling Protocol version 3                                                   
Session ID: 36877
Cookie: 889EDD7503A03975
Ethernet II, Src: 00:00:0c:00:6c:00, Dst: 00:00:0c:00:6f:00
Destination: 00:00:0c:00:6f:00 (00:00:0c:00:6f:00)
Source: 00:00:0c:00:6c:00 (00:00:0c:00:6c:00)
Type: 802.1Q Virtual LAN (0x8100)
802.1q Virtual LAN                                                                     
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 1100 1001 = ID: 201
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.2.1 (192.168.2.1), Dst Addr: 192.168.2.2
(192.168.2.2)
Version: 4
Header length: 20 bytes
! IP header DSCP, Flags detail, Fragment offset and TTL omitted for brevity
Protocol: ICMP (0x01)
Header checksum: 0x31be (correct)
Source: 192.168.2.1 (192.168.2.1)
Destination: 192.168.2.2 (192.168.2.2)
Internet Control Message Protocol                                                      
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xb7fa (correct)
Identifier: 0x000e
Sequence number: 0x0000
Data (72 bytes)
0000  0f 00 08 00 45 00 00 96 69 e8 00 00 ff 73 3a 3e 
^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cisco HDLC  IPv4  Delivery  Header (IP Protocol L2TPv3)
0010  0a 01 01 66 0a 01 01 67 00 00 90 0d 88 9e dd 75 
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
IPv4 Delivery Header          L2TPv3 Header
0020  03 a0 39 75 00 00 0c 00 6f 00 00 00 0c 00 6c 00 
^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
L2TPv3  Header L2TPv3 Payload  (Ethernet II Frame)
0030  81 00 00 c9 08 00 45 00 00 64 04 87 00 00 ff 01 
^^^^^  ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ethertype .1q  VLANID     IPv4 Hdr  (ICMP packet)
0040  31 be c0 a8 02 01 c0 a8 02 02 08 00 b7 fa 00 0e 
^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
IPv4 Hdr  (ICMP packet)         ICMP packet
!remainder omitted for brevity

Because the Ethereal capture was performed between the SanFran and Denver routers, the first Layer 2 header is the HDLC frame. The outer IP Delivery header is sourced from SanFran's loopback address of 10.1.1.102 (0x0a010166), destined to NewYork's address of 10.1.1.103 (0x0a010167). The L2TPv3 header consists of NewYork's local session ID of 36877 (0x0000900d) and a cookie value of 0x889edd7503a03975. Following the L2TPv3 header is the Ethernet II frame destined to Albany's MAC address of 0x00000c006c00 and sourced from Oakland's Ethernet port with MAC address 0x00000c006f00. In this particular case, the Ethernet frame is an 802.1q tagged frame that contains the VLAN tag protocol ID of 0x8100, a 3-bit VLAN CoS field of 0, a 1-bit VLAN canonical format indicator of 0, and the VLAN ID tag of 201. Because the far-end router's attachment circuit also uses a dot1Q tag of 201, NewYork does not change the original VLAN ID tag before sending it to the CE device. However, in the case of an Ethernet frame from Oakland to Hudson, the original VLAN ID tag of 200 would have to be rewritten to the far-end attachment circuit VLAN ID value of 140.

Case Study 11-2 focused on providing VLAN-to-VLAN emulation. It examined scenarios in which the VLAN header was transported unmodified (that is, between Oakland and Albany) and in which the VLAN header was rewritten (that is, between Oakland and Hudson). You need to consider several design issues when deploying such a solution.

In this VLAN-to-VLAN case study, the service provider dictates the VLAN values. From a customer perspective, this might be a heavy restriction. In such a scenario, the customer can use QinQ to alleviate this requirement. In essence, the customer can use the inner 802.1q tag in QinQ to represent the customer VLANs and then set the outer 802.1q tag to equal the value that the service provider requires. This allows for flexibility on the customer's behalf to use any VLAN rewrite.

Another consideration when dealing with VLAN-to-VLAN transport revolves around spanning tree. In the Oakland-to-Hudson scenario, the respective L2TPv3 endpoints rewrite the VLAN header as needed. Although the VLAN header is rewritten, the BPDU payload also contains a field known as the Per VLAN ID (PVID), which is not rewritten. If spanning tree is enabled in such a VLAN rewrite scenario, the BPDUs show a mismatch and the ports are blocked. The only solution is to avoid this rewrite scenario so that the BPDU payload matches the expected VLAN ID value on either end.