أستكشاف أخطاء "بروتوكول الخط معطل" وإصلاحها على واجهات POS

خيارات التنزيل

  • PDF     (382.2 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (105.4 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (153.4 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:١٩ مايو ٢٠٠٦
معرّف المستند:16152

لغة خالية من التحيز

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

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء حزمة عبر واجهة موجه SONET (POS) التي تحتوي على حالة بروتوكول خط من "down" وإصلاحها.

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

ترجمة أمر show interface pos

لأغراض المستند، يكون إخراج أمر show interface pos كما يبدي هذا الإخراج. لاحظ الأجزاء المبرزة من العرض والتعليقات:

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!--- The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!--- The loopback has not been set.

     Keepalive set (10 sec) 

!--- The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     0 packets input, 0 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

يشير مرجع أوامر Cisco IOS® إلى أن حالة حقل بروتوكول الخط "تشير إلى ما إذا كانت عمليات البرامج التي تتعامل مع بروتوكول الخط تعتبر الخط قابلا للاستخدام (أي أن رسائل keepalives ناجحة) أو ما إذا كان قد تم إسقاطه بواسطة المسؤول."

الحقول الهامة الأخرى في إخراج show interface pos هي:

  • التضمين—طريقة التضمين المعينة إلى الواجهة.

  • الاسترجاع — يشير إلى ما إذا كان الاسترجاع معينا.

  • keepalive — يشير إلى ما إذا كانت رسائل keepalives تم تعيينها.

نظرة عامة على مكدس بروتوكول POS

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

gspos_a0.gif

تدعم واجهات POS عمليات تضمين متعددة - HDLC و PPP وترحيل الإطارات. وبالتالي، فإن الحزمة عبر SONET هي PPP بشكل أكثر دقة عبر SONET أو HDLC عبر SONET. لا يغطي هذا المستند تضمين ترحيل الإطارات.

يرتبط PPP و HDLC إرتباطا وثيقا ويشتركان في هذه الخصائص:

  • توفير هيكل إطار مع رؤوس ومقطوفات. توفر المقطورة إمكانية التحقق من الأخطاء.

  • قم بتوفير تحديد الإطار، والذي يحدد المستقبل حيث تبدأ الحزمة والإطار وتنتهي بالضبط. في HDLC و PPP، يتم توفير تحديد الإطارات عن طريق نقش تعبئة خاص بين الإطارات أو نقش خامل. النمط هو 0x7E، أو 0111 110.

  • قم بتحديد حد أدنى وأقصى لطول الحزمة.

  • نقل حزم IP وتوفير طريقة للمستقبلين لتحديد النوع الدقيق للحزمة داخل الإطار القادم.

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

إستخدام أوامر debug

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

caution تحذير: نظرا لأن إخراج تصحيح الأخطاء يتم تعيينه كأولوية عالية في عملية وحدة المعالجة المركزية، فقد يؤدي ذلك إلى جعل النظام غير قابل للاستخدام. ولهذا السبب، أستخدم أوامر تصحيح الأخطاء فقط لاستكشاف أخطاء معينة وإصلاحها أو أثناء جلسات أستكشاف الأخطاء وإصلاحها مع موظفي الدعم الفني من Cisco. علاوة على ذلك، من الأفضل إستخدام أوامر تصحيح الأخطاء أثناء فترات انخفاض حركة مرور الشبكة وعدد أقل من المستخدمين. يقلل تصحيح الأخطاء خلال هذه الفترات من أحتمالية تأثير زيادة عمليات معالجة أمر تصحيح الأخطاء على إستخدام النظام. عندما تنتهي باستخدام أمر debug، تذكر أنه يعطله باستخدام الأمر no debug المحدد أو باستخدام الأمر no debug all.

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

  • debug serial interface—يتحقق مما إذا كانت حزم keepalive الخاصة ب HDLC تزيد أم لا. إذا لم تكن كذلك، توجد مشكلة توقيت محتملة على بطاقة الواجهة أو في الشبكة.

  • debug ppp negotiation — يعرض حزم PPP المرسلة أثناء بدء تشغيل PPP، حيث يتم التفاوض مع خيارات PPP.

  • debug ppp packet — يعرض حزم PPP التي يتم إرسالها واستقبالها. يعرض هذا الأمر مكبات حزم منخفضة المستوى.

  • تصحيح أخطاء PPP—يعرض أخطاء PPP (مثل الإطارات غير القانونية أو ذات التكوين الخاطئ) المرتبطة بالتفاوض حول اتصال PPP وتشغيله.

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

بروتوكول الخط معطل مع HDLC

HDLC هو نوع التضمين الافتراضي على واجهة موجه نقطة البيع. إن HDLC هو معيار دولي، ولكن تطبيقات الموردين تختلف من حقل واحد أو أكثر أو الرأس أو المقطورة من حيث الحجم والتنسيق. وتناقش مواصفات TeleOrdia GR-253، التي تحدد SONET، رسم خرائط HDLC عبر SONET (انظر الإصدار 3، القسم 3.4.2.3، pp.3-59). يحدد أن إطار HDLC يجب أن تتم محاذاته بايت مع إطار SONET، ويحدد أيضا تشويش مزامن ذاتي، وفحص تكرار دوري (CRC)، واستخدام حشو علامة HDLC كتعبئة بين الإطارات لتأخذ في الاعتبار الطبيعة المتغيرة لإطارات HDLC القادمة.

إذا أظهر الأمر show interface pos أن الخط والبروتوكول معطلان باستخدام عملية كبسلة HDLC، فيمكنك إستخدام أمر debug serial interface لعزل مشكلة خط كسبب لفشل الاتصال. يستخدم HDLC رسائل keepalives ويبلغ عن قيم ثلاثة عدادات في إخراج تصحيح الأخطاء:

  • myseq— يزيد بمقدار واحد في كل مرة يرسل الموجه حزمة keepalive إلى الموجه البعيد.

  • min—تعكس قيمة عداد minesen آخر رقم لتسلسل myseq اعترف الموجه البعيد باستلامه من الموجه. يقوم الموجه البعيد بتخزين هذه القيمة في العداد المرئي الخاص به وإرسال هذه القيمة في حزمة keepalive إلى الموجه.

  • YouSEE— يعكس قيمة رقم التسلسل الرئيسي الذي استلمه الموجه في حزمة keepalive من الموجه البعيد.

إذا لم تتزايد قيم keepalive في حقول mineseq و see و myseen في كل سطر تالي من الإخراج، فهناك مشكلة في نهاية واحدة من الاتصال. عندما يتجاوز الفرق في القيم في حقلي myseq و minesen ثلاثة، فإن السطر يذهب إلى الأسفل ويتم إعادة تعيين الواجهة.

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

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!--- Keepalives are sent every 10 seconds by default. !--- Both sides report incrementing sequence numbers.

وهذا نموذج إخراج من أمر debug serial interface لاتصال HDLC عند إيقاف تشغيل الواجهة البعيدة وحالات فقد الواجهة المحلية لأكثر من ثلاثة رسائل keepalive. 

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!--- The local router has failed to receive three keepalives and !--- brings down the line protocol. Note the difference between !--- "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- After you execute the no shut command on the remote router, !--- the local router receives a keepalive again and brings up !--- the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!--- After the shut/no shut, the remote router re-initialized its !--- sequence number.

بروتوكول الخط معطل مع PPP

يحدد RFC 1661 leavingcisco.com بروتوكول PPP كبروتوكول. تدعم واجهات نقطة البيع (POS) بروتوكول النقطة إلى النقطة (PPP) في الإطارات الشبيهة بإطار التحكم في إرتباط البيانات عالي المستوى (HDLC)، كما هو محدد في RFC 1662 leavingcisco.com، لتضمين البيانات في الطبقة 2. يتم عرض تنسيق الإطار ل PPP في الإطارات المتشابهة مع HDLC في هذا الشكل.

gspos_a2.gif

يحدد RFC 2615 إستخدام تضمين PPP عبر إرتباطات SONET أو SDH. تم تصميم بروتوكول الاتصال من نقطة إلى نقطة (PPP) للاستخدام على الارتباطات من نقطة إلى نقطة وهو مناسب لارتباطات SONET أو SDH، والتي يتم توفيرها كدوائر من نقطة إلى نقطة حتى في المخططات الحلقية.

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

ثم، يجب أن يرسل PPP حزم بروتوكول التحكم في الشبكة (NCP) لاختيار بروتوكول أو أكثر لطبقة الشبكة وتكوينه. وبمجرد تكوين كل بروتوكول من بروتوكولات طبقة الشبكة المختارة، يمكن إرسال مخططات البيانات من كل بروتوكول من بروتوكولات طبقة الشبكة عبر الارتباط.

يسرد هذا الجدول الفئات الثلاث لحزم LCP:

فئة حزمة LCP أنواع حزم LCP الغرض
تكوين الارتباط configure-request و configure-ack و configure-nak و configure-reject يستخدم لإنشاء إرتباط وتكوينه.
إنهاء الارتباط إنهاء الطلب وإنهاء التشغيل يستخدم لإنهاء إرتباط.
صيانة الروابط التعليمات البرمجية - الرفض والبروتوكول - الرفض و echo - الطلب و echo - الرد و discard - الطلب يستخدم لإدارة إرتباط ما وتصحيح أخطائه.

تكوين الارتباط

يتم إستخدام بروتوكول LCP لإنشاء الاتصال من خلال تبادل حزم التكوين. اكتمل هذا التبادل، ودخلت حالة فتح LCP، بمجرد إرسال حزمة Configure-Ack واستقبالها على حد سواء.

على قبض إخراج النموذج هذا على مرحلة تكوين إرتباط LCP على واجهة نقطة البيع:

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up

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

صيانة الارتباط (باستخدام رسائل تنشيط الاتصال)

توفر حزم LCP Echo-Request و Echo-Response آلية إسترجاع من الطبقة 2 لكلا الاتجاهين من الارتباط. عند إستلام طلب-echo في حالة فتح LCP، يجب إرسال رد-صدى.

يوضح هذا الرسم التخطيطي من RFC 1661 تنسيق حزمة keepalive ل PPP.

16152a.gif

تتضمن حزم LCP هذه حقول المفاتيح:

  • الرمز—9 ل Echo-Request و 10 ل Echo-Reply.

  • المعرف—عند الإرسال، يجب تغيير حقل المعرف كلما تغير محتوى حقل البيانات وكلما تم تلقي رد صحيح لطلب سابق. بالنسبة لعمليات إعادة الإرسال، قد يبقى المعرف بدون تغيير. عند الاستقبال، يتم نسخ حقل المعرف الخاص بطلب الارتداد إلى حقل المعرف الخاص بحزمة رد-صدى.

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

  • البيانات—حقل البيانات يساوي صفرا أو أكثر من الأنظمة الثمانية، ويحتوي على بيانات غير مفسرة ليستخدمها المرسل. قد تتكون البيانات من أي قيمة ثنائية. يشير طول الحقل إلى نهاية الحقل.

وفيما يلي مثال على تفاوض PPP لتصحيح الأخطاء عند تمكين رسائل keepalives:

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up

إنهاء الارتباط

يمكن PPP إنهاء الارتباط في أي وقت. وتتضمن المشغلات المحتملة فقد الناقل أو فشل المصادقة أو فشل جودة الارتباط أو انتهاء صلاحية مؤقت فترة الخمول أو الإغلاق الإداري للارتباط.

يستخدم LCP حزم الإنهاء لإغلاق الارتباط. يجب قطع اتصال مرسل "إنهاء-الطلب" بعد تلقي "إنهاء-Ack"، أو بعد انتهاء صلاحية عداد إعادة التشغيل. يجب أن ينتظر مستقبل "إنهاء طلب" حتى يقوم النظير بقطع الاتصال، ويجب عدم قطع الاتصال حتى يمر وقت إعادة تشغيل واحد على الأقل بعد إرسال Terminate-Ack.

16152a.gif

إنهاء حزم LCP تتضمن حقول المفاتيح التالية:

  • الرمز—5 لطلب الإنهاء و 6 لسجن الإنهاء.

  • المعرف—عند الإرسال، يجب تغيير حقل المعرف كلما تغير محتوى حقل البيانات وكلما تم تلقي رد صحيح لطلب سابق. بالنسبة لعمليات إعادة الإرسال، يمكن أن يبقى المعرف بدون تغيير. عند الاستقبال، يتم نسخ حقل معرف طلب الإنهاء إلى حقل معرف الحزمة Terminate-Ack.

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

هنا مثال على إخراج تفاوض PPP لتصحيح الأخطاء عندما تستلم حزمة TERMREQ:

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!--- While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down

نموذج تسلسل أستكشاف الأخطاء وإصلاحها

يصف هذا القسم نموذج سيناريو أستكشاف الأخطاء وإصلاحها لارتباط POS باستخدام تضمين PPP. وهو يستخدم هذه التكوينات:

تكوين الموجه A 
interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

تكوين الموجه B 
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

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

تفاوض DEBUG PPP

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

إخراج تصحيح الأخطاء للموجه A 
Router A Debug Output  
(1)  

!--- The router sends an outgoing confreq.

hswan-12008-2a#
*Nov  7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line
*Nov  7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open
*Nov  7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D)
 
(4)  

!--- Router A receives an incoming confreq from router B. 

*Nov  7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
 
(5) 

!--- Router A responds with a confack and receives a !--- confack from Router B. The LCP state is open. 
 
*Nov  7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
*Nov  7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176)
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
*Nov  7 08:27:00: PO1/0 LCP: State is Open
*Nov  7 08:27:00: PO1/0 PPP: Phase is UP
 
(7) 

!--- Router A begins the IPCP stage and negotiates an IP address. !--- In this setup, the peer router already has an address and !--- sends it in a confreq. If the peer router accepts the address, !--- it responds with a confack.

*Nov  7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 IPCP: State is Open
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: State is Open
*Nov  7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5
*Nov  7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS1/0, changed state to up

إخراج تصحيح أخطاء الموجه B 
(2) 

!--- Router B receives an incoming confrq from Router A. 

hswan-12008-2b#
Nov  7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 CDPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING
Nov  7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING
 
(3) 

!--- Router B sends its own LCP confreq.
  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2)
 
(6) 

!--- Router B responds with a confack and receives a confack from Router A. 
 
The LCP state is open.  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6
Nov  7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 
Nov  7 10:29:19.047: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.047: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
Nov  7 10:29:19.047: PO2/0 LCP: State is Open
Nov  7 10:29:19.047: PO2/0 PPP: Phase is UP
 
(8) 

!--- Router B also begins the IPCP stage and negotiates an IP address.
  
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 IPCP: State is Open
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: State is Open
Nov  7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6
*Nov  7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS2/0, changed state to up

حزمة debug ppp

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

تعرف قيم حقل البروتوكول في النطاق "0**" إلى "3***" بروتوكول طبقة الشبكة لحزم معينة، والقيم في النطاق "8***" إلى "b***" الحزم التي تنتمي إلى بروتوكولات التحكم في الشبكة (NCPs) المقترنة، إن وجدت. تعرف قيم حقل البروتوكول في النطاق "c***" إلى "f***" الحزم كبروتوكولات تحكم طبقة الارتباط (مثل LCP). هناك أيضا قيم متعددة خاصة بالمورد. انقر هنا للحصول على قائمة كاملة من قيم حقول بروتوكول PPP leavingcisco.com.

إخراج تصحيح الأخطاء للموجه A 
(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!--- 0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!--- 0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!--- 0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!--- 0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up
 
(3) 

!--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

إخراج تصحيح أخطاء الموجه B 
(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up
 
(4) 

!--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

ملاحظات أستكشاف الأخطاء وإصلاحها

تدعم واجهة نقطة البيع مع تضمين PPP أو HDLC آليتين لتنبيهك إلى فشل إرتباط: حزم keepalive للطبقة 2 وتنبيهات طبقة SONET. تستغرق رسائل تنشيط الاتصال وقتا أطول للإبلاغ عن مشكلة من بنية تنبيه SONET المتأصلة. ومع ذلك، فإن رسائل تنشيط الاتصال من الطبقة 2 مفيدة لأنها تقوم بالتحقق من المسار من وحدة المعالجة المركزية (CPU) لبطاقة الخط إلى وحدة المعالجة المركزية (CPU) لبطاقة الخط، بدلا من الإطارات إلى الإطارات كما هو الحال مع أجهزة التنبيه من مستوى SONET. يتفاعل PPP بسرعة أكبر لربط تغييرات الحالة منذ تعطل LCP فورا. وعلى النقيض من ذلك، يجب أن يقوم HDLC بفصل رسائل تنشيط الاتصال.

في إعداد من الخلف إلى الخلف بين موجهين، يؤدي سحب أحد شرائط الألياف إلى كسر اتصال الطبقة 1، وتقوم كلا واجهات POS بتغيير الحالة إلى أسفل/أسفل. ومع ذلك، عند توصيل واجهتي نقطة وصول (POS) للموجه عبر سحابة Telco باستخدام أجهزة SONET/SDH، لا يتم نشر معلومات فقدان الطبقة 1 إلى الطرف البعيد. في هذا تشكيل، keepalives هو الآلية أن يخفض الربط.

ضع في الاعتبار هذا الإعداد.

16152b.gif

هنا ما يحدث عند سحب شريط ألياف الإرسال على الارتباط من SDHb إلى SDHa:

  • لا يستقبل الموجه 7507a أي رسائل keepalives.

  • يرى الموجه 7507b رسائل keepalives من 7507a لأن ألياف الاستقبال لا تزال تعمل. أستخدم الواجهة التسلسلية لتأكيد هذا.

بالتناوب، عند إجراء هذا الاختبار، قم بتنفيذ الأمر show controller pos، الذي يعرض تنبيهات SONET. يجب أن ترى إشارة تنبيه مسار (P-AIS) على الموجه 7507a وإشارة عيب مسار عن بعد (P-RDI) على 7507b.

إختبارات الاسترجاع

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

ملاحظة: قم بتغيير التضمين من PPP إلى HDLC عند إستخدام الاسترجاع. يظهر بروتوكول الخط على واجهة تم تكوينها باستخدام PPP فقط عندما يتم التفاوض على جميع جلسات LCP و NCP بنجاح.

حالة بروتوكول الخط مع APs

تعمل واجهة نقطة البيع التي تم تكوينها للتحويل التلقائي للحماية (AP) على إسقاط بروتوكول الخط إذا كانت الواجهة هي قناة الحماية وليس قناة العمل. ولنتأمل هنا هذا النموذج من الطبولوجيا:

16152c.gif

تم التقاط إخراج السجل العينة هذا بعد إزالة كبلات الألياف على واجهة GSRb POS 1/0. لاحظ التغييرات في حالة بروتوكول الخط على كلا الواجهات عند حدوث تبديل APs. لاحظ أيضا التغييرات في حالات تجاور المسار الأقصر المفتوح أولا (OSPF). (راجع صفحة دعم تقنية نقاط الوصول (AP) للحصول على مزيد من المعلومات.) 

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done

تجنب تكوين نقاط الوصول على واجهة POS باستخدام تضمين PPP. لا يدرك PPP نقاط الوصول. إذا كانت الواجهة up/down بسبب إلغاء تحديد نقاط الوصول، فإن PPP يحاول إعادة ضبط الواجهة ويرسل حزم تفاوض PPP باستمرار.

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

يمكن أن تصبح واجهة نقطة الوصول من السلسلة Cisco 12000 Series في وضع APs الذي يعمل أو يحمي عالقة في حالة up/down (حتى مع الاسترجاع) عندما يتم تعطيل نقاط الوصول. تواجه بطاقة أخرى تم إدخالها في نفس الفتحة هذه المشكلة. انقل البطاقة إلى فتحة جديدة لاستعادة حالة بروتوكول الخط المناسبة. حللت هذا مشكلة في cisco ios برمجية إطلاق 12.0(19)S تحت cisco بق id CSCdt43759 (يسجل زبون فقط).

أستخدم هذه الخطوات كحل بديل:

  1. قم بتكوين الأمر ap protect.

  2. قم بإصدار الأمر apForce 1.

  3. قم بتكوين الأمر no ap protect.

مشكلات معروفة

لاحظ هذه التنبيهات عندما تقوم باستكشاف أخطاء بروتوكول الخط مع واجهات POS وإصلاحها:

  • قد تتم إعادة ضبط واجهة PA-POS بشكل مستمر بعد تغيير التضمين من PPP إلى HDLC. يتم الإبلاغ عن هذه المشكلة مقابل PA-POS في Cisco بق id CSCdk30893 (العملاء المسجلون فقط) ويتم حلها في Cisco BUG CSCdk18777 (العملاء المسجلون فقط) ومعرف تصحيح الأخطاء من Cisco CSCdk13757 (العملاء المسجلون فقط) للواجهات المختلفة التي تدعم عملية كبسلة PPP و HDLC. تحدث المشكلة عندما لا يتم إيقاف تشغيل PPP بالكامل عند تغيير التضمين.

  • تخضع واجهة نقطة وصول (POS) التي تم تكوينها باستخدام تضمين HDLC و keepalives لرقائق واجهة متكررة بدلا من إسقاط بروتوكول الخط عندما لا يتم إستلام رسائل keepalives من الطرف البعيد. حللت هذا مشكلة في cisco بق id CSCdp86387 (يسجل زبون فقط).

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

محفوظات المراجعة

المراجعة تاريخ النشر التعليقات
1.0
19-May-2006
الإصدار الأولي

تمت المساهمة من قبل

  • amdavis
    pdockeri

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا

ينطبق هذا المستند على هذه المنتجات