L2TP في StarOS - تنفيذ على ASR5k واستكشاف أخطاء L2TP Peering - L2TPTunnelDownPeerUnreachable

المقدمة

يصف هذا وثيقة كيف الطبقة 2 tunneling بروتوكول (L2TP) في StarOS يكون طبقت على ال ASR5k واستكشاف أخطاء L2TP peering - L2TPTunnelDownPeerUnreachable.

ما هو L2TP؟

يقوم L2TP بتوسيع طبيعة بروتوكول الاتصال من نقطة إلى نقطة. يوفر L2TP طريقة عملية كبسلة لنقل إطارات PPP النفقي، والتي تسمح بنقاط نهاية PPP بأن يتم إنشاء قنوات لها عبر شبكة محولة للحزم. يتم نشر L2TP بشكل شائع في سيناريوهات الوصول عن بعد التي تستخدم الإنترنت لتقديم خدمات من نوع إنترانت. المفهوم هو شبكة خاصة ظاهرية (VPN). 

العنصران الأساسيان من عناصر L2TP هما مركز الوصول إلى L2TP (LAC) وخادم شبكة L2TP (LNS):

• أمريكا اللاتينية والكاريبي: يعتبر مركز أمريكا اللاتينية ومنطقة البحر الكاريبي بمثابة نظير للمكاتب الوطنية التي تعمل كجانب واحد من نقطة نهاية النفق. يقوم LAC بإنهاء اتصال PPP البعيد ويجلس بين جهاز التحكم عن بعد و LNS. تتم إعادة توجيه الحزم من الاتصال البعيد وإليه عبر اتصال PPP. تتم إعادة توجيه الحزم إلى ومن LNS عبر نفق L2TP.

• LNS: يعد LNS نظيرا ل LAC الذي يعمل كجانب واحد من نقطة نهاية النفق. يمثل LNS نقطة الإنهاء لجلسات PPP النفقي الخاصة بمنطقة أمريكا اللاتينية والكاريبي. ويتم إستخدام هذا لتجميع جلسات PPP المتعددة المحولة إلى منطقة أمريكا اللاتينية والبحر الكاريبي والمدخل إلى الشبكة الخاصة. 

إعداد L2TP مبسط في شبكة الأجهزة المحمولة، كما هو موضح في هذه الصورة.

هناك نوعان مختلفان من الرسائل التي يستخدمها L2TP:

• رسائل التحكم: يقوم L2TP بتمرير رسائل التحكم والبيانات عبر قنوات التحكم والبيانات المنفصلة. تمرر قناة التحكم داخل النطاق إدارة اتصال التحكم المتسلسل، وإدارة المكالمات، والإبلاغ عن الأخطاء، ورسائل التحكم في الجلسة. لا يقتصر بدء اتصال عنصر التحكم على LAC أو LNS، بل على منشئ النفق ومستقبله الذي له صلة بمؤسسة اتصال عنصر التحكم. يتم إستخدام طريقة مصادقة تحدي سري مشترك بين نقاط نهاية النفق. 

• رسائل البيانات: يتم إستخدام رسائل البيانات لتضمين إطارات PPP التي يتم إرسالها إلى نفق L2TP.

يتم شرح تدفق المكالمات التفصيلي وإنشاء النفق هنا:

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

أين نستخدمها في التنقل؟

ويكون النشر النموذجي للمستخدمين في الشركات حيث تعمل الشبكة العالمية للخدمات البيئية كشبكة محلية للخدمات الكهربائية وتنشئ أنفاقا آمنة نحو الشبكات المحلية اللاسلكية (LNS) التي تعمل في الشبكة المؤسسية. تتوفر تدفقات المكالمات التفصيلية في ملحق دليل تكوين GGSN الذي يمكن العثور عليه، لكل إصدار برنامج محدد، هنا:

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

ما هو ASR5x00 في هذا الإعداد؟

يمكن أن يدعم ASR5k وظيفة LAC و LNS. 

التكوين لتمكين الخدمات على أجهزة Cisco على ASR5k 

نموذج تكوين LAC على 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

نموذج تكوين LNS على 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 }  

نموذج تكوين LNS على جهاز Cisco IOS

يمكن إستخدام هذا الأمر كعينة تكوين داعمة لتكوين Cisco IOS ولا يخضع لهذه المقالة. 

تكوين 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

أستكشاف أخطاء أحداث النظير التي يتعذر الوصول إليها وإصلاحها

سيعطي هذا القسم بعض الإرشادات حول كيفية أستكشاف أخطاء L2TPTunnelDownPeerUnreachable وإصلاحها في الشبكة. يتم شرحه هنا مع الإشارة إلى RP مغلق ل PDSN ولكن خطوات أستكشاف الأخطاء وإصلاحها هي نفسها عند أستكشاف الأخطاء وإصلاحها مع GGSN/PGW. 

على سبيل التذكير، يتم إنشاء نفق LAC إلى LNS لاحتواء جلسات عمل المشترك بينما يقوم بتوسيع اتصال المشترك من PDSN/HA/GGSN/PGW إلى LNS حيث يتم إنهاؤه وحيث يتم توفير عنوان IP. إذا كان على هيكل StarOS، فسيحصل LNS على عنوان IP من تجمع IP تم تكوينه. إذا كان في بعض LNS الأخرى، على سبيل المثال في أماكن عمل العميل، يتم توفير عنوان IP بواسطة LNS هناك. وفي السيناريو الأخير، قد يسمح هذا الأمر للمستخدمين بالاتصال بشبكتهم المنزلية من خلال مركز إدارة الشبكة (LAC) الذي يعمل على أحد شركاء التجوال.

يتم إنشاء نفق LNS ل LAC لأول مرة أثناء محاولة إعداد جلسة عمل المشترك الأولى، وسيظل قيد التشغيل طالما كانت هناك جلسات في النفق. 

عندما تنتهي الجلسة الأخيرة لنفق معين، يتم إغلاق ذلك النفق أو إغلاقه. ويمكن إنشاء أكثر من نفق واحد بين نفس النظراء في شبكة LAC-LNS. 

وفيما يلي لقطة من الإخراج من أنفاق الأمر show l2tp all الذي يظهر هذا في هذه الحالة يستضيف الهيكل خدمات LAC و LNS على حد سواء (TestLAC و TestLNS). لاحظ أن أنفاق LAC و LNS جميعها لها جلسات، بينما بعض أنفاق RP المغلقة ليس لها جلسات.

 [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 

يمكن عرض تكوين الخدمات باستخدام

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

وفيما يلي مثال على مصيدة L2TPTunnelDownPeerUnreachable مع خدمة LAC 1.1.1.2 وخدمة LNS (النظير) 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

الحصول على عدد مرات تشغيل هذا الملائمة (منذ إعادة التحميل أو آخر إعادة ضبط للإحصائيات) باستخدام الأمر show snmp trap statistics

يتم تشغيل مصيدة L2TPTunnelDownPeerUnreachable ل L2TP عندما تحدث مهلة إعداد نفق أو لا يتم الاستجابة لحزم KEEP (Hello). وعادة ما يكون السبب هو عدم إستجابة نظير شبكة LNS للطلبات الواردة من منطقة أمريكا اللاتينية ومنطقة البحر الكاريبي أو مسائل النقل في أي من الاتجاهين.

ولا توجد فخاخ للإشارة إلى أن النظير يصبح قابلا للوصول إليه، وهو ما يمكن أن يؤدي، إذا لم يكن مفهوما كيفية إجراء مزيد من التحقيقات، إلى الارتباك فيما إذا كانت لا تزال هناك مشكلة أم لا في وقت التحقيق (طلب الميزة المقدم).

للمتابعة، فإن الجزء الأكثر أهمية الذي نحتاج إليه هو عنوان IP للنظير. الخطوة الأولى هي التأكد من وجود اتصال IP يمكن فحصه باستخدام إختبار الاتصال. إذا كان هناك اتصال، يمكنك متابعة تصحيح الأخطاء

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

ملاحظات: 

يتعقب l2tpmgr إعداد جلسة عمل المشترك المحدد

إنشاء نفق L2tp-control:

هنا نموذج تصحيح الأخطاء من هذا الإخراج

حالة الاستخدام: فشل إعداد النفق الأولي بسبب انتهاء المهلة الزمنية لإعادة المحاولة

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 

فيما يلي مصيدة SNMP الناتجة التي تم تشغيلها لمطابقة السجلات الواردة أعلاه للحظة التي قام النظام فيها بتحديد الفشل

 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

حالة الاستخدام: فشل إعداد النفق الأولي بسبب انتهاء المهلة الزمنية لإعادة المحاولة - التحليل

ما نراه هو أن النفق يأتي في الساعة 16:34 ويحاول إرسال التحدي خمس مرات. على ما يبدو، لا يوجد رد، وفي نهاية المطاف ينفصل النفق. 

ابحث في إعدادات التكوين الافتراضية أو القيم التي تم تكوينها وانظر

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

سيتم تمثيل هذا التكوين كإعادة إرسال أولا بعد ثانية واحدة، ثم زيادة أسية - تتضاعف كل مرة: 1 و 2 و 4 و 8 و 8.

لاحظ أن مصطلح الحد الأقصى لعمليات إعادة الإرسال (خمسة) يشمل المحاولة/الإرسال الأولى. 
Retransmission-timeout-max هو الحد الأقصى لمدة الوقت بين عمليات الإرسال بعد (إذا) بلوغ هذا الحد
retransmission-timeout-first هي نقطة البداية لمدة الانتظار قبل إعادة الإرسال الأولى.

إذا، عند القيام بالحساب، في حالة المعاملات الافتراضية، سيحدث فشل بعد 1+ 2 + 4 + 8 + 8 ثانية = 23 ثانية، والتي ترى تماما كما في المخرجات أدناه.

حالة الاستخدام: فشل إعداد النفق الأولي بسبب رسائل تنشيط الاتصال

السبب الآخر لملائمة L2TPTunnelDownPeerUnreachable ليس إستجابة لرسائل keepalive-interval. ويتم إستخدام هذه العناصر أثناء الفترات التي لا توجد بها رسائل تحكم أو بيانات يتم إرسالها عبر النفق، لضمان أن الطرف الآخر لا يزال على قيد الحياة. إذا كانت هناك جلسات في النفق، ولكنها لا تفعل أي شيء، فإن هذا الأمر يضمن أن النفق لا يزال يعمل بشكل صحيح، لأنه بتمكين هو، يتم إرسال رسائل keepalive بعد الفترة التي تم تكوينها من عدم تبادل الحزم (أي 60 ثانية)، ويتوقع الاستجابات. تردد إرسال رسالة تنشيط الاتصال بعد إرسال الرسالة الأولى وعدم الحصول على إستجابة هو نفسه كما هو موضح أعلاه لإعداد النفق. لذلك، بعد 23 ثانية من عدم تلقي إستجابة لرسائل مرحبا (keepalive)، سيتم هدم النفق. راجع keepalive-interval القابل للتكوين (الافتراضي = 60s).

فيما يلي أمثلة على تبادل البقاء على قيد الحياة الناجح، من كل من مشترك الشاشة والتسجيل. لاحظ الفاصل الزمني لدقيقة واحدة بين مجموعات الرسائل كنتيجة لعدم إرسال بيانات مستخدم لمدة دقيقة واحدة. وفي هذا المثال، توجد خدمتا أمريكا اللاتينية والكاريبي والماوس اللينيني في نفس الهيكل، في سياقات تسمى الوجهة وLNS على التوالي. 

 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)

وأخيرا، ها هو مثال حيث، بالنسبة إلى نفق موجود، لم تستجب رسائل الترحيب، فتم قطع الاتصال والنفق. خرج مشترك جهاز العرض:

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

هنا السجلات المعنية.

لاحظ مهلة نفق التحكم في الإخراج - تمت إعادة المحاولة لخمس مرات، والفاصل الأخير 8000 مللي ثانية للمحاولات الفاشلة.

 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 

وملائمة SNMP المطابقة

 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

إظهار اعتبارات الإخراج

سيشير تشغيل الأمر التالي إلى ما إذا كانت هناك مشاكل في إمكانية الوصول إلى النظير مع نظير معين (أو لكل الأنفاق في خدمة lac/lns معينة)

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

يتطابق عداد الاتصالات النشطة مع عدد الأنفاق الموجودة لذلك النظير هناك يمكن أن يكون أكثر من واحد، كما هو موضح في الإخراج من أنفاق show l2tp جميعها من إصدارات سابقة.

يشير عداد "فشل الاتصال" إلى عدد حالات فشل إعداد النفق التي حدثت. 
قد يكون عداد "الحد الأقصى لإعادة المحاولة المتجاوز" أهم عداد، لأنه يشير إلى فشل الاتصال بسبب المهلة (تجاوزت كل إعادة محاولة النتائج في مصيدة L2TPTunnelDownPeerUnreachable). تخبرك هذه المعلومات فقط عن تكرار المشكلة لنظير معين، ولا تخبرك لماذا حدثت المهلة. ولكن معرفة التردد قد يكون مفيدا في تجميع الأجزاء معا في عملية أستكشاف الأخطاء وإصلاحها بشكل عام.

يوفر قسم الجلسات التفاصيل على مستوى جلسة عمل المشترك (مقابل مستوى النفق)
يتطابق عداد جلسات العمل النشطة مع مجموع (إذا كان هناك أكثر من نفق للنظير) عمود Active Sess الناتج من أنفاق show l2tp للنظير المعين.
يشير عداد "فشل الاتصال" إلى عدد جلسات العمل التي فشلت في الاتصال. لاحظ أن إعدادات جلسة العمل الفاشلة لا تقوم بتشغيل L2TPTunnelDownPeerUnreachable trap، فقط فشل إعدادات النفق تقوم بذلك.

هناك أيضا إصدار عدادات من الأمر show l2tp tunnel الذي يمكن أن يكون مفيدا.

 show l2tp tunnels counters peer-address <peer address>

وأخيرا، على مستوى جلسة العمل، يمكن عرض جميع المشتركين في نظير معين.

 show l2tp sessions peer-address <peer ip address>

يجب أن يتطابق عدد المشتركين الذين تم العثور عليهم مع عدد جلسات العمل النشطة كما تمت مناقشتها.