Troubleshooting L2TPv3
The L2TPv3 troubleshooting process depends on whether you are using dynamic session establishment or static session configuration. One common element is the control connection (assuming that it is configured with static sessions).
This section is split into three subsections:
The first subsection focuses on control connection establishment.
The second subsection focuses on dynamic session setup.
The third subsection focuses on static session configuration.
Troubleshooting L2TPv3 with dynamic session setup consists of troubleshooting control connection establishment and then troubleshooting dynamic session setup itself.
Troubleshooting L2TPv3 with static session configuration consists of troubleshooting control connection establishment (if configured), and then the static session configuration itself.
The flowchart in Figure 5-18 describes the troubleshooting process used with L2TPv3. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.
Figure 5-19 shows the sample topology used to illustrate the concepts in the sections that follow.
In Figure 5-19, frames received by London_LCCE/PE on interface serial 4/1 from mjlnet_CE1 are forwarded over an L2TPv3 session to Frankfurt_LCCE/PE. Frankfurt_LCCE/PE then forwards these frames out of interface serial 2/1 to mjlnet_CE2.
Frames received by London_LCCE/PE on interface Fast Ethernet 1/0.1 are forwarded over an L2TPv3 session to Frankfurt_LCCE/PE. Frankfurt_LCCE/PE then forwards the frames out of interface Fast Ethernet 0/0.1.
Similarly, frames received by Frankfurt_LCCE/PE on interface serial 2/1 from mjlnet_CE2 are forwarded over an L2TPv3 session to London_LCCE/PE. London_LCCE/PE then forwards these frames out of interface serial 4/1 to mjlnet_CE1.
Frames received by Frankfurt_LCCE/PE on interface Fast Ethernet 0/0.1 are forwarded over an L2TPv3 session to London_LCCE/PE. London_LCCE/PE then forwards the frames out of interface Fast Ethernet 1/0.1.
Note that although Figure 5-19 shows only one L2TPv3 session, two would in fact be required, one for each pair of attachment circuits.
Troubleshooting L2TPv3 Control Connection Setup
The first step in the L2TPv3 troubleshooting process is to verify control connection establishment, which is illustrated in Figure 5-20.
In Figure 5-20, the first attachment circuit changes state to active (up), and control connection establishment begins.
Before examining how control connection establishment can fail, it is useful to first have a look at a successful control connection establishment sequence.
The control connection establishment sequence can be examined using the debug vpdn l2x-events command, as shown in Example 5-15. Note that only the relevant portion of the output is shown.
Example 5-15. Successful Control Connection Establishment
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on *Mar 30 18:41:08.751 UTC: L2X: l2tun session [1646198216], event [client request], old state [open], new state [open] *Mar 30 18:41:08.751 UTC: L2X: L2TP: Received L2TUN message <Connect> *Mar 30 18:41:08.755 UTC: Tnl/Sn26577/62344 L2TP: Session state change from idle to wait-for-tunnel *Mar 30 18:41:08.755 UTC: Tnl/Sn26577/62344 L2TP: Create session *Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: SM State idle *Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: O SCCRQ *Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: Tunnel state change from idle to wait-ctl-reply *Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: SM State wait-ctl-reply *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: I SCCRP from Frankfurt_LCCE *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Got a challenge from remote peer, Frankfurt_LCCE *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Got a response from remote peer, Frankfurt_LCCE *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Tunnel Authentication success *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Tunnel state change from wait-ctl-reply to established *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: O SCCCN to Frankfurt_LCCE tnlid 63650 *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: SM State established London_LCCE# |
In highlighted line 1, London_LCCE sends a SCCRQ to Frankfurt_LCCE initiating control connection establishment. Authentication is enabled on London_LCCE, and so this SCCRQ contains a Challenge AVP.
An SCCRP is then received from Frankfurt_LCCE in highlighted line 2. Note that the hostname Frankfurt_LCCE is carried in the SCCRP using the Hostname AVP.
Also contained in the SCCRP are an authentication Challenge AVP and a Challenge Response AVP (highlighted lines 3 and 4). The Challenge Response corresponds to the Challenge in the SCCRQ sent by London_LCCE in highlighted line 1.
Note that the Challenge and Challenge Response AVPs will be replaced by the Message Digest and Control Message Authentication Nonce AVPs in later implementations of L2TPv3. Later versions of Cisco IOS Software will also be able to support Challenge and Challenge Response AVPs if configured to do so.
In highlighted line 5, London_LCCE reports that authentication has been successful. Then in highlighted line 6, London_LCCE sends an SCCCN. This completes control connection establishment, and in highlighted line 7, the L2TPv3 state machine (SM) state changes to established.
The control connection is now up. This can be confirmed using the show l2tun tunnel command, as shown in Example 5-16.
Example 5-16. Control Connection Is Established
London_LCCE#show l2tun tunnel Tunnel Information Total tunnels 1 sessions 2 LocID RemID Remote Name State Remote Address Port Sessions L2TPclass 33028 43495 Frankfurt_LCC est 10.1.1.2 0 2 FrankfurtV3Clas London_LCCE# |
Highlighted line 1 shows that one control connection and two data sessions have been established. Note that session establishment is not shown in Example 5-15.
In highlighted line 2, the local and remote control connection IDs are shown, together with the remote LCCE's hostname (Frankfurt_LCCE), control connection state (established), the remote LCCE's IP address (10.1.1.2), the number of sessions established (2), and the associated L2TP class (FrankfurtV3Class).
Control connection setup can fail for number of reasons, including the following:
There is no IP connectivity between the LCCEs' source addresses (loopback interfaces).
The peer LCCE's IP address is misconfigured (with the xconnect command).
An access list blocks IP protocol 115.
L2TPv3 authentication fails.
Use extended ping to ensure that there is basic IP connectivity between the local and remote LCCEs' source addresses (usually loopback interface IP addresses). If a ping test fails, begin regular IP troubleshooting. Note that a ping test will test only ICMP ECHO Request and ICMP ECHO Reply connectivity between LCCEs.
Other issues affecting control connection establishment (listed above) are examined in the following three sections.
Peer LCCE's IP Address Is Misconfigured (with the xconnect Command)
If the remote LCCE's IP address is misconfigured on the local LCCE, control connection establishment will fail.
It is worth noting that if multiple pseudowires are configured between LCCE peers, as long as one pseudowire is correctly configured (with the xconnect command), then the control connection will be successfully established.
Use the debug vpdn l2x-events command to troubleshoot this issue, as shown in Example 5-17. Note that only the relevant portion of the output is shown.
Example 5-17. Control Connection Establishment Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on London_LCCE# *Mar 30 21:20:53.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449 *Mar 30 21:20:54.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449 *Mar 30 21:20:56.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449 *Mar 30 21:20:59.815 UTC: L2X: l2tun session [1646198216], event [client request], old state [open], new state [open] *Mar 30 21:20:59.815 UTC: L2X: L2TP: Received L2TUN message <Connect> *Mar 30 21:20:59.815 UTC: Tnl/Sn49403/30972 L2TP: Session state change from idle to wait-for-tunnel *Mar 30 21:20:59.815 UTC: Tnl/Sn49403/30972 L2TP: Create session *Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: SM State idle *Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: O SCCRQ *Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: Tunnel state change from idle to wait-ctl-reply *Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: SM State wait-ctl-reply *Mar 30 21:21:00.815 UTC: Tnl49403 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134, tnl 0, ns 0, nr 0 *Mar 30 21:21:00.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to 2 seconds *Mar 30 21:21:02.815 UTC: Tnl49403 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134, tnl 0, ns 0, nr 0 *Mar 30 21:21:02.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to 4 seconds *Mar 30 21:21:06.815 UTC: Tnl49403 L2TP: O StopCCN *Mar 30 21:21:06.815 UTC: Tnl49403 L2TP: Tunnel state change from wait-ctl-reply to shutting-down *Mar 30 21:21:06.815 UTC: Tnl/Sn49403/30972 L2TP: Destroying session *Mar 30 21:21:06.815 UTC: L2X: Sending L2TUN message <Connect Fail> *Mar 30 21:21:06.815 UTC: Tnl/Sn49403/30972 L2TP: Session state change from wait-for-tunnel to idle London_LCCE# |
Highlighted lines 1 to 3 show three SCCRQs from Frankfurt_LCCE. Note that London_LCCE does not respond with an SCCRP.
Then in highlighted line 4, London_LCCE sends a SCCRQ. This is re-sent in highlighted lines 5 and 6. Note that there is no response (SCCRP) from Frankfurt_LCCE.
London_LCCE is receiving control connection messages from Frankfurt_LCCE but not responding. Additionally, London_LCCE is sending control messages (to Frankfurt_LCCE) but receiving no response.
Further clarity can be obtained using the debug vpdn l2x-errors command. This is shown in Example 5-18.
Example 5-18. Remote LCCE's IP Address Is Misconfigured on the Local LCCE
London_LCCE#debug vpdn l2x-errors L2X protocol errors debugging is on London_LCCE# *Mar 30 21:22:11.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE, local/remote address 10.1.1.1/10.1.1.2 *Mar 30 21:22:12.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE, local/remote address 10.1.1.1/10.1.1.2 *Mar 30 21:22:14.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE, local/remote address 10.1.1.1/10.1.1.2 London_LCCE# |
As you can see, London_LCCE cannot locate any configuration for remote peer Frankfurt_LCCE (highlighted line 1). Note Frankfurt_LCCE's IP address (10.1.1.2).
London_LCCE's configuration is then examined using the show running-config command, as shown in Example 5-19. Note that only the relevant portion of the output is shown.
Example 5-19. Frankfurt_LCCE's IP Address Is Misconfigured
London_LCCE#show running-config Building configuration... ! connect PVCtoFrank Serial4/1 60 l2transport xconnect 10.1.1.3 121 pw-class FrankfurtPW ! ! |
The highlighted line shows the IP address configured for Frankfurt_LCCE (for the pseudowire with VCID 121). As you can see it is 10.1.1.3. Unfortunately, Frankfurt_LCCE's IP address is 10.1.1.2.
The IP address for Frankfurt_LCCE is then reconfigured, as shown in Example 5-20.
Example 5-20. IP Address for Frankfurt_LCCE Is Reconfigured
London_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_LCCE(config)#connect PVCtoFrank Serial4/1 60 l2transport London_LCCE(config-fr-pw-switching)#xconnect 10.1.1.2 121 pw-class FrankfurtPW London_LCCE(config-fr-pw-switching)#exit London_LCCE# |
In the highlighted line, the IP address for Frankfurt_LCCE is reconfigured as 10.1.1.2. Once the IP address for Frankfurt_LCCE has been reconfigured, control connection establishment succeeds. This is verified using the show l2tun tunnel command, as shown in Example 5-21.
Example 5-21. Control Connection Establishment Has Succeeded
London_LCCE#show l2tun tunnel Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions L2TPclass 8055 44724 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas London_LCCE# |
As you can see, the control connection has been successfully set up to Frankfurt_LCCE.
It is also worth noting that if the local LCCE's IP address is misconfigured on the remote LCCE, then no control messages from the remote LCCE would be received by the local LCCE.
Access List Is Blocking L2TPv3
If an access list is blocking IP protocol 115, then control connection establishment will fail.
You can use the debug vpdn l2x-events command to troubleshoot this issue, as demonstrated in Example 5-22.
Example 5-22. Control Connection Establishment Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on *Mar 31 09:48:19.479 UTC: L2X: l2tun session [1646198216], event [client request], old state [open], new state [open] *Mar 31 09:48:19.479 UTC: L2X: L2TP: Received L2TUN message <Connect> *Mar 31 09:48:19.479 UTC: Tnl/Sn35842/42451 L2TP: Session state change from idle to wait-for-tunnel *Mar 31 09:48:19.479 UTC: Tnl/Sn35842/42451 L2TP: Create session *Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: SM State idle *Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: O SCCRQ *Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to 1 seconds *Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: Tunnel state change from idle to wait-ctl-reply *Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: SM State wait-ctl-reply *Mar 31 09:48:20.479 UTC: Tnl35842 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134, tnl 0, ns 0, nr 0 *Mar 31 09:48:20.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to 2 seconds *Mar 31 09:48:22.479 UTC: Tnl35842 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134, tnl 0, ns 0, nr 0 *Mar 31 09:48:22.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to 4 seconds London_LCCE# |
In highlighted line 1, London_LCCE initiates control connection establishment to Frankfurt_LCCE by sending a SCCRQ message. Then in highlighted lines 2 and 3, the SCCRQ is re-sent. No response from Frankfurt_LCCE. This might indicate the presence of an access list blocking L2TPv3 on any of the routers in the path between London_LCCE and Frankfurt_LCCE.
Use the show ip interface [interface_name] command to check for the presence of access lists. When Frankfurt_LCCE is checked, an access list is discovered on its serial 2/0 interface (which is in the path from London_LCCE), as demonstrated in Example 5-23.
Example 5-23. Access List on Frankfurt_LCCE
Frankfurt_LCCE#show ip interface serial 2/0 Serial2/0 is up, line protocol is up Internet address is 172.16.2.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is 101 Proxy ARP is disabled Security level is default Split horizon is enabled |
In the highlighted line, you can see that access list 101 is configured in an inbound direction on interface serial 2/0.
The composition of access list 101 is then verified using the show ip access-lists command, as shown in Example 5-24.
Example 5-24. Composition of Access List 101
Frankfurt_LCCE#show ip access-lists
Extended IP access list 101
permit tcp any any eq www
permit tcp any any eq telnet
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit udp any any eq tftp
permit udp any any eq ntp
permit udp any any eq snmp
permit udp any any eq snmptrap
deny ip any any log-input (111 matches)
Frankfurt_LCCE#
|
As you can see, access list 101 permits a number of protocols, but significantly not IP protocol 115 (L2TPv3). L2TPv3 is, therefore, denied.
In this case, it is decided that access list 101 is not necessary, and it is removed from interface serial 2/0, as shown in Example 5-25.
Example 5-25. Removal of Access List 101
Frankfurt_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. Frankfurt_LCCE(config)#interface serial 2/0 Frankfurt_LCCE(config-if)#no ip access-group 101 in Frankfurt_LCCE(config-if)#exit Frankfurt_LCCE# |
Access list 101 is removed from interface serial 2/0 in the highlighted line.
Once the access list has been removed, the control connection is successfully established between London_LCCE and Frankfurt_LCCE, as demonstrated in Example 5-26.
Example 5-26. Successful Establishment of the Control Connection
London_LCCE#show l2tun tunnel Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions L2TPclass 36025 30898 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas London_LCCE# |
The highlighted line shows that a control connection has been successfully established from London_LCCE to Frankfurt_LCCE.
L2TPv3 Authentication Fails
If L2TPv3 authentication fails (assuming that it is configured), then control connection setup will fail.
To troubleshoot L2TPv3 authentication issues, use the debug vpdn l2x-events command, as shown in Example 5-27.
An SCCRQ is sent by London_LCCE to Frankfurt_LCCE is highlighted line 1. Because authentication is configured in this scenario, this SCCRQ contains a Challenge AVP.
Example 5-27. L2TPv3 Authentication Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on London_LCCE# *Mar 30 19:28:34.551 UTC: L2X: l2tun session [1646198216], event [client request], old state [open], new state [open] *Mar 30 19:28:34.551 UTC: L2X: L2TP: Received L2TUN message <Connect> *Mar 30 19:28:34.551 UTC: Tnl/Sn51926/62398 L2TP: Session state change from idle to wait-for-tunnel *Mar 30 19:28:34.551 UTC: Tnl/Sn51926/62398 L2TP: Create session *Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: SM State idle *Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: O SCCRQ *Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: Tunnel state change from idle to wait-ctl-reply *Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: SM State wait-ctl-reply *Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: I SCCRP from Frankfurt_LCCE *Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: Got a challenge from remote peer, Frankfurt_LCCE *Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: Got a response from remote peer, Frankfurt_LCCE *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Tunnel auth failed for Frankfurt_LCCE *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Expected AA 00 3F A4 76 8A 43 7B 5F CC 28 D1 39 01 B6 FD *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Got C1 DD 86 6C F7 27 56 AA 71 20 6C 58 9B 7A 9E 6A *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: O StopCCN to Frankfurt_LCCE tnlid 51784 *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Tunnel state change from wait-ctl-reply to shutting-down *Mar 30 19:28:34.603 UTC: Tnl/Sn51926/62398 L2TP: Destroying session *Mar 30 19:28:34.603 UTC: L2X: Sending L2TUN message <Connect Fail> *Mar 30 19:28:34.603 UTC: Tnl/Sn51926/62398 L2TP: Session state change from wait-for-tunnel to idle London_LCCE# |
In highlighted line 2, a SCCRP is received from Frankfurt_LCCE. This SCCRP contains a Challenge AVP (highlighted line 3), and a Challenge Response AVP (highlighted line 4). The Challenge Response AVP is Frankfurt_LCCE's response to the Challenge AVP sent by London_LCCE in the SCCRQ (highlighted line 1).
NOTE
Note that the Challenge and Challenge Response AVPs will be replaced by the Message Digest and Control Message Authentication Nonce AVPs in later implementations of L2TPv3.
Things are looking good, but then in highlighted line 5, London_LCCE reports that authentication has failed. The reason for the authentication failure is shown in highlighted lines 6 and 7. Highlighted line 6 shows the authentication response (hash) that London_LCCE expected from Frankfurt_LCCE. The actual response is shown in highlighted line 7. As you can see, they are different, and so authentication fails.
Finally, in highlighted line 8, London_LCCE sends a StopCCN to Frankfurt_LCCE to signal control connection teardown. The authentication failure indicates that the shared password is inconsistent between London_LCCE and Frankfurt_LCCE. This is corrected in Example 5-28.
Example 5-28. Reconfiguration of Authentication Passwords on London_LCCE and Frankfurt_LCCE
! On London_LCCE: London_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_LCCE(config)#l2tp-class FrankfurtV3Class London_LCCE(config-l2tp-class)#password cisco London_LCCE(config-l2tp-class)#exit London_LCCE# ________________________________________________________________ ! On Frankfurt_LCCE: Frankfurt_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. Frankfurt_LCCE(config)#l2tp-class LondonVC3Class Frankfurt_LCCE(config-l2tp-class)#password cisco Frankfurt_LCCE(config-l2tp-class)#exit Frankfurt_LCCE# |
Once the password has been reconfigured on London_LCCE and Frankfurt_LCCE, control connection establishment is successful. This is verified using the show l2tun tunnel command, as shown in Example 5-29.
Example 5-29. Control Connection Establishment Succeeds
London_LCCE#show l2tun tunnel Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions L2TPclass 36452 1742 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas London_LCCE# |
The highlighted line shows that a control connection has been successfully established to Frankfurt_LCCE.
Note that if L2TPv3 authentication is configured on the local LCCE but not on the remote LCCE, no response (SCCRP) to the local LCCE's SCCRQ will be received. Always ensure that L2TPv3 authentication is consistently configured on peer LCCEs.
Troubleshooting L2TPv3 Dynamic Session Establishment
Once the control connection has been established, session setup can begin. If session setup fails, pseudowire connectivity will not be established.
Figure 5-21 shows L2TPv3 session setup.
Before beginning to troubleshoot L2TPv3 session establishment failure, it is important to examine a successful session establishment sequence.
Use the debug vpdn l2x-events command to examine the L2TPv3 session establishment sequence as demonstrated in Example 5-30. Note that only the relevant portion of the output is shown.
Example 5-30. Successful L2TPv3 Session Establishment
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on *Mar 30 18:41:08.803 UTC: Tnl/Sn26577/62344 L2TP: O ICRQ to Frankfurt_LCCE 63650/0 *Mar 30 18:41:08.803 UTC: Tnl/Sn26577/62344 L2TP: Session state change from wait-for-tunnel to wait-reply *Mar 30 18:41:08.847 UTC: Tnl/Sn26577/62344 L2TP: O ICCN to Frankfurt_LCCE 63650/43444 *Mar 30 18:41:08.847 UTC: Tnl26577 L2TP: Control channel retransmit delay set to 1 seconds *Mar 30 18:41:08.847 UTC: Tnl/Sn26577/62344 L2TP: Session state change from wait-reply to established *Mar 30 18:41:08.847 UTC: L2X: Sending L2TUN message <Connect OK> *Mar 30 18:41:08.847 UTC: L2X: l2tun session [1646198216], event [server response], old state [open], new state [open] *Mar 30 18:41:09.847 UTC: Tnl26577 L2TP: Control channel retransmit delay set to 1 seconds London_LCCE# |
In highlighted line 1, session establishment begins with London_LCCE sending an ICRQ message to Frankfurt_LCCE. An ICRP is then received from Frankfurt_LCCE. This message indicates that session establishment should proceed. Note that the ICRP message is not shown in Example 5-30.
Session establishment is completed in highlighted line 2, when London_LCCE sends a ICCN message to Frankfurt_LCCE. In highlighted line 3, the session state changes to established—the session is up.
Successful L2TPv3 session establishment can be verified using the show l2tun session command, as shown in Example 5-31.
Example 5-31. Successful L2TPv3 Session Establishment
London_LCCE#show l2tun session Session Information Total tunnels 1 sessions 2 LocID RemID TunID Username, Intf/ State Vcid, Circuit 24058 52352 33028 120, Fa1/0.1:10 est 24059 52353 33028 121, Se4/1:60 est London_LCCE# |
Highlighted line 1 shows that two sessions have been established (as well as one control connection). Highlighted lines 2 and 3 show the local and remote session IDs, control connection ID, VCID, interface, and state associated with the two L2TPv3 sessions.
L2TPv3 session setup can fail for a number of reasons, including the following:
The attachment circuit is inactive (down) on the peer LCCE.
The peer LCCE's IP address is misconfigured (with the xconnect command).
Peer LCCE VCIDs are mismatched.
Peer LCCE payload types are asymmetric.
Check that the attachment circuit is in an up/up (active) state on both of the peer LCCEs, using the show ip interface [interface_name] command.
The other issues in the preceding list are examined in the sections that follow.
Peer LCCE's IP Address Is Misconfigured (with the xconnect Command)
If the peer LCCE's IP address is misconfigured, session setup will fail. Use the debug vpdn l2x-events command to troubleshoot this issue, as shown in Example 5-32. Note that only the relevant portion of the output is shown.
Example 5-32. L2TPv3 Session Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on London_LCCE# *Mar 31 11:45:52.259 UTC: L2X: l2tun session [1646198152], event [client request], old state [open], new state [open] *Mar 31 11:45:52.259 UTC: L2X: L2TP: Received L2TUN message <Connect> *Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Session state change from idle to wait-for-tunnel *Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Create session *Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: O ICRQ to Frankfurt_LCCE 29622/0 *Mar 31 11:45:52.259 UTC: Tnl51874 L2TP: Control channel retransmit delay set to 1 seconds *Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Session state change from wait-for-tunnel to wait-reply *Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: I CDN from Frankfurt_LCCE tnl 29622, cl 0 *Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: Destroying session *Mar 31 11:45:52.287 UTC: L2X: Sending L2TUN message <Connect Fail> *Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: Session state change from wait-reply to idle *Mar 31 11:45:52.287 UTC: L2X: l2tun session [1646198152], event [server response], old state [open], new state [open] *Mar 31 11:45:52.287 UTC: L2X: l2tun session [1646198152], event [client free], old state [open], new state [open] London_LCCE# |
Highlighted line 1 shows London_LCCE sending an ICRQ message to Frankfurt_LCCE. Then in highlighted line 2, a CDN message is received. This signals session teardown. Session establishment has failed.
The peer IP addresses used for this pseudowire are then verified using the show running-config command on London_LCCE and Frankfurt_LCCE, as shown in Example 5-33. Note that only the relevant portion of the output is shown.
Example 5-33. Verifying Peer IP Address for the Pseudowire
! On London_LCCE: London_LCCE#show running-config Building configuration... ! interface FastEthernet1/0 no ip address no ip directed-broadcast ! interface FastEthernet1/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.2 120 pw-class FrankfurtPW ! ________________________________________________________________ ! On Frankfurt_LCCE: Frankfurt_LCCE#show running-config Building configuration... ! interface FastEthernet0/0 no ip address no ip directed-broadcast ! interface FastEthernet0/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.4 120 pw-class LondonPW ! |
In highlighted line 1, you can see that the peer IP address configured for the pseudowire on London_LCCE is 10.1.1.2. This address is correctly configured.
Then in highlighted line 2, you can see that the peer IP address configured on Frankfurt_LCCE is 10.1.1.4. This is incorrect—it should be 10.1.1.1.
The peer IP address is then reconfigured on Frankfurt_LCCE, as shown in Example 5-34.
Example 5-34. Reconfiguration of the Peer IP Address on Frankfurt_LCCE
Frankfurt_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. Frankfurt_LCCE(config)#interface FastEthernet0/0.1 Frankfurt_LCCE(config-subif)#xconnect 10.1.1.1 120 pw-class LondonPW Frankfurt_LCCE(config-subif)#exit Frankfurt_LCCE# |
As the highlighted line indicates, the peer IP address is reconfigured to be 10.1.1.1. Once the peer IP address has been reconfigured, session establishment succeeds.
Successful session establishment is verified using the show l2tun session command, as shown in Example 5-35.
Example 5-35. L2TPv3 Session Establishment Succeeds
London_LCCE#show l2tun session Session Information Total tunnels 1 sessions 2 LocID RemID TunID Username, Intf/ State Vcid, Circuit 32180 28768 51874 121, Se4/1:60 est 32235 28846 51874 120, Fa1/0.1:10 est London_LCCE# |
The highlighted line shows that the session has been successfully established.
Peer LCCE VCIDs Are Mismatched
If VCIDs on peer LCCEs are mismatched, then L2TPv3 session setup will fail.
Use the debug vpdn l2x-events command to troubleshoot this issue, as demonstrated in Example 5-36. Note that only the relevant portion of the output is shown.
Example 5-36. Session Establishment Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on London_LCCE# *Mar 31 15:45:21.567 UTC: Tnl7185 L2TP: I ICRQ from Frankfurt_LCCE tnl 41528 *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Session state change from idle to wait-connect *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Accepted ICRQ, new session created *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Xconnect VC ID 125 not provisioned *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: O CDN to Frankfurt_LCCE 41528/61379 *Mar 31 15:45:21.567 UTC: Tnl7185 L2TP: Control channel retransmit delay set to 1 seconds *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Destroying session *Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Session state change from wait-connect to idle London_LCCE# |
In highlighted line 1, an ICRQ message is received from Frankfurt_LCCE. This message is used to initiate session establishment.
Then in highlighted line 2, London_LCCE reports that VCID 125 contained within the ICRQ message (in a Remote End ID AVP—see Table 5-8) is not consistent with any pseudowire VCID configured locally. London_LCCE now signals session teardown by sending a CDN message in highlighted line 3. Session establishment has failed.
The next step is to examine the pseudowire configuration on London_LCCE and Frankfurt_LCCE using the show running-config command, as shown in Example 5-37.
Example 5-37. Pseudowire Configuration on London_LCCE and Frankfurt_LCCE
! On London_LCCE: London_LCCE#show running-config Building configuration... ! interface FastEthernet1/0 no ip address no ip directed-broadcast ! interface FastEthernet1/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.2 120 pw-class FrankfurtPW ! ________________________________________________________________ ! On Frankfurt_LCCE: Frankfurt_LCCE#show running-config Building configuration... Current configuration : 2217 bytes ! ! interface FastEthernet0/0 no ip address no ip directed-broadcast ! interface FastEthernet0/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.1 125 pw-class LondonPW ! |
Highlighted line 1 indicates that the VCID configured for the pseudowire on London_LCCE is 120, whereas in highlighted line 2 the VCID on Frankfurt_LCCE is 125—clearly a mismatch.
The VCID is then reconfigured on Frankfurt_LCCE, as shown in Example 5-38.
Example 5-38. Reconfiguration of the VCID on Frankfurt_LCCE
Frankfurt_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. Frankfurt_LCCE(config)#interface FastEthernet0/0.1 Frankfurt_LCCE(config-subif)#xconnect 10.1.1.1 120 pw-class LondonPW Frankfurt_LCCE(config-subif)#end Frankfurt_LCCE# |
In the highlighted line, the VCID is reconfigured as 120.
Once the VCID has been reconfigured, L2TPv3 session establishment is successful. This is verified using the show l2tun session command, as shown in Example 5-39.
Example 5-39. Successful L2TPv3 Session Establishment
London_LCCE#show l2tun session Session Information Total tunnels 1 sessions 2 LocID RemID TunID Username, Intf/ State Vcid, Circuit 43517 61344 7185 121, Se4/1:60 est 43562 61389 7185 120, Fa1/0.1:10 est London_LCCE# |
The highlighted line indicates that a session has been successfully established for VCID 120.
Asymmetric Payload Types
If L2TPv3 payload types are incompatible, session establishment will fail.
You can use the debug vpdn l2x-events command to troubleshoot this issue, as shown in Example 5-40. Note that only the relevant portion of the output is shown.
Example 5-40. L2TPv3 Session Establishment Fails
London_LCCE#debug vpdn l2x-events L2X protocol events debugging is on London_LCCE# *Apr 1 15:58:15.763 UTC: Tnl57072 L2TP: I ICRQ from Frankfurt_LCCE tnl 45648 *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Session state change from idle to wait-connect *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Accepted ICRQ, new session created *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Session state change from wait-connect to wait-for-service-selection-icrq *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Started service selection, peer IP address 10.1.1.2, VCID 121 *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: O CDN to Frankfurt_LCCE 45648/34007 *Apr 1 15:58:15.763 UTC: Tnl57072 L2TP: Control channel retransmit delay set to 1 seconds *Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Destroying session *Apr 1 15:58:15.767 UTC: Tnl/Sn57072/46769 L2TP: Session state change from wait-for-service-selection-icrq to idle London_LCCE# |
In highlighted line 1, London_LCCE receives an ICRQ message initiating session establishment, and in highlighted line 2, London_LCCE reports that this has been accepted.
All seems well, and then in highlight line 3, London_LCCE sends a CDN message to Frankfurt_LCCE signaling session teardown. Session establishment has failed.
To find out the reason for session establishment failure, you can use the debug vpdn l2x-errors command, as demonstrated in Example 5-41.
Example 5-41. Asymmetric Payload Types
London_LCCE#debug vpdn l2x-errors L2X protocol errors debugging is on London_LCCE# *Apr 1 15:59:06.091 UTC: Tnl/Sn57072/46779 L2TP: Asymmetric payload types are not supported *Apr 1 15:59:07.231 UTC: Tnl/Sn57072/46780 L2TP: Asymmetric payload types are not supported *Apr 1 15:59:09.263 UTC: Tnl/Sn57072/46781 L2TP: Asymmetric payload types are not supported London_LCCE# |
As you can see, London_LCCE is reporting that asymmetric payload types are not supported. This indicates a compatibility issue between attachment circuit types.
The configuration of the attachment circuits is then examined using the show running-config command on London_LCCE and Frankfurt_LCCE, as shown in Example 5-42. Note that only the relevant portion of the output is shown.
Highlighted lines 1 to 4 show that interface serial 4/0 on London_LCCE is configured for DLCI-to-DLCI switching.
Example 5-42. Configuration of Attachment Circuits on London_LCCE and Frankfurt_LCCE
! On London_LCCE: London_LCCE#show running-config Building configuration... ! interface Serial4/1 no ip address no ip redirects no ip directed-broadcast no ip proxy-arp encapsulation frame-relay frame-relay intf-type dce ! connect PVCtoFrank Serial4/1 60 l2transport xconnect 10.1.1.2 121 pw-class FrankfurtPW ! ! ________________________________________________________________ ! On Frankfurt_LCCE: Frankfurt_LCCE#show running-config Building configuration... Current configuration : 2109 bytes ! ! interface Serial2/1 no ip address no ip redirects no ip directed-broadcast no ip proxy-arp no cdp enable xconnect 10.1.1.1 121 pw-class LondonPW ! |
Highlighted line 5, however, shows that the corresponding interface on Frankfurt_LCCE (serial 2/1) is configured for Frame Relay trunking. In fact, interface serial 2/1 on Frankfurt should be configured for DLCI-to-DLCI switching.
Frankfurt_LCCE is then reconfigured, as shown in Example 5-43.
Example 5-43. Reconfiguration of Frankfurt_LCCE
Frankfurt_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. Frankfurt_LCCE(config)#frame-relay switching Frankfurt_LCCE(config)#interface serial 2/1 Frankfurt_LCCE(config-if)#encapsulation frame-relay Frankfurt_LCCE(config-if)#frame-relay intf-type dce Frankfurt_LCCE(config-if)#exit Frankfurt_LCCE(config)#connect PVCtoLondon serial 2/1 70 l2transport Frankfurt_LCCE(config-fr-pw-switching)#xconnect 10.1.1.1 121 pw-class LondonPW Frankfurt_LCCE(config-fr-pw-switching)#exit Frankfurt_LCCE# |
The highlighted lines indicate that interface serial 2/1 on Frankfurt_LCCE is reconfigured for DLCI-to-DLCI switching.
Once Frankfurt_LCCE has been reconfigured, L2TPv3 session establishment succeeds.
L2TPv3 session establishment is verified using the show l2tun session command, as shown in Example 5-44.
Example 5-44. L2TPv3 Session Establishment Succeeds
London_LCCE#show l2tun session Session Information Total tunnels 1 sessions 2 LocID RemID TunID Username, Intf/ State Vcid, Circuit 46661 33899 57072 120, Fa1/0.1:10 est 46831 34069 57072 121, Se4/1:60 est London_LCCE# |
The highlighted line shows that session establishment has succeeded.
NOTE
Cisco supports interworking between certain different Layer 2 circuit types (such as Frame Relay to Ethernet VLAN) in Cisco IOS Software Release 12.0(26)S and later. This feature is called L2VPN Interworking. See Cisco.com for more details.
Troubleshooting L2TPv3 with Static Session Configuration
If L2TPv3 sessions are statically configured, troubleshooting consists of verifying peer LCCE configuration. Always ensure that peer IP addresses are correctly configured and that session IDs and cookies are mirror images on peer routers.
In this scenario, traffic from CE router mjlnet_CE1 is not arriving at mjlnet_CE2 (see Figure 5-19). This is verified using ping, as shown in Example 5-45.
Example 5-45. No CE Router to CE Router Connectivity
mjlnet_CE1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) mjlnet_CE1# |
As you can see, there is no connectivity between the CE routers.
The next step is to verify L2TPv3 configuration on London_LCCE and Frankfurt_LCCE, as shown in Example 5-46. Note that only the relevant portion of the output is shown.
Example 5-46. L2TPv3 Configuration on London_PE and Frankfurt_PE
! On London_PE: London_LCCE#show running-config Building configuration... ! connect PVCtoFrankfurt Serial4/1 60 l2transport xconnect 10.1.1.2 123 encapsulation l2tpv3 manual pw-class FrankfurtPW l2tp id 1003 2001 l2tp cookie local 4 102 l2tp cookie remote 4 201 ! ! ________________________________________________________________ On Frankfurt_PE: Frankfurt_LCCE#show running-config Building configuration... ! connect PVCtoLondon Serial2/1 70 l2transport xconnect 10.1.1.1 123 encapsulation l2tpv3 manual pw-class LondonPW l2tp id 2001 1002 l2tp cookie local 4 201 l2tp cookie remote 4 102 ! ! |
A close comparison of the configuration on the two PE routers reveals that the peer IP addresses and the L2TPv3 cookies are correctly configured, but that the L2TPv3 (session) IDs are not.
Remember that the session IDs configured on peer routers must be a mirror image of each other. If you look at the highlighted lines in Example 5-46, you will notice that the session IDs on London_PE and Frankfurt_PE are not mirror images. In fact, the local session ID on London_PE is misconfigured. It should be 1002, but it is configured as 1003.
The local session ID on London_PE is then reconfigured, as shown in Example 5-47.
Example 5-47. Reconfiguration of the Local Session ID on London_PE
London_LCCE#conf t Enter configuration commands, one per line. End with CNTL/Z. London_LCCE(config)#connect PVCtoFrankfurt Serial4/1 60 l2transport London_LCCE(config-fr-pw-switching)#xconnect 10.1.1.2 123 encapsulation l2tpv3 manual pw-class FrankfurtPW London_LCCE(config-xconn)#l2tp id 1002 2001 London_LCCE(config-xconn)#end London_LCCE# |
Once London_PE has been reconfigured, connectivity is established between mjlnet_CE1 and mjlnet_CE2, as shown in Example 5-48.
Example 5-48. Connectivity Is Established Between mjlnet_CE1 and mjlnet_CE2
mjlnet_CE1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms mjlnet_CE2# |