مختبر MPLS L3VPN لا يستجيب للـ ping؟ تحقق من هذه القفزات الخمس

موجّهان للعميل، وزوج من أجهزة provider edge، و ping يموت دون رسالة خطأ. في مختبر MPLS L3VPN صغير يجلس العطل تقريبًا دائمًا عند واحدة من خمس نقاط تحقق، ولكل منها أمر يُظهر إما أن التبعية تعمل أو أنها مفقودة. الخطأ هو إعادة تشغيل BGP في كل مرة يفشل فيها ping بدلًا من اختبار التبعيات بالترتيب. إذا قفزت مباشرة إلى إعداد VRF فقد تقضي ساعة على مشكلة بدأت من القفزة التالية غير المحلولة على بعد جهازين.

اعمل على القائمة من الأسفل إلى الأعلى. نقطة التحقق التي تنجح تبقى ناجحة، وأول فشل هو الذي يستحق التنقيح.

نقطة التحقق الأولى: أجهزة PE تصل إلى بعضها

يحتاج كل PE إلى مسار نحو loopback الخاص بـ PE الآخر، وهذا المسار يجب أن يُحل عبر شيء حقيقي. بروتوكول interior gateway هو الطريق المعتاد إلى هناك، لكن المسار الساكن يعمل أيضًا ما دام البحث التكراري ينتهي عند adjacency حيّ. على أجهزة بنمط IOS، يُظهر show ip route 10.0.0.2 ثم show ip cef 10.0.0.2 ما إذا كانت البادئة موجودة وما إذا كان خلفها adjacency محلول. المسار الموجود في الجدول دون adjacency خلفه ليس قابلية وصول.

تحقق من الاتجاهين. تكاليف IGP غير المتماثلة، أو passive interface على الجانب الخطأ، أو distribute list يرشح الـ loopback، كلها تكسر اتجاهًا واحدًا فقط، واتجاه واحد يكفي لقتل الجلسة. إذا كان الـ loopback يستجيب للـ ping لكن جلسة BGP تبقى في Active، فانظر إلى update source قبل أن تلمس أي شيء آخر.

نقطة التحقق الثانية: يوجد مسار تسميات

لا يثبت مسار IP نحو الـ loopback البعيد أن النقل سيضع تسمية. في تصميم LDP، تأكد من أن الـ loopback البعيد لديه ارتباط محلي وارتباط بعيد، ومن أن التسمية الصادرة تظهر في جدول forwarding. يعرض show mpls ldp bindings 10.0.0.2 32 أزواج التسميات، ويعرض show mpls forwarding-table 10.0.0.2 ما ستضعه line card فعليًا. عندما لا يُظهر الأمر الثاني أي تسمية أو يرتد إلى IP، فإن النقل لا يحمل حركة VPN كما يفترض التصميم.

يأتي الفرق من الطريقة التي يفصل بها MPLS حالة forwarding عن بادئات الوجهة، وهو النموذج الموصوف في RFC 3031. إذا كان مختبرك يستخدم RSVP-TE أو تسميات ملاصقة لـ BGP بدلًا من LDP، فافحص حالة ذلك الميكانيزم نفسه; افتراض أن LDP يوزع كل تسمية في الطبقة السفلى طريقة شائعة لمطاردة خلل شبحي. المسار المعطوب للتسميات يظهر عادة لاحقًا كمسار VPN موجود لكنه غير صالح للاستخدام.

نقطة التحقق الثالثة: وصل مسار VPN سليمًا

انظر إلى مسار VPNv4 أو VPNv6 للبادئة الدقيقة للعميل، لا إلى ملخص الجلسة. يجب أن يعرض show bgp vpnv4 unicast all 10.10.1.0/24 الـ route distinguisher، والـ next hop المضبوط على loopback الـ PE البعيد، وتسمية. إذا كانت البادئة مفقودة، فأول مشتبه به هو سياسة التصدير على الـ PE المصدر أو سياسة الاستيراد على الـ PE المستقبل، والـ route targets هي الجاني المعتاد.

اقرأ فحص route target منفصلًا عن استقبال BGP. يمكن أن يصل المسار مع next hop صحيح ومع ذلك لا يهبط في VRF لأن importtarget لا يطابق. على الـ PE المستقبل، show ip route vrf CUSTOMER 10.10.1.0 هو الاختبار المهم; جدول BGP يثبت فقط أن المسار عبر مستوى التحكم.

نقطة التحقق الرابعة: الـ interface داخل الـ VRF

تعريف VRF مع route distinguisher و route targets لا ينقل أي interface إليه. يحتاج الـ interface المواجه لـ CE إلى تعيين VRF، ويجب أن يسرده show ip vrf interfaces أو show ip interface brief تحت المثيل الصحيح. هذه هي نقطة التحقق التي يخطئ فيها الإعداد المنسوخ أكثر من غيرها، لأن كتلة VRF تبدو كاملة بينما لا يزال الـ interface جالسًا في الجدول العام.

ثم تأكد من أن الـ PE تعلم بادئة العميل المحلية في ذلك الـ VRF، ومن أن الـ CE لديه مسار عودة عبر الوصلة. default ساكن على الـ CE يشير إلى الـ PE يكفي لمختبر، بشرط أن يكون في VRF الخاص بالـ PE مسار إلى LAN الخاص بالـ CE. إذا غاب أي من النصفين، يفشل الـ ping قبل وضع أي تسمية.

نقطة التحقق الخامسة: الرد يجد طريقًا إلى المنزل

تتبّع الحزمة المتجهة للأمام ثم حزمة العودة، لأنهما تستخدمان جدولين مختلفين. على PE الدخول، يجب أن يُحل مصدر العميل داخل الـ VRF إلى البادئة البعيدة مع التسمية البعيدة. على PE الخروج، يجب أن تُحل الوجهة داخل الـ VRF نفسه إلى الـ interface المواجه لـ CE. الـ ping الصادر من الـ PE نفسه ليس دليلًا: فقد يخرج عبر الجدول العام أو عبر عنوان مصدر آخر، ولهذا فإن ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 هو الاختبار الذي يجب تشغيله.

جدران الحماية على المضيفين، و reverse-path filtering، وقوائم الوصول على الـ CE لا تزال سارية. إذا كان مسار الذهاب يعمل ويموت الرد، فالمشكلة في مسار أو مرشح على جانب العودة، لا في نقل MPLS.

احتفظ بسطر واحد لكل نقطة تحقق يسمّي أول تبعية فشلت. ذلك السطر يحوّل شكوى أن العميل لا يستطيع الـ ping إلى سؤال محدد عن قابلية الوصول، أو حالة التسميات، أو استيراد المسارات، أو عضوية الـ interface، أو مسار العودة، ويمنع جلسة التنقيح التالية من تكرار الأوامر الخمسة نفسها بالترتيب نفسه.