الربط المتعدد للهياكل المتعددة PPP (MMP) (الجزء 2)

المقدمة

يستمر هذا المستند في وصف دعم بروتوكول PPP متعدد الارتباطات (MP) في "مكدس" أو بيئة متعددة الهياكل (تسمى في بعض الأحيان MMP، ل Multichassis Multilink PPP)، على الأنظمة الأساسية لخادم الوصول من Cisco Systems.

هذا المستند هو الجزء الثاني من مستند مكون من جزئين. راجع الجزء الأول من هذا المستند للحصول على مزيد من المعلومات.

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

يتم توفير المتطلبات الأساسية لهذا المستند في الجزء الأول من هذا المستند.

الأمثلة

AS5200 في حزمة (باستخدام مكبرات الاتصال)

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

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

systema#config
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3

  username stackq password therock

  int dialer 1
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  ppp multilink

  controller T1 0
  framing esf                    
  linecode b8zs                  
  pri-group timeslots 1-24

  interface Serial0:23
  no ip address
  encapsulation ppp
  dialer in-band
  dialer rotary 1
  dialer-group 1

المثال التالي من وحدة تحكم E1:

controller E1 0
  framing crc4  
  linecode  hdb3
  pri-group timeslots 1-31
  interface Serial0:15
  no ip address
  encapsulation ppp
  no ip route-cache
  ppp authentication chap
  ppp multilink

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

PRIs و BRIs بشكل افتراضي هي واجهات المتصل؛ PRI مكون بدون متصل صريح (من خلال أمر المتصل الدواري) لا يزال واجهة المتصل على Serial0:23، كما هو موضح في المثال التالي:

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink

إستخدام خادم إلغاء التحميل

يتم تعيين النظام على خادم إلغاء تحميل (باستخدام الأمر sgbp seed-bid). يجب تحديد جميع أعضاء مجموعة المكدس الأخرى باستخدام الأمر sgbp seed-bid default (أو، إذا لم تقم بتعريف الأمر seed-bid هذا، فإنه يتم تعيينه افتراضيا على هذا الأمر).

systema#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  sgbp seed-bid offload
  username stackq password therock

  interface virtual-template 1
  ip unnumbered e0
  :

  ppp authen chap
  ppp multilink

إلغاء تحميل الخادم باستخدام الواجهات المادية

إذا كان خادم إلغاء التحميل المعين يحتوي أيضا على واجهات مادية (على سبيل المثال، PRI) ترغب في خدمة مجموعة توجيه مكالمات telco نفسها كأعضاء المكدس الآخرين، فيمكنك تكوينها للقيام بذلك من خلال دمج التكوينات الموضحة في أقسام هذا المستند باسم AS5200 في مكدس (باستخدام المتصل) واستخدام خادم إلغاء تحميل.

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

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

الواجهات التسلسلية وغير التسلسلية غير المتصلة

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

#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  username stackq password therock
  interface virtual-template 1
  ip unnumbered e0
  :
  ppp authen chap
  ppp multilink

  int async 1
  encap ppp 
  ppp multilink 
  ppp authen chap
  :

  line 1
  login 
  autoselect ppp 
  autoselect during-login
  speed 38400
  flow hardware

الاتصال من خلال هيكل متعدد

حاليا، لا يدعم التكوين متعدد الهياكل خرج الطلب، نظرا لأن بروتوكول إعادة توجيه الطبقة 2 (L2F) لا يدعم خرج الطلب.

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

بعض الحلول هي كما يلي:

• عندما يتم إصدار الأمر sgbp ppp-forward على عضو المكدس الأمامي-end، فهذا يعني أن جميع مكالمات PPP و PPP متعددة الارتباطات تتم إعادة توجيهها تلقائيا إلى الفائز بعرض بروتوكول عطاء مجموعة المكدس (SGBP)، مثل خادم إلغاء التحميل.

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

    ip route 1.1.1.1 255.255.255.255 serial0:23
    int serial0:23
    ip address 3.3.3.3 255.0.0.0
    dialer map ip 1.1.1.1 howard 7771234
  

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

  ملاحظة: ينتج عن تقارب التوجيه زمن وصول.

• عندما لا يتم تعريف الأمر sgbp ppp-forward على عضو المكدس الأمامي-end، فهذا يعني أنه يتم إعادة توجيه مكالمات PPP متعددة الارتباطات فقط تلقائيا إلى الفائز بمناقصة SGBP، مثل خادم إلغاء التحميل. وبالتالي، فإن المتصل الذي يبدأ من عضو المكدس بالطرف الأمامي إلى النظير البعيد يمتد من اتصال PPP بين الطرف الأمامي والنظير البعيد - وهو السلوك نفسه كما لو كانت وحدات التخزين المتصلة بالشبكة (NAS) ليست جزءا من مجموعة مكدس.

  ملاحظة: يحدث هذا طالما أن الاتصال هو PPP مستقيم (وليس PPP متعدد الارتباطات).

الاتصال بهيكل متعدد

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

منع تثبيت مسار متصل على جانب العميل

قم بتكوين العميل 1.1.1.2 حيث يكون 1.1.1.2 هو عنوان NAS (أداة توجيه الإطارات الشفافة)، كما هو موضح أدناه.

  int bri0

  dialer map 1.1.1.2 ....

إذا كان لديك EIGRP، على سبيل المثال، يعمل بين العميل وخادم إلغاء التحميل، يشير جدول التوجيه على خادم إلغاء التحميل إلى أنه للوصول إلى 1.1.1.2 يجب أن يمر المسار عبر واجهة الوصول الظاهرية. وذلك لأن بروتوكول التحكم في PPP IP (IPCP) على جانب العميل يقوم بتثبيت مسار متصل 1.1.1.2 إلى واجهة BRI. ثم يعلن EIGRP عن هذا المسار إلى خادم إلغاء التحميل عبر جلسة PPP (عبر L2F). وهكذا يشير EIGRP على خادم إلغاء التحميل إلى أنه للوصول إلى 1.1.1.2، يجب أن يوجه إلى العميل - مسار العميل 1.1.1.1 إلى واجهة الوصول الظاهرية.

الآن، لديك حزمة موجهة للعميل 1.1.1.1. يرسل توجيه IP الحزمة إلى واجهة الوصول الظاهرية. تقوم واجهة الوصول الظاهرية بتضمين بروتوكول بيانات IP/المستخدم (UDP)/L2F/PPP وترسل الحزمة إلى NAS-1.1.1.2 في L2F. كل شيء طبيعي في هذه المرحلة. ثم، بدلا من إرسال الحزمة للخارج من خلال (على سبيل المثال) واجهة إيثرنت، يرسلها توجيه IP من خلال واجهة الوصول الظاهرية مرة أخرى. وذلك نظرا لأن جدول التوجيه يشير إلى أنه للوصول إلى وحدة التخزين المتصلة بالشبكة (NAS)، يجب أن تمر عبر العميل. وهذا يؤدي إلى إنشاء حلقة توجيه وتعطيل الإدخال والإخراج بشكل فعال عبر نفق L2F.

لمنع ذلك، لا تسمح ل IPCP بتثبيت مسار متصل على جانب العميل.

ملاحظة: لا ينطبق هذا إلا عندما يكون لديك بروتوكول توجيه IP قيد التشغيل بين العميل وبوابة Cisco الرئيسية.

تكوين العميل كما يلي:

  int bri0

  no peer neighbor-route

خرائط المتصل على العميل

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

على سبيل المثال:

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

في هذا المثال، 1.1.1.3 هو خادم إلغاء تحميل واحد فقط.

يتم توجيه حزمة موجهة ل 1.1.1.2 إلى BRI، ويقوم المتصل بتحديد الوجهة نظرا لوجود تطابق في خريطة المتصل. يربح خادم إلغاء التحميل 1.1.1.4 العطاء بالفعل ويتم عرض جلسة PPP هناك. يتم تبادل EIGRP بين العميل وخادم إلغاء التحميل. يتم ملء جدول توجيه IP على العميل بمسار 1.1.1.4 (خادم إلغاء التحميل) إلى BRI0. الآن، على العميل، يتم توجيه حزمة موجهة ل 1.1.1.4 إلى BRI0. ومع ذلك، يتعذر على المتصل الاتصال نظرا لعدم وجود مطابقة للمطالب.

ملاحظة: حدد دائما خرائط الاتصال لجميع الفائزين المحتملين بعطاءات SGBP على العملاء كلما كان الوصول إلى خوادم إلغاء التحميل متطلبا من العملاء.

التكوين والقيود

• يلزم توفر صورة-J للمؤسسة ل MP متعدد الهياكل.

• يمكن تحديد مجموعة مكدس واحدة فقط لكل خادم وصول.

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

• يتم دعم الواجهات لأجهزة PRI و[M]BRI والأجهزة التسلسلية وغير المتزامنة.

• اتصال غير معتمد.

تكوين تكوينات واجهة كل بروتوكول

لكافة الأغراض العملية، لا تقم بتكوين عنوان بروتوكول محدد على القالب الظاهري.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

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

  interface virtual-template 1

  ip unnum e0

  :

تكوين تكوينات البروتوكول العام

حيث يقوم العميل الذي يتصل بموجه وصول واحد ويتوقع أن يكون لخادم الوصول عنوان عام فريد (مثل DECnet) الآن بالاتصال فعليا بمجموعة المكدس متعدد الارتباطات والهياكل التي تتكون من العديد من خوادم الوصول. في هذا النوع من الحالات، قم بإنهاء مجموعة المكدس بشكل محدد في خادم وصول واحد. للقيام بذلك، قم بإصدار الأمر sgbp seed-bid overload على خادم الوصول المعين (أو تحديد أعلى عرض).

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

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

1. تأكد من أن SGBP قيد التشغيل.

2. تصحيح أخطاء PPP متعدد الارتباطات.

3. debug VPN و L2F.

التأكد من تشغيل SGBP بشكل صحيح

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

إذا عثرت على مشكلة كما هو موضح أعلاه، فقم بتشغيل الأمر debug sgbp hellos وdebug sgbp error. يجب أن تكون المصادقة بين عضوين في المكدس، على سبيل المثال بين النظام والنظام، كما يلي (على النظام):

  systema# debug sgdp hellos

  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2)
  %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq
  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2)
  %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2)
  %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7
  %SGBP-5-ARRIVING: New peer event for member systemb

يرسل النظام تحديا على نمط CHAP ويتلقى إستجابة من النظام. وبالمثل، فإن النظام يرسل تحديا ويتلقى إستجابة من النظام.

إذا فشلت المصادقة، ترى:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

وهذا يعني أن كلمة مرور النظام البعيد ل Stackq لا تطابق كلمة المرور المحددة على system.

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

وهذا يعني أن النظام لا يحتوي على اسم مستخدم أو كلمة مرور معرفة محليا أو من خلال TACACS+.

بشكل عام، قم بتحديد سر مشترك عبر جميع أعضاء المكدس لمكدس مجموعة المكدس. يمكنك تحديدها محليا أو من خلال TACACS+.

اسم مستخدم محلي معرف على كل عضو في المكدس هو:

  username stackq password blah

الغرض من هذا السر الشائع هو تسهيل عطاء عضو المكدس SGBP والتحكيم.

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

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

  systema#debug sgbp error
  %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5

هذا يعني أن عنوان IP المصدر الخاص ب SGBP Hello المتلقى من systemb لا يطابق عنوان IP الذي تم تكوينه محليا ل system (من خلال الأمر sgbp member). صححت هذا بالانتقال إلى system وفحص بحثا عن واجهات متعددة والتي من خلالها يمكن أن يقوم SGBP Hello بإرسال الرسالة.

سبب آخر شائع للأخطاء هو:

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

هذا يعني أنه ليس لديك نظام معرف محليا، ولكن عضو مكدس آخر لديه ذلك.

تصحيح أخطاء PPP متعدد الارتباطات

أول شيء للتحقق هو ما إذا كان العميل وعضو المكدس قد صادقا على PPP بشكل صحيح.

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

#config

username stackq password blah

#config

username userx password blah

لم يتم تضمين واجهات جهات المتصل

نظرا لعدم وجود واجهة المتصل على خادم إلغاء التحميل، يلزم أن يكون هناك مصدر آخر لتكوين الواجهة لواجهات الوصول الظاهرية. الإجابة هي واجهات القوالب الظاهرية.

1. أولا، تأكد من تحديد رقم القالب الظاهري العمومي متعدد الارتباطات على كل عضو في المكدس.

     #config
     Multilink virtual-template 1
   

2. إذا لم تقم بتكوين أي واجهات للمطالب للواجهات المادية المعنية (مثل PRI و BRI و Asynchronous و Synchronous Serial)، فيمكنك تحديد:

     interface virtual-template 1
     ip unnumbered e0
     ppp authen chap
     ppp Multilink
   

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

واجهات المتصل المعنية

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

ملاحظة: يتم عرض واجهة المتصل، المتصل 1، في جلسة عمل PPP متعددة الارتباطات كما يلي:

  systema#show ppp Multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  Dialer interface is Dialer1
  0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
  0 discarded,  0 lost received, sequence 40/66 rcvd/sent
  members 2
  Serial0:4  
  systemb:Virtual-Access6    (1.1.1.1)

LCP و NCPs

يجب أن تكون حالات LCP على جميع واجهات الأعضاء قيد التشغيل. يجب أن يكون IPCP و ATCP و NCPs الأخرى قيد التشغيل فقط على واجهة الحزمة.

يجب أن يكون إخراج show int لواجهة الحزمة Virtual-Access4 كما يلي:

  router#show int  Virtual-Access4
  Virtual-Access4 is up, line protocol is up 
          :
      LCP Open, Multilink Open
      Open: ipcp
              :

يجب أن تحتوي جميع واجهات الأعضاء الأخرى على مخرجات show int التالية:

  router# show int Serial0:4
  Serial0:4 is up, line protocol is up 
          :
  LCP Open, Multilink Open
  Closed:  ipcp

تصحيح أخطاء VPN/L2F

قم بتشغيل ما يلي:

  debug vpn event
  debug vpn error

عندما تقبل الواجهة المادية المكالمة الواردة ويتم إعادة توجيهها الآن إلى عضو المكدس الهدف، ترى ما يلي:

  Serial0:21 VPN Forwarding 
  Serial0:21 VPN vpn_forward_user userx is forwarded

في عضو المكدس الهدف، إذا رأيت ما يلي:

  Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
  Virtual-Access1 VPN PPP LCP not accepting sent CONFACK

ثم تحقق من تعريف واجهة القالب الظاهري. وبشكل عام، يجب أن تطابق واجهة القالب الظاهري معلمات واجهة PPP الخاصة بالواجهة المادية التي قبلت مكالمة واردة.

تذكر أدنى تكوين (باستخدام CHAP كمثال):

  #config
  multilink virtual template 4
  int virtual-template 4
  ip unnum e0
  encap ppp
  ppp authen chap 
  ppp Multilink

قد ترى ما يلي:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

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

من الأخطاء الشائعة الفشل في تعريف اسم المستخدم لاسم المكدس الشائع (stackq) أو عدم مطابقة كلمة مرور المكدس على جميع أعضاء المكدس.

أصدرت الأمر التالي:

  debug vpdn l2f-error

نتائج الرسالة التالية:

  L2F Tunnel authentication failed for stackq

قم بتصحيح تطابق اسم المستخدم وكلمة المرور على كل عضو في المكدس في هذه الحالة.

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

• الجزء 1 من هذا المستند
• ميزات PPP للوصول الظاهري في برنامج Cisco IOS
• يفهم VPDN
• الدعم الفني - Cisco Systems