أستكشاف أخطاء اتصال تقنية الطلب وإصلاحها - يقوم IOS DDR بتهيئة المكالمة

المقدمة

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

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

المتطلبات

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

• كالين

• توجيه اتصال IOS عند الطلب (DDR) من Cisco

• وسيلة شرح غير DDR

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

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

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

التاريخ

Dialup هو ببساطة تطبيق شبكة الهاتف المحولة العامة (PSTN) التي تحمل البيانات نيابة عن المستخدم النهائي. وهو يتضمن جهاز جهاز أماكن عمل العميل (CPE) الذي يرسل المحول الهاتفي رقم هاتف لتوجيه الاتصال إليه. تعد AS3600 و AS5200 و AS5300 و AS5800 كلها أمثلة للموجهات التي لديها القدرة على تشغيل واجهة معدل أولي (PRI) مع بنوك أجهزة المودم الرقمية. أما AS2511، فهي مثال على موجه يتصل بأجهزة المودم الخارجية.

لقد سجل سوق الناقل نموا كبيرا، والآن يتطلب السوق كثافة مودم أعلى. والإجابة على هذه الحاجة هي درجة أعلى من التفاعل مع معدات شركة الهاتف وتطوير المودم الرقمي. وهذا مودم قادر على الوصول الرقمي المباشر إلى PSTN. ونتيجة لذلك، تم الآن تطوير أجهزة مودم CPE أسرع تستفيد من وضوح الإشارة التي تتمتع بها أجهزة المودم الرقمية. وحقيقة أن أجهزة المودم الرقمية التي تتصل ببروتوكول PSTN من خلال واجهة PRI أو واجهة المعدل الأساسي (BRI) يمكن أن تنقل بيانات بأكثر من 53 ألف صفحة باستخدام معيار الاتصال V.90، تشهد على نجاح الفكرة.

كانت أول خوادم الوصول هي AS2509 و AS2511. يمكن أن تدعم AS2509 8 إتصالات واردة باستخدام أجهزة مودم خارجية، ويمكن أن تدعم AS2511 16. تم تقديم AS5200 مع 2 PRI ويمكنه دعم 48 مستخدم باستخدام أجهزة المودم الرقمية، ويمثل قفزة كبيرة إلى الأمام في التكنولوجيا. أزدادت كثافة المودم بشكل مضطرد مع دعم AS5300 ل 4 ثم 8 PRIs. أخيرا، تم إدخال AS5800 لملئ إحتياجات التجهيزات على صنف الناقل التي تحتاج للتعامل مع عشرات من T1S والمئات من إتصالات المستخدمين.

هناك تقنيتان عفا عليهما الزمن تذكران في مناقشة تاريخية لتكنولوجيا الاتصال. 56Kflex هو مودم قياسي أقدم (قبل V.90) بسرعة 56 كيلو تم اقتراحه من قبل Rockwell. تدعم Cisco الإصدار 1.1 من معيار 56KFLEX على أجهزة المودم الداخلية الخاصة بها، ولكنها توصي بترحيل أجهزة مودم CPE إلى V.90 في أقرب وقت ممكن. ومن بين التقنيات الأخرى التي عفا عليها الزمن الطراز AS5100. كانت AS5100 مشروعا مشتركا بين Cisco وشركة مصنعة للمودم. تم إنشاء AS5100 كوسيلة لزيادة كثافة المودم من خلال إستخدام بطاقات المودم الرباعية. تضمنت مجموعة من AS2511s بنيت على هيئة بطاقات أدخلت في لوحة خلفية مشتركة بواسطة بطاقات مودم رباعية، وبطاقة T1 مزدوجة.

الاصطلاحات

للحصول على مزيد من المعلومات حول اصطلاحات المستندات، راجع اصطلاحات تلميحات Cisco التقنية.

يقوم Cisco IOS DDR ببدء المكالمة

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

والتدفق العام للمنطق يشبه ما يلي:

1. هل يقوم توجيه الاتصال عند الطلب (DDR) ببدء مكالمة؟ (الإجابة بنعم تقدم على السؤال التالي).

2. إذا كان هذا مودم غير متزامن، هل تقوم البرامج النصية للدردشة بإصدار الأوامر المتوقعة؟

3. هل نجحت المكالمة مع PSTN؟

4. هل تستجيب الطرف البعيد للمكالمة؟

5. هل اكتملت المكالمة؟

6. هل تمر البيانات عبر الارتباط؟

7. هل إنعقدت الجلسة؟ (PPP أو انتهائية)

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

يسرد السطر التالي من إخراج أحداث طالب تصحيح الأخطاء لحزمة IP اسم واجهة DDR وعناوين المصدر والوجهة للحزمة:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

إذا لم تبدأ حركة المرور محاولة طلب، فإن السبب الأكثر شيوعا هو التكوين غير الصحيح (إما من تعريفات حركة المرور المثيرة للاهتمام، أو حالة واجهة المتصل، أو التوجيه).

إجراء المكالمة

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

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

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

Dialer1: Can't place call, no dialer pool set

بعد ذلك، تعرف نوع الوسائط التي يتم إستخدامها:

• DDR مودم غير متزامن خارجي.

• ذاكرة DDR للمودم غير المتزامن (CAS) T1/E1 المرتبطة بالقناة

• PRI Async Modem DDR

• DDR للمودم غير المتزامن ل BRI.

• PRI ISDN DDR

• BRI ISDN DDR

ذاكرة DDR للمودم غير المتزامن الخارجي.

1. لتحديد DDR مودم غير متزامن خارجي، أستخدم الأوامر التالية، ثم حاول إجراء مكالمة:

   router# debug modem
   router# debug chat line  
            
   
   

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

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

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

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. تأكد من أن البرنامج النصي للدردشة يحاول الاتصال المتوقع (أي الرقم الصحيح) استنادا إلى "سلسلة الإرسال." إذا لم يحاول البرنامج النصي للدردشة إجراء المكالمة المتوقعة، فتحقق من تكوين البرنامج النصي للدردشة. أستخدم الأمر start-chat في نافذة مطالبة EXEC لبدء البرنامج النصي للدردشة يدويا.

4. يمكن أن يصف عرض "المهلة المتوقعة: الاتصال" العديد من الاحتمالات المختلفة:

   • الإمكانية 1: لا يقوم المودم المحلي بالفعل بإجراء الاتصال. تحقق من أنه يمكن للمودم إجراء مكالمة عن طريق تنفيذ برنامج Telnet عكسي للمودم وبدء طلب يدويا. إذا كان الطرف البعيد لا يبدو أنه يجيب، فتحقق من وضع المكالمة بواسطة المودم الأصلي عن طريق إستدعاء رقم محلي يدويا باستخدام الأمر ATDT <number> والاستماع إلى الحلقة.

   • الإمكانية 2: لا يستجيب المودم البعيد. اختبر هذا عن طريق طلب المودم البعيد باستخدام هاتف POTS عادي. جرب هذا:

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

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

     3. إذا كانت المكالمة اليدوية لا تزال غير قادرة على الوصول إلى الهاتف العادي على الخط المعني، فحاول إستخدام خط آخر (معروف جيدا) في مرفق الاستقبال. إذا كان ذلك يتصل "موافق"، فاطلب من شركة Telco التحقق من خط الهاتف الذي يذهب إلى مودم التلقي.

     4. إذا كانت هذه مكالمة بعيدة، اطلب من الجانب الأصلي تجربة رقم مسافة طويلة (معروف جيدا) آخر. وإذا نجح ذلك، فقد لا يتم توفير مرفق الاستلام أو الخط لتلقي المكالمات البعيدة. إذا لم يتمكن الخط الأصلي من الوصول إلى أي أرقام مسافات طويلة أخرى، فقد لا يتم تمكين المسافة الطويلة له. جرب رموز 1010 لشركات المسافات الطويلة المختلفة.

     5. أخيرا، حاول إستخدام رقم محلي (معروف جيدا) آخر من السطر الأصلي. إذا فشل الاتصال حتى الآن، اطلب من شركة Telco التحقق من الخط الأصلي.

   • الإمكانية 3: الرقم الذي تم طلبه غير صحيح. تحقق من الرقم عن طريق طلبه يدويا. قم بتصحيح التكوين، إذا لزم الأمر.

   • الإمكانية 4: يستغرق تدريب المودم وقتا طويلا أو أن قيمة المهلة منخفضة للغاية. حاول زيادة قيمة المهلة في الأمر chat-script. إذا كانت المهلة عبارة عن 60 ثانية بالفعل أو أكثر، فقد تكون هناك مشكلة كبل بين المودم و DTE الذي يتصل به. قد تشير إخفاقات التدريب أيضا إلى وجود مشكلة في الدائرة الكهربائية أو عدم توافق المودم.

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

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

5. إذا كان كل شيء يعمل على ما يرام ولا يزال يتعذر عليك الاتصال بجهاز CAS المودم غير المتزامن DDR، فحاول تصحيح أخطاء PPP. أستخدم الأوامر:

   router# debug ppp negotiation
        router# debug ppp authentication
   

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

DDR المودم غير المتزامن CAS T1/E1

1. للتعرف على CAS T1/E1 Async Modem DDR، أستخدم الأوامر التالية، ثم حاول إجراء مكالمة:

   تحذير:  قد يؤدي تشغيل تصحيح الأخطاء على نظام مشغول إلى تعطيل الموجه من خلال التحميل الزائد لوحدة المعالجة المركزية أو التشغيل الزائد للمخزن المؤقت لوحدة التحكم!

   router# debug modem
   router# debug chat or debug chat line n
   
   router# debug modem csm
   router# debug cas
   

   ملاحظة: يتوفر الأمر debug cas على الأنظمة الأساسية Cisco AS5200 و AS5300 التي تشغل نظام Cisco IOS؟؟ الإصدار 12.0(7)T من البرنامج والإصدارات الأحدث. في الإصدارات السابقة من IOS، يجب إدخال خدمة الأوامر الداخلية إلى المستوى الرئيسي لتكوين الموجه وسيلزم إدخال تصحيح أخطاء CSM للمودم-mgmt في موجه أمر EXEC. يتطلب تصحيح الأخطاء على Cisco AS5800 الاتصال ببطاقة خط الاتصال. (أستخدم modem-mgmt csm no-debug-rbs لإيقاف تشغيل تصحيح الأخطاء.)

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

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

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

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. تأكد من أن البرنامج النصي للدردشة يحاول الاتصال المتوقع (أي الرقم الصحيح) استنادا إلى "سلسلة الإرسال". إذا لم يحاول البرنامج النصي للدردشة إجراء المكالمة المتوقعة، فتحقق من تكوين البرنامج النصي للدردشة. أستخدم الأمر start-chat في نافذة مطالبة EXEC لبدء البرنامج النصي للدردشة يدويا.

4. يمكن أن يصف عرض "المهلة المتوقعة: الاتصال" العديد من الاحتمالات المختلفة:

   • الإمكانية 1: لا يقوم المودم المحلي بالفعل بإجراء الاتصال. تحقق من إمكانية قيام المودم بإجراء مكالمة عن طريق تنفيذ برنامج Telnet عكسي على المودم وتمهيد الطلب يدويا. إذا كان الطرف البعيد لا يستجيب على ما يبدو، فتحقق من وضع المكالمة بواسطة المودم من خلال إستدعاء رقم محلي يدويا باستخدام الأمر ATDT<number> والاستماع إلى الحلقة.

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

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

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

     router# debug modem
     router# debug modem csm
     router# debug cas 
     

     ملاحظة: ظهر الأمر debug cas لأول مرة في الإصدار 12.0(7)T ل AS5200 و AS5300. تستخدم الإصدارات السابقة من IOS خدمة داخلية لأوامر التكوين على مستوى النظام مع أمر EXEC modem-mgmt debug rbs:

     يتم الآن تشغيل تصحيح الأخطاء:

     router#conf t 
     Enter configuration commands, one per line.  End with CNTL/Z. 
     router(config)#service internal 
     router(config)#^Z 
     router#modem-mgmt csm ? 
       debug-rbs     enable rbs debugging 
       no-debug-rbs  disable rbs debugging 
     router#modem-mgmt csm debug-rbs 
     router# 
     neat msg at slot 0: debug-rbs is on 
     neat msg at slot 0: special debug-rbs is on 
     

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

     router#modem-mgmt csm no-debug-rbs 
     neat msg at slot 0: debug-rbs is off 

     يتطلب تصحيح هذه المعلومات على AS5800 الاتصال ببطاقة خط الاتصال. فيما يلي مثال على مكالمة صادرة عادية عبر CAS T1 يتم توفيرها وتكوينها ل FXS-Ground-Start:

     Mica Modem(1/0): Rcvd Dial String(5551111) 
     [Modem receives digits from chat script]
     
     CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_LOCK at slot 1 and port 0 
     
     CSM_PROC_OC4_DIALING: 
     CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
     
     Mica Modem(1/0): Configure(0x1) 
     
     Mica Modem(1/0): Configure(0x2) 
     
     Mica Modem(1/0): Configure(0x5) 
     
     Mica Modem(1/0): Call Setup 
     
     neat msg at slot 0: (0/2): Tx RING_GROUND 
     
     Mica Modem(1/0): State Transition to Call Setup 
     
     neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
     [Telco switch goes OFFHOOK]
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_START_TX_TONE at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
     
     neat msg at slot 0: (0/2): 
     Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
     
     Mica Modem(1/0): Rcvd Tone detected(2) 
     
     Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
     
     Mica Modem(1/0): Rcvd Digits Generated 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
     
     Mica Modem(1/0): Link Initiate 
     
     Mica Modem(1/0): State Transition to Connect 
     
     Mica Modem(1/0): State Transition to Link 
     
     Mica Modem(1/0): State Transition to Trainup 
     
     Mica Modem(1/0): State Transition to EC Negotiating 
     
     Mica Modem(1/0): State Transition to Steady State 
     
     Mica Modem(1/0): State Transition to Steady State Speedshifting 
     
     Mica Modem(1/0): State Transition to Steady State
     

     تتماثل عمليات تصحيح الأخطاء ل T1s و E1s مع أنواع الإشارات الأخرى.

     الوصول إلى هذه النقطة في تصحيح الأخطاء يشير إلى أن أجهزة المودم الخاصة بالاتصال والإجابة عليها قد تم تدريبها وتوصيلها وأن بروتوكولات الطبقة العليا يمكن أن تبدأ في التفاوض. إذا تم تخصيص مودم بشكل صحيح للاستدعاء الصادر ولكن فشل الاتصال في الوصول إلى هذا الحد، فيجب فحص T1. أستخدم الأمر show controller t1/e1 للتحقق من عمل T1/E1. راجع أستكشاف أخطاء الخطوط التسلسلية وإصلاحها للحصول على شرح لمخرج وحدة التحكم في العرض. إذا لم يكن T1/E1 يعمل بشكل صحيح، يلزم أستكشاف أخطاء T1/E1 وإصلاحها.

   • الإمكانية 2: لا يستجيب المودم البعيد. اختبر هذا عن طريق طلب المودم البعيد بواسطة هاتف عادي. جرب هذا:

     1. تأكد من صحة رقم الهاتف المتصل. أستخدم سماعة الهاتف لاستدعاء رقم التلقي.

     2. تأكد من قدرة المكالمة اليدوية على الوصول إلى مودم الرد غير المتزامن. إذا كانت المكالمة اليدوية قادرة على الوصول إلى مودم الرد غير المتزامن، فقد لا يتم توفير سطر CAS للسماح بالمكالمات الصوتية الصادرة.

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

     4. إذا كانت المكالمة اليدوية لا تزال غير قادرة على الوصول إلى الهاتف العادي على الخط المعني، فحاول إستخدام خط آخر (معروف جيدا) في مرفق الاستقبال. إذا كان ذلك يتصل، اطلب من شركة telco التحقق من خط الهاتف الذي يذهب إلى مودم التلقي.

     5. إذا كانت هذه مكالمة للمسافات الطويلة، اطلب من الجانب الأصلي تجربة رقم آخر (معروف جيدا) للمسافات الطويلة. وإذا كان ذلك يعمل على تشغيل مرفق الاستلام أو الخط فقد لا يتم تزويده لتلقي المكالمات البعيدة. إذا لم يتمكن الخط الأصلي (CAS) من الوصول إلى أي أرقام مسافات طويلة أخرى، فقد لا يكون قد تم تمكين المسافة الطويلة له. جرب 10-10 رموز لشركات المسافات الطويلة المختلفة.

     6. وأخيرا، حاول إستخدام رقم محلي (معروف جيدا) آخر من سطر CAS الأصلي. إذا فشل الاتصال بعد، فقم بفحص telco إلى CAS.

   • الإمكانية 3: الرقم الذي تم طلبه غير صحيح. تحقق من الرقم عن طريق طلبه يدويا. قم بتصحيح التكوين، إذا لزم الأمر.

   • الإمكانية 4: يستغرق تدريب المودم وقتا طويلا جدا، أو أن قيمة المهلة منخفضة للغاية. حاول زيادة قيمة المهلة في الأمر chat-script. إذا كانت المهلة عبارة عن 60 ثانية بالفعل أو أكثر، فقد تكون هناك مشكلة كبل بين المودم و DTE الذي يتصل به. قد تشير إخفاقات التدريب أيضا إلى وجود مشكلة في الدائرة الكهربائية أو عدم توافق المودم.

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

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

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

PRI Async Modem DDR

1. لتحديد DDR لمودم PRI غير متزامن، أستخدم الأوامر التالية، ثم حاول إجراء مكالمة:

   تحذير:  قد يؤدي تشغيل تصحيح الأخطاء على نظام مشغول إلى تعطيل الموجه من خلال التحميل الزائد لوحدة المعالجة المركزية أو التشغيل الزائد للمخزن المؤقت لوحدة التحكم!

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug isdn
   router# debug ppp negotiate
   router# debug ppp authenticate
   

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

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

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

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. تأكد من أن البرنامج النصي للدردشة يحاول الاستدعاء المتوقع (الرقم الصحيح) استنادا إلى "سلسلة الإرسال". إذا لم يحاول البرنامج النصي للدردشة إجراء المكالمة المتوقعة، فتحقق من تكوين البرنامج النصي للدردشة. أستخدم الأمر start-chat في نافذة مطالبة EXEC لبدء البرنامج النصي للدردشة يدويا.

4. يمكن أن يصف عرض "المهلة المتوقعة: الاتصال" العديد من الاحتمالات المختلفة:

   • الإمكانية 1: لا يقوم المودم المحلي بالفعل بإجراء الاتصال. تحقق من أنه يمكن للمودم إجراء مكالمة عن طريق تنفيذ برنامج Telnet عكسي للمودم وبدء طلب يدويا. إذا كان الطرف البعيد لا يبدو أنه يجيب، فتحقق من وضع المكالمة بواسطة المودم من خلال إستدعاء رقم محلي يدويا باستخدام الأمر ATDT<number> والاستماع إلى الحلقة. إذا لم يتم سحب أي مكالمة، فقم بتشغيل تصحيح أخطاء ISDN. عند الشك الأول في فشل ISDN على BRI، تحقق دائما من الإخراج من حالة show isdn. الأشياء الأساسية التي يجب ملاحظتها هي أن الطبقة 1 يجب أن تكون نشطة والطبقة 2 يجب أن تكون في حالة MULTI_FRAME_ESTABLISHED. راجع دليل أستكشاف أخطاء الشبكة البينية وإصلاحها الفصل 16، تفسير حالة ISDN" للحصول على معلومات حول قراءة هذا الإخراج، بالإضافة إلى التدابير التصحيحية.

     بالنسبة لمكالمات ISDN الصادرة، تعد أحداث debug isdn q931 وdebug isdn أفضل الأدوات المستخدمة. ولحسن الحظ، فإن تصحيح المكالمات الصادرة مشابه جدا لتصحيح المكالمات الواردة. قد تبدو مكالمة ناجحة عادية بهذا الشكل:

     *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
     

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

     *Mar 20 22:11:03.212: ISDN SE0:23: 
     RX <-RELEASE_COMP pd = 8 callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     تشير قيمة السبب إلى أمرين:

     • يشير البايت الثاني من قيمة 4- أو 6- بايت إلى النقطة في مسار الاتصال من نهاية إلى نهاية التي تم تلقي قطع الاتصال أو release_comp منها. يمكن أن يساعدك ذلك على ترجمة المشكلة.

     • يشير كل من البايت الثالث والرابع إلى السبب الفعلي للفشل. انظر الجدول 9 للاطلاع على معاني القيم المختلفة.

   • الإمكانية 2: لا يستجيب المودم البعيد. اختبر هذا عن طريق طلب المودم البعيد بواسطة هاتف عادي. جرب هذا:

     1. تأكد من صحة رقم الهاتف المتصل. أستخدم سماعة الهاتف لاستدعاء رقم التلقي.

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

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

     4. إذا كانت المكالمة اليدوية لا تزال غير قادرة على الوصول إلى الهاتف العادي على الخط المعني، فحاول إستخدام خط آخر (معروف جيدا) في مرفق الاستقبال. إذا كان ذلك يتصل، اطلب من شركة telco التحقق من خط الهاتف الذي يذهب إلى مودم التلقي.

     5. إذا كانت هذه مكالمة للمسافات الطويلة، اطلب من الجانب الأصلي تجربة رقم آخر (معروف جيدا) للمسافات الطويلة. وإذا نجح ذلك، فقد لا يتم توفير مرفق الاستلام أو الخط لتلقي المكالمات البعيدة. إذا لم يتمكن خط الإنشاء (BRI) من الوصول إلى أي أرقام مسافات طويلة أخرى، فقد لا يكون قد تم تمكين المسافة الطويلة له. جرب 1010 رمز لشركات المسافات الطويلة المختلفة.

     6. أخيرا، حاول إستخدام رقم محلي (معروف جيدا) آخر من خط BRI الأصلي. إن يفشل التوصيل بعد، جعلت telco فحصت ال BRI.

   • الإمكانية 3: الرقم الذي تم طلبه غير صحيح. تحقق من الرقم عن طريق طلبه يدويا. قم بتصحيح التكوين، إذا لزم الأمر.

   • الإمكانية 4: يستغرق تدريب المودم وقتا طويلا أو أن قيمة المهلة منخفضة للغاية. حاول زيادة قيمة المهلة في الأمر chat-script. إذا كانت المهلة عبارة عن 60 ثانية بالفعل أو أكثر، فقد تكون هناك مشكلة كبل بين المودم و DTE المرفق به. قد تشير إخفاقات التدريب أيضا إلى وجود مشكلة في الدائرة الكهربائية أو عدم توافق المودم.

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

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

5. إذا كان كل شيء يعمل على ما يرام ولا يزال يتعذر عليك الاتصال بذاكرة BRI Async Modem DDR، فحاول تصحيح أخطاء PPP. إذا تم إكمال البرنامج النصي للدردشة بنجاح وكانت تصحيح أخطاء PPP تشير إلى فشل، راجع قسم أستكشاف أخطاء PPP وإصلاحها" في الفصل 17 من دليل أستكشاف الأخطاء وإصلاحها بين الشبكات.

ذاكرة DDR للمودم غير المتزامن ل BRI.

تعمل هذه الميزة فقط على النظام الأساسي Cisco 3640 باستخدام برنامج Cisco IOS الإصدار 12.0(3)T أو إصدار أحدث. وهو يتطلب مراجعة أجهزة لاحقة لوحدة شبكة BRI. لن يعمل هذا مع بطاقة واجهة WAN (WIC).

1. تأكد من صحة رمز البلد باستخدام الأمر show modem. أستخدم الأوامر التالية، ثم حاول إجراء مكالمة:

   تحذير:  قد يؤدي تشغيل تصحيح الأخطاء على نظام مشغول إلى تعطيل الموجه من خلال التحميل الزائد لوحدة المعالجة المركزية أو التشغيل الزائد للمخزن المؤقت لوحدة التحكم!

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug bri
   router# debug ppp negotiate
   router# debug ppp authenticate
   

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

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

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

   CHAT1: Attempting async line dialer script
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. تأكد من أن البرنامج النصي للدردشة يحاول الاستدعاء المتوقع (الرقم الصحيح) استنادا إلى "سلسلة الإرسال". إذا لم يحاول البرنامج النصي للدردشة إجراء المكالمة المتوقعة، فتحقق من تكوين البرنامج النصي للدردشة. أستخدم الأمر start-chat في نافذة مطالبة EXEC لبدء البرنامج النصي للدردشة يدويا.

4. يمكن أن يصف عرض "المهلة المتوقعة: الاتصال" العديد من الاحتمالات المختلفة:

   • الإمكانية 1: لا يقوم المودم المحلي بالفعل بإجراء الاتصال. تحقق من أنه يمكن للمودم إجراء مكالمة عن طريق تنفيذ برنامج Telnet عكسي للمودم وبدء طلب يدويا. إذا كان الطرف البعيد لا يبدو أنه يجيب، فتحقق من وضع المكالمة بواسطة المودم من خلال إستدعاء رقم محلي يدويا باستخدام الأمر ATDT<number> والاستماع إلى الحلقة. إذا لم يتم سحب أي مكالمة، فقم بتشغيل تصحيح أخطاء ISDN. عند الشك الأول في فشل ISDN على BRI، تحقق دائما من الإخراج من حالة show isdn. الأشياء الأساسية التي يجب ملاحظتها هي أن الطبقة 1 يجب أن تكون نشطة والطبقة 2 يجب أن تكون في حالة MULTI_FRAME_ESTABLISHED . راجع دليل أستكشاف أخطاء الشبكة البينية وإصلاحها الفصل 16، تفسير حالة ISDN" للحصول على معلومات حول قراءة هذا الإخراج والتدابير التصحيحية.

     بالنسبة لمكالمات ISDN الصادرة، تعد أحداث debug isdn q931 وdebug isdn أفضل الأدوات المستخدمة. ولحسن الحظ، فإن تصحيح المكالمات الصادرة مشابه جدا لتصحيح المكالمات الواردة. قد تبدو مكالمة ناجحة عادية بهذا الشكل:

     *Mar 20 21:07:45.025: ISDN BR0: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
     

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

     *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
     callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     تشير قيمة السبب إلى أمرين.

     • يشير البايت الثاني من قيمة 4- أو 6- بايت إلى النقطة في مسار الاتصال من نهاية إلى نهاية التي تم تلقي قطع الاتصال أو release_comp منها. يمكن أن يساعدك ذلك على ترجمة المشكلة.

     • يشير كل من البايت الثالث والرابع إلى السبب الفعلي للفشل. راجع الجدول 9 للاطلاع على معاني القيم المختلفة.

   • الإمكانية 2: لا يستجيب المودم البعيد. اختبر هذا عن طريق طلب المودم البعيد بواسطة هاتف عادي. جرب هذا:

     1. تأكد من صحة رقم الهاتف المتصل. أستخدم سماعة الهاتف لاستدعاء رقم التلقي.

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

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

     4. إذا كانت المكالمة اليدوية لا تزال غير قادرة على الوصول إلى الهاتف العادي على الخط المعني، فحاول إستخدام خط آخر (معروف جيدا) في مرفق الاستقبال. إذا كان ذلك يتصل، اطلب من شركة telco التحقق من خط الهاتف الذي يذهب إلى مودم التلقي.

     5. إذا كانت هذه مكالمة للمسافات الطويلة، اطلب من الجانب الأصلي تجربة رقم آخر (معروف جيدا) للمسافات الطويلة. وإذا نجح ذلك، فقد لا يتم توفير مرفق الاستلام أو الخط لتلقي المكالمات البعيدة. إذا لم يتمكن خط الإنشاء (BRI) من الوصول إلى أي أرقام مسافات طويلة أخرى، فقد لا يكون قد تم تمكين المسافة الطويلة له. جرب 10-10 رموز لشركات المسافات الطويلة المختلفة.

     6. أخيرا، حاول إستخدام رقم محلي (معروف جيدا) آخر من خط BRI الأصلي. إن يفشل التوصيل بعد، جعلت telco فحصت ال BRI.

   • الإمكانية 3: الرقم الذي تم طلبه غير صحيح. تحقق من الرقم عن طريق طلبه يدويا. قم بتصحيح التكوين، إذا لزم الأمر.

   • الإمكانية 4: يستغرق تدريب المودم وقتا طويلا جدا، أو أن قيمة المهلة منخفضة للغاية. حاول زيادة قيمة المهلة في الأمر chat-script. إذا كانت المهلة عبارة عن 60 ثانية بالفعل أو أكثر، فقد تكون هناك مشكلة كبل بين المودم و DTE المرفق به. قد تشير إخفاقات التدريب أيضا إلى وجود مشكلة في الدائرة الكهربائية أو عدم توافق المودم.

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

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

5. إذا كان كل شيء يعمل على ما يرام ولا يزال يتعذر عليك الاتصال بذاكرة BRI Async Modem DDR، فحاول تصحيح أخطاء PPP. إذا تم إكمال البرنامج النصي للدردشة بنجاح وكانت تصحيح أخطاء PPP تشير إلى فشل، راجع قسم أستكشاف أخطاء PPP وإصلاحها" في الفصل 17 من دليل أستكشاف الأخطاء وإصلاحها بين الشبكات.

PRI ISDN DDR

1. عند الشك الأول في فشل ISDN على PRI، تحقق دائما من الإخراج من حالة show isdn. الأشياء الأساسية التي يجب ملاحظتها هي أن الطبقة 1 يجب أن تكون نشطة وأن الطبقة 2 يجب أن تكون في حالة MULTI_FRAME_CREATED. راجع دليل أستكشاف أخطاء الشبكة البينية وإصلاحها الفصل 16، تفسير حالة ISDN" للحصول على معلومات حول قراءة هذا الإخراج والتدابير التصحيحية.

   بالنسبة لمكالمات ISDN الصادرة، تعد أحداث debug isdn q931 وdebug isdn أفضل الأدوات المستخدمة. ولحسن الحظ، فإن تصحيح المكالمات الصادرة مشابه جدا لتصحيح المكالمات الواردة. قد تبدو مكالمة ناجحة عادية بهذا الشكل:

   *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
   Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
   callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
   

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

   *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   تشير قيمة السبب إلى أمرين.

   • يشير البايت الثاني من قيمة 4- أو 6- بايت إلى النقطة في مسار الاتصال من نهاية إلى نهاية التي تم تلقي قطع الاتصال أو release_comp منها. يمكن أن يساعدك ذلك على ترجمة المشكلة.

   • يشير كل من البايت الثالث والرابع إلى السبب الفعلي للفشل. راجع الجدول 9 للاطلاع على معاني القيم المختلفة.

   ملاحظة: تشير النسخة المطبوعة التالية إلى فشل بروتوكول أعلى:

   Cause i = 0x8090 - Normal call clearing

   فشل مصادقة PPP سبب نموذجي. قم بتشغيل تفاوض PPP ومصادقة PPP للتصحيح قبل افتراض أن فشل الاتصال هو بالضرورة مشكلة ISDN.

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

BRI ISDN DDR

1. عند الشك الأول في فشل ISDN على BRI، تحقق دائما من الإخراج من حالة show isdn. الأمور الأساسية التي يجب ملاحظتها هي أن الطبقة 1 يجب أن تكون نشطة وأن الطبقة 2 يجب أن تكون في حالة MULTI_FRAME_CREATED. راجع الفصل 16 من دليل أستكشاف أخطاء الشبكة البينية وإصلاحها، "تفسير حالة ISDN show" للحصول على معلومات حول قراءة هذا الإخراج والتدابير التصحيحية.

   بالنسبة لمكالمات ISDN الصادرة، تعد أحداث debug isdn q931 وdebug isdn أفضل الأدوات المستخدمة. ولحسن الحظ، فإن تصحيح المكالمات الصادرة مشابه جدا لتصحيح المكالمات الواردة. قد تبدو مكالمة ناجحة عادية بهذا الشكل:

   *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
   *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
   

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

   *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   تشير قيمة السبب إلى أمرين.

   • يشير البايت الثاني من قيمة 4- أو 6- بايت إلى النقطة في مسار الاتصال من نهاية إلى نهاية التي تم تلقي قطع الاتصال أو release_comp منها. يمكن أن يساعدك ذلك على ترجمة المشكلة.

   • يشير كل من البايت الثالث والرابع إلى السبب الفعلي للفشل. راجع الجدول 9 للاطلاع على معاني القيم المختلفة.

     ملاحظة: تشير النسخة المطبوعة التالية إلى فشل بروتوكول أعلى:

     Cause i = 0x8090 - Normal call clearing

     فشل مصادقة PPP سبب نموذجي. قم بتشغيل تفاوض PPP ومصادقة PPP للتصحيح قبل افتراض أن فشل الاتصال هو بالضرورة مشكلة ISDN.

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

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

• دليل التكوين السريع لخدمات طلب IOS من Cisco
• دليل تكوين خدمات طلب IOS من Cisco: خدمات الشبكة
• دليل تكوين خدمات طلب IOS من Cisco: الخدمات الطرفية
• مرجع أمر خدمات طلب IOS من Cisco
• نظرة عامة على دراسة حالة الطلب
• الوصول إلى صفحات التقنية
• الدعم التقني والمستندات - Cisco Systems