لماذا يتجاهل L2VPN لديك مسار RSVP-TE LSP الذي بنيته للتو

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

تسمية واحدة تسمّي خدمة، والأخرى تحرّك حزمة

تسمية pseudowire، التي يشير إليها LDP الموجّه كما هو موصوف في RFC 4447، تخبر حافة المزوّد المستقبِلة أي دائرة إرفاق يجب أن تستقبل الإطار. وهي لا تقول شيئًا عن كيفية وصول الإطار إلى هناك. أما التسمية التي تحتها فتنتمي إلى النقل، وتُبنى تلك الحزمة بأي بروتوكول أعلن قابلية الوصول إلى loopback النظير، سواء كان LDP أو RSVP-TE أو مسارًا موجّهًا بالقطاعات. ولأن بروتوكولات مختلفة تشير إلى الطبقتين، يمكن أن تكون إحداهما سليمة بينما الأخرى قديمة. وهذا الفصل هو مصدر الالتباس كله.

يجدر القول بصراحة: pseudowire لا يختار LSP. إنه يسلّم الإطار إلى النقل، والنقل يقرّر من عنوان الوجهة الذي أُعطي له.

ولهذا أيضًا لا يثبت ping نظيف عبر LSP الجديد سوى القليل. فقد يكون LSP قائمًا وموسومًا ويحمل خدمات أخرى بينما لا يزال pseudowire لديك يُحلّ عبر قفزة تالية مختلفة. وإلى أن تقرأ الارتباط، فإن هاتين الحقيقتين غير مترابطتين.

الخيار أ: ثبّت pseudowire على نقل مختار

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

الثمن هو النطاق. سياسة تطابق عنوان نظير تؤثر على كل خدمة موجّهة إلى ذلك النظير، لا على pseudowire الذي كان في ذهنك فقط.

يستحق الاحتياطي قرارًا قبل نافذة التغيير لا خلالها. فإذا سقط LSP المثبّت، إما أن تدع الخدمة تسير على مسار معتمد آخر أو تدعها تتوقف. والسياسة التي تعود بصمت إلى مسار يخالف قيد كمون أو تباعد فقد حوّلت انقطاعًا نظيفًا إلى شيء أصعب بكثير في الشرح لأي شخص.

الخيار ب: اترك IGP يختار وراقب ما يحدث

ترك الخدمة وشأنها تصميم مشروع، وكثيرًا ما يكون الأفضل. يتبع pseudowire الحلّ نفسه الذي يتبعه أي مرور آخر إلى loopback النظير، فيرث تقارب IGP وكبت البادئات وأي فائض يقدمه النواة أصلًا. سياسات أقل تعني أماكن أقل يمكن أن تختبئ فيها مطابقة قديمة. والمقايضة أنك لم تعد تتحكم في المسار الذي تسلكه الخدمة، بل في أن مسارًا ما موجود فحسب.

المسار المتعدد متساوي الكلفة يشحذ هذه المقايضة أكثر مما يبدو أول الأمر. فالتجزئة لكل تدفق، لذا محادثتان داخل pseudowire واحد قد تنطلقان بتسميتين خارجيتين مختلفتين.

اقرأ إعادة التوجيه المثبّتة قبل أن تثق بأي منهما

ابدأ بعنوان النظير لا بالخدمة. على Junos، يطبع show route 203.0.113.1 detail القفزة التالية المختارة وعملية التسمية، ويقوم show route table mpls.0 بربط التسمية الواردة بتلك العملية. وعلى IOS XR، يعطي show mpls l2transport vc 100 detail حالة pseudowire مع الحزمة المفروضة.

أكّد LSP الذي يستخدمه النقل فعليًا، لا الذي يذكره مستند التصميم لديك. إن traceroute mpls ipv4 203.0.113.1/32 على IOS XR يمشي مسار تبديل التسميات ويسرد التسميات والواجهات الصادرة عليه، وهو أقرب شيء إلى مشاهدة المسار بنفسك. ثم أعد التجربة من حافة المزوّد البعيدة، لأن اتجاه العودة يُحلّ باستقلال والتفاوت شائع بعد نشر سياسة جزئي. والمسار الصحيح في اتجاه والخاطئ في الآخر أسوأ من مسار خاطئ في الاتجاهين، لأن نصف اختباراتك سينجح.

احفظ الأدلة مع سجل الخدمة: عنوان النظير، والقفزة التالية، والتسمية الخارجية، وتاريخ التحقق. سياسات المسارات تشيخ بسرعة، ولا أحد يتذكر أيّها كان ساريًا قبل ربعين.

اختر حسب نمط الفشل لا حسب التفضيل

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

السؤال الحاسم هو ما يكلفك المسار الخاطئ. فإن كان أداء خدمة على LSP خاطئ أسوأ قليلًا فقط، فدع IGP يقرر وأنفق الجهد على المراقبة. وإن كان مسار خاطئ يخرق عقدًا أو ملاحظة تدقيق أو شرط تباعد، فثبّته واكتب الاحتياطي. ثم اختبر الاحتياطي، لأن احتياطيًا غير مختبر افتراض لا خطة. وعلى أي حال، أعد قراءة الارتباط المثبّت بعد أي تغيير في النواة، وتعامل مع pseudowire قام على أنه دليل على لا شيء غير أن الإشارة تعمل.