دليل تكوين موجه DSL واستكشاف الأخطاء وإصلاحها من Cisco - PPPoE: الموجه DSL كحل أخطاء عميل PPPoE وإصلاحها
المحتويات
المقدمة
هناك العديد من الأسباب التي قد تجعل اتصال خط المشترك الرقمي (DSL) لديك لا يعمل بشكل صحيح. الهدف من هذا المستند هو عزل سبب الفشل وإصلاحه. تتمثل الخطوة الأولى لاستكشاف الأخطاء وإصلاحها في تحديد الطبقة التي فشلت فيها خدمة خط المشترك الرقمي غير المتزامن (ADSL). هناك ثلاث طبقات حيث يمكن أن يحدث الفشل.
-
الاتصال المادي ب DSL من الطبقة 1 إلى تجميع الوصول إلى خط المشترك الرقمي (DSLAM) الخاص ب ISP لديك
-
اتصال ATM من المستوى 2.1
-
من المستوى 2.2 - بروتوكول الاتصال من نقطة إلى نقطة عبر ATM (PPPoA) أو بروتوكول الاتصال من نقطة إلى نقطة عبر شبكة إيثرنت (PPPoE) أو التوصيل عبر RFC1483 أو التوجيه عبر RFC1483
-
الطبقة 3 - IP
أسهل طريقة لتحديد الطبقة التي يجب أن تبدأ في أستكشاف الأخطاء وإصلاحها هي إصدار الأمر show ip interface brief. يختلف إخراج هذا الأمر قليلا حسب التكوين الخاص بك.
827-ESC#show ip interface brief Interface IP-Address OK? Method Status Protocol ATM0 unassigned YES manual up up ATM0.1 unassigned YES unset up up Ethernet0 10.10.10.1 YES manual up up
إذا كانت حالات ATM0 و ATM0.1 قيد التشغيل والبروتوكول قيد التشغيل، فعليك البدء في أستكشاف الأخطاء وإصلاحها في الطبقة 2.
إذا كانت واجهات ATM معطلة، أو إذا إستمرت في الظهور إلى أعلى ثم الانتقال إلى أسفل (لا تظل مرتفعة وإلى أعلى)، فعليك البدء في أستكشاف الأخطاء وإصلاحها في الطبقة 1.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
الاصطلاحات
راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.
مشاكل الطبقة 1
هل يكتشف الناقل المصباح (CD) على اللوحة الأمامية لتشغيل موجه Cisco DSL أو إيقاف تشغيله؟
إذا كان ضوء الأسطوانة في حالة تشغيل، انتقل إلى قسم مشاكل الطبقة 2 في هذا المستند.
إذا كان ضوء CD في وضع إيقاف، فتابع بالسؤال التالي.
هل يستخدم مزود خدمة الإنترنت (ISP) لديك تقنية DSLAM التي تدعم مجموعة شرائح Alcatel؟
تحقق من هذه المعلومات باستخدام ISP لديك.
هل تم توصيل منفذ DSL الموجود على الجزء الخلفي من موجه DSL من Cisco في مقبس حائط DSL؟
إذا لم يتم توصيل منفذ DSL في مقبس حائط DSL، فقم بتوصيل المنفذ بالجدار باستخدام كابل RJ-11 يحتوي على 4 سنون أو 6 سنون. هذا كبل هاتف قياسي.
هل واجهة ATM في حالة معطلة إداريا؟
لتحديد ما إذا كانت واجهة ATM0 معطلة إداريا، قم بإصدار هذا الأمر في وضع التمكين على الموجه:
Router#show interface atm 0 ATM0 is administratively down, line protocol is down <... snipped ...>
إذا كانت حالة واجهة ATM0 معطلة إداريا، فعليك إصدار الأمر no shutdown ضمن واجهة ATM0.
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface atm 0 Router(config-if)#no shut Router(config-if)#end Router#write memory
هل قرع الكبل صحيح؟
إذا كانت حالة واجهة ATM0 معطلة أو متوقفة، فإن الموجه لا يرى ناقل على خط ADSL. وهذا يشير عموما إلى إحدى القضيتين:
-
المسامير النشطة الموجودة على مقبس حائط DSL غير صحيحة.
-
لم يقم مزود خدمة الإنترنت (ISP) لديك بإنشاء خدمة DSL على مقبس الحائط هذا.
وصف منفذ Cisco DSL Router xDSL
يوفر موصل RJ-11 وصلة xDSL للوسائط الخارجية من خلال مقبس معياري RJ-11 ذو ستة أسنان قابل لإضافة وحدات أخرى.
| مسمار | الوصف |
|---|---|
| 3 | xdsl_tip |
| 4 | XDSL_Ring |
أصدرت in order to حددت إن ال ATM0 قارن أسفل وأسفل، العرض قارن atm 0 أمر من يمكن أسلوب من المسحاج تخديد:
Router#show interface atm 0 ATM0 is down, line protocol is down <... snipped ...>
إذا كانت واجهة ATM معطلة أو متوقفة عن العمل - وليس معطلة إداريا - فتحقق من المسافة بين قابس حائط DSL الخاص بك. يستخدم الموجه DSL كبل RJ-11 (مكون من 4 سنون أو 6 سنون) قياسي لتوفير اتصال ADSL بمقبس الحائط. يتم إستخدام زوج السنون المركزي على كابل RJ-11 لحمل إشارة ADSL (السنون 3 و 4 على كبل مكون من 6 سنون، أو السنون 2 و 3 على كبل مكون من 4 سنون).
إذا كنت متأكدا من أنك تمتلك المسامير الصحيحة على مقبس الحائط وأن واجهة ATM0 لا تزال في الانخفاض والنزول، فاستبدل كبل RJ-11 بين منفذ DSL ومقبس الحائط. إذا كانت الواجهة لا تزال معطلة أو معطلة بعد إستبدال كابل RJ-11، فاتصل بموفر خدمة الإنترنت (ISP) لديك وتأكد من تمكين خدمة DSL على مقبس الحائط الذي تستخدمه.
إذا لم تكن متأكدا من مدى فعالية المسامير الموجودة على قابس الحائط، فاسأل مزود خدمة الإنترنت (ISP) الذي بحوزتك.
هل لديك إمداد الطاقة الصحيح ل Cisco 827؟
إذا قمت بالتحقق من أن كبل DSL لديك جيد وأن لديك خطوط توصيل صحيحة، فإن الخطوة التالية هي التأكد من توفر مصدر الطاقة الصحيح للطراز 827.
ملاحظة: لا يستخدم الطراز 827 نفس مصدر الطاقة الذي تستخدمه الموجهات الأخرى من السلسلة 800.
لتحديد ما إذا كان لديك وحدة تزويد بالطاقة صحيحة، ابحث في مؤخرة مهايئ الطاقة عن خرج +12 فولت 0.1 أمبير و -12 فولت 0.1 أمبير و +5 فولت 3 أمبير و -24 فولت 0.12 أمبير و -71 فولت 0.12 أمبير. إذا كان مصدر الطاقة لديك يفتقد موجز ويب +12V و -12V، فإنه يكون لموجه مختلف من سلسلة Cisco 800 ولا يعمل على السلسلة 827. لاحظ أنه إذا كنت تستخدم مصدر الطاقة غير الصحيح، فإن المحول Cisco 827 يعمل بكفاءة ولكنه غير قادر على التدريب (الاتصال) على ISP DSLAM.
هل وضع تشغيل DSL صحيح؟
إذا كان كل ما يصل إلى هذه النقطة في إجراء أستكشاف الأخطاء وإصلاحها من الطبقة 1 صحيحا، فإن الخطوة التالية هي التأكد من توفر وضع التشغيل DSL الصحيح لديك. توصي Cisco باستخدام وضع التشغيل التلقائي ل DSL إذا لم تكن متأكدا من تقنية DMT التي يستخدمها مزود خدمة الإنترنت (ISP) لديك. هذه هي الأوامر لتكوين الكشف التلقائي لوضع التشغيل:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface atm 0 Router(config-if)#dsl operating-mode auto Router(config-if)#end Router#write memory
هل تم إختبار الدائرة/إمدادها بشكل صحيح؟
احصل على هذه المعلومات من مزود خدمة الإنترنت (ISP) أو شركة الهاتف.
مشاكل الطبقة 2
هل لديك قيم PVC الصحيحة (VPI/VCI)؟
باستخدام نشر بروتوكول PPPoE، لا توجد طريقة سهلة لاكتشاف قيم معرف المسار الظاهري/معرف القناة الظاهرية (VPI/VCI) للدائرة الافتراضية الدائمة (PVC) بشكل ديناميكي. اتصل ب ISP الخاص بك إذا لم تكن متأكدا من قيم PVC الخاصة بك.
هل تتلقى بيانات من مزود خدمة الإنترنت (ISP) لديك؟
إذا كانت لديك قيم PVC الصحيحة، فإن الخطوة التالية هي التحقق من أنك تحاول التفاوض حول PPP باستخدام ISP الخاص بك. للقيام بذلك، قم بإصدار الأمر show interface atm0 وحدد حزم الإدخال والإخراج.
Router#show interface atm0 ATM0 is up, line protocol is up Hardware is DSLSAR (with Alcatel ADSL Module) MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5, PVC mode 24 maximum active VCs, 256 VCS per VP, 1 current VCCs VC idle disconnect time: 300 seconds Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 5 bits/sec, 0 packets/sec 5 minute output rate 7 bits/sec, 0 packets/sec 100 packets input, 5600 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 250 packets output, 1400 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 output buffer failures, 0 output buffers swapped out
إذا كانت عدادات حزم الإدخال تتزايد، فيجب أن تتلقى حزم تفاوض PPPoE من ISP لديك. إذا لم يكن هذا هو الحال، فاتصل بموفر خدمة الإنترنت (ISP) لديك.
إذا كانت العدادات المرتبطة بالإخراج في تزايد، فيجب أن تقوم بإرسال حزم تفاوض PPPoE. إذا لم تكن هذه هي الحالة، فتحقق من التكوين على الموجه. إذا تم تكوين PPP بشكل صحيح، يتم إرسال حزم تفاوض PPP باستمرار من واجهة ATM0.
إذا كانت الحزم تزيد في الإتجاه الصادر فقط، فاستمر في خطوات أستكشاف الأخطاء وإصلاحها في هذا المستند.
هل تم تشغيل جلسة PPPoE؟
يتم تنفيذ PPPoE على مرحلتين. المرحلة الأولى هي إنشاء جلسة عمل تعادل القوة الشرائية عبر شبكة إيثرنت، والمرحلة الثانية هي التفاوض بشأن تعادل القوة الشرائية. يجب إنشاء PPPoE قبل التفاوض على معلمات PPP القياسية. أسهل طريقة لتحديد ما إذا كانت لديك جلسة PPPoE نشطة هي إصدار الأمر show vpdn.
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels %No active PPTP tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 0 0000.0000.0000 0000.0000.0000 UNKN ATM0 8/35
في هذا المثال، لا توجد جلسات عمل PPPoE نشطة. ويشار إلى ذلك بواسطة معرف أمان (SID) من 0، وRemMAC و LocMAC من 0000.0000.000. إذا كنت في هذه الحالة، فقم بالمتابعة إلى القسم التالي.
تبدو جلسة عمل PPPoE التي تم التفاوض عليها بنجاح كما يلي:
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 1 0050.7359.35b7 0001.96a4.84ac Vi1 UP ATM0 8/35
في هذا المثال، يمكنك أن ترى أن SID هو رقم غير صفري، وأن كل من RemMAC وLocMAC يتم تعبئتهما. والمجال الآخر للمصلحة هو Wide، الذي يشير إلى ما إذا كان قد تم التفاوض بشأن تعادل القوة الشرائية بنجاح والتصديق عليه. إذا كان Wide UP، فإن PPP قد تم التفاوض عليه بنجاح والمصادقة عليه، ويمكنك المتابعة إلى قسم لماذا يمكنني الوصول إلى بعض صفحات الويب باستخدام PPPoE دون أخرى؟ في هذا المستند. إذا كانت مساحة Wide منخفضة، فاستمر في القسم التالي.
هل تتلقى إستجابة PPPoE من موجه التجميع؟
إذا لم يتم إنشاء جلسة عمل PPPoE نشطة، فأنت بحاجة إلى إصدار الأمر debug vpdn pppE-events لتحديد ما لا ينتج PPPoE.
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:49:38.030: padi timer expired *Mar 3 21:50:10.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: padi timer expired *Mar 3 21:50:42.030: Sending PADI: vc=8/35 *Mar 3 21:50:42.030: padi timer expired *Mar 3 21:51:14.030: Sending PADI: vc=8/35 *Mar 3 21:51:14.030: padi timer expired *Mar 3 21:51:46.030: Sending PADI: vc=8/35 *Mar 3 21:51:46.030: padi timer expired Router#undebug all
في هذا المثال، يرسل موجه DSL من Cisco باستمرار إطارات بدء الاكتشاف النشط ل PPPoE (PADI) إلى ISP بدون إستجابة. إطار PADI هو الأول في سلسلة من إطارات إعداد المكالمات عبر بروتوكول PPPoE. إذا لم يستجب مزود خدمة الإنترنت (ISP) الخاص بك مع عرض الاكتشاف النشط (PADO) الخاص ب PPPoE، فإن تفاوض PPPoE لا ينجح. الحل الوحيد لهذه المشكلة هو الاتصال ب ISP.
إذا قمت بالتفاوض بنجاح مع PPPoE، فإن إخراج VPDN PPPoE-events الخاص بك يبدو مثل هذا الإخراج:
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off *Mar 3 21:50:35.030: OUT PADR from PPPoE tunnel *Mar 3 21:50:50.030: IN PADS from PPPoE tunnel Router#undebug all
إذا تم التفاوض على PPPoE بنجاح، فتابع القسم التالي حول أستكشاف أخطاء PPP وإصلاحها.
ترى هل يتفاوض بروتوكول الاتصال من نقطة إلى نقطة على النحو اللائق؟
إذا كانت الطبقة 1 قيد التشغيل وكان لديك معرف فئة المورد (VPI)/معرف فئة المورد (VCI) الصحيح، فإن الخطوة التالية هي التأكد من ظهور بروتوكول النقطة إلى النقطة (PPP) بشكل صحيح. ومن أجل تحقيق ذلك، يلزمك تشغيل سلسلة من أوامر تصحيح الأخطاء على الموجه Cisco DSL وتفسير الإخراج. تصحيح الأخطاء الأساسي الذي تستخدمه هو تفاوض PPP debug. هذا المخرج من الأمر هو مثال على تفاوض PPP الناجح:
Router#debug ppp negotiation PPP protocol negotiation debugging is on Router# 2w3d: Vi1 PPP: No remote authentication for call-out 2w3d: Vi1 PPP: Phase is ESTABLISHING 2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10 2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E) 2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15 2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A) 2w3d: Di1 IPCP: Remove route to 20.20.2.1 2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10 2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E) 2w3d: Vi1 LCP: State is Open 2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer 2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2" 2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John" 2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4 2w3d: Vi1 PPP: Phase is UP 2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10 2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) 2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10 2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201) 2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10 2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201) 2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: State is Open 2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2 2w3d: Di1 IPCP: Install route to 20.20.2.1 Router#
هناك أربع نقاط فشل رئيسية في مفاوضات تعادل القوة الشرائية:
-
لا توجد إستجابة من الجهاز البعيد (ISP)
-
بروتوكول التحكم في الارتباط (LCP) غير مفتوح
-
فشل المصادقة
-
فشل بروتوكول التحكم في بروتوكول IP (IPCP)
لا توجد إستجابة من مزود خدمة الإنترنت (ISP) لديك
لا يجب أن يكون ISP الخاص بك الذي لا يستجيب مشكلة نظرا لأنك تحققت بالفعل من زيادة الحزم على واجهة ATM0 في الإتجاه الوارد. ومع ذلك، إذا رأيت الحزم تتزايد على ATM0 في الإتجاه الوارد، وعندما تقوم بتشغيل تفاوض PPP تصحيح الأخطاء تتلقى هذا الإخراج، اتصل ب ISP للتحقق من إرسال الحزم إلى موجه DSL من Cisco.
Router#debug ppp negotiation *Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout *Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] *Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out *Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 *Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10 *Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10 *Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10 *Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) Router#undebug all
في هذا المخرج هناك فقط o ربط، أي يكون ربط خارج. in order to بنجاح تفاوضت PPP، هناك ينبغي كنت i داخل ربط من ك isp ل كل o ربط يرسل. إذا كانت الحزم تزيد من الوارد لكنك لا ترى i packet، فاتصل ب ISP الخاص بك للتحقق من الحزم التي يتم إرسالها إلى موجه DSL من Cisco.
LCP غير مفتوح
ال LCP ليس مفتوح عادة بسبب حالة عدم توافق في خيار PPP. يحدث عدم التطابق هذا عندما يحتوي موجه DSL من Cisco على معلمة PPP تم تكوينها بحيث لا يدعم ISP الخاص بك، أو عندما يحتوي ISP لديك على معلمة تم تكوينها بحيث لا يدعمها موجه DSL من Cisco. يعرض هذا الإخراج مثالا على عدم تطابق خيار PPP:
Router#debug ppp negotiation *Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout *Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out *Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808) *Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14 *Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) *Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9 !--- PPP option reject *Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- PPP option that is rejected *Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10 *Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808) *Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14 *Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) *Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 !--- PPP option reject *Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- PPP option that is rejected *Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14 *Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) Router#undebug all
سواء كانت حزمة I أو O، فإن configure-negative-Acknowledge (CONFNAK) يشير إلى عدم تطابق تكوين PPP. وهذا يعني أن أحد جانبي اتصال PPP يطلب خيار PPP يتعذر على الجانب الآخر أو لم يتم تكوينه لتنفيذه. إذا قام موجه DSL من Cisco بإرسال CONFNAK (المشار إليه بواسطة O CONFNAK)، فإن موجه DSL من Cisco غير قادر على الأداء أو لم يتم تكوينه للخيار الذي يرسله ISP. إذا تم إرسال CONFNAK بواسطة ISP لديك (المشار إليها بواسطة i confnak)، فقد قمت بتكوين خيار على موجه Cisco DSL لا يكون ISP لديك راغبا في تنفيذه.
يصف السطر بعد CONFNAK الخيار المرفوض. في هذا المثال إخراج الإخراج، يكون الخيار هو CHAP ولكنه قد يكون أي خيار. المكان الوحيد على موجه Cisco DSL الذي يمكن تكوين خيارات PPP فيه هو طالب الواجهة 1. قم بإصدار الأمر show run interface dialer 1 لعرض تكوين طالب الواجهة 1 الخاص بك.
إذا كان مزود خدمة الإنترنت (ISP) الخاص بك يرسل الأمر i confnak، فابحث عن أوامر تحت متصل الواجهة 1 التي تطابق السطر بعد الارتباط وإزالتها. إذا قام موجه DSL من Cisco بإرسال الأمر o confnak، فقم بإضافة أمر إلى متصل الواجهة 1 للتفاوض مع PPP بشكل صحيح مع ISP لديك. في حالة إرسال الموجه للحزم، قد تحتاج إلى إستدعاء Cisco TAC لتحديد الأمر (الأوامر) التي يجب تمكينها على موجه Cisco DSL.
فشل المصادقة
يحدث فشل في المصادقة عندما يكون مزود خدمة الإنترنت (ISP) لديك غير قادر على مصادقة اسم مستخدم أو كلمة مرور PPP لديك. وهناك سيناريوهان حيث يمكن أن يحدث هذا. السيناريو الأول هو عدم تطابق نوع المصادقة، والذي يحدث عندما لا تقوم بتكوين الموجه بشكل صحيح. تمثل جميع تكوينات المصادقة المدرجة في هذا المستند كلا من أنواع مصادقة PAP و CHAP. لمرونة التكوين، يجب تكوين بروتوكول CHAP وبروتوكول PAP معا. إذا لم يتم تكوين كليهما، فقد ترى المخرجات من أمر debug ppp مثل هذا الإخراج:
Router#debug ppp negotiation 00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- Sends CHAP requests 00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483) 00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14 00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023) !--- Receives PAP requests from the service provider 00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9) 00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8 Router#undebug all
أو
Router#debug ppp negotiation 00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15 00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- Receives CHAP requests from the service provider 00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC) 00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14 00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) !--- Sends out PAP requests Router#undebug all !--- Turn off ppp debug
لتصحيح كلا مشكلتي عدم تطابق المصادقة، ارجع إلى تكوين خيار تنفيذ PPPoA المناسب وأعد تكوين مصادقة PPP.
سيناريو مشكلة المصادقة الثاني الذي يمكنك مواجهته هو اسم مستخدم PAP أو كلمة مرور غير صحيحين. أصدرت in order to حددت إن يكون هذا هو المشكلة، الأمر debug ppp تفاوض. بافتراض تكوين الموجه لديك لكل من بروتوكول المصادقة لتأكيد الاتصال بقيمة التحدي (CHAP) وبروتوكول مصادقة كلمة المرور (PAP)، كما يوضح التكوين الموضح مسبقا في هذا الدليل، فقد لا يستخدم ISP الخاص بك مصادقة PAP.
لتحديد المصادقة المستخدمة من قبل مزود خدمة الإنترنت (ISP) لديك، تحقق من الخيارات الموجودة في حزمة i confreq المرسلة إليك من مزود خدمة الإنترنت (ISP) لديك. إذا تم اتباع هذه الحزمة بخيار يسمى AuthProto PAP، فأنت تستخدم PAP. إذا تم اتباع I CONFREQ بخيار يسمى AuthProto CHAP، فأنت تستخدم CHAP ويجب أن تنتقل إلى كيف أعرف ما إذا كان اسم مستخدم وكلمة مرور CHAP صحيحين؟
كيف يمكنني معرفة ما إذا كان اسم مستخدم وكلمة مرور PAP صحيحة؟
بعد التأكد من إستخدام ISP الخاص بك، قم بإصدار الأمر debug ppp negotiation لتأكيد صحة اسم مستخدم وكلمة مرور PAP.
Router#debug ppp negotiation *Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout *Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out *Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10 *Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F) *Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10 *Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F) *Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14 *Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E) *Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14 *Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E) *Mar 2 00:50:17.249: Vi1 LCP: State is Open *Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" !--- "cisco" is the PAP username configured on this DSL router. *Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure" *Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4 *Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4 *Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u *Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent *Mar 2 00:50:19.305: Vi1 LCP: State is Closed *Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
إن يتلقى أنت PAP صحة هوية مشكلة، أنت ينبغي رأيت ال LCP دولة يذهب إلى فتح. مباشرة بعد تغيير حالة LCP، يجب أن ترى PPP يدخل مرحلة المصادقة. إذا احتوى أحد الأسطر التالية على I AUTH-NAK، إما أن اسم مستخدم PAP أو كلمة مرور PAP غير صحيحة. عند هذه النقطة، تحتاج إلى إعادة تكوين اسم مستخدم وكلمة مرور PAP باستخدام هذا التسلسل من الأوامر. لاحظ أن اسم مستخدم وكلمة مرور PAP متحسسان لحالة الأحرف.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username
password
Router(config-if)#end
Router#write memory
كيف يمكنني معرفة ما إذا كان اسم مستخدم وكلمة مرور CHAP صحيحين؟
بعد التأكد من أن مزود خدمة الإنترنت (ISP) لديك يستخدم بروتوكول CHAP، قم بإصدار الأمر debug ppp negotiation لتأكيد صحة اسم مستخدم وكلمة مرور CHAP.
Router#debug ppp negotiation *Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout *Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out *Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10 *Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1) *Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15 *Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393) *Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15 *Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393) *Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10 *Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1) *Mar 3 02:51:47.351: Vi1 LCP: State is Open *Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3" *Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco *Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found *Mar 3 02:51:47.399: Vi1 CHAP: Using default password *Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco" !--- "cisco" is the CHAP username configured on this DSL router. *Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure" *Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4 *Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4 *Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load] *Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent *Mar 3 02:51:49.451: Vi1 LCP: State is Closed *Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load] Router#undebug all
إذا كانت لديك مشكلة في مصادقة CHAP، فيجب أن ترى حالة LCP انتقل إلى فتح. مباشرة بعد تغيير حالة LCP، يجب أن ترى PPP يدخل مرحلة المصادقة. من هذه النقطة ترى سلسلة من خطوط CHAP. إذا كان آخر هذه الأسطر يظهر أنا فشل، فلديك اسم مستخدم وكلمة مرور CHAP غير صحيحين. أستخدم هذا التسلسل من الأوامر لتصحيح اسم مستخدم وكلمة مرور CHAP الخاصين بك. لاحظ أن اسم المستخدم وكلمة المرور متحسسان لحالة الأحرف.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname
كيف أعرف متى تكون مصادقة PPP ناجحة؟
يوضح هذا المثال تفاوض CHAP بنجاح.
Router#debug ppp negotiation <... snipped ...> *Mar 3 03:30:09.335: Vi1 LCP: State is Open *Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3" *Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco *Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found *Mar 3 03:30:09.383: Vi1 CHAP: Using default password *Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco" *Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4 !--- CHAP negotiation was a success. *Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] <... snipped ...> Router#undebug all
يوضح هذا المثال تفاوض PAP بنجاح.
Router#debug ppp negotiation <... snipped ...> *Mar 3 03:33:19.491: Vi1 LCP: State is Open *Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load] *Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco" *Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5 *Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] !--- PAP negotiation was a success. <... snipped ...> Router#undebug all
لماذا يمكنني الوصول إلى بعض صفحات الويب باستخدام PPPoE وليس مع صفحات أخرى؟
يعد الوصول إلى بعض صفحات الويب فقط مشكلة شائعة عند تشغيل عميل PPPoE على موجه. ومن خلال التصميم، يمكن أن يدعم بروتوكول النقطة إلى النقطة عبر شبكة إيثرنت (PPPoE) وحدة الحد الأقصى للإرسال (MTU) تصل إلى 1492 بايت. لذلك، يجب التأكد من أن الأجهزة الطرفية تقوم بإرسال إطارات لا تزيد عن 1492 بايت. قد يكون تحديد وحدة الحد الأقصى للإرسال (MTU) ب 1492 بايت مشكلة لأن معظم محطات العمل الخاصة بالأجهزة الشخصية والمستخدمين النهائيين تحتوي على وحدة الحد الأقصى للإرسال (MTU) افتراضية تبلغ 1500 بايت.
هناك خياران لضبط حجم وحدة الحد الأقصى للنقل (MTU): ضبط حجم وحدة الحد الأقصى للنقل (MTU) في الموجه وضبط حجم وحدة الحد الأقصى للنقل (MTU) في الكمبيوتر.
ضبط حجم PPPoE MTU على موجه DSL من Cisco
ملاحظات هامة:
تعمل أوامر التكوين هذه فقط إذا قمت بتشغيل ترجمة عنوان الشبكة (NAT) أو ترجمة عنوان المنفذ (PAT) على موجه DSL من Cisco.
تم تغيير الأمر ip adjust-mss في الإصدار 12.2(2)XH من برنامج Cisco IOS® إلى ip tcp adjust-mss <mss value>. وثقت هذا تغير في إطلاق بطاقة ل ال cisco 800 sery مسحاج تخديد و cisco 820 sery مسحاج تخديد ل cisco ios إطلاق 12.2(2)xh.
!
vpdn enable
no vpdn logging
!
vpdn-group pppoe
request-dialin
protocol pppoe
!
interface ethernet0
no shut
ip address <ip address> <subnet mask>
ip adjust-mss 1452
!--- The TCP MSS command requires an MSS of 1452, not 1492.
ip nat inside
no ip directed-broadcast
!
interface atm0
no shut
no ip address
no ip directed-broadcast
no atm ilmi-keepalive
bundle-enable
!
interface atm0.1 point-to-point
no ip directed-broadcast
pvc <vpi/vci>
pppoe-client dial-pool-number 1
!
!
interface dialer1
ip address negotiated
mtu 1492
ip nat outside
encapsulation ppp
dialer pool 1
ppp chap hostname <username>
ppp chap password <password>
ppp pap sent-username <username> password <password>
!
ip nat inside source list 1 interface dialer1 overload
!
ip classless
ip route 0.0.0.0 0.0.0.0 dialer1
access-list 1 permit
0.0.255.255
!
ضبط حجم PPPoE MTU على الكمبيوتر باستخدام الأداة المساعدة DR TCP
أتمت هذا steps in order to غيرت ال MTU حجم على pc. يتم حفظ تغيير السجل عند انتهاء الإجراء.
ملاحظة: تتوافق الأداة المساعدة DR TCP مع جميع أجهزة الكمبيوتر القائمة على Windows.
-
قم بتنزيل أحدث إصدار من الأداة المساعدة DR TCP
. -
قم بتحديث صفحة المستعرض للتأكد من أن الصفحة حديثة.
-
قم بتشغيل الأداة المساعدة DR.TCP.
-
من القائمة أختر مهايئ Ethernet.
-
في حقل وحدة الحد الأقصى للنقل (MTU)، اكتب 1492.
-
انقر فوق تطبيق لحفظ التغيير، ثم انقر فوق إنهاء.
-
أعد تمهيد عميل PPPoE للكمبيوتر الشخصي.
.تحتاج إلى تشغيل الأداة المساعدة مرة واحدة فقط لكل جهاز كمبيوتر عميل PPPoE.
خطوات أستكشاف أخطاء وحدة الحد الأقصى للنقل (MTU) وإصلاحها الإضافية
إذا قمت بتغيير حجم وحدة الحد الأقصى للنقل (MTU) باستخدام DR TCP أو على موجه DSL من Cisco ولا تزال غير قادرة على إستعراض مواقع ويب معينة، فقم بضبط حجم وحدة الحد الأقصى للنقل (MTU) مرة أخرى. قم بتغيير حجم وحدة الحد الأقصى للنقل (MTU) إلى 1452 في DR TCP، أو قم بتغيير قيمة ضبط MSS على موجه DSL من Cisco إلى 1412. إذا كانت هذه الأحجام كبيرة جدا، فاستمر في تقليل أحجام MTU حتى تصل إلى خط أساس مقداره 1400 للبروتوكول DR TCP أو 1360 للضبط عبر MSS على موجه DSL من Cisco.
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
08-Oct-2006 |
الإصدار الأولي |
التعليقات