المحتويات

المقدمة

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

المتطلبات

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

التاريخ

الاصطلاحات

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

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

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

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

PRI Async Modem DDR

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

PRI ISDN DDR

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

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

الجدول 1: لا تبدأ حركة المرور محاولة طلب

الأسباب المحتملة

الإجراءات المقترحة

تعريفات "حركة مرور مثيرة للاهتمام" مفقودة أو غير صحيحة

1. باستخدام الأمر show running-config، تأكد من تكوين الواجهة باستخدام مجموعة المتصل وأن هناك مستوى عمومي dialer-list تم تكوينه باستخدام رقم مطابق.

2. تأكد من تكوين الأمر dialer-list للسماح إما ببروتوكول كامل أو للسماح بحركة المرور التي تطابق قائمة وصول

3. تحقق من أن قائمة الوصول تعلن أن الحزم التي تمر عبر الارتباط مثيرة للاهتمام. يتمثل أحد الاختبارات المفيدة في إستخدام أمر EXEC للمستوى المتميز debug ip packet [list number] باستخدام رقم قائمة الوصول ذات الصلة. ثم حاول إختبار الاتصال، أو إرسال حركة مرور البيانات، عبر الارتباط بطريقة أخرى. إذا تم تعريف مرشحات حركة المرور المثيرة للاهتمام بشكل صحيح، سترى الحزم في إخراج تصحيح الأخطاء. إذا لم يكن هناك إخراج تصحيح أخطاء من هذا الاختبار، فإن قائمة الوصول لا تطابق الحزم.

حالة الواجهة

أستخدم الأمر show interfaces <interface name>لضمان أن الواجهة في الحالة "up/up (spoofing)".

- الواجهة في الوضع "الاحتياطي"

تم تكوين واجهة (أساسية) أخرى على الموجه لاستخدام واجهة المتصل كواجهة نسخ إحتياطي. علاوة على ذلك، لا تكون الواجهة الأساسية في حالة "down/down"، والتي تكون مطلوبة لإخراج واجهة المتصل من وضع الاستعداد. كما يجب تكوين تأخير النسخ الاحتياطي على الواجهة الأساسية، أو لن يتم فرض أمر واجهة النسخ الاحتياطي مطلقا. للتحقق من أن واجهة المتصل ستتغير من "وضع الاستعداد" إلى "أعلى/أعلى (انتحال)"، يكون من الضروري عادة سحب الكبل من الواجهة الأساسية. ببساطة، لن يؤدي إيقاف تشغيل الواجهة الأساسية باستخدام أمر التكوين إلى وضع الواجهة الأساسية في "down/down"، ولكن بدلا من ذلك سيتم وضعها في "down إداريا" ؟ وليس نفس الشيء. بالإضافة إلى ذلك، إذا كان الاتصال الأساسي عبر ترحيل الإطارات، فيجب إجراء تكوين ترحيل الإطارات على الواجهة الفرعية التسلسلية من نقطة إلى نقطة، ويجب أن تكون شركة الهاتف قد قامت بتمرير البت "النشط". تعرف هذه الممارسة أيضا باسم "واجهة الإدارة المحلية الشاملة (LMI)".

- الواجهة "معطلة إداريا"

تم تكوين واجهة المتصل باستخدام الأمر shutdown. هذا أيضا الحالة الافتراضية لأي واجهة عند تمهيد موجه Cisco لأول مرة. أستخدم أمر تكوين الواجهة no shutdown لإزالة هذا العائق.

توجيه غير صحيح

قم بإصدار أمر EXEC show ip route [a.b.c.d]، حيث يمثل a.b.c.d عنوان واجهة المتصل بالموجه البعيد. إذا تم إستخدام ip unnumber على الموجه البعيد، فاستخدم عنوان الواجهة المدرجة في الأمر ip unnumber. يجب أن يعرض الإخراج مسارا إلى العنوان البعيد عبر واجهة المتصل. إذا لم يكن هناك مسار، فتأكد من تكوين المسارات الثابتة أو العائمة من خلال فحص إخراج show running-config. إذا كان هناك مسار عبر واجهة أخرى غير واجهة المتصل، فإن التلميح هو أن DDR يتم إستخدامها كنسخة إحتياطية. فحص تكوين الموجه للتأكد من تكوين المسارات الثابتة أو العائمة. أضمن طريقة لاختبار التوجيه، في هذه الحالة، هي تعطيل الاتصال الأساسي وتنفيذ الأمر show ip route [a.b.c.d] للتحقق من تثبيت المسار المناسب في جدول التوجيه.
ملاحظة: إذا حاولت ذلك أثناء عمليات الشبكة المباشرة، فقد يتم تشغيل حدث طلب. ويتحقق هذا النوع من الاختبار على أفضل وجه خلال دورات الصيانة المقررة.

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

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

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

Async1 DDR: Attempting to dial 5551212

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

الجدول 2: لم يتم وضع المكالمة

مشكلة محتملة

الإجراءات المقترحة

خريطة المتصل غير مكونة بشكل صحيح

أستخدم الأمر show running-config لضمان تكوين واجهة الطلب باستخدام عبارة واحدة على الأقل لخريطة المتصل تشير إلى عنوان البروتوكول وترقم الاستدعاء للموقع البعيد.

ملف تعريف المتصل غير المكون بشكل صحيح

أستخدم الأمر show running-config لضمان تكوين واجهة المتصل باستخدام أمر تجمع المتصل X وأن واجهة المتصل على الموجه تم تكوينها باستخدام عضو تجمع المتصل X المطابق. إذا لم يتم تكوين ملفات تعريف المتصل بشكل صحيح، فقد ترى رسالة تصحيح أخطاء مثل:
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