تجاوز فشل WAN في DMVPN: سياسة التوجيه أم إغلاق النفق؟

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

القرار يأتي قبل الإعداد

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

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

اكتب الإجابة، لأن الإعداد هو الجزء السهل.

ما الذي تغيره سياسة التوجيه فعلا

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

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

تختلف الصياغة بين المنصات والإصدارات، فتحقق من الدليل الخاص بالإصدار الذي تشغله فعلا.

ما الذي يغيره إغلاق النفق

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

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

يمكن لأمر استعادة مضم ن في الشيفرة أن يتجاوز أيضا إغلاق صيانة نفذه شخص آخر.

اجعل المسبار يسلك المسار الذي تظنه

المسبار الذي يتبع أفضل مسار حالي ينتقل إلى WAN الاحتياطي مع كل شيء آخر، ثم يبلغ أن الأساسي سليم لأنه لم يعد يستخدمه.

ثبت المسبار على الواجهة أو عنوان المصدر للمسار الذي تختبره. وتحقق أيضا مما يستهدفه، لأن الوصول إلى القفزة التالية لمزود الخدمة يثبت أقل من الوصول إلى الخدمة التي وجد النفق من أجلها. اضبط تأخيري الصعود والهبوط عن قصد: فالتأخير القصير للهبوط يتفاعل بسرعة ويتذبذب، بينما الطويل يستوعب التقلبات ويخفي الأعطال الحقيقية. دليل تتبع وتوجيه السياسات في IOS XE من Cisco يوثق التوليفات المدعومة، ومجموعة الميزات على منصتك تحدد أيها يمكنك استخدامه.

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

احسم الاستعادة، ثم تحقق

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

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

احتفظ بالأدلة من تلك النافذة، لأن التغيير التالي سيقارن بها.