المخطط الانسيابي لاستكشاف أخطاء ISDN وإصلاحها
المحتويات
المقدمة
يساعدك هذا المستند على أستكشاف أخطاء وصول واجهة المعدل الأساسي (BRI) الخاصة بشبكة ISDN وإصلاحها. في المخطط الانسيابي وعينة الإخراج الموضحة أدناه، قمنا بإعداد اتصال ISDN BRI بآخر باستخدام ملفات تعريف المتصل. ومع ذلك، تنطبق نفس خطوات أستكشاف الأخطاء وإصلاحها على الاتصالات بموجهات أخرى (مثل المكاتب الفرعية) وعند إستخدام توجيه الاتصال عند الطلب القديم (DDR).
ملاحظة: يمكنك أيضا إستخدام مجتمع دعم Cisco لمساعدتك في حل مشكلة ISDN الخاصة بك.
للحصول على معلومات أولية حول ISDN و DDR، راجع التدريب الصوتي الموجود في اتصال تعلم Cisco.
مخطط انسيابي
انقر فوق إرتباط أدناه للحصول على مزيد من المعلومات حول العنصر. أستخدم الزر "الخلف" في المستعرض للعودة إلى هذا المخطط الانسيابي.
أستكشاف الأخطاء وإصلاحها: كيفية تسجيل الدخول والتقاط عمليات تصحيح الأخطاء هذه
يمكنك الاتصال بالموجه الخاص بك إما من خلال كبل وحدة التحكم المرفق بالمنفذ التسلسلي الخاص بالكمبيوتر الشخصي الخاص بك، أو من خلال إستخدام برنامج Telnet.
إذا كنت بحاجة إلى الاتصال بالموجه الخاص بك من خلال وحدة التحكم، فيرجى الرجوع إلى تطبيق إعدادات المحاكي الطرفي الصحيحة لاتصالات وحدة التحكم. إذا كان الموجه الخاص بك تم إعداده بالفعل للاتصال على الإيثرنت وتريد الاتصال بالموجه لديك باستخدام برنامج Telnet، فما عليك سوى إستخدام عميل برنامج Telnet للاتصال بعنوان IP الخاص بالموجه عبر الإيثرنت.
في أي حالة (وحدة تحكم أو برنامج Telnet)، من الأفضل إستخدام عميل يسمح لك بالاحتفاظ بمحفوظات الإخراج التي تم تلقيها أثناء الجلسة، حيث قد يتعين عليك التمرير مرة أخرى في إخراج تصحيح الأخطاء للبحث عن رسائل معينة.
قم بتنشيط مللي ثانية على إخراج تصحيح الأخطاء ورسائل السجل. عندما يطلب منك، يدخل الكلمة يشكل على مسحاج تخديدك ويدخل enable أسلوب:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
إذا كنت متصلا باستخدام برنامج Telnet، فاكتب المراقبة الطرفية كما يلي:
router#terminal monitor router#
بعد ذلك، أدخل أوامر تصحيح الأخطاء أدناه:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
ثم ابدأ إختبار الاتصال على موجه الاتصال. فيما يلي إخراج تصحيح أخطاء لعينة إستدعاء ناجح. يتم إبراز المراحل المختلفة، كما تم تعريفها في المخطط الانسيابي.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
أستكشاف الأخطاء وإصلاحها: هل يحاول الموجه الطلب؟
لمعرفة ما إذا كان الموجه يحاول إجراء مكالمة، تحقق مما إذا كانت لديك الخطوط التالية في إخراج تصحيح الأخطاء الخاص بموجه الاتصال:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
في إخراج تصحيح الأخطاء، يكون 8134 هو رقم دليل ISDN الذي يحاول الموجه طلبه. تم تحديد هذا الرقم باستخدام الأمر سلسلة المتصل أو خريطة المتصل.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
العرض: لا يحاول الموجه الطلب
إذا لم يكن الموجه الخاص بك يحاول الطلب، فهناك العديد من الاحتمالات:
لا يوجد إخراج تصحيح أخطاء على الإطلاق
إذا لم يكن هناك إخراج تصحيح أخطاء على الإطلاق، فإن هذا يكون على الأرجح لأن حزمة IP التي تقوم بإرسالها لم يتم توجيهها حتى إلى واجهة المتصل. والأسباب الأكثر شيوعا لذلك هي:
- تحقق من تكوين IP على واجهة المتصل. يجب أن يكون لديك عنوان IP على واجهة المتصل أو واجهة IP غير المرقمة (حيث تكون الواجهة واجهة up/up مثل إيثرنت x، loopback x وما إلى ذلك) أو عنوان IP الذي تم التفاوض بشأنه (إذا كان العميل سيحصل على عنوان IP من NAS). إذا كنت تستخدم ذاكرة DDR القديمة، فيجب تكوين عنوان IP على الواجهة المادية (على سبيل المثال، واجهة BRI 0).
- تحقق من تكوين الأمر ip routing. عندما تنظر إلى التكوين الخاص بك باستخدام الأمر show running-config، يجب ألا ترى الأمر no ip routing.
- تحقق من وجود مسار ثابت يشير إلى واجهة المتصل أو الخطوة التالية (إذا كنت تستخدم خرائط المتصل).
المثال التالي (لملف تعريف المتصل) هو مسار ثابت ل 172.22.53.0/24 مع متصل الخطوة التالية 1:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
المثال التالي (ل DDR القديم) هو مسار ثابت ل 172.22.53.0/24 مع المرحلة التالية 172.16.1.1. يجب أن يتطابق عنوان الخطوة التالية مع عنوان IP في عبارة خريطة المتصل المستخدمة للطلب:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- تحقق من أن المتصل أو الواجهة المادية ليست في حالة إيقاف إداريا أو وضع الاستعداد. أستخدم الأمر show interface dialer X أو show interface bri X لضمان أن الواجهة في الحالة up/up (الانتحال).
إذا كانت الواجهة معطلة إداريا، فاستخدم الأمر no shutdown في وضع تكوين الواجهة.
إذا كانت الواجهة في حالة الاستعداد، فإن واجهة الاتصال أو واجهة BRI تكون بمثابة نسخة إحتياطية لاتصال قيد التشغيل. يمكنك إما إزالة أمر واجهة النسخ الاحتياطي أسفل الواجهة الأساسية أو سحب الكبل من الواجهة الأساسية.
يوجد إخراج تصحيح الأخطاء ولكن لا توجد رسالة "محاولة الطلب"
في هذه الحالة، قد تكون هناك حزمة IP موجهة إلى الواجهة، ولكن الموجه يتجاهلها ولا يبدأ المكالمة لسبب ما. راجع إخراج تصحيح الأخطاء لمعرفة سبب عدم إجراء محاولة الاستدعاء. فيما يلي بعض نواتج تصحيح الأخطاء وأسبابها المحتملة:
مثال 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
لا تتطابق حركة المرور التي تم إنشاؤها مع تعريف حركة المرور المثير للاهتمام. لهذا المثال، قم بتعديل قائمة الوصول 101.
تعريف حركة مرور بسيط وممتع قد يكون للسماح لجميع حركة مرور IP كما في:
maui-soho-01(config)#dialer-list 1 protocol ip permit
تحذير: قد يؤدي تمييز حركة مرور IP على أنها مثيرة للاهتمام إلى بقاء إرتباط ISDN قيد التشغيل إلى أجل غير مسمى، خاصة إذا كان لديك بروتوكول توجيه أو حركة مرور دورية أخرى. اضبط تعريف حركة المرور الممتع ليلائم إحتياجاتك.
لمزيد من المعلومات عن حركة المرور المثيرة، راجع تقنية الاتصال بالوثيقة: نظرة عامة وتوضيحات.
مثال 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
لا توجد مجموعة متصل مكونة على واجهة المتصل. إضافة مجموعة متصل كما هو الحال في المثال التالي:
interface Dialer1 dialer-group X
ملاحظة: يجب أن تكون قيمة X هي القيمة نفسها المستخدمة مع أمر dialer-list.
مثال 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
يوجد بيان مجموعة المتصل على واجهة المتصل، ولكن قائمة المتصل المشار إليها غير موجودة. قم بتكوين قائمة المتصل كما هو موضح في المثال التالي:
dialer-list X protocol ip permit
ملاحظة: يجب أن تكون قيمة X هي القيمة نفسها المستخدمة مع الأمر dialer-group أسفل واجهة المتصل.
مثال 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
في هذه الحالة، يعتبر الحزمة الصادرة مثيرة بما يكفي لجلب الارتباط، ولكن لا يوجد واجهة مادية متاحة لإجراء المكالمة. تأكد من تكوين عضو تجمع المتصل س في الواجهة المادية وتم تكوين تجمع المتصل X في واجهة المتصل. مثال:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
تحقق أيضا من أن واجهة BRI ليست في حالة إيقاف التشغيل.
مثال 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
في هذه الحالة، لم يتم تكوين سلسلة المتصل على واجهة المتصل. يريد الموجه إجراء مكالمة ولكنه لا يعرف رقم دليل ISDN الذي يجب الاتصال به. تعريف سلسلة المتصل:
interface Dialer1 dialer string 8134
لمزيد من معلومات أستكشاف الأخطاء وإصلاحها، ارجع إلى القسم "موجه الاتصال لا يرسل رسالة إعداد" في المستند أستكشاف أخطاء ISDN BRI الطبقة 3 وإصلاحها باستخدام الأمر debug isdn q931.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
أستكشاف الأخطاء وإصلاحها: هل تم اتصال إستدعاء ISDN بنجاح؟
لتحديد ما إذا كان اتصال اتصال اتصال ISDN، ابحث عن رسالة Connect_ACK و٪LINK-3-UPDOWN في تصحيح الأخطاء:
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
إذا ظهرت لك هذه الرسالة، فسيتم توصيل مكالمة ISDN بنجاح ويمكنك المتابعة إلى الخطوة التالية. إذا لم تشاهد رسالة كهذه، فاقرأ أدناه لمعرفة الأسباب المحتملة.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
العرض: إستدعاء ISDN لا يتصل بنجاح
- إذا رأيت مخرجات مماثلة لما يلي، فتحقق من توصيل كبل ISDN في كل من الموجه ومقبس Telco.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- تحقق من أن دائرة ISDN تعمل بشكل صحيح. أستخدم الأمر show isdn status للتحقق من أن الطبقة 1 نشطة، والطبقة 2 هي MULTI_FRAME_ESTABLISHED و SPIDs (إذا لزم الأمر) صحيحة. لمزيد من المعلومات، ارجع إلى المستند باستخدام الأمر show isdn status لاستكشاف أخطاء BRI وإصلاحها.
إن يتلقى أنت الإنتاج من عرض isdn وضع أمر من ك cisco أداة، أنت يستطيع استعملت cisco CLI محلل أن يعرض ممكن إصدار ونقطة معينة. لاستخدام Cisco CLI Analyzer (محلل واجهة سطر الأوامر من Cisco)، يجب أن تكون مستخدما مسجلا، وأن تسجل دخولك، وأن يتم تمكين JavaScript. - تحقق من صحة سلسلة متصل ISDN التي تم تكوينها. تذكر أنه قد يتوجب عليك إضافة صفر بادئ، تسعة أو أرقام أخرى للحصول على خط خارجي عند إتصالك عبر PBX.
- إذا كان الاتصال يستخدم شركة نقل مسافات طويلة، فاتصل بشركة الاتصالات المحلية وموفر المسافات الطويلة للتحقق من تنشيط الخدمة. وغالبا ما يكون لدى شركة Telco المحلية دائرة ISDN التي تم تكوينها بشكل غير صحيح بحيث لا يتم تحويل مكالمات ISDN البعيدة الصادرة إلى شبكة موفر المسافات الطويلة المناسبة. يجب عليك أيضا التحقق من تشغيل شبكة موفري المسافات الطويلة.
في الولايات المتحدة، وفي الحالات التي يتعذر فيها على شركة Telco أو موفر المسافات الطويلة حل المشكلة، قد ترغب في إستخدام شركة InterexChange Carrier (PIC) مسجلة مسبقا. رموز PIC هي بادئات ذات سبع خانات تعرف شركات الاتصالات البعيدة للولايات المتحدة إلى شركات الصرافة المحلية (LEC). ويتيح هذا للعملاء إستخدام شركات إتصالات مختلفة للمسافات الطويلة للمكالمات الفردية. تم تكوين رمز PIC كبادئة للرقم المطلوب. تكون معظم بطاقات PICs بالتنسيق 1010xxx.
لا تستخدم سلسلة متصل xxxxx أو لا توجد خريطة متصل لإزالة الرقم الموجود ثم تكوين الرقم الجديد.
على سبيل المثال، سلسلة المتصل 101032151255111.
- ابحث عن رسالة قطع اتصال ISDN.
يقوم برنامج Cisco IOS®بفك ترميز رمز السبب في رسالة قطع الاتصال هذه ويعطيك رسالة نصية واضحة تحتوي غالبا على معلومات مفيدة تؤدي إلى سبب المشكلة. السلاسل المحتملة التي قد تجدها هنا تتضمن:
- رقم غير مخصص أو غير معين
- وجهة غير متوافقة (يشير كلاهما إلى أن الرقم المطلوب قد يكون غير صحيح)
- العدد مشغول (مما يشير إلى أن الجانب المتصل مشغول)
- الفشل المؤقت (الذي يشير إلى انقطاع مؤقت عن شبكة Telco)
للعثور على السبب المحتمل لسبب انقطاع محدد، يرجى الرجوع إلى فهم رموز سبب انقطاع الاتصال ISDN q931.
على سبيل المثال، قد يتم الإشارة إلى قطع الاتصال بسبب رقم ISDN غير صحيح مع:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
بالإشارة إلى مستند رموز أسباب قطع الاتصال المشار إليه مسبقا، يمكننا تحديد أن رمز قطع الاتصال كان ناتجا عن محاولة الاتصال بمعدات غير ISDN (على سبيل المثال، سطر تناظري).
قد يتم الإشارة إلى قطع الاتصال بسبب وجود رقم منسق بشكل غير صحيح مع:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)بالإشارة إلى رموز سبب قطع الاتصال ل ISDN q931 الخاصة بفهم المستند، يمكننا تحديد أن رمز قطع الاتصال كان سببه تنسيق غير صالح لرقم ISDN البعيد. يفشل التوصيل لأن عنوان الوجهة مقدم (إلى المفتاح) في تنسيق لا يمكن التعرف عليه، أو الغاية عنوان غير كامل.
يوضح المثال التالي مكالمة مرفوضة بسبب رقم ISDN غير صحيح:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- إذا قام Telco بتوفير معرفات ملف تعريف الخدمة (SPIDs) لك ليتم إستخدامها، فتأكد من تكوين معرفات SPIDs هذه على واجهة BRI. يتم إستخدام SPIDs بشكل شائع فقط في الولايات المتحدة ومع أنواع المحولات NI و DMS (لا تحتاج أنواع المحولات 5ess إلى SPIDs).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
يمكنك إستخدام الأمر show isdn status للتحقق من صحة معرفات المنتج (SPIDs).
لمزيد من المعلومات، ارجع إلى المستند أستكشاف أخطاء ISDN BRI SPIDs وإصلاحها.
إن يتلقى أنت الإنتاج من عرض isdn وضع أمر من ك cisco أداة، أنت يستطيع cisco CLI محلل يستعمل أن يعرض ممكن إصدار ونقطة معينة. لاستخدام Cisco CLI Analyzer (محلل واجهة سطر الأوامر من Cisco)، يجب أن تكون مستخدما مسجلا، وأن تسجل دخولك، وأن يتم تمكين JavaScript. - إذا لم يحل الإجراء المذكور أعلاه المشكلة، فاستخدم طبقة ISDN BRI 3 الخاصة باستكشاف أخطاء المستند وإصلاحها باستخدام الأمر debug isdn q931 لمزيد من أستكشاف الأخطاء وإصلاحها.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
أستكشاف الأخطاء وإصلاحها: هل نجحت مرحلة PPP LCP؟
في إخراج تصحيح الأخطاء، يجب أن ترى سطر رسالة إلى ما يلي:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
إذا رأيت هذا السطر، فهذا يشير إلى أنه قد تم التفاوض بشأن بروتوكول التحكم في الارتباط (LCP) بنجاح. تشير أي حالة غير مفتوحة إلى فشل LCP.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
العرض: لا تنجح مرحلة PPP LCP
السبب المحتمل: لم يتم تكوين PPP
إذا كان لديك إخراج تصحيح أخطاء مماثل للأسطر التالية، فإن هذا يشير إلى أن PPP لم يبدأ.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
لاحظ من إخراج تصحيح الأخطاء أن الموجه لا يرسل أي رسائل PPP confreq. قد يكون هذا بسبب أنه لم يتم تكوين الواجهة لتضمين PPP.
في هذه الحالة، تحقق من تكوين الأمر عملية كبسلة PPP تحت واجهة المتصل والواجهة المادية. وفيما يلي أمثلة على ذلك:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
السبب المحتمل: عدم تطابق سرعة ISDN
في بعض الأحيان قد ترى رسائل LCP CONFREQ الصادرة فقط، ولكن لا توجد رسائل LCP واردة. ويرد أدناه مثال على ذلك:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
قد يرجع سبب هذه المشكلة إلى:
- لم يتم تكوين الطرف البعيد ل PPP. شكلت الأمر عملية كبسلة ppp على الطرف البعيد
- لا تصل الحزم من خلال وسائط الإرسال. السبب الأكثر شيوعا لهذا هو عدم تطابق سرعة ISDN
طبيعة المشكلة، من وجهة نظر ISDN، أن أحد الجانبين ربما يكون متصلا 56 ك بينما الآخر موصل 64 ك. من المحتمل ألا تدعم الدائرة المحلية أو البعيدة الاتصالات الافتراضية بسرعة 64 ألف لفة في الدقيقة. حاول تكوين كلا النهايتين للتشغيل عند 56 كيلوبايت.
لملفات تعريف المتصل:
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
بالنسبة ل DDR القديمة (خرائط المتصل):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
السبب المحتمل: لا يوافق الموجهان على بروتوكول مصادقة (CHAP أو PAP) لاستخدامه
إذا كان لديك إخراج تصحيح أخطاء مماثل للأسطر التالية، فإن هذا يشير إلى أن الموجه والجانب البعيد لم يوافقا على بروتوكول مصادقة لاستخدامه:
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
في هذه الحالة، تحقق من تكوين ما يلي:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
لمزيد من المعلومات حول بروتوكول المصادقة لتأكيد الاتصال بقيمة التحدي (CHAP) أو بروتوكول مصادقة كلمة المرور (PAP)، ارجع إلى المستندات التالية:
- استيعاب مصادقة PPP CHAP وتكوينها
- مصادقة PPP باستخدام أوامر إستدعاء بروتوكول PPP chap ومصادقة PPP
- تكوين بروتوكول مصادقة كلمة مرور PPP (PAP) واستكشاف أخطاء هذا البروتوكول وإصلاحها
يمكنك أيضا إستخدام مجتمع دعم Cisco لمزيد من أستكشاف أخطاء PPP وإصلاحها.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
أستكشاف الأخطاء وإصلاحها: هل نجحت مصادقة PPP؟
تحقق من إخراج تصحيح الأخطاء لخط مماثل لهذا:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
العرض: مصادقة PPP غير ناجحة
تأكد من تكوين الأسطر التالية:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
في المثال، XXXXX هو اسم المستخدم الخاص بك و YYYY هو كلمة المرور الخاصة بك.
ملاحظة: قم بتكوين اسم المستخدم وكلمة المرور فقط لطريقة المصادقة التي تستخدمها مع النظير لديك. على سبيل المثال، إذا لم تستخدم كلاهما PAP، فإنك لا تحتاج إلى الأمر PPP PAP send-username. ومع ذلك، إذا لم تكن متأكدا من دعم النظير PAP أو CHAP، فقم بتكوين كليهما.
على حسب إصدار برنامج Cisco IOS software وتكوينه، قد تظهر كلمة المرور مشفرة في التكوين الخاص بك. إذا كان هذا هو الحال، عند تنفيذ أمر show running-configuration، سترى كلمة "كلمة المرور" متبوعة بالرقم 7 ثم بتسلسل من الأرقام، مثل المثال التالي:
interface Dialer1 ppp chap password 7 140005
في هذه الحالة، لا يمكنك التحقق من صحة كلمة المرور التي تم تكوينها أم لا بالنظر إلى التكوين. للتأكد من صحة كلمة المرور، ببساطة أدخل وضع التكوين وقم بإزالة كلمة المرور وتكوينها مرة أخرى. لتعريف فشل كلمة المرور في تصحيح الأخطاء، قارن إخراج تصحيح الأخطاء مع إخراج النموذج أدناه.
إذا كان هذا الموجه سيقوم بمصادقة النظير، فتأكد من تكوين كلمة مرور اسم المستخدم لكلمة المرور، حيث يكون اسم المستخدم هو الاسم الموفر من قبل موجه النظير للمصادقة.
مثال 1
تعني رسالة مثل الرسالة التالية أن كلمة مرور CHAP غير صحيحة.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
تلميح: يعني فشل CHAP الوارد (المشار إليه بواسطة CHAP: I Failure) أن النظير غير قادر على مصادقة الموجه. أستخدم تفاوض PPP الخاص بتصحيح الأخطاء على الموجه النظير لتحديد السبب الدقيق للفشل.
لمزيد من المعلومات، ارجع إلى مصادقة PPP للمستند باستخدام أوامر إستدعاء بروتوكول PPP chap ومصادقة بروتوكول الإنترنت.
مثال 2
قد تعني رسالة مثل الرسالة أدناه أن اسم مستخدم CHAP غير صالح:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
تلميح: يعني فشل CHAP الوارد (المشار إليه بواسطة CHAP: I Failure) أن النظير غير قادر على مصادقة الموجه. أستخدم تفاوض PPP الخاص بتصحيح الأخطاء على الموجه النظير لتحديد السبب الدقيق للفشل.
لمزيد من المعلومات، ارجع إلى مصادقة PPP للمستند باستخدام أوامر إستدعاء بروتوكول PPP chap ومصادقة بروتوكول الإنترنت.
مثال 3
تعني رسالة مثل ما يلي أن كلمة مرور PAP غير صحيحة:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
أحلت ل كثير معلومة الوثيقة يشكل ويستكشف PPP كلمة صحة هوية بروتوكول (PAP).
مثال 4
تعني رسالة مثل ما يلي أن اسم مستخدم PAP غير صالح:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
أحلت ل كثير معلومة الوثيقة يشكل ويستكشف PPP كلمة صحة هوية بروتوكول (PAP).
يمكنك أيضا إستخدام مجتمع دعم Cisco لاستكشاف أخطاء PPP وإصلاحها بشكل إضافي.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
أستكشاف الأخطاء وإصلاحها: هل اكتملت مرحلة PPP NCP (IPCP)؟
العنصر الأساسي الذي تم التفاوض عليه في IPCP هو عنوان كل نظير. قبل تفاوض IPCP، يكون كل نظير في إحدى حالتين محتملتين؛ إما أن يكون له عنوان IP أو لا. إذا كان النظير لديه عنوان بالفعل، فإنه يرسل هذا العنوان في CONFREQ إلى النظير الآخر. إذا كان العنوان مقبولا للنظير الآخر، يتم إرجاع CONFACKs. إذا كان العنوان غير مقبول، يكون الرد عبارة عن CONFNAK يحتوي على عنوان للنظير لاستخدامه.
هذه هي المرحلة الوحيدة التي لا يمكن تحديدها بشكل صحيح بالنظر إلى سطر واحد فقط. للتأكد من أن بروتوكول التحكم في IP (IPCP) يتم إعداده بشكل صحيح، يلزمك التحقق من أنه تم التفاوض بشأن عناوين IP في كلا الاتجاهين. انظر إلى تصحيح أخطائك للاطلاع على السطور التالية:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
و
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
و
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
قد لا تتبع هذه المجموعات الثلاث من الخطوط بعضها البعض على الفور. من المهم التحقق مما إذا كان هناك إقرار تكوين صادر (أو CONFACK) يحتوي، من بين خيارات أخرى، على عنوان تحته.
يجب أن يكون هناك أيضا إقرار تكوين وارد (I CONFACK) مع عنوان IP آخر تحته.
وأخيرا، يجب أن يكون هناك سطر يشير إلى أن حالة IPCP مفتوحة. بعد هذا، يجب أن تكون قادرا على إختبار اتصال كلا عنواني IP بنجاح تام من الموجه الخاص بك مباشرة.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
العرض: تفاوض PPP NCP (IPCP) غير ناجح
مشكلة: فشل التفاوض على عنوان IP
أحد الأسباب التي قد تؤدي إلى فشل IPCP هو فشل مفاوضات عنوان IP. على سبيل المثال، قد يكون NAS يحاول تعيين عنوان إلى العميل بينما يكون لموجه العميل عنوان IP مختلف تم تكوينه أو قد تكون هناك مشكلة أخرى شائعة عندما يطلب العميل عنوانا ولا يحتوي NAS على أي عناوين متوفرة للعميل.
على موجه الاتصال:
إذا كان الموجه الموجه المستدعى يقوم بتعيين عنوان IP بشكل ديناميكي إلى موجه الاتصال، فتحقق من أن لديك عنوان الأمر ip الذي تم التفاوض عليه في واجهة المتصل.
إذا كان موفر NAS/ISP قد منحك عنوان IP ساكن إستاتيكي، فتحقق من تكوين عنوان IP هذا (وقناع الشبكة الفرعية) في واجهة المتصل باستخدام الأمر ip address subnet_mask.
على الموجه الملقب:
تأكد من أن الواجهة التي تتحكم في الاتصال (على سبيل المثال، int dialer x) لها عنوان IP وتقوم بتعيين عنوان للنظير باستخدام الأمر peer default ip address .
ملاحظة: إذا كان موجه العميل لديه عنوان IP تم تكوينه، فلن تحتاج إلى تعيين عنوان باستخدام الأمر peer default ip address
لمزيد من المعلومات، ارجع إلى تقنية اتصال المستند: تقنيات أستكشاف الأخطاء وإصلاحها.
مشكلة: الموجه المستدعى فشل ربط ملف تعريف المتصل
إذا لم يتطابق اسم المستخدم الذي تمت مصادقته مع اسم المتصل عن بعد الذي تم تكوينه تحت واجهة المتصل، فسيتم قطع اتصال المكالمة بواسطة الموجه الذي تم استدعاؤه. فيما يلي إخراج طالب تصحيح الأخطاء لهذا الخطأ:
على موجه الاتصال:
يظهر تصحيح الأخطاء التالي قطع اتصال بسبب ربط ملف تعريف طالب غير صحيح على الموجه المسمى؛
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
ملاحظة: لا يساعد تصحيح الأخطاء من الجانب المتصل في أستكشاف هذه المشكلة وإصلاحها إلا للإشارة إلى أن النظير قام بقطع الاتصال. نقل أستكشاف الأخطاء وإصلاحها إلى الموجه الذي تم إستدعائه.
على الموجه الملقب:
يظهر تصحيح الأخطاء التالي فشل المكالمة بسبب مشاكل ربط ملف تعريف المتصل:
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
الحل:
قم بتكوين الأمر تجمع أرقام المتصل على واجهة المتصل. يجب أن يتطابق رقم التجمع مع رقم التجمع الذي تم تكوينه على الواجهة الفعلية.
قم بتكوين الأمر dialer remote-name على واجهة المتصل. يجب أن يتطابق الاسم المحدد تماما مع اسم المستخدم الذي يقدمه الموجه عن بعد للمصادقة. في هذا المثال، اسم المستخدم الذي تمت مصادقته هو maui-soho-03.
للحصول على مزيد من المعلومات حول أستكشاف الأخطاء وإصلاحها في مشاكل الربط، ارجع إلى المستند تكوين ملفات تعريف المتصل واستكشاف أخطائها وإصلاحها.
يمكنك أيضا إستخدام مجتمع دعم Cisco لمزيد من أستكشاف أخطاء PPP وإصلاحها.
عودة إلى المخطط الانسيابي لاستكشاف الأخطاء وإصلاحها
مشكلات ما بعد الاتصال
العرض: قطع الاتصال قبل الأوان أو عدم قطع الاتصال على الإطلاق
إذا تم قطع الاتصال بشكل غير متوقع أو لم يتم قطع الاتصال أبدا، فتحقق من تعريف حركة مرور البيانات الخاملة والمهمة. يمكنك إستخدام أمر حزمة متصل debug لمعرفة ما إذا كانت حزمة معينة مثيرة للاهتمام أم لا. على سبيل المثال:
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
في المثال الوارد أعلاه، تعد بدلات OSPF غير مثيرة للاهتمام لكل قائمة وصول 101، في حين تكون الحزمة الثانية مثيرة للاهتمام لكل قائمة وصول 101.
- قم بضبط مهلة خامل المتصل في تكوين واجهة المتصل. الإعداد الافتراضي هو 120 ثانية، ولكن قد ترغب في زيادة هذه القيمة أو خفضها وفقا لاحتياجاتك.
- قم بتغيير تعريف حركة المرور المثيرة للاهتمام (تم تكوينه باستخدام الأمر dialer-list). إذا تم قطع الاتصال قبل الأوان فقد ترغب في تعريف حركة المرور المثيرة للاهتمام بشكل أكثر تفصيلا. إذا لم تتوقف المكالمة أبدا، فعليك تغيير تعريف حركة المرور المثير للاهتمام ليصبح أكثر تقييدا. على سبيل المثال، يمكنك تعريف حركة مرور بروتوكول التوجيه على أنها غير مثيرة للاهتمام. هنا عينة حركة مرور تعريف:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1لمزيد من المعلومات، ارجع إلى الوثيقة Dialup Technology: نظرة عامة وتوضيحات.
العرض: يقوم الموجه بإخفاء الاتصال بشكل دوري
في حالات معينة، قد تلاحظ أن الموجه يقوم بحفظ الاتصال بشكل دوري، حتى في حالة عدم وجود حركة مرور واضحة للمستخدم تتطلب أن يكون الارتباط قيد التشغيل. ويمكن أن يؤدي ذلك إلى رسوم رسوم رسوم رسوم رسوم مرتفعة حيث يتم فرض رسوم على خدمة ISDN في الدقيقة الواحدة.
السبب الأكثر شيوعا هو أن العملية التي تولد حركة مرور دورية (مثل بروتوكول التوجيه، و NTP، و SNMP، وما إلى ذلك) قد يتم اعتبارها دون قصد مثيرة للاهتمام. أستكشاف هذه المشكلة وإصلاحها على خطوتين:
- حدد حركة المرور التي تتسبب في طلب الارتباط.
- الإشارة إلى حركة المرور على أنها غير مثيرة للاهتمام.
حدد حركة المرور التي تتسبب في اتصال الارتباط بالطلب.
لتحديد حركة المرور التي تتسبب في طلب الارتباط، يلزمك تمكين حزمة طالب تصحيح الأخطاء. راقبت المسحاج تخديد بينما ال isdn خطوة يكون أسفل وراقبت بعض دوري متعة حركة مرور أن يحاول أن يجلب الخطوة.
تلميح: قم بتعيين جميع بروتوكولات التوجيه التي تم تكوينها على الموجه غير مثيرة للاهتمام، ما لم تكن هناك حاجة إليها بشكل محدد.
يوضح المثال التالي علاقة OSPF الدورية التي تم تمييزها كعلامة مثيرة للاهتمام:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
الطريقة الوحيدة لتعريف أن الحزمة أعلاه هي إستقبال OSPF هي من عنوان الوجهة (d=224.0.0.5) الذي تم تعريفه ل OSPF. يسرد الجدول التالي العناوين المستخدمة لبعض بروتوكولات التوجيه الشائعة:
|
بروتوكول التوجيه
|
غاية عنوان ل دوري التحديثات أو رسائل تنشيط الاتصال |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EIGRP
|
224.0.0.10
|
|
بروتوكول أقصر مسار أولاً (OSPF)
|
224.0.0.5
|
يجب وضع علامة على حركة المرور التي تتسبب في طلب الموجه (بروتوكول التوجيه أو حركة المرور الدورية الأخرى) على أنها غير مثيرة للاهتمام.
تعيين حركة المرور الدورية على أنها غير مثيرة للاهتمام
قم بتغيير تعريف حركة المرور المثيرة للاهتمام (تم تكوينه باستخدام الأمر dialer-list). في هذا المثال، قم بتعريف حركة مرور بيانات OSPF و NTP على أنها غير مثيرة للاهتمام. هنا عينة حركة مرور تعريف:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
لمزيد من المعلومات، ارجع إلى الوثيقة Dialup Technology: نظرة عامة وتوضيحات.
ملاحظة: يحتوي OSPF على ميزة تسمى دائرة الطلب يمكن إستخدامها أيضا هنا. راجع المستند لماذا تستمر دائرة طلب OSPF في إظهار الارتباط للحصول على مزيد من المعلومات
العرض: القناة الثانية لا تتصل
في العديد من الحالات، قد يتصل الموجه فقط بقناة B واحدة، في حين تظل القناة B الأخرى في وضع الخمول. أحلت ل كثير معلومة على يتحرى هذا إصدار الوثيقة يتحرى ثانية قناة اتصال إخفاق على ISDN BRI خطوة.
مشاكل اتصال IP
إن ال ISDN يظهر ربط غير أن أنت يستطيع لا يمر حركة مرور عبر الخطوة بعد ذلك الإصدار ربما يكون تحشد أو nat مشكلة ذات صلة. راجع مجتمع دعم Cisco للحصول على مزيد من معلومات أستكشاف الأخطاء وإصلاحها.
إذا كنت تستخدم إرتباط ISDN كنسخ إحتياطي لاتصال WAN، ارجع إلى المستند تكوين نسخ DDR الاحتياطي واستكشاف أخطائه وإصلاحها.
التعليقات