فهم المعلومات المهمة على أوامر تصحيح الأخطاء

المقدمة

يصف هذا وثيقة مبادئ التوجيهية العامة على إستخدام debug أوامر بما في ذلك الأمر debug ip packet المتوفر على منصات Cisco IOS®.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• الاتصال بالموجه باستخدام منافذ وحدة التحكم والمنافذ (AUX) و vty

• مشاكل تكوين Cisco IOS® العامة

• تفسير مخرجات تصحيح أخطاء Cisco IOS®

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

معلومات أساسية

توفر هذه الصفحة بعض الإرشادات العامة حول إستخدام تصحيح الأخطاء المتاحة على Cisco IOSplatforms، بالإضافة إلى أمثلة لاستخدام الأمر debug ip packet تصحيح الأخطاء المشروط بشكل صحيح.

يوفر إخراج أوامر EXEC debug ذات الامتيازات معلومات تشخيصية تتضمن مجموعة متنوعة من أحداث الشبكات البينية المتعلقة بحالة البروتوكول ونشاط الشبكة بشكل عام.

التحذيرات

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

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

قبل بدء debug الأمر، ضع في الاعتبار دائما الإخراج الذي يمكن أن ينتجه هذا الأمر ومقدار الوقت الذي يمكن أن يستغرقه ذلك.

على سبيل المثال، إذا كان لديك موجه مع واجهة معدل أساسية (BRI)، debug isdn q931 فمن المحتمل ألا يضر النظام.

وفي أي وقت، قد يؤدي تنفيذ نفس تصحيح الأخطاء على تهيئة AS5800 مع تكوين E1 بالكامل إلى توليد قدر كبير من الإدخال قد يمكنها من التعليق والتوقف عن الاستجابة.

قبل تصحيح الأخطاء، انظر إلى حمل وحدة المعالجة المركزية باستخدام show processes cpu الأمر. تحقق من توفر وحدة معالجة مركزية (CPU) كافية قبل بدء تصحيح الأخطاء.

راجع أستكشاف أخطاء إستخدام وحدة المعالجة المركزية (CPU) العالي وإصلاحها على موجهات Cisco للحصول على مزيد من المعلومات حول كيفية معالجة أحمال وحدة المعالجة المركزية (CPU) العالية.

على سبيل المثال، إذا كان لديك موجه Cisco 7200 مع واجهة ATM تقوم بالجسر آنذاك، وفقا لمقدار الواجهات الفرعية التي تم تكوينها، فإن إعادة تشغيل الموجه يمكن أن تستخدم الكثير من وحدة المعالجة المركزية (CPU) الخاصة به.

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

قبل التصحيح

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

يحتوي هذا القسم على بعض الإرشادات.

الحصول على مخرجات تصحيح الأخطاء

يمكن للموجهات عرض مخرجات تصحيح الأخطاء على واجهات مختلفة، بما في ذلك منافذ وحدة التحكم والمنافذ (AUX) و vty. يمكن للموجهات أيضا تسجيل الرسائل إلى مخزن مؤقت داخلي إلى خادم syslog خارجي ل UNIX.

تتم مناقشة التعليمات والتحذيرات لكل طريقة بعد ذلك:

منفذ وحدة التحكم

إذا كنت متصلا بوحدة التحكم، ضمن التكوينات العادية، فلا حاجة إلى القيام بعمل إضافي. يجب عرض إخراج تصحيح الأخطاء تلقائيا.

ومع ذلك، تأكد من logging console level تعيين الأمر على النحو المرغوب ومن عدم تعطيل التسجيل باستخدام الأمر no logging console الصحيح.

المنفذ (AUX) المساعد

إذا كنت متصلا عبر منفذ مساعد، فاكتب terminal monitor الأمر. تحقق أيضا من عدم تنشيط no logging on الأمر على الموجه.

منافذ vty

إذا كنت متصلا عبر منفذ مساعد أو عبر برنامج Telnet، فاكتب الأمر terminal monitor التالي. تحقق أيضا من عدم إستخدام no logging on الأمر.

تسجيل الرسائل إلى مخزن مؤقت داخلي

جهاز التسجيل الافتراضي هو وحدة التحكم، ويتم عرض جميع الرسائل على وحدة التحكم ما لم يتم تحديد خلاف ذلك.

لتسجيل الرسائل إلى مخزن مؤقت داخلي، أستخدم أمر التكوين logging buffered الداخلي. هذه هي الصياغة الكاملة لهذا الأمر:

logging buffered no logging buffered 

logging buffered يقوم الأمر بنسخ رسائل السجل إلى مخزن مؤقت داخلي بدلا من كتابتها إلى وحدة التحكم. المخزن المؤقت دائري بطبيعته، لذا فإن الرسائل الأحدث تقوم باستبدال الرسائل القديمة.

لعرض الرسائل التي تم تسجيل الدخول إلى المخزن المؤقت، أستخدم أمر show logging EXEC ذي الامتيازات. الرسالة الأولى المعروضة هي أقدم رسالة في المخزن المؤقت.

يمكنك تحديد حجم المخزن المؤقت بالإضافة إلى مستوى خطورة الرسائل التي سيتم تسجيلها.

no logging buffered يقوم الأمر بإلغاء إستخدام المخزن المؤقت ويكتب الرسائل إلى وحدة التحكم (الافتراضي).

تسجيل الرسائل إلى خادم UNIX Syslog

لتسجيل الرسائل إلى مضيف خادم syslog، أستخدم أمر تكوين موجه التسجيل. فيما يلي الصياغة الكاملة لهذا الأمر:

 logging <ip-address> no logging <ip-address>  

loggingيحدد هذا الأمر مضيف خادم syslog لتلقي رسائل التسجيل. الوسيطة < ip-address> هي عنوان IP الخاص بالمضيف.

بإصدار هذا الأمر أكثر من مرة، يمكنك إنشاء قائمة بخوادم syslog التي تستلم رسائل التسجيل.

no logging يمحو هذا أمر ال syslog نادل مع العنوان يعين من القائمة ميلان إلى جانب من syslogs.

مهام تصحيح الأخطاء السابقة الأخرى

1. قم بإعداد برنامج المحاكي الطرفي (على سبيل المثال، HyperTerminal) حتى يمكنه التقاط إخراج تصحيح الأخطاء إلى ملف. على سبيل المثال، في HyperTerminal، انقرTransfer، ثم انقر Capture Text ، واختر الخيارات المناسبة. لمزيد من المعلومات، ارجع إلى التقاط إخراج النص من HyperTerminal. للحصول على برنامج محاكاة طرفية آخر، ارجع إلى وثائق البرامج.

2. تمكين الطوابع الزمنية بالمللي ثانية (مللي ثانية) باستخدام service timestamps الأمر التالي:

    router(config)#service timestamps debug datetime msec 
         router(config)#service timestamps log datetime msec
   

تضيف هذه الأوامر أختام الوقت إلى تصحيح الأخطاء بالتنسيق MMM DD HH:MM:SS، مشيرة إلى التاريخ والوقت وفقا لساعة النظام. إذا لم يتم تعيين ساعة النظام، فسيتم وضع علامة نجمية (*) قبل التاريخ والوقت للإشارة إلى أن التاريخ والوقت غير صحيحين على الأرجح.

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

ومع ذلك، لاحظ أنه عندما ينتج عن منفذ وحدة التحكم العديد من الرسائل، فإنه لا يمكن ربطها بالتوقيت الفعلي للحدث.

على سبيل المثال، إذا قمت debug x25 بتمكين كل شيء على مربع يحتوي على 200 VCs، وتم تسجيل الإخراج إلى المخزن المؤقت (باستخدام no logging console logging buffered الأوامر)، فلا يمكن أن يكون الطابع الزمني المعروض في إخراج تصحيح الأخطاء (داخل المخزن المؤقت) هو الوقت المحدد الذي تمر فيه الحزمة عبر الواجهة. لذلك، لا تستخدم الطوابع الزمنية ل MSEC لإثبات مشاكل الأداء، ولكن للحصول على معلومات نسبية حول وقت حدوث الأحداث.

لإيقاف تصحيح الأخطاء

لإيقاف تصحيح الأخطاء، أستخدم no debug allundebug allالأوامر النظرية. تحقق من إيقاف تشغيل تصحيح الأخطاء باستخدام الأمرshow debug.

تذكر أن no logging console terminal no monitor الأمر يمنع المخرجات من أن تصبح مخرجات على وحدة التحكم، Aux أو vty على التوالي. لا يقوم بإيقاف تصحيح الأخطاء وبالتالي يستخدم موارد الموجه.

إستخدام أمر debug ip packet

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

أفضل طريقة لتحديد الإخراج debug ip packet من أجل إنشاء قائمة وصول مرتبطة بتصحيح الأخطاء. يمكن إخضاع debug ip packet الحزم التي تطابق معايير قائمة الوصول فقط. لا يلزم تطبيق قائمة الوصول هذه على أي واجهة، بل يتم تطبيقها على عملية تصحيح الأخطاء.

قبل الاستخدام debugging ip packet ، لاحظ أن الموجه يقوم بالتبديل السريع بشكل افتراضي، أو يمكن أن يتم تحويل CEF إذا تم تكوينه للقيام بذلك. وهذا يعني أنه بمجرد وجود هذه التقنيات، لا يتم توفير الحزمة للمعالج، وبالتالي لا يظهر تصحيح الأخطاء أي شيء. لكي يعمل هذا، يلزمك تعطيل التحويل السريع على الموجه باستخدام no ip route-cache (لحزم البث الأحادي) أو no ip mroute-cache (لحزم البث المتعدد). يجب تطبيق هذا على الواجهات التي يفترض أن تتدفق فيها حركة المرور. تحقق من ذلك باستخدام show ip route الأمر.

التحذيرات

• يمكن أن يؤدي تعطيل التحويل السريع على موجه يعالج عددا كبيرا من الحزم إلى إرتفاع إستخدام وحدة المعالجة المركزية (CPU) حتى يتم تعليق المربع أو فقدان إتصاله بأقرانه.

• لا تقوم بتعطيل التحويل السريع على موجه يشغل Multi-Protocol Label Switching (MPLS). يتم إستخدام MPLS بالاقتران مع CEF. لذلك، يمكن أن يكون لتعطيل التحويل السريع على الواجهة تأثير كارثي.

تأمل في هذا السيناريو:

قائمة الوصول التي تم تكوينها على Router_122 هي :

access-list 105 permit icmp host 10.10.10.2 host 10.1.1.1 access-list 105 permit icmp host 10.1.1.1 host 10.10.10.2  

تسمح قائمة الوصول هذه لأي حزمة من حزم بروتوكول رسائل التحكم في الإنترنت (ICMP) من الموجه المضيف_121 (مع عنوان IP 10.10.10.2) إلى الموجه_123 (مع عنوان IP 10.1.1.1) وكذلك في الإتجاه الآخر.

من المهم أن تسمح للحزم في أي من الاتجاهين، وإلا فيمكن للموجه إسقاط حزمة ICMP العائدة.

قم بإزالة التحويل السريع على واجهة واحدة فقط على Router_122. هذا يعني أنه يمكنك فقط رؤية تصحيح الأخطاء للحزم الموجهة لتلك الواجهة، كما هو موضح من منظور Cisco IOS الذي يعترض الحزمة.

من تصحيح الأخطاء، تظهر هذه الحزم مع "d=". نظرا لأنك لم تقم بإيقاف تشغيل التحويل السريع على الواجهة الأخرى بعد، فإن الحزمة العائدة لا تخضع debug ip packet لها. يوضح هذا الإخراج كيفية تعطيل التحويل السريع:

router_122(config)#interface virtual-template 1 router_122(config-if)#no ip route-cache router_122(config-if)#end 

يجب الآن debug ip packet التنشيط باستخدام قائمة الوصول المعرفة مسبقا (access-list 105).

router_122# debug ip packet  detail 105 IP packet debugging is on (detailed) for access list 105 router_122# 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0  ! -- ICMP packet from 10.1.1.1 to 10.10.10.2. ! -- This packet is displayed because it matches the ! -- source and destination requirements in access list 105  00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0

قم الآن بإزالة التحويل السريع على الواجهة الأخرى (على الموجه_122). هذا يعني أن جميع الحزم عبر هذين الواجهات يتم تحويلها الآن إلى حزم (وهو متطلب ل debug ip packet )

router_122(config)#interface serial 3/0 router_122(config-if)#no ip route-cache router_122(config-if)#end router_122# 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0  ! -- ICMP packet (echo) from 10.10.10.2 to 10.1.1.1  00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0  ! -- ICMP return packet (echo-reply) from 10.1.1.1 to 10.10.10.2  00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0

لاحظ أن إخراج حزمة IP للتصحيح لا يعرض أي حزم لا تطابق معايير قائمة الوصول.

أحلت ل بعض معلومة إضافي على هذا إجراء، يفهم العملية أزيز و traceroute أمر.

للحصول على مزيد من المعلومات حول كيفية إنشاء قوائم الوصول، ارجع إلى تسجيل قائمة الوصول إلى IP القياسية.

تصحيح الأخطاء المؤهل

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

انظر إلى تطبيق بسيط للتصحيح الشرطي. ضع في الاعتبار هذا السيناريو: يحتوي الموجه الظاهر بعد ذلك (trabol) على واجهتين (السلسلة 0 والتسلسل 3) تشغلان تضمين HDLC.

يمكنك إستخدام الأمر debug serial interface normalCommand لمراقبة رسائل keepalives الخاصة ب HDLC التي يتم استقبالها على جميع الواجهات. أنت يستطيع راقبت ال keepalives على كلا قارن.

traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up  ! -- HDLC keeplaive on interface Serial 0  *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up  ! -- HDLC keeplaive on interface Serial 3  *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up

تمكين تصحيح الأخطاء الشرطي للواجهة التسلسلية 3. هذا يعني أنه يتم عرض تصحيح الأخطاء فقط للواجهة التسلسلية 3. أستخدم debug interface <interface_type interface_number >الأمر.

traxbol#debug interface serial 3 Condition 1 set

أستخدم show debug condition الأمر للتحقق من أن تصحيح الأخطاء الشرطية نشط. لاحظ أن شرط للواجهة serial 3 نشط.

traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#

لاحظ أنه يتم الآن عرض تصحيح الأخطاء فقط للواجهة التسلسلية 3

*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up

أستخدم undebug interface <interface_type interface_number> الأمر لإزالة تصحيح الأخطاء الشرطي. من المستحسن إيقاف تشغيل تصحيح الأخطاء (على سبيل المثال، باستخدام إلغاء تصحيح الأخطاء الكل) قبل إزالة المشغل الشرطي.

هذا لتجنب طوفان من مخرجات تصحيح الأخطاء عند إزالة الشرط.

traxbol#undebug interface serial 3  This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol

يمكنك الآن ملاحظة عرض تصحيح الأخطاء لكل من الواجهة serial 0 وكذلك التسلسل 3.

*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up

يوضح هذا القسم الطريقة الصحيحة للحد من تصحيح حزم ATM إلى واجهة فرعية واحدة:

arielle-nrp2#debug atm packet interface atm 0/0/0.1  !--- Note that you explicitly specify the sub-interface to be used for debugging  ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#

إذا حاولت atm debugging تمكين جميع الواجهات (بحالة مطبقة)، يمكن أن يعلق الموجه إذا كان يحتوي على عدد كبير من واجهات ATM الفرعية. يتم عرض مثال على الطريقة غير الصحيحة لتصحيح أخطاء ATM.

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

إذا كان عدد الواجهات مرتفعا، فعندئذ يكون إخراج تصحيح الأخطاء لجميع الواجهات مرتفعا للغاية ويمكن أن يتسبب في تعليق الموجه.

arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1  ! -- A condition for a specific interface.  arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O):  ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1  VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O):  !--- You also see debugs for interface ATM0/0/0.1 as you wanted.  VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

معلومات ذات صلة

• دعم تقنية الاتصال والوصول
• الدعم الفني والتنزيلات من Cisco