تقنية الاتصال: تقنيات أستكشاف المشكلات وحلها

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

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

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

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

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

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

المقدمة

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

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

المتطلبات

يجب أن يكون قراء هذا المستند على دراية بما يلي:

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

كانت خوادم الوصول الأولى هي Cisco2509 و Cisco2511. يمكن أن تدعم 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 التقنية.

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

تبدأ عملية أستكشاف مشكلات مكالمة واردة وحلها في الجزء السفلي وتشق طريقها نحو الأعلى. يبحث التدفق العام للمنطق عما يلي:

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

  2. هل يستجيب الطرف المتلقي للمكالمة؟

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

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

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

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

بالنسبة للمكالمات الواردة التي تتضمن أجهزة المودم الرقمية، أولا، تأكد من أن ISDN أو CAS الأساسية تتلقى المكالمة. إذا كنت تستخدم مودم خارجي، يمكن تخطي مقاطع مجموعة ISDN و CAS.

أستكشاف أخطاء مكالمات ISDN الواردة وإصلاحها

أستخدم الأمر debug isdn q931. فيما يلي مثال للمخرجات من اتصال ناجح: 

Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

تشير رسالة الإعداد إلى أنه يتم بدء اتصال من قبل الطرف البعيد. يتم الاحتفاظ بالأرقام المرجعية للاستدعاء كزوج. في هذه الحالة يكون رقم مرجع المكالمة للجانب الوارد من الاتصال هو 0x06، ورقم مرجع المكالمة للجانب الصادر من الاتصال هو 0x86. تعمل إمكانية الحامل (يشار إليها عادة باسم غطاء الشاشة) على إخبار الموجه بنوع المكالمة القادمة. في هذه الحالة، يكون الاتصال من النوع 0x8890. تشير هذه القيمة إلى "سرعة ISDN 64 كيلوبايت/ثانية". ولو كانت القلنسوة تمثل 0 x8090A2، لكانت قد أشارت إلى "قانونها المتصل بالكلام/الصوت".

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

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

ملاحظة: إستدعاء مودم BRI غير المتزامن هو ميزة خاصة ب 3600 موجه تشغل الإصدار 12.0(3)T، أو إصدار أحدث. وهو يتطلب مراجعة الأجهزة الأخيرة للوحدة النمطية لشبكة واجهة BRI. لا تدعم وحدات WIC إستدعاء المودم غير المتزامن.

في حالة وصول المكالمة ولكن لم تكتمل، ابحث عن رمز سبب (انظر الجدول 17-10). يتم الإشارة إلى إتمام ناجح بواسطة Connect-ack.

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

عند هذه النقطة، يتم اتصال اتصال اتصال اتصال ISDN، ولكن لم يتم رؤية أي بيانات عبر الارتباط. أستخدم الأمر debug ppp negotiate لمعرفة ما إذا كانت أي حركة مرور PPP قادمة عبر الخط. إن لا يرى أنت حركة مرور، هناك أمكن كنت سرعة عدم توافق. لتحديد ما إذا كانت هذه هي الحالة، أستخدم أمر EXEC للمستوى المتميز show running-config لعرض تكوين الموجه. تحقق من إدخالات أوامر تكوين واجهة خريطة المتصل في الموجه المحلي والموجه البعيد. يجب أن تبدو هذه الإدخالات مماثلة لما يلي: 

dialer map ip 131.108.2.5 speed 56 name C4000

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

للحصول على معلومات تفصيلية حول تكوين خرائط المتصل وتوصيفاته، ارجع إلى دليل تكوين حلول طلب Cisco IOS، ومرجع أوامر حلول الطلب، ودليل التكوين السريع لحلول الطلب.

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

أستكشاف أخطاء مكالمات CAS الواردة وإصلاحها

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

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

أولا، حدد ما إذا كان محول شركة الهاتف قد تم "من فوق" للإشارة إلى المكالمة الواردة. إذا لم يكن موجودا، فتحقق من الرقم الذي يتم استدعاؤه. قم بذلك من خلال إرفاق هاتف بخط هاتف الجهة الناشئة والاتصال بالرقم. إذا ظهرت المكالمة بشكل صحيح، تكون المشكلة في CPE الأصلي. إذا لم يظهر الاستدعاء بعد على CAS، فتحقق من T1 (الفصل 15).في هذا المثيل، أستخدم أمر debug serial interfaces.

يوضح ما يلي اتصالا جيدا باستخدام Debug modem CSM: 

Router# debug modem csm
CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
CSM_RING_INDICATION_PROC: RI is on
CSM_RING_INDICATION_PROC: RI is off
CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0

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

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

أستخدم أوامر تصحيح الأخطاء التالية عند أستكشاف أخطاء مكالمات المودم الواردة وإصلاحها:

  • مودم تصحيح الأخطاء

  • debug modem csm (لأجهزة المودم الرقمية المتكاملة)

أستخدم أوامر تصحيح الأخطاء التالية بالاقتران للإشارة إلى المكالمة الجديدة القادمة:

  • debug isdn q931

  • debug cas

وبافتراض وصول المكالمة إلى المودم، يحتاج المودم إلى إجراء المكالمة.

تلميحات لتصحيح أخطاء أجهزة المودم الخارجية

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

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

انتقاء مكالمة المودم غير المتزامن

إذا لم يرد مودم خارجي، فتحقق من توصيل الكبلات بين المودم وخادم الوصول أو الموجه. تأكد من أن المودم متصل بالمنفذ tty أو المنفذ المساعد على الموجه باستخدام كبل RJ-45 ملفوف ومهايئ MMOD DB-25. توصي Cisco وتدعم تكوين الكبل هذا لمنافذ RJ-45. لاحظ أن هذه الموصلات تتم عنونة عادة: المودم.

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

  • إذا كان ترتيب المسامير الملونة هو نفسه في كل طرف، فإن الكبل يكون مستقيما.

  • إذا كان ترتيب الألوان معكوسا في كل نهاية، فإن الكبل ملفوف.

  • يكون الكبل كبل توصيل عكسي إذا كانت الألوان تشير إلى ما يلي:

كبل توصيل عكسي RJ45 إلى RJ45: 

RJ45                  RJ45 
         5 ------------------ 2
         2 ------------------ 5
         4 ------------------ 1 
         1 ------------------ 4

للتأكد من سلامة الإشارات، أستخدم الأمر show line الموضح في الفصل 16.

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

انتقاء مكالمة المودم الرقمي (المتكامل)

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

  1. تأكد من وجود الأمر isdn incoming-voice modem ضمن أي واجهات ISDN التي تتعامل مع إتصالات المودم الواردة.

  2. ضمن تكوين الخط ل TTY الخاص للمودم، تأكد من وجود إدخال المودم.

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

تدريب المودم

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

للوصول إلى الجزء السفلي من مشكلة مودم فردي، انتقل إلى موجه الأمر AT عند المودم الأصلي أثناء ربطه بخط اهتمام POTS. إذا كنت تريد الاتصال بمودم رقمي في خادم وصول Cisco، فعليك بالاستعداد لتسجيل ملف .wav من موسيقى التدريب، أو تسلسل تعلم الإعاقة الرقمية (DIL). DIL هي العلامة الموسيقية (تسلسل PCM) التي يقوم المودم التناظري المنشأ V.90 بإخبار المودم الرقمي المتلقي بتشغيله. ويتيح هذا التسلسل للمودم التناظري تمييز أي إعاقة رقمية في الدائرة، مثل تحويلات D/A المتعددة أو القانون/القانون أو القطع المسروقة أو اللوحات الرقمية. إذا لم تسمع DIL، فإن أجهزة المودم لم تتفاوض على V.90 في V.8/V.8bis (أي، مشكلة توافق المودم). إذا كنت تستمع إلى DIL وإعادة التدريب في V.34، فإن المودم التناظري قرر (على أساس تشغيل DIL) أن V.90 غير ممكن.

هل الموسيقى فيها ضجيج؟ إذا كان الامر كذلك، فنظفوا الدارة.

هل يستسلم العميل بسرعة، دون إجراء تدريب V.34؟ على سبيل المثال، ربما لا يعرف ماذا يتعين عليه أن يفعل حين يسمع صوت "8. 8" مكررا. في هذه الحالة يجب محاولة تعطيل V.8bis (وبالتالي K56Flex) على الخادم (إذا كان ذلك مقبولا). يجب أن تحصل على برنامج ثابت جديد للعميل أو قم باستبدال مودم العميل. بالتناوب، يمكن لنهاية الطلب إدراج خمسة فواصل في نهاية سلسلة الطلب. يؤدي هذا إلى تأخير الاستماع لمودم الاستدعاء وسيتسبب في انتهاء مهلة نغمة V.8bis من الخادم المتلقي دون التأثير على مودم العميل. خمسة فواصل في سلسلة الطلب هي إرشادات عامة وقد تحتاج إلى التعديل للسماح بالشروط المحلية.

إنشاء الجلسة

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

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

تسلسل تحديد تلقائي عادي مع حزم PPP الواردة LCP: 

*Mar  1 21:34:56.958: TTY1: DSR came up
*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E 

!--- The inbound traffic is displayed in hexadecimal format. This is based on the !--- bits coming in over the line, regardless of whether the bits are ASCII !--- characters or elements of a packet. The bits represented in this example are !--- correct for a LCP packet. Anything different would be either a malformed packet !--- or character traffic.

*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate 

!--- Having determined that the inbound traffic is actually an LCP packet, the access !--- server triggers the PPP negotiation process.

*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up 

!--- The async interface changes state to up, and the PPP negotiation (not shown) !--- commences.

إذا كان الاستدعاء عبارة عن جلسة PPP وإذا تم تكوين الوضع غير المتزامن المخصص على الواجهة غير المتزامنة، فاستخدم الأمر debug ppp negotiation لمعرفة ما إذا كان أي حزم طلب تكوين قادمة من الطرف البعيد. تظهر الأخطاء هذه ك confreq. إذا لاحظت حزم PPP الواردة والصادرة على حد سواء، فقم بالمتابعة إلى "أستكشاف أخطاء PPP وإصلاحها". وإلا، اتصل من النهاية التي تنشأ عنها المكالمة بجلسة عمل وضع الحرف (أو "exec") (أي جلسة غير PPP).

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

يتعذر على المودم إرسال البيانات أو تلقيها

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

  • إعداد سرعة المودم غير مؤمن

    1. أستخدم أمر EXEC show line على خادم الوصول أو الموجه. يجب أن يشير إخراج المنفذ المساعد إلى سرعتي Tx و Rx اللتين تم تكوينهما حاليا.

      للحصول على شرح لمخرجات أمر show line، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

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

      الصيغة:

      السرعة بت/ثانية

      وصف الصيغة Syntax:

      bps - معدل الباود بعدد وحدات بت في الثانية. الإعداد الافتراضي هو 9600 بت في الثانية.

      يثبت المثال التالي الأسطر 1 و 2 على خادم وصول Cisco 2509 إلى 115200 بت في الثانية:

      line 1 2
speed 115200

      ملاحظة: إذا تعذر عليك، لسبب ما، إستخدام التحكم في التدفق، فقم بتحديد سرعة الخط إلى 9600 بت في الثانية. من المحتمل أن تؤدي السرعات الفائقة إلى فقد البيانات.

    3. أستخدم أمر EXEC show line مرة أخرى وتأكد من تعيين سرعة الخط على القيمة المطلوبة.

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

    5. أستخدم سلسلة أوامر المودم التي تتضمن الأمر "lock DTE speed" للمودم. راجع وثائق المودم الخاصة بك للحصول على صياغة أمر تكوين دقيقة.

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

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

  • لم يتم تكوين التحكم في تدفق الأجهزة على المودم أو الموجه المحلي أو البعيد

    1. أستخدم أمر EXEC show line aux-line-number وابحث عن التالي في حقل الإمكانيات: 

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      لمزيد من المعلومات، راجع تفسير مخرجات سطر العرض في الفصل 16.

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

      للحصول على شرح لمخرجات أمر show line، راجع القسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

    2. قم بتكوين التحكم في تدفق الأجهزة على الخط باستخدام أمر تكوين سطر التحكم في التدفق للأجهزة.

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

      الصيغة:

      عنصر تحكم الانسياب {none | برنامج [تأمين] [في | خارج] | الأجهزة [في | out]}

      وصف الصيغة Syntax:

      • none - يوقف تشغيل التحكم في التدفق.

      • البرنامج - يضبط التحكم في تدفق البرامج. تحدد الكلمة الأساسية الاختيارية الإتجاه: في سبب أن ينصت برنامج Cisco IOS software إلى التحكم في التدفق من الجهاز المرفق، ويتسبب out في قيام البرنامج بإرسال معلومات التحكم في التدفق إلى الجهاز المرفق. إذا لم تقم بتحديد إتجاه، فكلتاهما مفترضة.

      • القفل - يجعل من المستحيل إيقاف تشغيل التحكم في التدفق من المضيف البعيد عندما يحتاج الجهاز المتصل إلى التحكم في تدفق البرنامج. ينطبق هذا الخيار على الاتصالات باستخدام بروتوكولات Telnet أو rlogin.

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

      مثال:

      يوضح المثال التالي التحكم في تدفق الأجهزة على السطر 7: 

      line 7
flowcontrol hardware

      ملاحظة: إذا تعذر عليك إستخدام التحكم في التدفق لسبب ما، فقم بتحديد سرعة الخط إلى 9600 بت في الثانية. من المحتمل أن تؤدي السرعات الفائقة إلى فقد البيانات.

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

    4. أستخدم سلسلة أمر مودم تتضمن الأمر RTS/CTS flow للمودم الخاص بك. يضمن هذا الأمر أن المودم يستخدم نفس طريقة التحكم في التدفق (أي التحكم في تدفق الأجهزة) مثل خادم الوصول أو الموجه من Cisco. راجع وثائق المودم الخاصة بك للحصول على صياغة أمر تكوين دقيقة.

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

    1. أستخدم أمر EXEC المميز show running-config لعرض تكوين الموجه. تحقق من إدخالات أمر خريطة المتصل لمعرفة ما إذا تم تحديد الكلمة الأساسية broadcast أم لا.

    2. إذا كانت الكلمة الأساسية مفقودة، فقم بإضافتها إلى التكوين.

      الصيغة:

      بروتوكول خريطة المتصل وعنوان الخطوة التالية [الاسم hostname] [بث] [سلسلة الطلب]

      وصف الصيغة Syntax:

      • البروتوكول - البروتوكول خاضع للتعيين. وتتضمن الخيارات IP و IPX والجسر والقطة.

      • عنوان الخطوة التالية - عنوان البروتوكول الخاص بواجهة غير متزامنة للموقع المقابل.

      • name hostname - معلمة مطلوبة تستخدم في مصادقة PPP. إنه اسم الموقع البعيد الذي تم إنشاء خريطة المتصل له. الإسم حالة حساس ويجب أن يطابق اسم المضيف للموجه البعيد.

      • broadcast - كلمة أساسية إختيارية تبث الحزم (على سبيل المثال، تحديثات RIP أو IPX RIP/SAP) التي يتم إعادة توجيهها إلى الوجهة البعيدة. في تكوينات عينة التوجيه الثابتة، لا تكون تحديثات التوجيه مطلوبة ويتم حذف الكلمة الأساسية broadcast.

      • سلسلة الطلب - رقم هاتف الموقع البعيد. يجب تضمين أي رموز وصول (على سبيل المثال، 9 للخروج من المكتب، رموز الطلب الدولية، رموز المنطقة).

    3. تأكد من أن أوامر خريطة المتصل تحدد عناوين الخطوة التالية الصحيحة.

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

    5. تأكد من أن كل الخيارات الأخرى في أوامر خريطة المتصل محددة بشكل صحيح للبروتوكول الذي تستخدمه.

    للحصول على معلومات تفصيلية حول تكوين خرائط المتصل، ارجع إلى دليل تكوين الشبكة الواسعة من Cisco IOS ومرجع أوامر الشبكة الواسعة.

  • مشكلة في طلب المودم

    • تأكد من تشغيل مودم الطلب وتوصيله بشكل آمن بالمنفذ الصحيح. حدد ما إذا كان مودم آخر يعمل عند إتصاله بالمنفذ نفسه.

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

لا يتلقى عميل Dialup أية مطالبة EXEC

  • تم تمكين التحديد التلقائي على السطر

    حاول الوصول إلى وضع EXEC بالضغط على Enter.

  • تم تكوين الخط باستخدام الأمر no exec

    1. أستخدم أمر EXEC show line لعرض حالة البند المناسب.

      تحقق من حقل "الإمكانيات" لمعرفة ما إذا كان يقول "EXEC Suppressed". إذا كانت هذه هي الحالة، يتم تمكين أمر تكوين سطر no exec.

    2. قم بتكوين أمر تكوين سطر exec على السطر للسماح ببدء جلسات EXEC. لا يحتوي هذا الأمر على وسيطات أو كلمات أساسية.

    يشغل المثال التالي exec في السطر 7: 

    line 7 
exec

  • لم يتم تمكين التحكم في التدفق.

     أو

    يتم تمكين التحكم في التدفق على جهاز واحد فقط (إما DTE أو DCE).

     أو

    التحكم في التدفق غير مكون بشكل صحيح.

    1. أستخدم أمر EXEC show line aux-line-number وابحث عن التالي في حقل الإمكانيات: 

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      لمزيد من المعلومات، راجع تفسير مخرجات سطر العرض في الفصل 16.

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

      لشرح المخرجات من أمر show line، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

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

      line 7
flowcontrol hardware

      ملاحظة: إذا تعذر عليك إستخدام التحكم في التدفق لسبب ما، فقم بتحديد سرعة الخط إلى 9600 بت في الثانية. من المحتمل أن تؤدي السرعات الفائقة إلى فقد البيانات.

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

    4. أستخدم سلسلة أوامر المودم التي تتضمن الأمر تدفق RTS/CTS للمودم الخاص بك. يضمن هذا الأمر أن المودم يستخدم نفس طريقة التحكم في التدفق (أي التحكم في تدفق الأجهزة) مثل خادم الوصول أو الموجه من Cisco. راجع وثائق المودم الخاصة بك للحصول على صياغة أمر تكوين دقيقة.

  • إعداد سرعة المودم غير مؤمن

    1. أستخدم أمر EXEC show line على خادم الوصول أو الموجه. يجب أن يشير إخراج المنفذ المساعد إلى سرعتي Tx و Rx اللتين تم تكوينهما حاليا.

      للحصول على شرح لمخرجات أمر show line، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

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

      الصيغة:

      السرعة بت/ثانية

      وصف الصيغة Syntax:

      bps - معدل الباود بعدد وحدات بت في الثانية. الإعداد الافتراضي هو 9600 بت في الثانية.

      مثال:

      يثبت المثال التالي الأسطر 1 و 2 على خادم وصول Cisco 2509 إلى 115200 بت في الثانية: 

      line 1 2
speed 115200

      ملاحظة: إذا تعذر عليك إستخدام التحكم في التدفق لسبب ما، فقم بتحديد سرعة الخط إلى 9600 بت في الثانية. من المحتمل أن تؤدي السرعات الفائقة إلى فقد البيانات.

    3. أستخدم أمر EXEC show line مرة أخرى وتأكد من تعيين سرعة الخط على القيمة المطلوبة.

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

    5. أستخدم سلسلة أوامر المودم التي تتضمن الأمر lock DTE speed للمودم الخاص بك. راجع وثائق المودم الخاصة بك للحصول على صياغة أمر تكوين دقيقة.

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

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

جلسات الاتصال ترى "القمامة"

  • إعداد سرعة المودم غير مؤمن

    1. أستخدم أمر EXEC show line على خادم الوصول أو الموجه. يجب أن يشير إخراج المنفذ المساعد إلى سرعتي Tx و Rx اللتين تم تكوينهما حاليا.

      للحصول على شرح لمخرجات أمر show line، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

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

      لتعيين معدل البود الطرفي، أستخدم أمر تكوين سطر السرعة. يضبط هذا الأمر كلا من سرعات الإرسال (إلى المحطة الطرفية) والاستقبال (من المحطة الطرفية).

      الصيغة:

      السرعة بت في الثانية

      وصف الصيغة Syntax:

      معدل الباود للبت في الثانية (بت في الثانية). الإعداد الافتراضي هو 9600 بت في الثانية.

      مثال:

      يثبت المثال التالي الأسطر 1 و 2 على خادم وصول Cisco 2509 إلى 115200 بت في الثانية:

      الخط 1-2

      السرعة 115200

      ملاحظة: إذا تعذر عليك إستخدام التحكم في التدفق لسبب ما، فقم بتحديد سرعة الخط إلى 9600 بت في الثانية. من المحتمل أن تؤدي السرعات الفائقة إلى فقد البيانات.

    3. أستخدم أمر EXEC show line مرة أخرى وتأكد من تعيين سرعة الخط على القيمة المطلوبة.

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

    5. أستخدم سلسلة أوامر المودم التي تتضمن الأمر lock DTE speed للمودم الخاص بك. راجع وثائق المودم الخاصة بك للحصول على صياغة أمر تكوين دقيقة.

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

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

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

يتم فتح جلسة عمل الطلب الهاتفي في جلسة عمل موجودة

  • مودم تم تكوينه ل DCD دائما عالي

    1. يجب إعادة تهيئة المودم بحيث يكون DCD مرتفعا على الأقراص المضغوطة فقط. ويتم تحقيق ذلك عادة باستخدام سلسلة أوامر المودم &C1، ولكن تحقق من وثائق المودم لديك للحصول على الصياغة الدقيقة للمودم.

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

    3. قم بإنهاء جلسة عمل Telnet من خلال إدخال قطع الاتصال وإعادة تكوين سطر خادم الوصول باستخدام أمر تكوين سطر exec

  • لم يتم تمكين التحكم في المودم على خادم الوصول أو الموجه

    1. أستخدم أمر EXEC show line على خادم الوصول أو الموجه. يجب أن يتم عرض إخراج المنفذ المساعد في الداخل أو RIisCD في عمود المودم. وهذا يشير إلى تمكين التحكم في المودم على خط خادم الوصول أو الموجه.

      لشرح إخراج سطر العرض، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

    2. قم بتكوين الخط للتحكم في المودم باستخدام أمر تكوين سطر modem inout. تم تمكين التحكم في المودم الآن على خادم الوصول.

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

  • توصيل كبلات غير صحيح

    1. تحقق من الكبلات بين المودم وخادم الوصول أو الموجه. تأكد من توصيل المودم بالمنفذ المساعد على خادم الوصول أو الموجه باستخدام كابل RJ-45 ملفوف ومهايئ MMOD DB-25. يوصى بتكوين الكابلات هذا ويدعمه من قبل Cisco لمنافذ RJ-45. وعادة ما تكون هذه الموصلات معروفة: المودم.

      هناك نوعان من كابلات RJ-45: مباشرة ومدارة. إذا أمسكت بطرفي كبل RJ-45 جنبا إلى جنب، سترى ثمانية شرائط ملونة، أو مسامير، في كل طرف. إذا كان ترتيب المسامير الملونة هو نفسه في كل طرف، عندئذ يكون الكبل مستقيما. إذا كان ترتيب الألوان معكوسا في كل نهاية، عندئذ يتم لف الكبل.

      يكون الكبل المدور (CAB-500RJ) قياسيا مع ال 2500/CS500 من Cisco.

    2. أستخدم أمر EXEC show line للتحقق من صحة توصيل الكبلات. راجع شرح إخراج الأمر show line في القسم "إستخدام أوامر تصحيح الأخطاء" في هذا الفصل 15.

لا يتم قطع اتصال مودم تلقي الاتصال بشكل صحيح

  • المودم لا يستشعر DTR

    أدخل سلسلة أمر Hangup DTR modem. يقوم هذا الأمر بإخبار المودم بإسقاط الناقل عندما لا يتم تلقي إشارة DTR بعد ذلك.

    على مودم متوافق مع Hayes يتم إستخدام سلسلة &D3 بشكل شائع لتكوين Hangup DTR على المودم. للاطلاع على الصياغة الدقيقة لهذا الأمر، راجع الوثائق الخاصة بمودم المستخدم.

  • لم يتم تمكين التحكم في المودم على الموجه أو خادم الوصول

    1. أستخدم أمر EXEC show line على خادم الوصول أو الموجه. يجب أن يعرض إخراج المنفذ المساعد inout أو RIisCD في عمود المودم. وهذا يشير إلى تمكين التحكم في المودم على خط خادم الوصول أو الموجه.

      لشرح مخرج سطر العرض، راجع قسم "إستخدام أوامر تصحيح الأخطاء" في الفصل 15.

    2. قم بتكوين الخط للتحكم في المودم باستخدام أمر تكوين سطر inout للمودم. تم تمكين التحكم في المودم الآن على خادم الوصول.

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

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

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

  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. باستخدام الأمر 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

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

لم يتم وضع المكالمة

وترد أدناه بعض المشاكل المحتملة والإجراءات المقترحة:

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

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

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

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

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

    تأكد من تكوين سلسلة المتصل.

الاتصال الصادر غير المتزامن - التحقق من عملية البرنامج النصي للدردشة

إذا كانت المكالمة الصادرة مكالمة مودم، فيجب تنفيذ برنامج نصي للدردشة لمتابعة المكالمة. بالنسبة ل 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

يمكن تقسيم مشاكل البرنامج النصي للدردشة إلى ثلاث فئات:

  • خطأ في التكوين

  • فشل المودم

  • فشل الاتصال

فشل البرنامج النصي للمحادثة

تعرض هذه القائمة المخرجات المحتملة من دردشة تصحيح الأخطاء التي تظهر والإجراءات المقترحة:

  • لم يتم العثور على برنامج نصي للدردشة المتطابقة ل [number]

    لم يتم تكوين برنامج نصي للدردشة. أضف واحدة.

  • انتهت مهلة الاتصال بالبرامج النصية للدردشة، الحالة = انتهت مهلة الاتصال، المضيف البعيد لا يستجيب

    لا يستجيب المودم للبرنامج النصي للدردشة. تحقق من الاتصال للمودم (ارجع إلى الجدول 16-2 في الفصل 16).

  • المهلة المتوقعة: الاتصال

    • الإمكانية 1: لا يقوم المودم المحلي بالفعل بإجراء الاتصال. تحقق من إمكانية قيام المودم بإجراء مكالمة عن طريق تنفيذ برنامج Telnet عكسي على المودم وتمهيد الطلب يدويا.

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

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

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

إستدعاء ISDN الصادر

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

بالنسبة لمكالمات 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

!--- The CONNECT message is the key indicator of success. If a CONNECT is not received, !--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by !--- a cause code (see below)

*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 في مسار الاستدعاء الطرفي. يمكن أن يساعدك ذلك على ترجمة المشكلة.

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

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

Cause i = 0x8090 - Normal call clearing

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

حقول كود السبب

يسرد الجدول 17-9 حقول رمز السبب ISDN التي تعرض بالتنسيق التالي ضمن أوامر تصحيح الأخطاء: 

i=0x y1 y2 z1 z2 [a1 a2]

حقول رمز السبب ISDN

الحقل وصف القيمة
0x القيم التالية موجودة في السداسي عشر.
y1 8—ترميز معيار ITU-T.
Y2 0—مستخدم واحد—شبكة خاصة تخدم المستخدم المحلي 2—شبكة عامة تخدم المستخدم المحلي 3—شبكة النقل 4—شبكة عامة تخدم المستخدم البعيد 5—شبكة خاصة تخدم المستخدم البعيد 7—شبكة دولية خارج نقطة الشبكة البينية
z1 فئة (الرقم السداسي العشري الأكثر أهمية) قيمة السبب. ارجع إلى الجدول التالي للحصول على معلومات تفصيلية حول القيم المحتملة.
z2 قيمة السبب (الرقم السداسي العشري الأقل قيمة). ارجع إلى الجدول التالي للحصول على معلومات تفصيلية حول القيم المحتملة.
A1 (إختياري) حقل التشخيص الذي يكون دائما 8.
ألف 2 (إختياري) مجال التشخيص الذي يعد أحد القيم التالية: 0—غير معروف 1—دائم 2—مؤقت

قيم سبب ISDN

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

قيمة سداسية عشرية السبب الشرح
81 رقم غير مخصص (غير معين) تم إرسال رقم ISDN إلى المحول بالتنسيق الصحيح، ومع ذلك، لم يتم تعيين الرقم إلى أي معدات وجهة.
90 مسح عادي للمكالمات تمت إزالة المكالمة العادية.
91 المستخدم مشغول يعترف النظام المستدعى بطلب الاتصال ولكنه غير قادر على قبول الاستدعاء لأن جميع القنوات B قيد الاستخدام.
92 لا يوجد مستخدم يستجيب يتعذر إكمال الاتصال لأن الوجهة لا تستجيب للاستدعاء.
93 لا توجد إجابة من المستخدم (تم تنبيه المستخدم) تستجيب الوجهة لطلب الاتصال ولكنها تفشل في إكمال الاتصال في الوقت المحدد. توجد المشكلة في الطرف البعيد من الاتصال.
95 تم رفض المكالمة الوجهة قادرة على قبول المكالمة ولكنها رفضتها لسبب غير معروف.
9 درجة مئوية تنسيق رقم غير صالح تعذر إنشاء الاتصال بسبب تقديم عنوان الوجهة بتنسيق غير قابل للتعرف عليه أو بسبب عدم اكتمال عنوان الوجهة.
9 درجات فهرنهايت عادي، غير محدد الإبلاغ عن حدوث حدث عادي عند عدم تطبيق سبب قياسي. لا يوجد إجراء مطلوب.
A2 لا تتوفر دائرة/قناة لا يمكن إنشاء الاتصال نظرا لعدم توفر قناة مناسبة لإجراء المكالمة.
A6 الشبكة خارج النظام لا يمكن الوصول إلى الوجهة لأن الشبكة لا تعمل بشكل صحيح، وقد يستمر الشرط لفترة ممتدة من الوقت. قد تكون محاولة إعادة الاتصال الفورية غير ناجحة.
AC الدائرة/القناة المطلوبة غير متوفرة يتعذر على الجهاز البعيد توفير القناة المطلوبة لسبب غير معروف. قد تكون هذه مشكلة مؤقتة.
ب 2 المرفق المطلوب غير مشترك تدعم الأجهزة البعيدة الخدمة التكميلية المطلوبة عن طريق الاشتراك فقط. غالبا ما يكون ذلك مرجعا إلى خدمة المسافات الطويلة.
B9 القدرة لحاملها غير مصرح بها طلب المستخدم إمكانية الحامل التي توفرها الشبكة، ولكن المستخدم غير مخول باستخدامها. قد تكون هذه مشكلة اشتراك.
D8 وجهة غير متوافقة يشير إلى أنه تم إجراء محاولة للاتصال بمعدات غير ISDN. على سبيل المثال، على خط تناظري.
E0 عنصر المعلومات الإلزامية مفقود تلقت معدات الاستلام رسالة لا تتضمن أحد عناصر المعلومات الإلزامية. عادة ما يكون ذلك بسبب خطأ في قناة D. إذا حدث هذا الخطأ بشكل منهجي، فقم بالإبلاغ عنه إلى موفر خدمة ISDN الخاص بك.
الفئة E4 محتويات عنصر معلومات غير صحيحة تلقى الجهاز البعيد رسالة تتضمن معلومات غير صحيحة في عنصر المعلومات. عادة ما يكون ذلك بسبب خطأ في قناة D.

إستدعاء CAS الصادر

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

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

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

  • مودم تصحيح الأخطاء

  • debug modem csm

  • 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# 
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. راجع الفصل 15 للحصول على معلومات أستكشاف الأخطاء وإصلاحها في T1.

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

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

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

فيما يلي مثال على تسلسل PPP ناجح. راجع تفاصيل تفاوض PPP LCP للحصول على وصف تفصيلي لحقول الإخراج. 

Montecito# 
Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up
Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.415: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.415: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.415: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.415: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.543: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.543: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.543: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.547: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:16.919: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:16.919: As1 LCP:    PFC (0x0702)
Mar 13 10:57:16.919: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: State is Open
Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end
Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4
Mar 13 10:57:17.191: As1 PPP: Phase is UP
Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 13 10:57:17.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: As1 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: As1 LCP:  (0x80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: As1 LCP:  (0x04)
Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
 changed state to up
Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd
Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 13 10:57:20.307: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar 13 10:57:20.543: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22
Mar 13 10:57:20.547: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: State is Open
Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1

ملاحظة: قد تظهر تصحيح الأخطاء بتنسيق مختلف. يوضح هذا المثال تنسيق إخراج تصحيح أخطاء PPP الأحدث الذي تم تعديله في الإصدار 11.2(8) من IOS. انظر الفصل 16 على سبيل المثال، تصحيح أخطاء PPP باستخدام الإصدارات الأقدم من IOS.

تفاصيل تفاوض PPP LCP

طابع زمني الوصف
10:57:15.415 طلب تكوين صادر (o confreq). يرسل NAS حزمة طلب تكوين PPP الصادرة إلى العميل.
10:57:15.543 إقرار التكوين الوارد (I Confack). يقر العميل بطلب Montecito PPP.
10:57:16.919 طلب التكوين الوارد (i confreq). يريد العميل التفاوض على بروتوكول رد الاتصال.
10:57:16.919 رفض التكوين الصادر (o confrej). يرفض NAS خيار رد الاتصال.
10:57:17.047 طلب التكوين الوارد (i confreq). يطلب العميل مجموعة جديدة من الخيارات. لاحظ عدم طلب رد اتصال Microsoft هذه المرة.
10:57:17.047 إقرار التكوين الصادر (أو CONFACK). يقبل NAS المجموعة الجديدة من الخيارات.
10:57:17.047 تم إكمال تفاوض PPP LCP بنجاح. حالة LCP "مفتوحة". لقد أقر كلا الطرفين (CONFACK) بطلب تكوين الجانب الآخر (CONFREQ).
10:57:17.047 حتى 10:57:17.191 اكتملت مصادقة PPP بنجاح. بعد تفاوض بروتوكول LCP، تبدأ المصادقة. يجب أن تتم المصادقة قبل تسليم أي بروتوكولات شبكة، مثل IP. يعتمد كلا الجانبين الطريقة التي تم التفاوض عليها أثناء LCP. تقوم Montecito بمصادقة العميل باستخدام CHAP.
10:57:20.551 الدولة مفتوحة لبروتوكول التحكم في بروتوكول الإنترنت (IPCP). يتم التفاوض على مسار وتثبيته لنظير IPCP، والذي يتم تعيينه لعنوان IP 1.1.1.1.

بروتوكول التحكم في الارتباط

عادة ما تتم مواجهة نوعين من المشاكل أثناء تفاوض LCP.

يحدث الأول عندما يقوم أحد النظراء بعمل طلبات تكوين لا يمكن للنظير الآخر أو لا يمكنه التعرف عليها. بينما يكون هذا تكرار متكرر، إلا أنه يمكن أن يكون مشكلة إذا أصر الطالب على المعلمة. والمثال النموذجي هو عند التفاوض على AUTHTYPE (المعروف أيضا باسم "AuthProto"). على سبيل المثال، تم تكوين العديد من خوادم الوصول لقبول CHAP فقط للمصادقة. إذا تم تكوين المتصل لإجراء مصادقة PAP فقط، سيتم تبادل CONFREQs و CONFNAKs حتى يقوم أحد النظراء أو الآخر بإسقاط الاتصال. 

BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
...
...

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

Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open  
Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25  
Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) 
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 
Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). 
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 
Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) 
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 

!--- This repeats every two seconds until:

Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 
Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)  
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR

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

إذا ظهرت الأعراض عند تجاوز الاتصال ISDN، فمن المحتمل أن تكون المشكلة أن أحد النظراء يتصل عند 56 كيلوبايت بينما يتصل الآخر عند 64 كيلوبايت. وفي حين ان هذه الحالة نادرة، فهي تحدث. يمكن ان تكون المشكلة احد النظراء أو كليهما، أو ربما شركة الهاتف. أستخدم debug isdn q931 وفحص رسائل الإعداد على كل نظير. يجب أن تتطابق "القدرة على الحامل" التي يتم إرسالها من نظير مع "القدرة على الحامل" التي تم رؤيتها في رسالة "الإعداد" التي تم تلقيها على النظير الآخر. كعلاج ممكن، قم بتكوين سرعة الطلب، وهي 56 ألف أو 64 ألف لفة في الدقيقة، إما في خريطة المتصل على مستوى الواجهة أو في سرعة الأمر المتصل isdn التي يتم تكوينها ضمن فئة الخريطة. 

*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

هذا وضع قد يبرر مكالمة إلى ال cisco TAC. اجمع المخرجات التالية من كلا النظيرين قبل إستدعاء TAC:

  • show running-config

  • show version

  • debug isdn q931

  • debug isdn حادث

  • تفاوض DEBUG PPP

المصادقة

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

يوضح المثال التالي أن اسم المستخدم Goleta ليس لديه إذن للاتصال ب NAS، والذي لا يحتوي على اسم مستخدم محلي تم تكوينه لهذا المستخدم. لإصلاح المشكلة، أستخدم الأمر username name password لإضافة اسم المستخدم "Goleta" إلى قاعدة بيانات AAA المحلية من NAS: 

Mar 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response.  Username Goleta not found
Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure"
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING

يوضح المثال التالي أن اسم المستخدم "Goleta" تم تكوينه على NAS. ومع ذلك، فشلت مقارنة كلمة المرور. لحل هذه المشكلة، أستخدم الأمر username name password لتحديد كلمة مرور تسجيل الدخول الصحيحة ل Goleta: 

Mar 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed"
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING

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

بروتوكول التحكم في الشبكة

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

solvang# show debug
Generic IP:
IP peer address activity debugging is on
PPP:
PPP protocol negotiation debugging is on

*Mar  1 21:35:04.186: As4 PPP: Phase is UP
*Mar  1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
*Mar  1 21:35:04.194: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar  1 21:35:04.282: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.286: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:04.290: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:04.298: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar  1 21:35:04.310: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
*Mar  1 21:35:04.318: As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar  1 21:35:04.318: As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar  1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
*Mar  1 21:35:04.326: As4 LCP:  (0x80FD0101000F12060000000111050001)
*Mar  1 21:35:04.330: As4 LCP:  (0x04)
*Mar  1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 21:35:04.338: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4,
 changed state to up
*Mar  1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.278: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:07.282: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:07.286: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.298: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.302: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.310: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.430: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.434: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.442: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Mar  1 21:35:07.450: ip_get_pool: As4: using pool default
*Mar  1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Mar  1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Mar  1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.462: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.466: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.474: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.478: As4 IPCP: State is Open
*Mar  1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2

تفاصيل تفاوض PPP NCP

طابع زمني الوصف
21:35:04.190 طلب تكوين صادر (o confreq). يرسل NAS حزمة طلب تكوين PPP الصادرة تحتوي على عنوان IP الخاص بها إلى النظير.
21:35:04.282 Confreq الوارد. يطلب النظير إجراء ضغط رأس VJ. وهو يحتاج إلى عنوان IP لنفسه، وكذلك عناوين خوادم DNS الأساسية والثانوية.
21:35:04.306 config-reject الصادر (CONFREJ). تم رفض ضغط رأس VJ.
21:35:04.314 حتى 21:35:04.330 يرسل النظير طلبا لتنفيذ بروتوكول التحكم في الضغط؛ يتم رفض البروتوكول بالكامل بواسطة NAS بواسطة رسالة PROTREJ. يجب ألا يحاول النظير (ولا) إعادة محاولة CCP.
21:35:04.334 يتعرف النظير على عنوان IP الخاص ب NAS مع Confack.
21:35:07.274 Confreq الوارد. لم يعد النظير يطلب ضغط رأس VJ، ولكنه ما يزال يحتاج إلى عنوان IP لنفسه، بالإضافة إلى عناوين خوادم DNS الأساسية والثانوية.
21:35:07.294 يرسل NAS تكوين يحتوي على العنوان الذي يريد أن يستخدمه النظير، وعناوين خوادم DNS الأساسية والثانوية.
21:35:07.426 يرسل النظير العناوين مرة أخرى إلى NAS؛ محاولة لتأكيد تلقي العناوين بشكل صحيح.
21:35:07.458 يتعرف NAS على العناوين ب CONFACK.
21:35:07.478 بعد إصدار كل جانب من الاتصال CONFACK، ينتهي التفاوض. يظهر الأمر show interfaces async4 على NAS "IPCP: open".
21:35:07.490 يتم تثبيت مسار مضيف إلى النظير البعيد في جدول توجيه NAS.

من الممكن أن يقوم النظراء بالتفاوض في نفس الوقت على أكثر من بروتوكول من الطبقة 3. فعلى سبيل المثال، ليس من غير الشائع أن نرى التفاوض بشأن IP و IPX. ومن الممكن أيضا أن يجري أحد البروتوكولات التفاوض بنجاح بينما يفشل الآخر في ذلك.

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

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

  1. التحقق من تكوين بروتوكول الواجهة

    اختبر إخراج أمر EXEC ذي الامتيازات show running-config. تحقق من تكوين الواجهة لدعم البروتوكول الذي ترغب في تشغيله عبر الاتصال.

  2. التحقق من عنوان الواجهة

    تأكد من أن الواجهة المعنية تحتوي على عنوان تم تكوينه. إذا كنت تستخدم ip unnumber [interface-name] أو ipx ppp-client loopback [number]، فتأكد من تكوين الواجهة المشار إليها باستخدام عنوان.

  3. التحقق من توفر عنوان العميل

    إذا كان من المفترض أن يقوم NAS بإصدار عنوان IP للمتصل، فتأكد من توفر هذا العنوان. يمكن الحصول على عنوان IP الذي سيتم تسليمه إلى المتصل من خلال أحد الأساليب التالية:

    • قم بالتكوين محليا على الواجهة. تحقق من تكوين الواجهة للأمر peer default ip address a.b.c.d. في الممارسة العملية، يجب إستخدام هذه الطريقة فقط على الواجهات التي تقبل الاتصالات من متصل واحد، مثل الواجهة غير المتزامنة (وليس المجموعة غير المتزامنة).

    • تجمع العناوين الذي تم تكوينه محليا على NAS. يجب أن تحتوي الواجهة على الأمر peer default ip address pool [pool-name]. وبالإضافة إلى ذلك، يجب تحديد التجمع على مستوى النظام باستخدام الأمر ip local pool [pool-name] [first-address] [last-address]. يجب أن يكون نطاق العناوين المحدد في التجمع كبيرا بما يكفي لاستيعاب عدد المتصلين المتصلين المتصلين في نفس الوقت كما هو ممكن ل NAS.

    • خادم DHCP. يجب تكوين واجهة NAS باستخدام الأمر peer default ip address dhcp. علاوة على ذلك، يجب تكوين NAS للإشارة إلى خادم DHCP باستخدام أمر التكوين العام ip dhcp-server [address].

    • AAA. إذا كنت تستخدم TACACS+ أو RADIUS للتخويل، يمكن تكوين خادم AAA لتسليم عنوان IP محدد إلى متصل محدد في كل مرة يتصل فيها المتصل. انظر الفصل 16 للحصول على المزيد من المعلومات.

  4. التحقق من تكوين عنوان الخادم

    لإرجاع العناوين التي تم تكوينها لخوادم اسم المجال أو خوادم Windows NT إستجابة لطلبات بروتوكول نظام تمهيد تشغيل الكمبيوتر (BOOTP)، تأكد من تكوين الأوامر على المستوى العام async-bootp dns-server [address] وasync-bootp nbns-server [address].

    ملاحظة: بينما يمكن تكوين الأمر async-bootp subnet-mask [mask] على وحدة التخزين المتصلة بالشبكة (NAS)، لن يتم التفاوض حول قناع الشبكة الفرعية بين وحدة التخزين المتصلة بالشبكة (NAS) وكمبيوتر عميل طلب اتصال PPP. نظرا لطبيعة إتصالات من نقطة إلى نقطة، يستخدم العميل تلقائيا عنوان IP الخاص ب NAS (الذي تم التعرف عليه أثناء تفاوض IPCP) كبوابة افتراضية. لا يلزم قناع الشبكة الفرعية في بيئة الاتصال من نقطة إلى نقطة هذه. ال pc يعرف أن إن لا يطابق الغاية عنوان محلي، الربط سوفت كنت أرسلت إلى التقصير مدخل (NAS) أي يكون دائما بلغت عن طريق ال PPP خطوة.

قبل إستدعاء فريق TAC الخاص بأنظمة Cisco

قبل الاتصال بمركز المساعدة التقنية لأنظمة Cisco (TAC)، تأكد من أنك قرأت هذا الفصل وأكملت الإجراءات المقترحة لمشكلة نظامك.

بالإضافة إلى ذلك، قم بما يلي وتوثيق النتائج حتى نتمكن من مساعدتك بشكل أفضل:

لجميع المشاكل، قم بتجميع إخراج show running-config وshow version. تأكد من أن الأمر service timestamp debug datetime msec موجود في التكوين.

بالنسبة لمشاكل DDR، اجمع ما يلي:

  • إظهار خريطة المتصل

  • طالب تصحيح الأخطاء

  • تفاوض DEBUG PPP

  • تصحيح أخطاء مصادقة PPP

إذا كان ISDN مشاركا، فقم بتجميع:

  • show isdn وضع

  • debug isdn q931

  • debug isdn حادث

إذا كانت أجهزة المودم معنية، فقم بتجميع:

  • إظهار البنود

  • إظهار السطر [x]

  • إظهار المودم (إذا كانت أجهزة المودم المدمجة مشتركة)

  • show modem version (إذا كانت أجهزة المودم المدمجة مشتركة)

  • مودم تصحيح الأخطاء

  • تصحيح أخطاء مودم CSM (إذا كانت أجهزة المودم المدمجة مشتركة)

  • دردشة تصحيح الأخطاء (إذا كان سيناريو DDR)

إذا كانت T1s أو PRIs معنية، قم بتجميع:

  • show controller t1

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

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

المراجعة تاريخ النشر التعليقات
1.0
14-Sep-2005
الإصدار الأولي

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

Feedbackالتعليقات

اتصل بنا

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