الخلاصة

  • لا تصبح قيمة BfdStrictNegotiated صحيحة في المراجعة 19 إلا إذا أعلن الطرفان Capability 74؛ إعلان طرف واحد عرضٌ وليس اتفاقاً.
  • بعض البرمجيات تميّز بين الوضع المتفاوض عليه، والحجب الأحادي، والتجاوز الذي يفرض الحجب رغم غياب إعلان الطرف الآخر، ولذلك لا تمثل كلمة «strict» سلطة واحدة.
  • يحتاج التشغيل الآمن إلى إثبات ما أُرسل وما استُقبل، وسلامة مسار OPEN، والوضع الفعلي في كل إصدار، وحالة BFD وBGP والعدادات عند الطرفين.

وصلت رسالة OPEN من الجهة المقابلة وفيها Capability 74. سجل الجهاز المحلي القدرة نفسها. بدت النتيجة واضحة: الطرفان يريدان BFD strict mode. لكن أداة التغيير كانت قد فعّلت على أحدهما خيار التفاوض، وعلى الآخر خياراً يفرض الانتظار حتى عند غياب موافقة الجار. وفي مسار ثالث كان بإمكان المشغّل تجاوز نتيجة التفاوض أصلاً.

الرقم واحد، أما حق إصدار قرار «لن تبدأ BGP بعد» فكان موزعاً بثلاث طرق.

هذه ليست لعبة لغوية. فالمراجعة 19 من draft-ietf-idr-bgp-bfd-strict-mode، المؤرخة في 26 أغسطس/آب 2026، تجعل الإعلان المتبادل للقدرة الصفرية الطول ذات الرمز 74 أساس الوضع المتفاوض عليه. الوثيقة مسودة نشطة لفريق عمل IDR، وتقول في رأسها إنها تستهدف Standards Track وتحدّث RFC 4271 إذا اعتُمدت. لكنها ما زالت تحمل حالة I-D Exists وليست RFC، كما أن مراجعات التشغيل والأمن وBGP Directorate تظل أدلة على نقاش جارٍ لا شهادة توافق تشغيلي.

الغرض من الآلية وجيه. في العلاقة المعتادة بين BGP وBFD يمكن أن تتأسس جلسة BGP قبل أن يصبح كاشف الفشل السريع جاهزاً. وقد تُعلن مسارات على وصلة متدهورة قبل أن يسقطها BFD. الوضع الصارم يغيّر ترتيب القبول: ينتظر متكلم BGP وصول جلسة BFD المرتبطة إلى Up قبل أن يسمح لآلة الحالات بالوصول إلى Established.

لكن ترتيب القبول هو ممارسة للسلطة. والسؤال الحاسم ليس هل كُتبت كلمة strict في التهيئة، بل من وافق على الشرط، وما الدليل الذي يحرر البوابة، ومن يستطيع تجاوزه.

القدرة إعلان نية، والتقاطع هو القرار

يعرض الجهاز الداعم Capability 74 في OPEN عندما يكون الوضع الصارم مفعلاً. ولا تصبح BfdStrictNegotiated صحيحة إلا إذا احتوت رسالتا OPEN المحلية والبعيدة على القدرة. بهذا يفصل التصميم بين ثلاث طبقات: رغبة محلية في التهيئة، وعرض أُرسل على السلك، وتقاطع ثنائي يسمح بتغيير سلوك آلة الحالات.

ذلك الفصل مهم لأن واجهات المنتجات لا تستخدم دائماً المصطلح نفسه للمعنى نفسه. توثيق Cisco الحالي يفرّق بين سلوك صارم أحادي أو مملوك للمنتج، ووضع strict-mode-negotiate القائم على القدرة، وخيار override يفرض البوابة حتى من دون دعم معلن من النظير. ويوضح أن السلوك غير القياسي قد يمنع الجلسة من الارتفاع. أما توثيق Juniper فيؤكد الإعلان المتبادل ويوصي بتهيئة متناظرة. لا تثبت هذه الوثائق وجود عيب في منتج؛ بل تثبت أن الحقل المنطقي strict=true يمحو قراراً لا يجوز محوه.

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

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

انتظار الطرفين ليس لحظة واحدة

بعد نجاح التفاوض، تضيف المراجعة 19 حالات انتظار فرعية في Connect وActive وOpenSent. قد يتبادل الطرفان OPEN بينما يحجب الجهاز المحلي KEEPALIVE منتظراً BFD المحلي. وقد يصل BFD البعيد إلى Up أولاً، فيرسل النظير KEEPALIVE قبل أن يحقق الطرف المحلي شرطه. لذلك تظهر حالة OpenSentConfirmedBfdUpPending: تحفظ الدليل على أن النظير تقدم، من دون الادعاء بأن BFD المحلي أصبح جاهزاً.

هذه الحالة تجيب عن سؤال السلطة بصورة أدق من ضوء أخضر موحد. استلام KEEPALIVE لا يمنح الطرف البعيد حق إعلان الشرط المحلي منجزاً. وارتفاع BFD في جهة لا يغيّر تلقائياً ساعة الجهة الأخرى. مراجعة BGP Directorate للمراجعة 18 نبهت إلى السباق، لأن معالجة KEEPALIVE مبكرة وفق OpenSent العادية قد تنتهي بخطأ في آلة الحالات وإعادة اتصال TCP. أما النص الأحدث فيحفظ الحدث وينتظر، وهو فرق بين دليلين لا بين نجاح وفشل بسيطين.

إذا هبط BFD قبل التأسيس في الوضع المتفاوض عليه، ترسل الآلة Cease مع السبب الفرعي BFD Down، وتغلق TCP وتحرر الموارد وتعود إلى Idle. وبعد Established يؤدي BFD Down أيضاً إلى حذف المسارات المكتسبة عبر الاتصال. رمز RFC 9384 يحسن وصف الإغلاق، لكنه لا يثبت سببه الجذري: عطب المسار، أو عدم تناظر التهيئة، أو اختلاف التوقيت، أو ازدحام، أو حجب متعمد للحزم، أو مشكلة مصادقة، أو سلوك إصدار.

الإصدار الجاري جزء من عقد الصلاحية

ملحق التنفيذ في المسودة يسجل Junos 23.2R1 وما بعده مع توافق معلن مع المراجعة 17، وIOS XR 24.3.1 وما بعده مع المراجعة 12، وNokia 23.7R1 مع المراجعة 07، ويشير إلى أن الإصدار المذكور من Nokia لا ينفذ BfdHoldTimer. هذه إفادات تنفيذ واردة في مسودة جارية، لا اعتماد مستقل ولا ضماناً لكل منصة.

قيمتها أنها تمنعنا من مساواة الرمز بالمعنى الكامل. قد يتفق جهازان على Capability 74، لكن أحدهما ينفذ مجموعة حالات أحدث، أو ينتظر عداداً لا يوجد عند الآخر، أو يربط أمراً محلياً بنموذج أحادي مختلف. «يدعم BFD strict mode» ليس مجموعة توافق. مجموعة التوافق هي زوج محدد من الإصدارات والأنماط والعدادات خضع لتجربة متبادلة يمكن إعادتها.

وتزيد الساعات المحلية المسألة تعقيداً. تعرف المسودة BfdHoldTime افتراضياً قدره 30 ثانية، وتستخدم BfdHoldTimer عندما يكون BGP holdtime المتفاوض عليه صفراً، كما يمكن أن يفرض hold-down بقاء BFD في Up زمناً قبل Established. قيمة hold-down محلية؛ توصي الوثيقة بقيم متقاربة ولا تفاوض على رقم واحد. قد يدخل جهاز Established ويبدأ حساب holdtime بينما لا يزال الآخر ممنوعاً من إرسال KEEPALIVE. عندها تنهي آلية الحماية الجلسة التي كان يفترض أن تحميها.

إيصال القبول يجب أن يُقرأ من الجهتين

قبل التغيير، لا يكفي تصدير تهيئة واحدة. يلزم صف لكل طرف يضم المنصة والإصدار، والأمر الفعلي ومعناه، ومراجعة السلوك الموثقة، وBGP holdtime، وBFD hold time، وhold-down، وطريقة المصادقة، والحالات الفرعية المتوقعة. ثم يضاف ما حدث بالفعل: capability 74 المرسلة والمستقبلة، وقيمة BfdStrictNegotiated، وهوية جلسة BFD ونقاط نهايتها، وأزمنة الانتقال، وحالة BGP، وإشعار الإغلاق، ونتيجة المرور.

ويجب أن يتعمد الاختبار خلق عدم التناظر. فعّل التفاوض في جهة واحدة وتأكد من أن السلوك العادي يستمر بدلاً من حجب أحادي خفي. استخدم قيم hold-down مختلفة ولاحظ من يدخل Established أولاً. أخّر BFD المحلي ودع النظير يرسل KEEPALIVE، ثم تحقق من حالة الانتظار المخصصة بدلاً من إعادة ضبط غامضة. احجب حزم BFD في مختبر مضبوط وتأكد من أن أثر الإتاحة يظهر كدليل مستقل لا كعبارة عامة «فشل BGP».

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

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

قيمة BFD strict mode أنه يمنع تبادل المسارات قبل أن يصبح كاشف الفشل مستعداً. ولأن هذه البوابة قوية، يجب ألا تستمد سلطتها من تشابه كلمة في واجهتين. أرسل الطرفان Capability 74، نعم. لكن الاتفاق الحقيقي لا يظهر إلا عندما يثبت كل طرف ما عرضه، وما قبله، وما انتظره، ومن كان يملك حق تجاوز الانتظار.

المصادر