فهم إخراج تفاوض تصحيح أخطاء PPP

المقدمة

في التطبيقات المتعلقة بالطلب، يكون PPP هو نوع التضمين الأكثر إستخداما. يسمح بروتوكول الاتصال من نقطة إلى نقطة (PPP) لجهازين على إرتباط اتصال من نقطة إلى نقطة بالتفاوض على معلمات مختلفة للمصادقة والضغط وبروتوكولات الطبقة 3 (L3)، مثل IP. يؤدي فشل تفاوض PPP بين موجهين إلى فشل الاتصال.

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

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

المتطلبات

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

• يجب تمكين PPP على الواجهات على كلا الموجهين. قم بإصدار الأمر encapsulation ppp لتنفيذ ذلك.

• قم بإصدار هذا الأمر لتمكين الطوابع الزمنية بالمللي ثانية على الموجه:

  Router(config)# service timestamp debug datetime msec
  

  للحصول على مزيد من المعلومات حول أوامر التصحيح، راجع المعلومات المهمة حول أوامر التصحيح.

ملاحظة: لا يمكن بدء تفاوض PPP بين نظارين ما لم تكن الطبقة الأدنى (ISDN، الواجهة المادية، خط الطلب، وما إلى ذلك) تحت وظائف PPP بشكل كامل. على سبيل المثال، إذا كنت تريد تشغيل PPP عبر ISDN، فيجب أن تكون جميع طبقات ISDN نشطة؛ وإلا فإن PPP لا تبدأ.

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

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

الاصطلاحات

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

مراحل التفاوض على بروتوكول الاتصال من نقطة إلى نقطة

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

*Mar  3 23:32:50.296: BR0:1 PPP: Phase is DOWN

*Mar  3 23:32:06.884: BR0:1 PPP: Phase is ESTABLISHING

*Mar 3 23:32:06.952: BR0:1 PPP: Phase is AUTHENTICATING

*Mar  3 23:42:53.412: BR0:1 PPP: Phase is UP

*Mar  3 23:43:23.256: BR0:1 PPP: Phase is TERMINATING

^{1. LCP = بروتوكول التحكم في الارتباط}

^{2. CHAP = بروتوكول المصادقة لتأكيد الاتصال بقيمة التحدي}

^{3. PAP = بروتوكول مصادقة كلمة المرور}

^{4. NCP = بروتوكول التحكم في الشبكة}

يوضح هذا المخطط عمليات انتقال مرحلة PPP:

حزم تفاوض PPP: وصف

يتضمن هذا الجدول وصف حزم تفاوض PPP التي يتم إستخدامها في كل من تفاوض LCP و NCP:

^{1. NAK = الاعتراف السلبي}

^{2. ACK = الاعتراف}

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

بروتوكول LCP والمصادقة ومرحلة NCP

وضمن بعض مراحل بروتوكول الاتصال من نقطة إلى نقطة (PPP) الموضحة سابقا، يدخل بروتوكول الاتصال من نقطة إلى نقطة أيضا مراحل محددة مثل تفاوض بروتوكول LCP والمصادقة ومفاوضات بروتوكول NCP. لمزيد من المعلومات، ارجع إلى RFC 1548 وRFC 1661 .

LCP (مرحلة إلزامية)

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

يوضح هذا المخطط طريقة عرض مفاهيمية لمصافحة LCP:

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

المصادقة (المرحلة الاختيارية بشكل افتراضي)

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

للحصول على معلومات CHAP ذات الصلة، ارجع إلى فهم مصادقة PPP CHAP وتكوينها.

ملاحظة: المصادقة إختيارية و PPP لا يدخل هذه المرحلة إلا إذا أحتاج إلى المصادقة.

NCP (مرحلة إلزامية)

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

يقول RFC 1332 إن بروتوكول IPCP يتفاوض على خيارين: الضغط وتعيينات عناوين IP. ومع ذلك، يتم إستخدام IPCP أيضا لتمرير المعلومات ذات الصلة بالشبكة مثل خوادم نظام اسم Windows (WINS) الأساسية والنسخ الاحتياطي ونظام اسم المجال (DNS).

يتم التفاوض باستخدام رسائل CONF، كما هو موضح في حزم تفاوض PPP: قسم وصف في هذا المستند.

أستكشاف الأخطاء وإصلاحها مع إخراج تفاوض PPP الخاص بتصحيح الأخطاء

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

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

2. بالنسبة للمرحلة التي حدث فيها الفشل، ابحث عن الرسائل التي تشير إلى نجاح بروتوكول LCP أو المصادقة أو بروتوكول NCP (حسب الاقتضاء):

   • يجب أن تكون حالة LCP مفتوحة. يمكنك أيضا النظر إلى رسائل CONFACK الأخيرة الصادرة والواردة للتحقق من أنه تم التفاوض بشأن المعلمات المطلوبة.

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

   • يجب أن تكون حالة IPCP مفتوحة. تحقق من صحة العنونة ومن تثبيت مسار إلى النظير.

إخراج تفاوض PPP للقراءة تصحيح الأخطاء

تتميز معظم الخطوط في إخراج أمر تفاوض ppp ل تصحيح الأخطاء ب:

1. الطابع الزمني- المللي ثانية تكون الطوابع الزمنية مفيدة. راجع قسم المتطلبات الأساسية لهذا المستند للحصول على مزيد من المعلومات.

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

3. نوع رسالة PPP—يشير هذا الحقل إلى ما إذا كان السطر رسالة PPP أو LCP أو CHAP أو PAP أو IPCP عامة.

4. إتجاه الرسالة— يشير I إلى حزمة واردة، ويشيرO إلى حزمة صادرة. يمكن إستخدام هذا الحقل لتحديد ما إذا كان قد تم إنشاء الرسالة أو استقبالها بواسطة الموجه.

5. الرسالة — يتضمن هذا الحقل الحركة المعينة قيد التفاوض.

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

7. الطول— يحدد حقل الطول طول حقل المعلومات. هذا الحقل غير مهم لاستكشاف الأخطاء العامة وإصلاحها.

ملاحظة: قد لا تظهر الحقول من 4 إلى 7 في جميع رسائل PPP، وفقا للغرض من الرسالة.

ملاحظة: يوضح هذا المثال الحقول:

إخراج تفاوض PPP الخاص بتصحيح الأخطاء للعينة

هذا وصف مشروح لمخرج الأمر debug ppp negotiation:

maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar  1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

!--- The Physical Layer (BRI Interface) is up. Only now can PPP !--- negotiation begin.

*Mar  1 00:06:36.661: BR0:1 PPP: Treating connection as a callin
*Mar  1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 
[0 sess, 0 load]

!--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.

*Mar  1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar  1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17

!--- This is the incoming CONFREQ. The ID field is 7.

*Mar  1 00:06:37.038: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.) !--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback uses 6.)

*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

!--- This is an outgoing CONFREQ, with parameters for the peer to implement. !--- Note that the ID Field is 4, so this is not related to the previous !--- CONFREQ message.

*Mar  1 00:06:37.058: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.062: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- This router requests: !--- Option: Authentication Protocol, Value: CHAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

!--- This is an outgoing CONFREJ for message with Field ID 7. !--- This is the response to the CONFREQ received first.

*Mar  1 00:06:37.070: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The option that this router rejects is Callback. !--- If the router wanted to do MS Callback rather than PPP Callback, it !--- would have sent a CONFNAK message instead.

*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

!--- This is an incoming CONFACK for a message with Field ID 4.

*Mar  1 00:06:37.102: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.106: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- The peer can support all requested parameters.

*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

!--- This is an incoming CONFREQ message; the ID field is 8. !--- This is a new CONFREQ message from the peer in response to the CONFREJ id:7.

*Mar  1 00:06:37.117: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

!--- This is an outgoing CONFNACK for a message with Field ID 8.

*Mar  1 00:06:37.129: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

!--- This router recognizes the option Authentication Protocol, !--- but does not accept the value PAP. In the CONFNAK message, !--- it suggests CHAP instead.

*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

!--- This is an incoming CONFREQ message with Field ID 9.

*Mar  1 00:06:37.169: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- CHAP authentication is requested.

*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

!--- This is an outgoing CONFACK for a message with Field ID 9.

*Mar  1 00:06:37.181: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.185: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.189: BR0:1 LCP: State is Open

!--- This indicates that the LCP state is Open.

*Mar  1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]

!--- The PPP Phase is AUTHENTICATING. PPP Authentication occurs now. !--- Two-way authentication is now performed (indicated by the both keyword).

*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

!--- This is the outgoing CHAP Challenge. !--- In LCP the routers had agreed upon CHAP as the authentication protocol.

*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

!--- This is an incoming Challenge message from the peer.

*Mar  1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first
*Mar  1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"

!--- This is an incoming response from the peer.

*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

!--- This router has successfully authenticated the peer.

*Mar  1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3
*Mar  1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar  1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4

!--- This is an incoming Success message. Each side has !--- successfully authenticated the other.

*Mar  1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]

!--- The PPP status is now UP. NCP (IPCP) negotiation begins.

*Mar  1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
*Mar  1 00:06:37.308: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)

!--- This is an outgoing CONFREQ message. It indicates that !--- the local machine address is 172.22.1.1.

*Mar  1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
*Mar  1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar  1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4

!--- These messages are for CDP Control Protocol (CDPCP).

*Mar  1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
*Mar  1 00:06:37.336: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)

!--- This is an incoming CONFREQ message that indicates that the peer !--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer !--- does not have an address and requests the local router to provide it !--- with an address in IPCP negotiation.

*Mar  1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
*Mar  1 00:06:37.348: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)
*Mar  1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.360: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)
*Mar  1 00:06:37.363: BR0:1 IPCP: State is Open

!--- The IPCP state is Open. Note that in the IPCP negotiation, each side !--- accepted the IP address of the peer, and one was assigned to the peer.

*Mar  1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
*Mar  1 00:06:37.375: BR0:1 CDPCP: State is Open

!--- This indicates that the CDPCP state is Open.

*Mar  1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2

!--- A route to the peer is installed.

*Mar  1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
 changed state to up
*Mar  1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
 maui-soho-03

المسرد والرسائل المشتركة

عام

CONFREQ (configure-request):

عندما تصبح الطبقة السفلى متوفرة (لأعلى)، يتم إرسال CONFREQ لبدء المرحلة الأولى من PPP (مرحلة LCP). ويتم إستخدامه في مرحلتي LCP و NCP كمحاولة لتكوين الاتصال. لفتح اتصال بالنظير، يرسل الجهاز هذه الرسالة مع خيارات التكوين والقيم التي يتمنى المرسل أن يدعمها النظير. يتم التفاوض على جميع الخيارات والقيم في آن واحد. إذا استجاب النظير برسالة CONFREJ أو CONFNAK، يرسل الموجه حينئذ CONFREQ آخر مع مجموعة أخرى من الخيارات أو القيم.

CONFACK (configure-acknowledge):

إذا كانت جميع الخيارات في رسالة CONFREQ قابلة للتعرف عليها وكانت جميع القيم مقبولة، فعندئذ يرسل الموجه رسالة CONFACK.

CONFREJ (تكوين الرفض):

إذا كان أحد خيارات التكوين التي تم تلقيها في CONFREQ غير مقبول أو غير قابل للتعرف عليه، فإن الموجه يستجيب مع رسالة CONFREJ. أما الخيار غير المقبول (من المجلس الوطني لشؤون اللاجئين) فهو وارد في رسالة المجلس الوطني لشؤون اللاجئين.

CONFNAK (تكوين الإقرار السالب):

إذا كان خيار التكوين المستلم قابلا للتعرف عليه ومقبولا، ولكن بعض القيم غير مقبولة، يرسل الموجه رسالة تكوين. يقوم الموجه بإلحاق الخيار والقيمة التي يمكنه قبولها في رسالة CONFNAK حتى يمكن للنظير تضمين هذا الخيار في رسالة CONFREQ التالية.

ECHOreq (طلب صدى) و ECHOrep (رد صدى):

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

TERMREQ (طلب الإنهاء):

يشير هذا الإطار إلى أن نظير PPP الذي أرسل هذا الإطار ينهي اتصال PPP.

تيرماك (الاعتراف بإنهاء العقد):

يتم إرسال هذه الرسالة إستجابة لرسالة TERMREQ. يؤدي هذا إلى إغلاق اتصال PPP.

إنتهاء

تشير هذه الرسالة إلى انقطاع اتصال PPP. يمكن قطع اتصال LCP أو NCP:

• على الإغلاق الإداري (LCP فقط).

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

• عندما تخفق المفاوضات.

• اكتشاف حلقة الخط.

LCP

ACCM (خريطة أحرف التحكم غير المتزامن):

هذا أحد خيارات تفاوض LCP ضمن إطار CONFREQ. يضبط ACCM تسلسلات هروب الحرف. ACCM يقول للمنفذ أن يتجاهل حروف التحكم المحددة ضمن تدفق البيانات. إن لا يساند المسحاج تخديد على الآخر نهاية من التوصيل تفاوض ACM، الميناء يجبر أن يستعمل FFFFFF. في تلك الحالة، أصدرت هذا أمر:

ppp accm match 000a000

ACFC (ضغط حقل التحكم والعنوان):

ACFC هو خيار بروتوكول LCP يسمح لنقاط النهاية بإرسال الرسائل ذهابا وإيابا بكفاءة أكبر.

AuthProto (بروتوكول المصادقة):

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

رد الاتصال "#":

تشير هذه الرسالة إلى أن خيار رد الاتصال قيد التفاوض. يشير الرقم بعد بناء جملة رد الاتصال إلى خيار رد الاتصال الذي تم التفاوض عليه. الرقم 0 هو رد اتصال PPP عادي، بينما يشير الرقم 6 إلى خيار رد اتصال Microsoft (والذي يتوفر تلقائيا في الإصدار 11.3(2)T من برنامج Cisco IOS® Software أو إصدار أحدث).

CHAP (بروتوكول مصادقة مصافحة الاستبيان):

تشير هذه الرسالة إلى أن بروتوكول المصادقة قيد التفاوض هو CHAP.

EndpointDisc (مميز نقطة النهاية):

هذا خيار LCP يستخدم لتعريف نظير PPP في اتصال PPP متعدد الارتباطات. لمزيد من المعلومات، ارجع إلى المعايير الخاصة بتسمية حزم PPP متعددة الارتباطات.

LCP: الحالة مفتوحة

تشير هذه الرسالة إلى أنه تم إكمال تفاوض LCP بنجاح.

LQM (مراقبة جودة الارتباط)

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

عند تمكين LQM، يتم إرسال تقارير جودة الارتباط (LQRs) في كل فترة keepalive. يتم إرسال LQRs بدلا من رسائل keepalives. تتم الاستجابة لجميع رسائل تنشيط الاتصال الواردة بشكل صحيح. إذا لم يتم تكوين LQM، يتم إرسال رسائل keepalives كل فترة keepalive، ويتم الاستجابة لجميع قوائم التحكم في الوصول (LQR) الواردة باستخدام LQR.

عدد سحري

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

قد يتم إزالة الارتباط أو لا يتم على اكتشاف تكرار حلقي، وهو يعتمد على إستخدام الأمر down-when-looped.

PAP (بروتوكول مصادقة كلمة المرور)

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

PFC (ضغط حقل البروتوكول)

يقوم هذا الخيار بتشغيل الضغط لحقول البروتوكول إما في حالة التشغيل أو في حالة الإيقاف.

MRU (وحدة الاستقبال الأقصى المعاد بناؤها)

هذا خيار LCP تفاوض في عملية إعداد PPP Multilink LCP. يحدد هذا الخيار الحد الأقصى لعدد وحدات البايت التي يمكن أن تشكل إطارا. إذا لم يتم التفاوض على MRU في LCP، فلا يمكن تشغيل Multilink PPP (MPPP) على الارتباط.

MRU (الحد الأقصى للوحدة المستلمة)

MRU هو خيار LCP يتم التفاوض عليه في إطار CONFREQ للتفاوض على حجم الحزم المتبادلة.

المصادقة

AUTH-REQ (طلب مصادقة)

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

Auth-ACK (إقرار المصادقة)

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

Auth-Nak أو الفشل

يتم إرسال هذا الإطار من نظير PPP المصدق عند فشل المصادقة على نظير PPP المصدق.

تحدي

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

إستجابة

هذا الإطار هو إستجابة CHAP المرسلة من نظير PPP المصدق إلى نظير PPP المصدق.

وتتكون الاستجابة المطلوبة من جزأين:

• إخراج تجزئة MD5 للسر المشترك.

• إما اسم المضيف للجهاز البعيد أو اسم المستخدم على الجهاز البعيد.

يستخدم هذا الإطار فقط عند إستخدام CHAP لمصادقة اتصال PPP.

NCP

العنوان a.b.c.d

• في رسالة CONFREQ صادرة، تشير هذه القيمة إلى عنوان IP الذي يرغب الموجه المحلي في إستخدامه. إذا كان العنوان المضمن هو 0.0.0.0، فإن الجهاز المحلي يطلب من النظير تزويده بعنوان IP يمكن إستخدامه.

• في رسالة CONFREQ واردة، تشير هذه القيمة إلى عنوان IP الذي يرغب النظير في إستخدامه. إذا كان العنوان المضمن هو 0.0.0.0، فإن النظير يطلب من الجهاز المحلي إمداده بعنوان IP يمكن إستخدامه.

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

• في رسالة CONFNAK واردة، تشير هذه القيمة إلى عنوان IP الذي يجب أن يستخدمه الجهاز المحلي، بدلا من العنوان الذي اقترحه في رسالة CONFREQ السابقة.

• في رسالة CONFACK الصادرة، تشير هذه القيمة إلى أن عنوان IP المطلوب بواسطة النظير مقبول للجهاز المحلي.

• في رسالة CONFACK واردة، تشير هذه القيمة إلى أن عنوان IP المطلوب بواسطة الجهاز المحلي مقبول للنظير.

CCP (بروتوكول التحكم في الضغط)

تشير هذه الرسالة إلى أن بروتوكول الضغط قيد التفاوض بين كلا نظاري PPP. يدعم برنامج Cisco IOS بروتوكولات الضغط هذه التي سيتم التفاوض عليها عبر اتصال PPP:

• ضغط MS من نقطة إلى نقطة (MS-PPC)

• مكدس

• متكهن

CDPCP (بروتوكول التحكم في بروتوكول أستكشاف Cisco)

تشير هذه الرسالة إلى حدوث تفاوض CDP في مرحلة NCP. لإيقاف تشغيل CDP على الموجه، قم بإصدار الأمر no cdp run.

CODEREJ (رفض الرمز)

يتم إرسال حزمة CODEREJ عند إستلام حزمة غير قابلة للتفسير معبأة من نظير PPP البعيد.

تثبيت المسار إلى a.b.c.d

عندما ينتهي الموجه من بروتوكول IPCP (مرحلة NCP لبروتوكول IP L3)، يجب عليه تثبيت عنوان IP المحدد إلى نظير PPP البعيد في جدول التوجيه والنظر إليه كمسار متصل في جدول التوجيه. إذا لم تظهر هذه الرسالة، فتحقق من عدم تكوين الأمر no peer neighbor-route.

IPCP (بروتوكول التحكم في بروتوكول الإنترنت)

تشير هذه القيمة إلى أن IP هو طبقة الشبكة قيد التفاوض في مرحلة NCP.

حالة IPCP مفتوحة

تشير هذه الرسالة إلى أنه قد تم إكمال مرحلة IPCP (NCP لبروتوكول IP L3) بنجاح.

PROTREJ (رفض البروتوكول)

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

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

• تكوين بروتوكول مصادقة كلمة مرور PPP (PAP) واستكشاف أخطاء هذا البروتوكول وإصلاحها
• مصادقة PPP باستخدام أوامر إستدعاء بروتوكول PPP chap hostname و مصادقة PPP
• استيعاب مصادقة PPP CHAP وتكوينها
• أستكشاف أخطاء مصادقة PPP (CHAP أو PAP) وإصلاحها
• صفحات دعم تقنية الطلب
• الدعم الفني - Cisco Systems