الخلاصة

  • يدمج الإصدار 03 RFC 7606 بوصفه مساهمته الرئيسية. ويرتب القسم 6.4.1 أربع استجابات لخطأ UPDATE: إعادة ضبط الجلسة، تعطيل عائلة عناوين، سحب المسارات الواردة في الرسالة المتأثرة، أو إسقاط سمة غير مؤثرة.
  • فئة الخطأ تحدد الاستجابة التي تفرضها القاعدة. وتعالج treat-as-withdraw المسارات فقط عندما يمكن تحليل NLRI بنجاح؛ أما إسقاط السمة فيقتصر على سمة لا تغيّر اختيار المسار أو تثبيته.

تصل UPDATE غير سليمة من جار. والسؤال التشغيلي هو: ما النطاق الذي يجب أن تتحمله الشبكة بسببها؟

مسودة draft-ietf-idr-bgp4-rfc4271bis المؤرخة 22 أكتوبر تنقل هذا السؤال إلى متن مواصفة BGP-4. ويقول الملحق B إن المساهمة الأساسية للإصدار 03 هي دمج RFC 7606، التي راجعت عام 2015 طريقة التعامل مع أخطاء رسائل BGP UPDATE. ويعرض القسم 6.4.1 أربع استجابات من الأقوى إلى الأضعف. إنها درجات لتحديد حجم الأثر، وليست قائمة يختار منها الموجّه ما يفضّله. نوع الخطأ يحدد المعالجة، مع إتاحة إعادة سلوك إعادة ضبط الجلسة عبر الإعداد.

أربع درجات للأثر

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

تأتي بعدها إيقاف AFI/SAFI، أي عزل عائلة عناوين داخل الجلسة نفسها. يحدد AFI وSAFI بروتوكول طبقة الشبكة ونوع معلومات الوصول المتبادلة. وتشير المسودة إلى إجراء Multiprotocol BGP القائم الذي يتيح للموجّه تجاهل المسارات اللاحقة لتلك العائلة عند تلقيها من الجار نفسه. قد تتأثر IPv4 unicast بينما تواصل IPv6 unicast العمل عبر الجلسة ذاتها. الحد هنا هو عائلة واحدة على اتصال واحد، وليس الجار كله.

أما treat-as-withdraw فيطال المسارات الموجودة في رسالة UPDATE التي تضم الخطأ. تُزال تلك المسارات من Adj-RIB-In كما لو أن الرسالة سحبتها صراحة. ويتطلب ذلك تحليل NLRI بنجاح. إذا لم يعرف الموجّه أي بادئات حملتها الرسالة، فلن يستطيع إعداد قائمة سحب دقيقة من فراغ.

وفي أدنى السلم يأتي إسقاط السمة. تُحذف سمة المسار غير السليمة ويستمر تحليل بقية UPDATE. الأثر أصغر، لكن الشرط ضيق: يجب ألا تؤثر السمة في اختيار المسار أو تثبيته. إسقاط قيمة تفضيل أو next hop أو أي معلومة تغيّر قرار التوجيه يجعل تبديل المسار يبدو كأنه تنظيف بسيط.

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

ما جمعه الإصدار 03

قدمت RFC 7606 بالفعل طريقة منقحة للتعامل مع أخطاء UPDATE. ويدمجها الإصدار 03 في متن BGP-4 الأساسي، بحيث يجمع بين المواصفة الرئيسية وسياسة الأخطاء في نص واحد. كما يلغي عدة رموز فرعية قديمة لأخطاء UPDATE بعدما لم تعد شروطها تولّد NOTIFICATION وفق الإجراءات الجديدة. ويغيّر معالجة NEXT_HOP غير الصحيح دلالياً من «تجاهل» إلى treat-as-withdraw، ويسمح للتنفيذ بالعودة إلى إعادة ضبط الجلسة عبر الإعداد.

الدمج جزئي؛ فالتعديلات التي أدخلتها RFC 7606 على مواصفات أخرى تبقى خارج هذه المسودة. وفي 24 أكتوبر، يصنف Datatracker الوثيقة على أنها Active Internet-Draft ضمن مجموعة IDR، وحالة IESG هي “I-D Exists”. وتشير الخطة إلى تقديم مواصفة BGP الأساسية إلى IESG في مايو 2027 بوصفها Internet Standard. ويذكر رأس المسودة أنها ستحدّث RFC 7606 إذا اعتُمدت.

تصل النتائج إلى الشبكة العاملة. إعادة ضبط الجلسة تحوّل خطأ رسالة إلى حدث على مستوى الجوار. تعطيل عائلة يغيّر مسار استعادة الخدمة على ذلك الاتصال. وقد ينقل treat-as-withdraw حركة البادئات المتأثرة بينما تستمر رسائل UPDATE الأخرى. أما إسقاط سمة فيبقي المسار ويحذف معلومة منه؛ وتعتمد سلامته على المعنى الدقيق للسمة.

الشبكة الحية هي مكان الاختبار. على المشغّل أن يربط لكل فئة خطأ سبب المحلل، والمعالجة المحددة، والفعل المنفذ، والمسارات التي تغيرت، ونتيجة التوجيه. حالة Established تجيب عن وضع الجلسة فقط. أما الدليل التشغيلي فيتبع قرار UPDATE عبر Adj-RIB-In، والمسار المختار، وFIB، ثم الحزمة.

المصادر