الخلاصة
- تسمح RFC 2918 بطلب Adj-RIB-Out الحالي من peer قادر لـAFI/SAFI متفاوض عليه، مع بقاء export policy لدى الجار.
- تحيط RFC 7313 الإعادة بـBoRR وEoRR، فتجعل القديم stale، وتستبدل ما يعود، وتحذف ما يبقى غائباً عند النهاية.
- لا يثبت نجاح الأمر أو استمرار الجلسة الأثر؛ يجب مقارنة prefix وattribute والاختيار وFIB والحركة.
يصلح مشغل inbound filter رفض مئتي prefix مشروع. ينجح commit، لكن الإعلانات المرفوضة لا تعود من تلقاء نفسها. إذا لم يحتفظ router بنسخة خام، فلا توجد inputs تمر عبر القاعدة الجديدة.
وتواجه السياسة الأشد المشكلة نفسها: قد تبقى routes المقبولة سابقاً في RIB حتى يعاد تقييمها. يكون الملف صحيحاً والحالة العاملة قديمة.
كانت inbound soft reconfiguration تحفظ جميع updates بلا تعديل، بما فيها المرفوضة. تشتري استقلالاً محلياً بكلفة memory وCPU مستمرة.
تعيد RFC 2918 توزيع الحالة. تعلن capability code 2 القدرة على استقبال ROUTE-REFRESH. لا يرسل requester الطلب إلا بعد استلام capability من peer، ويحدد AFI/SAFI جرى تفاوضه.
يعيد peer إعلان Adj-RIB-Out الحالي وفق outbound policy الخاصة به. لا يقرأ الطالب database البعيدة ولا يفرض route مفلترة. يسمع فقط ما يختار الجار إصداره الآن.
ليست هذه archive تاريخية. قد تكون route القديمة سُحبت، أو تغيرت attributes والسياسة البعيدة، أو ظهرت route جديدة. النتيجة تقاطع حالتين حاضرتين.
لذلك لا يشرح count السبب. نقص خمسمئة route قد ينتج من filter محلي أو withdraw بعيد أو export جديد. يلزم exact set وتوقيت وattributes.
لم تحدد RFC 2918 الأساسية بداية ونهاية replay كامل. يمكن أن تختلط UPDATE العادية، فلا نعرف أثناء العملية هل route غائبة أم لم تصل بعد.
تضيف RFC 7313 Enhanced Route Refresh code 70. يفتح BoRR الدورة ويغلقها EoRR. عند BoRR يعلم المستقبل routes الخاصة بذلك peer وAFI/SAFI بأنها stale. تستبدل الإعلانات العائدة، وتحذف EoRR الباقي.
يبقى stream حياً. يمكن إرسال التغييرات التي تقع أثناء الدورة. يثبت EoRR اكتمال الفترة، لا صحة كل route ولا تطابق الماضي.
يجوز للمستقبل وضع حد محلي لعمر stale والحذف من دون انتظار دائم. يمنع ذلك بقاء reachability قديمة، لكن timer قصيراً قد يحذف routes سليمة قبل نهاية replay بطيء.
يختلف EoRR عن End-of-RIB في Graceful Restart. الأول يغلق إعادة الإعلان، والثاني ينسق استمرارية control plane. تفصل RFC 7313 بينهما لتجنب purge مبكر.
كما تختلف inbound وoutbound soft operations. في inbound يطلب المحلي من البعيد أو يستخدم نسخة محفوظة؛ في outbound يعيد بناء إعلاناته هو. الاسم المتشابه يخفي مالك state المختلف.
تعرض وثائق Cisco ثلاثة مسارات: request ديناميكي مع capability، معالجة copy مخزنة، أو hard reset عند غياب الاثنين. يهدم الأخير session ويؤثر في كل reachability.
الخيار مبادلة بين الموارد والاعتماد. تخزين raw input يشتري استقلالاً بالذاكرة. Route Refresh يوفرها لكنه يعتمد على peer وexport الحالي. Hard reset يوسع blast radius.
توضح FRRouting أن بعض controls ما زالت تحتاج routes المرفوضة، مثل طرق count معينة في maximum-prefix. استعادة feed الحالي لا تنشئ inventory تاريخياً لكل غرض.
تعرف RFC 5291 ORF كـcapability مستقلة. يمكن للمستقبل إرسال filter information، لكن ROUTE-REFRESH العادي لا يحرر policy البعيدة.
يبدأ الإثبات قبل التغيير. سجل advertised وreceived capability الأساسية وenhanced لكل اتجاه وAFI/SAFI. الدعم المحلي لا يثبت استجابة peer، والدعم الأساسي لا يثبت BoRR/EoRR.
ابن baseline من exact prefix وattribute، والمقبول، وbest path، وpolicy version، وuptime، وFIB next hop. إذا كانت المرفوضات غير مرئية، صرّح بالثغرة.
ابدأ بـpeer وfamily واحدين. سجل request وBoRR وEoRR والمدة. راقب غياب النهاية، stale timeout، CPU، reset، withdraw وتغير best path.
قارن المجموعات لا الأعداد وحدها. حذف عشر وإضافة عشر يبقي العدد. Aggregate وmore-specifics يغيران الحجم. Attribute مختلف يغير النتيجة مع NLRI نفسه.
ثم تحقق من forwarding. قد تخسر route المقبولة الاختيار، أو يفشل next hop، أو يعجز الرابط الجديد عن الحمل. Refresh يوفر input ولا يثبت packet delivery.
يتطلب rollback replay أيضاً. إعادة policy القديمة لا تعيد القرارات تلقائياً. وإذا تغير remote export، فقد يستحيل استرجاع snapshot الأولى.
ينبغي للأتمتة ضبط concurrency. طلب refresh من عدد كبير يولد UPDATE وإعادة حساب. Soft يعني عدم إسقاط session عمداً، لا غياب العمل.
تظهر مواصفة Heng Lu الدنيا في طلب صغير: peer وfamily وإعادة إعلان. يحتفظ كل AS بسياساته. وتقتضي أولوية running code capability متفاوضاً عليها، ودورة مرصودة، وRIB diff وFIB بدلاً من رسالة نجاح.
يفصل Route Refresh إصلاح policy عن هدم session، لكنه لا يفصل الإصلاح عن الدليل. وحدها routes التي عادت وأعيد حكمها وظهر أثرها في forwarding تثبت سلطة القاعدة الجديدة.
Sources
- RFC 2918: Route Refresh Capability
- RFC 7313: Enhanced Route Refresh
- RFC 4271: BGP-4
- RFC 5291: Outbound Route Filtering
- RFC 4724: Graceful Restart
- Cisco: dynamic inbound soft reset
- Cisco IOS XR: soft clear
- FRRouting: وثائق BGP
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
- Heng Lu: Data Sovereignty
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
