Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Troubleshooting SNMP trap L2TPTunnelDownPeerUnreachable

Includes show l2tp-based CLI commands (and how to interpret output) to troubleshoot L2TPTunnelDownPeerUnreachable SNMP trap for LAC-LNS and ClosedRP PDSN service, configurables for tunnel retries/timeouts/keep-alives, identifying peer address, l2tp logging, etc. 

A LAC (L2TP Access Concentrator) to LNS (L2TP Network Server) tunnel is created in order to contain subscriber sessions while it extends the subscriber connection from a PDSN (or Home Agent) to the LNS where it is terminated and where an IP address is provided. If on a Starent chassis, the LNS will get an IP address from a configured IP pool just like for Simple IP (SIP) or Mobile IP (MIP), while if on some other LNS, for example at the customer premises, the IP address is provided by the LNS there. In this latter scenario, this could effectively allow for SIP users to connect to their home network through a LAC running on a roaming partner, which, to a limited degree gives MIP functionality (mobility) by allowing the SIP user to roam through other provider networks which SIP users cannot normally do.

A LAC LNS tunnel is first created as the first subscriber session is attempted to be setup, and will stay up as long as there are sessions in the tunnel. When the last session ends for a given tunnel, that tunnel is closed or shut down. More than one tunnel can be established between the same LAC-LNS peers. Note that this is an important difference from a Closed RP PDSN service, which also relies on L2TP protocol for tunneling, where tunnels remain up forever regardless of whether any sessions exist in the tunnel. Here is a snippet of output from the command “show l2tp tunnels all” that shows this – in this case the chassis hosts BOTH LAC and LNS services (TestLAC and TestLNS). Note the LAC and LNS tunnels ALL have sessions, while some Closed RP tunnels have no sessions.

[local]1X-PDSN# show l2tp tunnels all | more
|+----State: (C) - Connected       (c) - Connecting
|            (d) - Disconnecting   (u) - Unknown
|
|
v  LocTun ID  PeerTun ID Active Sess Peer IPAddress  Service Name   Uptime
--- ---------- ---------- ----------- --------------- ------------   ---------
...........
C  88         7          13          10.225.16.202   CRP            00938h47m
C  89         7          15          10.225.34.55    CRP            00938h47m
C  90         7          8           10.225.36.24    CRP            00938h47m
C  91         8          5           10.225.16.152   CRP            99h14m32s
C  92         7          2           10.225.30.76    CRP            00938h47m
C  93         7          0           10.225.38.238   CRP            00938h47m
C  94         2          0           10.225.34.88    CRP            00122h09m
C  95         7          2           10.225.30.27    CRP            00938h47m
............
C  30         1          511         214.97.107.28   TestLNS         00603h50m
C  31         56         468         214.97.107.28   TestLNS         00589h31m
C  10         105        81          79.116.237.27   TestLAC         00283h53m
C  29         16         453         79.116.231.27   TestLAC         00521h32m
C  106        218        63          79.116.231.27   TestLAC         00330h10m
C  107        6          464         79.116.237.27   TestLAC         00329h47m
C  30         35         194         214.97.107.28   TestLNS         00596h06m

Important note: Although the text of this article mentions/focuses on LAC-LNS (service) tunnels specifically, the article applies also to troubleshooting L2TPTunnelDownPeerUnreachable traps related to ClosedRP PDSN service.

For a further explanation of Starent’s implementation of LAC and LNS as well as how to configure it, see the appropriate chapter devoted to these topics in the PDSN Administration Guides. This article assumes a basic understanding as discussed in the documentation.

Note that LAC and LNS services are configured like any other services on a Starent chassis. Once configured, the settings can be viewed, including default ones, with the command:

show (lac-service | lns-service) name <lac or lns service name>

Here is an example of the L2TPTunnelDownPeerUnreachable trap with LAC service 192.168.51.152 and LNS service (peer) 192.168.51.155

Tue Jun 23 16:34:22 2009 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 192.168.51.155 local address 192.168.51.152

You can get a count of how many times this trap has been triggered (since reload or last reset of statistics) using the command "show snmp trap statistics"

The L2TPTunnelDownPeerUnreachable trap is triggered for L2TP when a tunnel setup timeout occurs OR keep-alive (Hello) packets are not responded to. The cause is usually due to the LNS peer not responding to requests from the LAC or transport issues in either direction. There is no trap to indicate that the peer becomes reachable, which, if it is not understood how to investigate further, may lead to confusion as to whether there is still an issue or not at the time of investigation. If a L2TPTunnelDownPeerUnreachable trap is triggered, for pre-version 8.1, the peer address that is not reachable is NOT displayed by the SNMP trap history command:

Tue Dec 09 14:10:12 2008 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)

But, you can view this information if you have access to the actual trap as sent to the trap server, for example:

1228987532 1228987489 16 Thu Dec 11 04:24:49 2008 JNKLBV-G-SPM1-24 - starL2TPTunnelDownPeerUnreachable: PeerIPAddr: 10.214.197.86 LocalTunnelID: 531 PeerTunnelID: 47;4 .1.3.6.1.4.1.8164.2.92 0

Starting in v8.1, the peer address is also displayed as part of the trap history, as shown above.

Note that the LAC or LNS service configuration may or may not list any, some, or all peers, so you cannot depend on referencing the config for a complete list of peers. Most implementations actually rely on receiving the attribute Tunnel-Server-Endpoint along with other L2TP attributes from radius for the subscriber being authenticated, leaving the service's config bare bones including just the service bind address. See the manuals for details on configuring LAC and LNS, as this is beyond the scope of this article.

Following are some procedures and commands that can be used to further troubleshoot this trap.

Important note: Most of the related commands use the keyword l2tp. If the chassis also contains Closed RP tunnels, then the output of these commands will reflect these tunnels also, so be careful in interpreting the output. You can often qualify the command with the name of the LAC or LNS or ClosedRP PDSN service or peer address to narrow the results to what is desired.

As implied above, the most important piece of information needed to troubleshoot is the peer address. If you do not know this address (assuming pre-v8.1 and no easy/quick access to the full trap data), then you will need to find it out. Since the problem has already occurred, you will need to setup and try to catch it again.

***************   WARNING: the below operations should only be performed by Starent Support Personnel and NOT by the customer *************

Turn on l2tpmgr and l2tp-control logging at debug level, either using the active logging or runtime logging feature as follows. l2tpmgr tracks specific subscriber session setup while l2tp-control tracks tunnel establishment:

Active logging (exec mode) – logs written to terminal window

logging filter active facility l2tpmgr level debug
logging filter active facility l2tp-control level debug
logging active

To stop logging:


no logging active

Runtime logging (global config mode) – logs saved internally

logging filter runtime facility l2tpmgr level debug
logging filter runtime facility l2tp-control level debug

To view logs:


show logs (and/or check the syslog server if configured)

**********************  WARNING END *********************

If a lot of logs are generated, then you may need to grep to find the lines of interest. Specifying the peer IP address is a good start, as it should be included in all relevant logs for the issue you are troubleshooting.

Attached to this article is a file containing the output of a successful setup of a SIP LAC-LNS call for reference.

Below is output to expect if an INITIAL tunnel setup fails due to retry timeouts. Note the retries are exponential, doubling each time (seconds): 1, 2, 4, 8, 8. This is based on the following (default) configurables in the LAC service:
      max-retransmission 5
      retransmission-timeout-first 1
      retransmission-timeout-max 8

These (defaults) can be viewed with “show config verbose” or (as mentioned earlier) “show lac-service name <lac service name>”

Note the term max-retransmissions (5) includes the first attempt/transmission.
retransmission-timeout-max is maximum amount of time between transmissions after (if) this limit is reached
retransmission-timeout-first is the starting point of how long to wait before the first retransmission.

So, doing the math, in the case of the default parameters, a failure would occur after 1+ 2 + 4 + 8 + 8 seconds = 23 seconds, which is seen exactly as in the output below. The LAC service in this case is located in the context "destination" as indicated in the output.

2009-Jun-23+16:34:00.017 [l2tpmgr 48140 debug] [7/0/555 <l2tpmgr:1> l2tpmgr_call.c:591] [callid 4144ade2] [context: destination, contextID: 3]  [software internal system] L2TPMgr-1  msid 0000012345  username laclnsuser  service <lac> - IPSEC tunnel does not exist

2009-Jun-23+16:34:00.018 [l2tp-control 50069 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_fsm.c:105] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user] l2tp fsm: state L2TPSNX_STATE_OPEN event L2TPSNX_EVNT_APP_NEW_SESSION

---------------------

2009-Jun-23+16:34:00.018 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (138)
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) TIE_BREAKER(0706050403020100) FIRM_VER(256) *HOST_NAME(lac) VENDOR_NAME(StarentNetworks) *ASSND_TUN_ID(10) *RECV_WIN_SIZE(16) *CHALLENGE(dbed79cdc497f266bd374d427607cd52)

2009-Jun-23+16:34:00.928 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (138)
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) TIE_BREAKER(0706050403020100) FIRM_VER(256) *HOST_NAME(lac) VENDOR_NAME(StarentNetworks) *ASSND_TUN_ID(10) *RECV_WIN_SIZE(16) *CHALLENGE(dbed79cdc497f266bd374d427607cd52)

2009-Jun-23+16:34:02.943 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (138)
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) TIE_BREAKER(0706050403020100) FIRM_VER(256) *HOST_NAME(lac) VENDOR_NAME(StarentNetworks) *ASSND_TUN_ID(10) *RECV_WIN_SIZE(16) *CHALLENGE(dbed79cdc497f266bd374d427607cd52)

2009-Jun-23+16:34:06.870 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (138)
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) TIE_BREAKER(0706050403020100) FIRM_VER(256) *HOST_NAME(lac) VENDOR_NAME(StarentNetworks) *ASSND_TUN_ID(10) *RECV_WIN_SIZE(16) *CHALLENGE(dbed79cdc497f266bd374d427607cd52)

2009-Jun-23+16:34:14.922 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (138)
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) TIE_BREAKER(0706050403020100) FIRM_VER(256) *HOST_NAME(lac) VENDOR_NAME(StarentNetworks) *ASSND_TUN_ID(10) *RECV_WIN_SIZE(16) *CHALLENGE(dbed79cdc497f266bd374d427607cd52)

-------------------

2009-Jun-23+16:34:22.879 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13660 to 192.168.51.155:1701 (38)
l2tp:[TLS](0/0)Ns=1,Nr=0 *MSGTYPE(StopCCN) *RESULT_CODE(2/0) *ASSND_TUN_ID(10)

2009-Jun-23+16:34:22.879 [l2tp-control 50069 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_fsm.c:105] [callid 4144ade2] [context: destination, contextID: 3]  [software internal user] l2tp fsm: state L2TPSNX_STATE_WAIT_TUNNEL_ESTB event L2TPSNX_EVNT_PROTO_TUNNEL_DISCONNECTED

Here is the resultant SNMP trap triggered to match the above logs for the moment the system determined the failure:

Tue Jun 23 16:34:22 2009 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 192.168.51.155 local address 192.168.51.152

Whether or not the peer address is known, logging will be needed to authoritatively determine where the problem might lie, especially if it turns out to be a protocol issue (vs. purely a transport or far end (LNS or LAC) failure issue)

With the peer address known, a very basic test would be to ping it from the context where the service is defined. If the network transport is good, a response should be received.

As mentioned above, the other reason for the L2TPTunnelDownPeerUnreachable trap is no response to "keepalive-interval" messages. These are used during periods where there are no control messages or data being sent over the tunnel, to ensure that the other end is still alive. IF there are sessions in the tunnel, but they are not doing anything, this command ensures that the tunnel is still working properly, because by enabling it, keepalive messages are sent after the configured period of no packet exchange (i.e. 60 seconds), and responses are expected. The frequency of sending the keepalive after sending the first one and not getting a response is the same as described above for tunnel setup. So, after 23 seconds of not receiving a response to hello (keepalive) messages, the tunnel will be torn down. See configurable “keepalive-interval” (default = 60s).

Here are examples of successful keep-alive exchange, both from monitor subscriber and logging. Note the interval of one minute between sets of messages as a result of no user data being transmitted for one minute. In this example, the LAC and LNS services are located in the same chassis, in contexts named "destination" and "lns" respectively. Because of this, duplicates of the same message are displayed for logging.

INBOUND>>>>>  12:54:35:660 Eventid:50000(3)
L2TP Rx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (20)
l2tp:[TLS](5/0)Ns=19,Nr=23 *MSGTYPE(HELLO)

<<<<OUTBOUND  12:54:35:661 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (12)
l2tp:[TLS](1/0)Ns=23,Nr=20 ZLB

<<<<OUTBOUND  12:55:35:617 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (20)
l2tp:[TLS](1/0)Ns=23,Nr=20 *MSGTYPE(HELLO)

INBOUND>>>>>  12:55:35:618 Eventid:50000(3)
L2TP Rx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (12)
l2tp:[TLS](5/0)Ns=20,Nr=24 ZLB

2009-Jul-07+12:54:35.660 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 106478e8] [context: lns, contextID: 11]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (20)
l2tp:[TLS](5/0)Ns=19,Nr=23 *MSGTYPE(HELLO)
2009-Jul-07+12:54:35.660 [l2tp-control 50000 debug] [7/0/9133 <l2tpmgr:2> l2tp.c:13050] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user inbound protocol-log] L2TP Rx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (20)
l2tp:[TLS](5/0)Ns=19,Nr=23 *MSGTYPE(HELLO)
2009-Jul-07+12:54:35.661 [l2tp-control 50021 debug] [7/0/9133 <l2tpmgr:2> l2tp.c:953] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user] L2TP Protocol (Local[svc: lac]: 5/0  Remote[192.168.51.155]: 1/0): Number of Messages in Sent Control Queue: 0
2009-Jul-07+12:54:35.661 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (12)
l2tp:[TLS](1/0)Ns=23,Nr=20 ZLB
2009-Jul-07+12:54:35.661 [l2tp-control 50000 debug] [7/0/555 <l2tpmgr:1> l2tp.c:13050] [callid 106478e8] [context: lns, contextID: 11]  [software internal user inbound protocol-log] L2TP Rx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (12)
l2tp:[TLS](1/0)Ns=23,Nr=20 ZLB
2009-Jul-07+12:54:35.661 [l2tp-control 50021 debug] [7/0/555 <l2tpmgr:1> l2tp.c:953] [callid 106478e8] [context: lns, contextID: 11]  [software internal user] L2TP Protocol (Local[svc: lns]: 1/0  Remote[192.168.51.152]: 5/0): Number of Messages in Sent Control Queue: 0


2009-Jul-07+12:55:35.617 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (20)
l2tp:[TLS](1/0)Ns=23,Nr=20 *MSGTYPE(HELLO)
2009-Jul-07+12:55:35.618 [l2tp-control 50000 debug] [7/0/555 <l2tpmgr:1> l2tp.c:13050] [callid 106478e8] [context: lns, contextID: 11]  [software internal user inbound protocol-log] L2TP Rx PDU, from 192.168.51.152:13661 to 192.168.51.155:13660 (20)
l2tp:[TLS](1/0)Ns=23,Nr=20 *MSGTYPE(HELLO) 2009-Jul-07+12:55:35.618 [l2tp-control 50021 debug] [7/0/555 <l2tpmgr:1> l2tp.c:953] [callid 106478e8] [context: lns, contextID: 11]  [software internal user] L2TP Protocol (Local[svc: lns]: 1/0  Remote[192.168.51.152]: 5/0): Number of Messages in Sent Control Queue: 0
2009-Jul-07+12:55:35.618 [l2tp-control 50001 debug] [7/0/555 <l2tpmgr:1> l2tpsnx_proto.c:1474] [callid 106478e8] [context: lns, contextID: 11]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (12)
l2tp:[TLS](5/0)Ns=20,Nr=24 ZLB
2009-Jul-07+12:55:35.618 [l2tp-control 50000 debug] [7/0/9133 <l2tpmgr:2> l2tp.c:13050] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user inbound protocol-log] L2TP Rx PDU, from 192.168.51.155:13660 to 192.168.51.152:13661 (12)
l2tp:[TLS](5/0)Ns=20,Nr=24 ZLB
2009-Jul-07+12:55:35.619 [l2tp-control 50021 debug] [7/0/9133 <l2tpmgr:2> l2tp.c:953] [callid 42298fa6] [context: destination, contextID: 3]  [software internal user] L2TP Protocol (Local[svc: lac]: 5/0  Remote[192.168.51.155]: 1/0): Number of Messages in Sent Control Queue: 0

Finally, here is an example where, for an EXISTING tunnel (NOT one that is attempting to be setup the first time), hello messages are not responded to, and the call and tunnel are torn down. Monitor Subscriber output:

<<<<OUTBOUND  14:06:21:406 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)

<<<<OUTBOUND  14:06:22:413 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)

<<<<OUTBOUND  14:06:24:427 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)

<<<<OUTBOUND  14:06:28:451 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)

<<<<OUTBOUND  14:06:36:498 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)

<<<<OUTBOUND  14:06:44:446 Eventid:50001(3)
L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (38)
l2tp:[TLS](2/0)Ns=5,Nr=2 *MSGTYPE(StopCCN) *RESULT_CODE(2/0) *ASSND_TUN_ID(6)

Here are the respective logs and SNMP trap. Note the output "Control tunnel timeout -  retry-attempted 5 , last-interval 8000 ms" for the failed attempts.

2009-Jul-07+14:06:21.406 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)
2009-Jul-07+14:06:22.413 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)
2009-Jul-07+14:06:24.427 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)
2009-Jul-07+14:06:28.451 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)
2009-Jul-07+14:06:36.498 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (20)
l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)
2009-Jul-07+14:06:44.446 [l2tp-control 50068 warning] [7/0/9133 <l2tpmgr:2> l2tp.c:14841] [callid 42c22625] [context: destination, contextID: 3]  [software internal user] L2TP (Local[svc: lac]: 6  Remote[192.168.51.155]: 2): Control tunnel timeout -  retry-attempted 5 , last-interval 8000 ms, Sr 2, Ss 5, num-pkt-not-acked 1, Sent-Q-len 1, tun-recovery-flag 0, instance-recovery-flag 0, msg-type Hello
2009-Jul-07+14:06:44.446 [l2tp-control 50001 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_proto.c:1474] [callid 42c22625] [context: destination, contextID: 3]  [software internal user outbound protocol-log] L2TP Tx PDU, from 192.168.51.152:13661 to 192.168.51.155:13661 (38)
l2tp:[TLS](2/0)Ns=5,Nr=2 *MSGTYPE(StopCCN) *RESULT_CODE(2/0) *ASSND_TUN_ID(6)
2009-Jul-07+14:06:44.447 [l2tp-control 50069 debug] [7/0/9133 <l2tpmgr:2> l2tpsnx_fsm.c:105] [callid 42c22625] [context: destination, contextID: 3]  [software internal user] l2tp fsm: state L2TPSNX_STATE_CONNECTED event L2TPSNX_EVNT_PROTO_SESSION_DISCONNECTED

Tue Jul 07 14:06:44 2009 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 192.168.51.155 local address 192.168.51.152

Running the following command will indicate if there have been peer reachability issues with a specific peer (or for all tunnels in a particular lac/lns service)

show l2tp statistics (peer-address <peer ip address> | ((lac-service | lns-service) <lac or lns service name>))

The “Active Connections” counter matches the number of existing tunnels for that peer – there can be more than one, as seen in the output from “show l2tp tunnels all” from earlier.

Remember that the output for all statistics and counters commands includes data going back to when the statistic/counter was last reset or the chassis rebooted, so a single snapshot of this information is not really useful for troubleshooting. The appropriate statistics can be noted (and optionally cleared which makes it much easier to keep track of the new increments because the numbers are much smaller and will have started at zero) and can continue to be run to see if the problem continues to occur or clears or has cleared already. To clear statistics: “clear l2tp statistics”

The “Failed to Connect” counter will indicate how many tunnel setup failures have occurred.
The “Max Retry Exceeded” counter is probably the most important counter, as it indicates failure to connect due to a timeout (each Retry exceeded results in a L2TPTunnelDownPeerUnreachable trap). Again, this information only tells you the frequency of the problem for a given peer, it does not tell you why the timeout occurred. But knowing the frequency can be helpful in putting together the pieces in the overall troubleshooting process.

The Sessions section gives detail at the subscriber session level (vs. tunnel level)
The “Active Sessions” counter matches the sum of (if more than one tunnel for a peer) the “Active Sess” column output from “show l2tp tunnels” for the particular peer.
The “Failed to Connect” counter indicates how many sessions have failed to connect. Note that failed session setups do NOT trigger the L2TPTunnelDownPeerUnreachable trap, only failed tunnel setups do.

There is also a counters version of the “show l2tp tunnels” command that may be useful:

show l2tp tunnels counters peer-address <peer address>

Finally, at the session level, all of the subscribers for a given peer can be viewed.

show l2tp sessions peer-address <peer ip address>

The number of subscribers found should match the number of active sessions as discussed above.

Imported from Starent Networks Knowledgebase Article # 10540

Version history
Revision #:
1 of 1
Last update:
‎01-25-2012 06:38 AM
Updated by:
 
Everyone's tags (1)