الخلاصة

  • يضيف RFC 9494 فترة احتفاظ ثانية لكل AFI/SAFI، لكن قيمة LLST المعلنة لا تثبت بقاء next hop أو FIB أو الخدمة صالحة.
  • تتحول المهلة إلى سلطة قابلة للتدقيق فقط عندما يقيدها المستقبل محلياً، ويستبعد المسارات غير المناسبة، ويتتبع الاختيار والنشر والتحويل، ويثبت نهايتها عبر EoR أو انتهاء المؤقت أو تدخل المشغل.
  • قد يهزم مسار قديم أكثر تحديداً مساراً حديثاً أقل تحديداً حتى بعد خفض تفضيله؛ لذلك لا يكفي ظهور بديل جديد في جدول BGP لإثبات سلامة المرور.

لنتصور حادثة مقصودة للتوضيح. تنقطع جلسة BGP، ثم تنتهي مدة Graceful Restart العادية. يحتفظ helper مع ذلك بمسار أكثر تحديداً ست ساعات إضافية. يضع عليه علامة stale ويخفضه إلى أدنى تفضيل. وفي الوقت نفسه يصل مسار تجميعي حديث من جهة سليمة. تبدو لوحة التحكم مطمئنة: يوجد بديل جديد، والمسار المحتفظ به لم يُحذف. لكن longest-prefix match ما زال يرسل الوجهات الواقعة داخل البادئة الأدق إلى الطريق القديم. جدول التوجيه يملك إجابة؛ الخدمة خلفها لم تعد تجيب.

ليس هذا خللاً بالضرورة. صُمم RFC 9494 لكي يسمح باحتفاظ أطول عندما يستغرق بناء control plane وقتاً كبيراً، أو عندما تنقل BGP معلومات أقرب إلى إعداد موزع منها إلى قابلية وصول متغيرة بسرعة. المشكلة أن الأداة نفسها تستطيع إطالة black hole أو ربط خدمة منتهي الصلاحية أو اختلاف في الاختيار بين الموجهات.

السؤال القيادي إذن ليس: هل تدعم المنصة LLGR؟ السؤال هو: من سمح لحالة من الماضي بأن تستمر في صنع قرار حاضر، وما الحد المحلي المقبول، وأي دليل يستطيع إيقاف التسامح قبل أن ينتهي العداد؟

مرحلتان متتابعتان وليستا ضماناً واحداً

يحدد RFC 4724 آلية BGP Graceful Restart. تنقل capability رقم 64 مدة Restart Time ومعلومات الحفظ لكل عائلة. عندما تسقط الجلسة يمكن للـ receiving speaker أن يحتفظ مؤقتاً بمسارات المتحدث الذي يعيد التشغيل. ويعلن End-of-RIB اكتمال مجموعة التحديثات الأولية لكل AFI/SAFI.

سبب إعادة الضبط جزء من الدليل. يسمح RFC 8538 للطرفين، بعد تبادل N bit، بتطبيق إجراءات graceful على أنواع كثيرة من NOTIFICATION وعلى انتهاء Hold Time. أما Cease المصحوب بـ Hard Reset فيطلب إنهاء كاملاً. عبارة «الجلسة سقطت» بلا رمز الخطأ والرمز الفرعي والتوقيت لا تكفي لتفسير سبب بقاء المسارات.

يضيف RFC 9494 capability رقم 71. تحتوي كل خانة على AFI وSAFI وflags وLong-Lived Stale Time بطول 24 bit. تُقاس LLST بالثواني ولا توجد قيمة افتراضية عالمية؛ فصلاحية IPv4 unicast ليست صلاحية Route Target constraints أو FlowSpec أو معلومات discovery.

لا تعمل LLGR كمسار مستقل حول GR. إذا أعلن الطرف capability LLGR من دون capability GR وجب تجاهل LLGR. وهي تستعير من GR مفهوم EoR وآلة الحالات وقواعد reset. لذلك لا يثبت ظهور الرقم 71 في أمر عرض أن احتفاظاً صالحاً جرى التفاوض عليه؛ يلزم أيضاً الرقم 64، والعائلة المحددة، والقيم المتبادلة، والسياسة المحلية.

يمكن أن تعمل المرحلتان بالتتابع. خلال مدة GR لا تنخفض أفضلية المسار لمجرد أنه محتفظ به. عند الدخول في LLGR يصبح المسار least preferred. قبل عودة الجلسة يكون الحد البروتوكولي الأعلى للعائلة هو Restart Time المستلم مضافاً إليه LLST المستلم، مع خضوع القيم للحد الأعلى أو الأدنى الذي يفرضه المستقبل. ويمكن أن تكون إحدى المرحلتين صفراً.

أدنى تفضيل لا يعني عدم الاستخدام

عند بداية LLGR يشغل helper مؤقتاً لكل AFI/SAFI، ويضيف LLGR_STALE إلى المسارات الباقية، ويحذف المسارات التي تحمل NO_LLGR، ثم يطبق قواعد التفضيل والنشر. سجلات IANA للـ capability codes ولـ well-known communities تثبت التعيينات: LLGR_STALE هي 0xFFFF0006 أو 65535:6، وNO_LLGR هي 0xFFFF0007 أو 65535:7.

يبين RFC 1997 البنية التقليدية للـ communities. وجود القيمة الصحيحة لا يصادق على المتحدث ولا يفوض البادئة ولا يثبت أن الطريق لا يزال قابلاً للاستخدام. إنها تعليمة سياسة تنتقل مع المسار، وليست شهادة على حالته.

يجب أن يكون المسار LLGR-stale أقل تفضيلاً من أي مسار غير موضوع في فئة least preferred. وإذا كانت كل البدائل least preferred تعود قواعد كسر التعادل المعتادة. لكن قرار BGP ليس قرار مطابقة الوجهة. يقرر RFC 4271 اختيار المسار، ثم يختار التحويل المسار الأكثر تحديداً للعنوان. لذلك يستطيع prefix قديم بطول /24 أن يستمر في الفوز محلياً أمام aggregate حديث بطول /16. يحذر RFC 9494 صراحة من فقدان الاتصال في هذا السيناريو.

كما أن خفض التفضيل قد لا يكون متسقاً بين كل متحدثي iBGP. يربط LLGR الحالة المحلية بحالة الجلسة المحلية، وقد يرى موجهان الحالة نفسها بصورة مختلفة. في شبكة تستخدم hop-by-hop forwarding قد تختار العقد مسارات متعارضة فتتشكل حلقة. لا يوصي RFC 9494 باستخدام LLGR لمجموعات المسارات التي تتعرض لهذا الخطر. وهذا حد معماري، لا إعداد timer يمكنه إصلاحه.

من يحق له رفض الاحتفاظ الطويل؟

تمنح NO_LLGR المسار وسيلة لرفض المرحلة الطويلة. عند دخول LLGR يحذف helper المسارات التي تحملها بدلاً من تمديدها. لكن community طلب ضمن سياسة ثنائية، وليست إثباتاً أن كل وسيط مررها أو احترمها. يجب أن تظهر في Adj-RIB-In الفعلية وفي نتيجة السياسة، لا في تصميم نظري فقط.

ولا ينبغي نشر مسار LLGR-stale إلى جار لم يعلن LLGR. يصف RFC 9494 إجراء اختيارياً للانتشار الجزئي، لكنه محصور في جيران iBGP أو confederation ويشترط NO_EXPORT وLOCAL_PREF صفراً. هذا ليس إذناً عاماً لنقل stale reachability إلى eBGP. ويظل معنى NO_EXPORT محكوماً بتسجيل المجتمع وسياسة الجار.

الأهم أن المستقبل هو من يصنع الأثر المحلي. المرسل يقترح LLST ونطاق AFI/SAFI؛ المستقبل يختار تمكين الوظيفة، ويطبق الحد، ويقرر المسارات المستثناة وسياسة النشر. ينص RFC 9494 على ألا تُمكّن إجراءاته افتراضياً، بل تحتاج إلى إعداد إيجابي لكل AFI/SAFI. وهنا تظهر السلطة الحقيقية: لا يستطيع إعلان capability بعيد أن يجبر شبكة على استئجار وقت غير محدود لحالته القديمة.

ينبغي أن تكون حدود الوقت مرتبطة بنوع المعلومة. قد يكون الاحتفاظ الطويل منطقياً لمعلومات شبه ثابتة استغرق جمعها ساعات، وقد يكون خطيراً لمسار Internet عادي حيث تتغير صلاحية next hop خلال ثوان. وصف كل العائلات بعبارة «نحتاج الاستمرارية» يمحو الفرق الذي جعل RFC يرفض قيمة افتراضية واحدة.

عودة الجلسة لا تصفّر الدين

عودة TCP وبلوغ BGP حالة Established لا تعني أن المسارات القديمة أصبحت حديثة. بعد إعادة الاتصال تبقى LLST جارية إلى أن يتزامن AFI/SAFI. يحدث التزامن عند استقبال EoR أو انتهاء GR Selection_Deferral_Timer. وإذا انتهت LLST أولاً يحذف helper كل مسار stale لم يجدده peer.

يحمل F bit في LLGR إفادة عن حفظ الحالة للعائلة خلال restart السابق. إذا رجعت الجلسة من دون AFI/SAFI، أو اختفت capability المطلوبة، أو لم يعد F bit المناسب مضبوطاً، وجب حذف المسارات المحتفظ بها لتلك العائلة فوراً. لهذا يجب أن تقارن التحقيقات ما تفاوض عليه الطرفان قبل الانقطاع وبعده، لا أن تسجل «neighbor up» فقط.

لا يتجدد مؤقت LLST أثناء الفشل لمجرد وصول قيمة capability جديدة في مكان ما. وباستثناء تدخل يدوي واضح، لا يعاد تحديثه حتى يقيم peer جلسة جديدة ويتزامن. التمديد التلقائي المتكرر يحول budget محدوداً إلى احتفاظ لا ينتهي، ويلغي الغرض من الحد.

أما EoR فهو دليل اكتمال epoch التحديث الأولي للعائلة، وليس إثباتاً مستقلاً لنجاح الحزم. قد يكتمل الإعلان بينما يظل next hop غير قابل للحل، أو لا تُبرمج FIB كما ينبغي، أو يبقى label قديماً، أو تفشل الخدمة بعد المسار. نهاية control-plane لا تنهي واجب data-plane.

عندما تحتفظ BGP بما يشبه الإعداد

تظهر الحجة الأقوى لـ LLGR عندما تكون المعلومات الموزعة مكلفة البناء وبطيئة التغير: state يخدم VPN أو discovery أو قيود توزيع، لا مجرد وصول hop-by-hop. لكنه ليس سبباً لإهمال المعنى. فالحالة المحتفظ بها قد تربط مساراً بـ label أو encapsulation أو خدمة تغيرت بعد سقوط الجلسة.

يحذر RFC 9494 تحديداً من إعادة استخدام MPLS label. إذا بقي مسار VPN stale بينما أُعيد تخصيص label إلى VPN أخرى، فقد يوجه الطريق القديم الحركة إلى سياق جديد. لذلك يجب أن يكون زمن إعادة استخدام label أطول من أقصى نافذة stale الفعلية، أو توجد آلية تمنع الالتباس. يصبح timer هنا حد عزل أمني، لا مجرد ضبط availability.

تبقى قابلية حل next hop شرطاً أساسياً. وقد تضيف BFD إشارة منفصلة عن صلاحية المسار في مواضع مناسبة، لكنها لا تحول community أو timer إلى ضمان. دليل liveliness يجب أن يطابق الشيء الذي يدعي حمايته: الوصول إلى next hop لا يثبت صحة الخدمة، وفحص الخدمة لا يفسر وحده سياسة النشر.

كما تختلف المنصات. تعرض وثائق Cisco 8000 مفهوماً وإعدادات لـ BGP persistence، وتوثق Juniper LLGR في Junos، وتشرح Nokia تفاعل GR وLLGR في SR OS. الأوامر والقيم الافتراضية والعائلات المدعومة ليست قابلة للتعميم. يجب أن تحمل كل حجة تشغيلية اسم المنصة والإصدار الفعلي.

سجل يثبت حقبة stale كاملة

يبدأ الدليل قبل الفشل. احفظ capability المحلية والبعيدة، وتفاصيل AFI/SAFI، وRestart Time، وLLST، وN bit وF bit، والحدود المحلية، وسياسة NO_LLGR والنشر. يوضح RFC 5492 كيف تُعلن capabilities في BGP؛ لكن الإعلان وحده لا يخبرنا ما قبله النظام فعلياً.

عند الحادثة احفظ سبب reset ورمزه ووقته، ولحظة دخول GR ثم LLGR، والمسار كما استُلم، والـ communities بعد السياسة، وقرار best path. بعد ذلك تتبع recursive next hop، وRIB، وFIB، وحالة label أو encapsulation، وعدادات الحزم وتجارب الخدمة طوال الحقبة. لقطة واحدة بعد الانقطاع قد تثبت وجود المسار، لكنها لا تثبت أنه ظل صالحاً لساعات.

ينتهي السجل بحدث واضح: EoR مع تحديث المسارات، أو انتهاء LLST وحذف غير المجدد، أو clear يدوي له مالك وسبب. ثم يلزم إثبات أن الطريق القديم خرج من FIB وأن الإعلان النظيف عاد وأن الاختبار عبر الوجهة نجح. إذا لم نستطع تحديد متى انتهت سلطة المسار القديم، فنحن لا نملك budget؛ نملك أملاً.

المصادر

  1. RFC 9494 — Long-Lived Graceful Restart for BGP
  2. RFC 4724 — Graceful Restart Mechanism for BGP
  3. RFC 8538 — Notification Message Support for BGP Graceful Restart
  4. RFC 5492 — Capabilities Advertisement with BGP-4
  5. RFC 1997 — BGP Communities Attribute
  6. RFC 4271 — A Border Gateway Protocol 4
  7. IANA — Capability Codes
  8. IANA — BGP Well-known Communities
  9. Cisco — Understanding BGP Persistence
  10. Juniper — Long-Lived Graceful Restart
  11. Nokia — BGP Graceful Restart and Long-Lived Graceful Restart