الخلاصة

  • بقاء جلسة BGP في حالة Established لا يثبت بقاء المسارات التي حملتها رسالة UPDATE مشوهة؛ فقد تعاملت معها الشبكة كسحب مع استمرار الجلسة.
  • الاختيار الآمن بين إعادة الجلسة وتعطيل AFI/SAFI وtreat-as-withdraw وإسقاط السمة يعتمد على إمكان تحليل NLRI ومعنى السمة والسياسة المحلية، لا على رغبة عامة في إبقاء الجلسة خضراء.

الرسالة الواحدة ليست المسار الواحد

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

في معالجة RFC 4271 الأساسية، يقود خطأ UPDATE إلى NOTIFICATION وإنهاء الجلسة. عند زوال الجلسة تزول معها المسارات المتعلمة من ذلك النظير، بما فيها مسارات صحيحة جاءت في رسائل أخرى. أما RFC 7606 فيسمح، في حالات محددة، بمعاملة كل المسارات الموجودة في UPDATE المشوهة كما لو أنها سحبت. تزال تلك المسارات من Adj-RIB-In وتبقى الجلسة Established. وهكذا قد تكون خانة الجار خضراء بينما تختفي الوجهات التي جمعتها الرسالة المعيبة. RFC 7606.

هذه ليست عملية إصلاح للرسالة، وليست تجاهلا صامتا لها. لو أسقط المستقبل UPDATE تزايدية من دون تحديث الحالة القديمة، فقد يترك مسارا سابقا غير صالح مثبتا. treat-as-withdraw يفعل العكس: ينفق قابلية الوصول للمسارات الموجودة في الرسالة كي يمنع بقاء حالة لا يمكن الوثوق بسماتها. وقد يؤدي ذلك إلى مسار بديل أقل جودة أو إلى انعدام الوصول كليا. لذلك لا يصح وصفه بأنه يحافظ على كل المسارات أو يمنع الحلقات والثقوب السوداء.

أربع درجات لا أربعة أسماء للعمل نفسه

يرتب RFC 7606 الإجراءات من الأقوى إلى الأضعف: إعادة الجلسة، وتعطيل AFI/SAFI، وtreat-as-withdraw، وإسقاط السمة. إعادة الجلسة تنهيها وتزيل مجالا واسعا من الحالة. تعطيل AFI/SAFI أضيق من حيث العائلة، لكنه قد يزيل كل مسارات العائلة المتأثرة ويتجاهل ما يصل لاحقا منها طوال الجلسة؛ لا يعادل سحب UPDATE واحدة. توضح إجراءات امتدادات البروتوكول متعددة العائلات هذا الحد. RFC 4760.

treat-as-withdraw يخص كل NLRI في الرسالة المعنية. أما attribute discard فيزيل السمة المشوهة ويواصل معالجة UPDATE. لا يسمح RFC 7606 بذلك إلا لسمة لا تؤثر في اختيار المسار أو تثبيته. حتى هذه العبارة تحتاج فحص السياسة المحلية: يمكن لسياسة خاصة أن تجعل سمة غير مؤثرة افتراضيا ذات أثر فعلي في الاختيار. إسقاطها حينئذ قد يحافظ على الوصول بثمن محو معنى كانت المؤسسة تعتمد عليه.

وتظهر دقة الفرق في السمات نفسها. تحدد مراجعات RFC 7606 treat-as-withdraw لأخطاء معينة في ORIGIN وAS_PATH وNEXT_HOP وMED وLOCAL_PREF، بينما تستخدم attribute discard لشروط محددة في ATOMIC_AGGREGATE وAGGREGATOR. لا يسمح اسم السمة وحده باختيار إجراء مرتجل؛ ينبغي الرجوع إلى مواصفة الخطأ المحددة والسياق الذي وردت فيه.

عندما تضم UPDATE أكثر من خطأ وتفرض الأخطاء إجراءات مختلفة، يطبق الإجراء الأقوى. وتبقى هناك حالات خاصة مهمة: تكرار MP_REACH_NLRI أو MP_UNREACH_NLRI يوجب NOTIFICATION بسبب Malformed Attribute List، بينما يحتفظ المستقبل بأول ظهور لسمة أخرى مكررة ويتخلص من الظهورات اللاحقة. هذه الحدود تمنع تحويل «التسامح» إلى قاعدة عامة تتجاهل كل خطأ ما دامت الجلسة قائمة.

لا سحب بلا وجهات قابلة للقراءة

لكي يتعامل المستقبل مع المسارات كسحب، يجب أن يعرف أي مسارات يقصد. يشترط RFC 7606 العثور على حقول NLRI وقراءتها كاملة، سواء كانت في الحقل التقليدي أو MP_REACH_NLRI وMP_UNREACH_NLRI. إذا تعذر تحديدها أو تحليلها، تبقى إعادة الجلسة وفق RFC 4271 أو تعطيل AFI/SAFI وفق RFC 4760 لازمين بحسب الحالة. لا يجوز استخدام الإجراء الأخف فقط لأن أثره التشغيلي أقل إزعاجا.

هذا الحد هو أهم قرار للبرنامج: هل الخلل في سمة يمكن عزلها مع بقاء حدود الوجهات مفهومة، أم أنه أفسد القدرة على معرفة أين تبدأ NLRI وتنتهي؟ قد يكون اختلاف طول الحقل كافيا لإسقاط افتراضات المحلل. عندها لا توجد قائمة موثوقة يمكن إعلان سحبها. اختيار treat-as-withdraw من دون هذه القائمة ليس احتواء للخطأ بل تخمين في الحالة.

تقدم Large Communities مثالا حديثا على قاعدة محددة. إذا لم يكن طول قيمة السمة مضاعفا غير صفري لـ12، يطلب RFC 8092 treat-as-withdraw. أما القيم المكررة وحدها فلا تجعل السمة مشوهة، بل تزال النسخ المكررة بصمت. يبين ذلك أن الإجراء يرتبط بتعريف المفسدة في مواصفة السمة، لا بانطباع أن البيانات تبدو غريبة.

وتقدم سمات الانتقال للأرقام المستقلة من أربعة بايتات مثالا آخر. يختار RFC 6793 إسقاط AS4_PATH أو AS4_AGGREGATOR في حالات محددة مع التسجيل المحلي، لأن معناهما وسياق قدرات النظير مختلفان. كذلك يحظر RFC 7607 استخدام AS 0 في مواضع محددة ويحيل المعالجة إلى RFC 7606 أو RFC 6793 بحسب السمة. ليس الهدف توسيع المقال إلى AS 0، بل إظهار أن الدلالة والسياق يحددان الإجراء.

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

بقاء الجلسة قد يوسع فجوة الرؤية

عند وصول UPDATE المشوهة عبر IBGP، يحذر RFC 7606 من عدم اتساق التوجيه داخل النظام المستقل، بما قد ينتج حلقات تمرير طويلة العمر أو ثقوبا سوداء. قد يتعامل جهاز مع المسارات كسحب، بينما يحتفظ جهاز آخر برؤية مختلفة بسبب إصدار أو إعداد أو مسار نشر آخر. وتصبح الجلسات الخضراء في هذه الحالة ستارا يخفي خلافا حول الوجهة لا خللا في الاتصال بين الجيران.

التوصية هي تتبع المسار إلى نقطة دخوله وتصفية مصدر المعلومة المشوهة هناك، لا الاكتفاء بمعالجة النسخ الداخلية تباعا. يلزم مقارنة Adj-RIB-In وLoc-RIB في أكثر من موضع، وحالة الإعلان عبر عاكسات المسارات، ثم FIB الفعلية. إذا اختفى المسار من جدول BGP ولم تزل إدخالته من العتاد، أو أعيد إعلانه من مسار داخلي آخر، فإن نتيجة الحزم قد لا تطابق سجل الخطأ.

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

الذاكرة الجنائية جزء من الاحتواء

يفرض RFC 7606 مرافق تصحيح تسجل NLRI المعنية وتحتفظ برسالة UPDATE المشوهة كاملة للتحليل. من دون PDU أو بديل يصرح بوضوح بما فقد، يصعب إثبات السمة والطول والعلامات والعائلة وجميع الوجهات. اختفاء مسار وحده لا يثبت أن UPDATE مشوهة كانت السبب؛ ربما سحبها المرسل أو فشلت سياسة أخرى أو تغيرت القفزة التالية.

يمكن لـBMP Route Mirroring أن ينقل نسخة حرفية من الرسالة المستلمة ويشير إلى Errored PDU عوملت كسحب. لكنه مسار اختياري وليس سجلا مثاليا: يحدد RFC 7854 أيضا إشارة Messages Lost عندما تفقد رسائل، مثلا بسبب نفاد مساحة الانتظار. ويمكن أن تكون المرآة انتقائية أو ذات تكلفة موارد. يجب أن يذكر الدليل حالة الفقد، لا أن يحول غياب الرسالة عن الجامع إلى إثبات أنها لم تصل.

تشرح وثائق Cisco IOS XR فئات وإجراءات مثل TreatAsWithdraw وDiscardAttr، وتعرض رسائل سجل فيها الجار وطول الرسالة والسمة والعائلة وسياق NLRI. وتصف Junos الإعادة والسحب والإسقاط والمسارات المخفية وسلوك التسجيل. أما Nokia SR OS فتوضح update-fault-tolerance والفارق مع المعالجة القديمة. كل مصدر يثبت سلوك منتجه وإصداره فقط؛ لا توجد صيغة إعداد أو قيمة افتراضية تصلح قاعدة لكل المنصات.

التعافي ليس عودة اللون الأخضر

يبدأ إثبات النجاح من PDU الدقيقة وتصنيف المحلل والإجراء المختار ونطاقه. ثم تسجل جميع NLRI، وحالة Adj-RIB-In قبل الإجراء وبعده، واختيار Loc-RIB، والإعلانات اللاحقة، وFIB، ونتائج الحزم. بعد إصلاح المرسل، ينبغي رؤية UPDATE بديلة سليمة وعودة المسارات من دون حالة قديمة أو اختلاف بين العقد.

إعادة الجلسة في البداية قد تعيد الخطأ نفسه إذا بقي عيب المرسل. وtreat-as-withdraw قد يدخل في دورة اختفاء وعودة إذا استمر الإعلان المعيب ثم ظهر بديل نظيف مؤقتا. لذلك لا يكفي توقف العداد فترة قصيرة. النجاح هو تصحيح المصدر وتلاشي التكرار واتساق الحالة. الخلاصة العملية ليست أن RFC 7606 يحافظ على الاتصال؛ بل إنه يتيح للمشغل إنفاق أقل قدر مناسب من حالة التوجيه، بشرط أن يثبت بالمسار والحزمة ما أنفقه وما استعاده.