L2TP dans StarOS - Mise en oeuvre sur ASR5k et dépannage de l'appairage L2TP - L2TPTunnelDownPeerUnreachable

Introduction

Ce document décrit comment le protocole L2TP (Layer 2 Tunneling Protocol) dans StarOS est mis en oeuvre sur ASR5k et dépannage de l'appairage L2TP - L2TPTunnelDownPeerUnreachable.

Qu’est-ce que L2TP ?

L2TP étend la nature point à point du protocole PPP. L2TP fournit une méthode d’encapsulation pour la transmission de trames PPP à canaux, qui permet aux points d’extrémité PPP d’être tunnellisés sur un réseau à commutation de paquets. Le protocole L2TP est le plus souvent déployé dans des scénarios de type accès distant qui utilisent Internet pour offrir des services de type intranet. Le concept est celui d'un réseau privé virtuel (VPN). 

Les deux principaux éléments physiques de L2TP sont le concentrateur d’accès L2TP (LAC) et le serveur de réseau L2TP (LNS) :

• BAC : Le LAC est un homologue du LNS qui agit comme un côté du point d'extrémité du tunnel. Le LAC met fin à la connexion PPP distante et se trouve entre le distant et le LNS. Les paquets sont transférés vers et depuis la connexion distante via la connexion PPP. Les paquets en provenance et à destination du LNS sont transférés via le tunnel L2TP.

• LNS : Le LNS est un homologue du LAC qui agit comme un côté du point d'extrémité du tunnel. Le LNS est le point de terminaison des sessions en tunnel PPP de LAC. Il est utilisé pour agréger les sessions PPP multicanaux de LAC et pour entrer dans le réseau privé. 

Configuration L2TP simplifiée dans le réseau mobile, comme illustré dans cette image.

Il existe deux types de message différents que L2TP utilise :

• Messages de contrôle : L2TP transmet les messages de contrôle et de données sur des canaux de contrôle et de données distincts. Le canal de contrôle intrabande transmet les messages de gestion de connexion de contrôle séquencé, de gestion des appels, de rapport d'erreurs et de contrôle de session. L'initialisation de la connexion de contrôle n'est pas spécifique au LAC ou au LNS, mais plutôt à l'émetteur et au récepteur du tunnel qui a de la pertinence dans l'établissement de la connexion de contrôle. Une méthode d'authentification par défi à secret partagé est utilisée entre les points d'extrémité du tunnel. 

• Messages de données : Les messages de données sont utilisés pour encapsuler les trames PPP envoyées dans le tunnel L2TP.

L'établissement détaillé du flux d'appels et du tunnel est expliqué ici :

http://www.cisco.com/c/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/23980-l2tp-23980.html

Où l'utilisons-nous dans la mobilité ?

Le déploiement type est destiné aux utilisateurs d'entreprise où le GGSN agit comme LAC et établit des tunnels sécurisés vers LNS qui sont exploités dans le réseau d'entreprise. Des flux d'appels détaillés sont disponibles dans l'annexe du guide de configuration GGSN qui se trouve, par version logicielle spécifique, ici :

http://www.cisco.com/c/en/us/support/wireless/asr-5000-series/products-installation-and-configuration-guides-list.html

Qu'est-ce que ASR5x00 dans cette configuration ?

ASR5k peut prendre en charge les fonctionnalités LAC et LNS. 

Configuration pour activer les services sur les périphériques Cisco sur l'ASR5k 

Exemple de configuration pour LAC sur ASR5k

 apn test-apn
      accounting-mode none
      aaa group AAA
      authentication msisdn-auth
      ip context-name destination
      tunnel l2tp peer-address 1.1.1.1 local-hostname lac_l2tp   

 configure
   context destination-gi
   lac-service l2tp_service
      allow called-number value apn
      peer-lns 1.1.1.1 encrypted secret pass
      bind address 1.1.1.2

Exemple de configuration pour LNS sur ASR5k

  configure
  context destination-gi
    lns-service lns-svc  
    bind address 1.1.1.1
    authentication { { [ allow-noauth | chap < pref  > | mschap <  pref  > | | pap <  pref  >  | msid-auth }  

Exemple de configuration de LNS sur le périphérique Cisco IOS

Ceci peut être utilisé comme exemple de configuration de prise en charge pour la configuration de Cisco IOS et n'est pas soumis à cet article. 

Configuration LNS

 aaa group server radius AAA
 server 2.2.2.2 auth-port 1812 acct-port 1813
 ip radius source-interface GigabitEthernet0/1
 !

 aaa authentication login default local
 aaa authentication ppp AAA group AAA
 aaa authorization network AAA group AAA
 aaa accounting network default
 action-type start-stop
 group radius 

 vpdn-group vpdn
 accept-dialin
 protocol l2tp
 virtual-template 10
 l2tp tunnel password pass 

 interface Virtual-Template10
 ip unnumbered GigabitEthernet0/1
 peer default ip address pool AAA
 ppp authentication pap chap AAA
 ppp authorization AAA

Dépanner un événement homologue inaccessible

Cette section donne quelques directives sur la façon de dépanner l'événement L2TPTunnelDownPeerUnreachable dans le réseau. Il est expliqué ici en référence au RP fermé PDSN, mais les étapes de dépannage sont les mêmes lors du dépannage avec GGSN/PGW. 

À titre de rappel, un tunnel LAC vers LNS est créé afin de contenir les sessions d'abonnés pendant qu'il étend la connexion d'abonné d'un PDSN/HA/GGSN/PGW au LNS où il est terminé et où une adresse IP est fournie. S'il se trouve sur un châssis StarOS, le LNS obtient une adresse IP à partir d'un pool d'adresses IP configuré. Si sur un autre LNS, par exemple dans les locaux du client, l'adresse IP est fournie par le LNS. Dans ce dernier scénario, cela pourrait permettre aux utilisateurs de se connecter à leur réseau domestique via un LAC exécuté sur un partenaire d'itinérance.

Un tunnel LNS LAC est d'abord créé lorsque la première session d'abonné est tentée d'être configurée et reste active tant qu'il y a des sessions dans le tunnel. 

Lorsque la dernière session se termine pour un tunnel donné, ce tunnel est fermé ou arrêté. Plusieurs tunnels peuvent être établis entre les mêmes homologues LAC-LNS. 

Voici un extrait du résultat de la commande show l2tp tunnels all qui montre ceci dans ce cas le châssis héberge à la fois les services LAC et LNS (TestLAC et TestLNS). Notez que les tunnels LAC et LNS ALL ont des sessions, tandis que certains tunnels RP fermés n'ont aucune session.

 [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  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 

La configuration des services peut être vue avec

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

Voici un exemple du piège L2TPTunnelDownPeerUnreachable avec le service LAC 1.1.1.2 et le service LNS (homologue) 1.1.1.1

 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 1.1.1.1 local address 1.1.1.2

Récupère le nombre de fois que ce déroutement a été déclenché (depuis le rechargement ou la dernière réinitialisation des statistiques) à l'aide de la commande show snmp trap statistics

Le déroutement L2TPTunnelDownPeerUnreachable est déclenché pour L2TP lorsqu'un délai d'installation du tunnel se produit OU que des paquets de maintien en vie (Hello) ne reçoivent pas de réponse. La cause est généralement due au fait que l'homologue LNS ne répond pas aux demandes de BAC ou aux problèmes de transport dans les deux directions.

Il n'y a pas de piège pour indiquer que l'homologue devient accessible, ce qui, s'il n'est pas compris comment enquêter plus loin, peut conduire à la confusion quant à savoir s'il existe encore un problème ou non au moment de l'enquête (demande de fonction soumise).

Pour continuer, la partie la plus importante dont nous avons besoin est l'adresse IP de l'homologue. La première étape consiste à s’assurer que la connectivité IP peut être vérifiée avec PING. Si la connectivité existe, vous pouvez poursuivre les débogages

****THIS IS TO BE RUN CAREFULLY and UPON verification of TAC/BU****
 
 
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)

Remarques : 

l2tpmgr suit la configuration de la session d'abonné spécifique

l2tp-control trace l'établissement du tunnel :

Voici un exemple de débogage de cette sortie

Cas d’utilisation : Échec de la configuration initiale du tunnel en raison des délais d'attente des nouvelles tentatives

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

--------------------- 
 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 1.1.1.2:13660 to 1.1.1.1: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)  
 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 1.1.1.2:13660 to 1.1.1.1: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)  
 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 1.1.1.2:13660 to 1.1.1.1: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)  
 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 1.1.1.2:13660 to 1.1.1.1: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)  
 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 1.1.1.2:13660 to 1.1.1.1: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)  
 ------------------- 

 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 1.1.1.2:13660 to 1.1.1.1:1701 (38) 
 l2tp:[TLS](0/0)Ns=1,Nr=0 *MSGTYPE(StopCCN) *RESULT_CODE(2/0) *ASSND_TUN_ID(10) 
 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 

Voici le déroutement SNMP résultant déclenché pour correspondre aux journaux ci-dessus au moment où le système a déterminé la défaillance

 16:34:22 2009 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 1.1.1.1 local address 1.1.1.2

Cas d’utilisation : Échec de la configuration initiale du tunnel en raison des délais d'attente des nouvelles tentatives - Analyse

Ce que nous voyons, c'est que le tunnel arrive à 16h34 et il tente d'envoyer le défi cinq fois. Apparemment, il n'y a pas de réponse et finalement le tunnel se déconnecte. 

Examinez les valeurs de configuration par défaut ou configurées et reportez-vous à la section

       max-retransmission 5
       retransmission-timeout-first 1
       retransmission-timeout-max 8

Cette configuration doit être interprétée comme une première retransmission après 1 seconde, puis une augmentation exponentielle - doublant à chaque fois : 1, 2, 4, 8, 8.

Notez que le terme max-retransmissions (cinq) inclut la première tentative/transmission. 
retransmission-timeout-max est la durée maximale entre les transmissions après (si) cette limite est atteinte
retransmission-timeout-first est le point de départ du délai d’attente avant la première retransmission.

Donc, en faisant le calcul, dans le cas des paramètres par défaut, une défaillance se produirait après 1+ 2 + 4 + 8 + 8 secondes = 23 secondes, qui est vu exactement comme dans le résultat ci-dessous.

Cas d’utilisation : Échec de la configuration initiale du tunnel en raison de keepalives

L'autre raison du déroutement L2TPTunnelDownPeerUnreachable n'est pas une réponse aux messages keepalive-interval. Ils sont utilisés pendant les périodes où aucun message de contrôle ou données n'est envoyé par le tunnel, pour s'assurer que l'autre extrémité est toujours en vie. S'il y a des sessions dans le tunnel, mais qu'elles ne font rien, cette commande garantit que le tunnel fonctionne toujours correctement, car en l'activant, les messages de test d'activité sont envoyés après la période configurée d'absence d'échange de paquets (c'est-à-dire 60 secondes), et les réponses sont attendues. La fréquence d'envoi du keepalive après l'envoi du premier et l'absence de réponse est la même que celle décrite ci-dessus pour la configuration du tunnel. Ainsi, après 23 secondes après ne pas recevoir de réponse aux messages Hello (keepalive), le tunnel sera désactivé. Voir intervalle de conservation configurable (par défaut = 60).

Voici des exemples d'échanges de maintien en vie réussis, à partir de l'abonné de surveillance et de la journalisation. Notez l'intervalle d'une minute entre les jeux de messages en raison de l'absence de transmission de données utilisateur pendant une minute. Dans cet exemple, les services LAC et LNS sont situés dans le même châssis, dans des contextes nommés destination et lns respectivement. 

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

  <<<<OUTBOUND  12:54:35:661 Eventid:50001(3) 
 L2TP Tx PDU, from 1.1.1.2:13661 to 1.1.1.1:13660 (12) 
  l2tp:[TLS](1/0)Ns=23,Nr=20 ZLB
  
<<<<OUTBOUND  12:55:35:617 Eventid:50001(3) 
 L2TP Tx PDU, from 1.1.1.2:13661 to 1.1.1.1:13660 (20) 
  l2tp:[TLS](1/0)Ns=23,Nr=20 *MSGTYPE(HELLO) 
  
INBOUND>>>>>  12:55:35:618 Eventid:50000(3) 
 L2TP Rx PDU, from 1.1.1.1:13660 to 1.1.1.2:13661 (12) 
 l2tp:[TLS](5/0)Ns=20,Nr=24 ZLB 

 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 1.1.1.1:13660 to 1.1.1.2:13661 (20) l2tp:[TLS](5/0)Ns=19,Nr=23 *MSGTYPE(HELLO)

 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 1.1.1.2:13661 to 1.1.1.1:13660 (20) l2tp:[TLS](1/0)Ns=23,Nr=20 *MSGTYPE(HELLO)

Enfin, voici un exemple où, pour un tunnel EXISTANT, les messages Hello ne reçoivent pas de réponse et l'appel et le tunnel sont désactivés. Sortie de l'abonné moniteur :

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

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

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

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

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

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

Voici les journaux respectifs.

Notez le délai d'attente du tunnel de contrôle de sortie - tentative de nouvelle tentative de cinq, dernier intervalle de 8 000 ms pour les tentatives échouées.

 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 1.1.1.2:13661 to 1.1.1.1:13661 (20) 
 l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)  
 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 1.1.1.2:13661 to 1.1.1.1:13661 (20) 
 l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)  
 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 1.1.1.2:13661 to 1.1.1.1:13661 (20) 
 l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HE	LLO)  
 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 1.1.1.2:13661 to 1.1.1.1:13661 (20) 
 l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)  
 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 1.1.1.2:13661 to 1.1.1.1:13661 (20) 
 l2tp:[TLS](2/0)Ns=4,Nr=2 *MSGTYPE(HELLO)  
 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[1.1.1.1]: 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 
 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 1.1.1.2:13661 to 1.1.1.1:13661 (38) 
 l2tp:[TLS](2/0)Ns=5,Nr=2 *MSGTYPE(StopCCN) *RESULT_CODE(2/0) *ASSND_TUN_ID(6)  
 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 

Et déroutement SNMP correspondant

 14:06:44 2009 Internal trap notification 92 (L2TPTunnelDownPeerUnreachable)  context destination service lac peer address 1.1.1.1 local address 1.1.1.2

Afficher les considérations de sortie

L'exécution de la commande suivante indique s'il y a eu des problèmes d'accessibilité des homologues avec un homologue spécifique (ou pour tous les tunnels d'un service lac/lns particulier).

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

Le compteur Connexions actives correspond au nombre de tunnels existants pour cet homologue, il peut y en avoir plusieurs, comme le montre le résultat de show l2tp tunnels tout à partir de plus tôt.

Le compteur Echec de connexion indique le nombre d'échecs de configuration de tunnel survenus. 
Le compteur Max Retry Exceeded est probablement le compteur le plus important, car il indique un échec de connexion en raison d'un délai d'attente (chaque nouvelle tentative a pour résultat un déroutement L2TPTunnelDownPeerUnreachable). Ces informations vous indiquent uniquement la fréquence du problème pour un homologue donné, mais ne vous indiquent pas pourquoi le délai d'attente s'est produit. Mais connaître la fréquence peut être utile pour assembler les éléments dans le processus de dépannage global.

La section Sessions fournit des détails au niveau de la session de l'abonné (par rapport au niveau du tunnel)
Le compteur Sessions actives correspond à la somme (si plusieurs tunnels pour un homologue) de la sortie de colonne Sessions actives de la commande show l2tp tunnels pour l'homologue particulier.
Le compteur Échec de connexion indique le nombre de sessions qui n'ont pas pu se connecter. Notez que les échecs de configuration de session ne déclenchent PAS le piège L2TPTunnelDownPeerUnreachable, seuls les échecs de configuration de tunnel le font.

Il existe également une version counters de la commande show l2tp tunnels qui peut être utile.

 show l2tp tunnels counters peer-address <peer address>

Enfin, au niveau de la session, tous les abonnés d'un homologue donné peuvent être affichés.

 show l2tp sessions peer-address <peer ip address>

Le nombre d'abonnés trouvés doit correspondre au nombre de sessions actives tel que discuté.