الخلاصة

  • تقترح المراجعة 13 حل next hop في forwarding database لمستوى البيانات الذي تختاره السياسة، وتسمح باستخدام نتيجة OAM للمستوى نفسه في أهلية المسار.
  • لا تحدد المسودة واجهة تُظهر المستوى والجدول ونتيجة الفحص وسبب الاستبعاد، ولذلك قد يرى المشغّل اختفاء المسار من دون معرفة الدليل الذي حرّك القرار.
  • يلزم إيصال قرار يربط كل تغيير بالمسار والسياسة والجدول والآلية والعمر والنتيجة، مع قياس مستقل للتوجيه والخدمة وإجراء rollback معروف.

بدأت الحادثة بسؤال بسيط: لماذا اختفى مسار كان موجوداً قبل دقيقة؟ أظهر سجل BGP أن best path تغيّر، ثم خرج withdrawal إلى الجار. كانت جلسة BGP مستقرة، ولم يتغير AS path أو local preference. لم تعرض واجهة التشغيل سوى عبارة عامة: unresolvable.

كان السبب الحقيقي نتيجة OAM سلبية مرتبطة بـ next hop. لكن الواجهة لم تعرض اسم مستوى البيانات، ولا VRF أو الجدول، ولا وقت الفحص، ولا ما إذا كانت النتيجة قديمة، ولا عدد المسارات الأخرى التي استُبعدت معها. عرف النظام لماذا تصرف. لم يسمح للإنسان بمعرفة ذلك.

تتناول draft-ietf-idr-bgp-bestpath-selection-criteria-13 مشكلة تشغيلية حقيقية. صدرت المراجعة في 14 سبتمبر 2026 بوصفها Internet-Draft نشطة ضمن مجموعة IDR، وتهدف إلى Proposed Standard وتقترح تحديث RFC 4271 إذا اعتُمدت. ليست RFC حالياً. يسجل Datatracker أن قضايا المراجعة تحتاج إلى حل وإلى نسخة جديدة؛ وتصفها مراجعات Routing وOperations وSecurity وBGP بأنها تحتاج إلى مزيد من العمل.

ينطلق النص من Route Resolvability Condition في RFC 4271. قبل أن يدخل مسار BGP في منافسة best path، يجب أن يكون next hop قابلاً للحل. لكن وجود route في IP RIB لا يضمن أن المستوى الفعلي الذي سيحمل traffic يعمل. في MPLS VPN قد يبقى PE البعيد reachable عبر IP، بينما يفقد LSP إدخال label أو يتعطل forwarding في عقدة وسطية. يستمر PE المحلي في جذب traffic ثم يسقطه داخل الشبكة.

تقترح المراجعة معيارين. الأول يقول إن فحص reachability ينبغي أن يستخدم forwarding database لبروتوكول مستوى البيانات الذي تختاره السياسة. والثاني يسمح بفحص path availability بواسطة آلية OAM مرتبطة بالمستوى نفسه. بذلك يصبح وجود المسار في BGP مرتبطاً بإشارة من forwarding الفعلي، لا بمجرد route IP.

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

كلمة واحدة تخفي سلسلة قرارات

وصف unresolvable قد ينتج من حالات مختلفة: لا route للـ next hop؛ لا forwarding entry في MPLS؛ اختير جدول أو VRF لا يحتوي endpoint؛ انتهت صلاحية نتيجة OAM؛ لم تبدأ الجلسة بعد؛ فشل authentication؛ وصلت نتيجة سلبية صحيحة؛ أو تعطلت آلية القياس بينما ظل production traffic يعمل.

لكل حالة استجابة مختلفة. غياب entry قد يتطلب إصلاح control protocol. اختيار جدول خاطئ يتطلب تصحيح policy. نتيجة منتهية تحتاج إلى إعادة فحص. آلية غير مهيأة تعني indeterminate. false negative يحتاج إلى منع automation من سحب مسار جيد. جمعها تحت reason code واحد يحذف المسار العملي إلى الإصلاح.

تقول مراجعة Operations إن نتيجة الفحص غير observable في النص الحالي. وتقترح إظهار data plane المختار، ونتيجة كل next hop، وعدد المسارات التي استبعدتها الآلية. وهذا الحد الأدنى لا يكفي وحده. يجب أيضاً ربط القرار بالـ prefix والمسار والpeer وAFI/SAFI وVRF والجدول الدقيق وpolicy version وforwarding generation وآلية OAM ووقت النتيجة ومدة صلاحيتها.

هذا السجل ليس شرطاً وارداً حرفياً في المراجعة 13؛ إنه توجيه تشغيلي تفرضه السلطة الجديدة التي يمنحها التصميم للقياس. إذا كان signal يستطيع تغيير route، فيجب أن تكون provenance الخاصة به قابلة للقراءة بالسرعة نفسها التي يحدث بها التغيير.

الغموض يوسّع سطح الهجوم

توضح مراجعة Security أن التغيير الحقيقي هو انتقال signal من data plane إلى قرار في control plane. إذا تمكن شخص من drop أو delay أو spoof لرسائل liveness، فقد يجعل router يستبعد كل route تستخدم next hop تحت policy معينة. ثم ينقل BGP النتيجة إلى الجيران على شكل withdrawal أو replacement.

في dual-homed topology، قد يؤدي تعطيل فحص جهة واحدة إلى steering للtraffic نحو الجهة الأخرى. ويمكن لنتيجة إيجابية مزيفة أن تبقي path مكسوراً، بينما يؤدي false negative إلى سحب path سليم. يشير RFC 5880 إلى false up وfalse down في BFD، ويناقش RFC 8029 spoofing وreplay وtampering في LSP Ping. لا تختار المسودة آلية بعينها؛ وهذه الأمثلة تحدد حدوداً يجب ألا يمحوها interface عام.

حتى مع authentication، يستطيع طرف on-path إسقاط probe صحيح. وقد يمرر probe بينما يسقط data، أو يحدث العكس. لذلك لا يكفي reason code يقول OAM failed. يجب إظهار الآلية، mode، authentication state، scope، آخر نجاح وآخر فشل، ومدى تطابق مسار القياس مع traffic.

غياب هذه التفاصيل لا يبطئ troubleshooting فقط. إنه يسمح لخطر أمني بأن يبدو مثل network fault عادي، أو يسمح لعطل القياس بأن يبدو مثل forwarding failure مؤكّد. القرار يصبح غير قابل للطعن لأن الدليل الذي أنتجه غير معروض.

الإجراء ليس نتيجة الخدمة

withdrawal يثبت أن control plane أرسل تحديثاً. لا يثبت أن traffic انتقل إلى البديل، ولا أن الجار قبله، ولا أن FIB الجديدة ثبتت، ولا أن application نجحت. وبالمثل، نتيجة OAM إيجابية تثبت استجابة وفق semantics لآلية محددة وفي وقت محدد، ولا تثبت كل ECMP member أو FEC أو remote VRF أو customer prefix.

يجب أن تبقى السلسلة منفصلة: استلام BGP path؛ اختيار المستوى والجدول؛ قراءة forwarding state؛ إجراء OAM؛ تفسير السياسة للنتيجة؛ إعادة تشغيل decision process؛ تغيير FIB؛ إرسال update؛ معالجة الجار؛ قياس traffic؛ ثم إثبات service outcome. كل خطوة لها receipt مستقل.

عندما تعرض أداة التشغيل السهم الأخير فقط، فإنها تخلط بين السبب والفعل والنتيجة. لا يستطيع المشغّل معرفة هل السحب أصلح blackhole، أم خلقه بسبب false negative، أم لم يغيّر الخدمة لأن البديل نفسه معطل.

rollback يحتاج إلى قائمة ما تغيّر

التراجع ليس إيقاف feature وحسب. إذا بقيت نتائج سلبية مخزنة أو ظلت paths معلّمة ineligible، فقد يستمر الأثر بعد تعطيل الفحص. يلزم استعادة policy version معروفة، وإبطال القرارات المشتقة عند الحاجة، وإعادة تقييم paths المتأثرة، ثم التحقق من FIB والإعلانات وtraffic.

لذلك يجب أن تنتج كل عملية استبعاد قائمة قابلة للاستعلام: ما next hop؛ كم path؛ ما الخدمات؛ ما البديل؛ ما reason؛ وما event الذي سيعيدها إلى المنافسة. كما يجب تسجيل override البشري، مدته والسلطة التي منحته. من دون ذلك قد يتحول workaround المؤقت إلى policy دائمة لا يراها أحد.

تشكك المراجعات أيضاً في قول المسودة إن التأثير السلبي في convergence غير متوقع. جلسة واحدة قد تتحكم في عدد كبير من routes، وflapping قد يولد موجات من withdrawals وreadvertisements. إن لم تعرض المنصة fan-out وtransition rate، فسيرى المشغّل كل route كحادثة مستقلة ويغفل المصدر المشترك.

قيمة المراجعة 13 أنها ترفض اعتبار IP reachability دليلاً كافياً على MPLS forwarding. لكن لا يجوز استبدال التبسيط بتبسيط آخر: إشارة OAM لا تصبح حقيقة شاملة لأنها وصلت إلى BGP. السلطة القابلة للدفاع عنها هي سلطة تشرح أي دليل استخدمت، في أي نطاق وزمن، وكيف يمكن إلغاء أثرها.

المصادر