الخلاصة

  • تحوّل Route Target Constraints اهتمام الاستيراد لدى PE إلى حالة إفصاح خاصة بكل نظير: تتحرك RT Membership NLRI باتجاه مصادر المسارات، وتعود قابلية الوصول الخاصة بـ VPN عبر الرسم المعكوس.
  • لا يكتمل إثبات الانضمام أو الانسحاب أو الانتقال إلا بتفاوض AFI 1/SAFI 132، والعضوية الدقيقة، ومزامنة محدودة الزمن، وفروق Adj-RIB-Out، وسياسة أمن مستقلة، وأدلة VRF والتسمية وFIB والحزم.

تبدأ الحادثة من لوحة تبدو مطمئنة. VRF الجديدة موجودة، وقائمة import RT توافق المسار المنتظر. لدى PE المصدر المسار في جدول VPN، ولا توجد جلسة ساقطة أو إنذارات سعة على RR. ومع ذلك، يبقى جدول الطرف المستقبل فارغاً.

الخلل الأول قد لا يكون في المسار المتجه من المصدر. ربما لم تنشئ PE المستقبلة RT Membership NLRI، أو لم يحتفظ العاكس بالاتجاه اللازم منها. عندئذ لا يجد RR سبباً لإدخال المسار في VPN Adj-RIB-Out الخاص بذلك النظير. المسار موجود، لكن طلب الإفصاح عنه غير موجود.

هذه هي وظيفة RFC 4684، المعروفة باسم RTC أو RT-Constrain. بدلاً من توزيع كثيف يرسل معظم مسارات VPN إلى جميع أجهزة PE لتسقط غير اللازمة محلياً، تعلن الجهة المستقبلة اهتمامها، ويبني RR مرشح إخراج لكل نظير، ثم يعيد المسارات المطابقة فقط.

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

Route Target يحدد الأهلية ولا يضمن الوصول

يفصل RFC 4364 بين Route Distinguisher وRoute Target. يجعل RD البادئات المتداخلة فريدة في BGP، بينما تستخدم RT، وهي extended community، في سياسات التصدير والاستيراد الخاصة بـ VRF.

حين تطابق إحدى RT في المسار إحدى قيم import RT في VRF تصبح المسار مؤهلة للدخول. لا يعني ذلك أنها ثُبّتت. ما زالت هناك عملية اختيار BGP، والسياسة المحلية، وعلاقة PE/CE، وحل next hop والتسمية، وبرمجة RIB وFIB.

لا تغيّر RTC هذا الحد. إعلان العضوية وصفٌ لطلب التوزيع، لا هوية عميل. لا ينشئ VRF، ولا يصادق الجهة التي تستخدم RT، ولا يتحقق من مسار VPN، ولا يثبت مرور الحزم.

لذلك قد يكون الغياب في المصدر، أو استقبال RR، أو عضوية RTC، أو انعكاس مسارات العضوية، أو المرشح المشتق، أو Adj-RIB-Out، أو استيراد PE، أو الاختيار، أو التسمية، أو FIB، أو مستوى البيانات. يبدأ التشخيص الصحيح من أول حد لا يحمل الحالة المتوقعة.

الاهتمام يتحرك عكس قابلية الوصول

يقيم RFC 4684 رسماً معكوساً. يعلن المستقبل اهتمامه باتجاه الأنظمة التي تحتفظ بمسارات VPN أو توزعها، ثم تتحرك المسارات المطابقة عائدة إليه. ليست العضوية أمراً بعيداً؛ إنها كائن قابلية وصول في BGP يخضع للاختيار والسياسة وانعكاس المسارات.

تُنقل العضوية في MP_REACH_NLRI أو MP_UNREACH_NLRI وفق RFC 4760، باستخدام AFI 1 وSAFI 132. باستثناء العضوية الافتراضية، يحتوي المفتاح على origin AS بطول أربعة octets وRoute Target بطول ثمانية، ضمن بادئة من 32 إلى 96 بتاً. البادئة الأقصر تعبر عن اهتمام أوسع، وتستهلك نطاق إفصاح وحالة أكبر.

بادئة العضوية ذات الطول صفر هي default RT membership. تعني استعداد النظير لتلقي جميع إعلانات VPN ذات الصلة بهذه العلاقة. ليست default IP route، ولا VRF افتراضية، ولا عميلاً عاماً، ولا أمراً بتثبيت كل شيء.

قد تحتاج وظيفة RR أو مرحلة انتقال مختلطة إلى توزيع كثيف. لكن default membership استثناء له كلفة واضحة: يقلل الانتقائية، ويزيد ضغط التلاقي، ويوسع المعلومات المرئية. يجب تحديد النظير والعائلات والسبب والسياسات المستقلة التي تبقى نافذة.

تفاوض capability لا يثبت عضوية بعينها

يتعين أن يتفق الطرفان في BGP OPEN على AFI 1/SAFI 132. يثبت ذلك إمكان تبادل عائلة RTC فقط. لا يثبت إنشاء بادئة عضوية محددة أو استقبالها أو اختيارها أو استخدامها في مرشح VPN.

ولا تكفي أوامر الإعداد مثل rtfilter أو family route-target. الحد الأدنى من الأدلة هو عرض capability في الاتجاهين، وUPDATE الدقيق، وRTC RIB، وكل مسارات العضوية ذات الصلة، ونتيجة السياسة، والمرشح الفعلي لكل نظير في VPN Adj-RIB-Out.

تشرح وثيقة Cisco عن Route Target Constraint كيف تنتج إحدى عائلات منتجاتها تحديثات rtfilter من import RT في VRF ويشتق RR مرشحاً. وتعرض وثيقة Juniper عن family route-target الاتجاه التشغيلي نفسه.

هذه أوصاف خاصة بالمنتج. لا تنتقل الأوامر والقيم الافتراضية إلى منصات أخرى. يوثق أمر Cisco bgp default route-target filter وضوابط Juniper Route Target Filtering سلوكاً محلياً؛ وجود الإعداد لا يثبت تفاوض RFC 4684 مع النظير.

أفضل مسار واحد قد يمحو جهات الطلب

يمكن لعدة أجهزة PE في AS واحدة أن تنشئ البادئة نفسها {origin AS, Route Target}. لو استخدم RR أفضل مسار iBGP عادي فقط، فقد تختفي الاتجاهات الأخرى التي يأتي منها الطلب، فلا يتلقى بعض العملاء المسارات المطابقة.

لهذا يطلب RFC 4684 مراعاة جميع مسارات iBGP المتاحة للبادئة عند بناء مرشح الإخراج، ويعدل نشر العضوية المنشأة محلياً. يعتمد ذلك على بنية انعكاس سليمة كما في RFC 4456، لكنه ليس مجرد السلوك المعتاد لأفضل مسار.

كما أنه ليس ADD-PATH لمسارات VPN. الغرض هو حفظ جميع اتجاهات الطلب، لا تسليم بدائل متعددة لقابلية الوصول. ظهور RT في جدول واحد لا يثبت أي PE طلبها، أو أي مسارات احتفظ بها RR، أو أي مجموعة VPN كشفها لكل نظير.

الانضمام والانسحاب انتقالان في رسم حي

عند وصول إعلان عضوية أو سحبه، يعيد المرسل تقييم VPN RIB-OUT وينشئ أقل عدد من الإعلانات والسحوبات للانتقال من الرسم القديم إلى الجديد. اعتماد إعداد VRF لا يثبت اكتمال الانضمام، وحذف RT من ملف لا يثبت اكتمال الانسحاب.

في الانضمام، يلزم إثبات نية الاستيراد، وإنشاء العضوية، واستقبالها والاحتفاظ بمساراتها، وتوسعة المرشح، وظهور المسار في Adj-RIB-Out، ثم استقباله واستيراده وحل next hop والتسمية وبرمجة FIB ونجاح الحزم.

في الانسحاب، يجب التأكد أولاً من أن لا VRF أخرى تحتاج RT نفسها. لا تُسحب مسار لا تزال تطابق RT نشطة أخرى. قد تحمل المسار عدة RT وقد يستورد VRF عدة قيم، ولذلك قد يخفي العدد الثابت مساراً مفقودة وأخرى مسرّبة. المقارنة الصحيحة بين هويات المسارات وصفاتها.

EoR يضع نهاية للانتظار

يوصي RFC 4684 بعلامة End-of-RIB لعائلة RTC حتى دون Graceful Restart. يمكن أن ينتظر RR المجموعة الأولية من العضويات قبل إطلاق إعلانات VPN، لكن الانتظار يجب أن يكون محدوداً، والقيمة الافتراضية المحددة 60 ثانية.

ليست الستون ثانية هدف خدمة موحداً؛ إنها حد يمنع التحسين من التحول إلى انقطاع دائم. ينبغي تسجيل المؤقت الفعلي، ووقت EoR، والسلوك بعد انتهاء المهلة.

RTC UPDATE يغير الاهتمام الحالي، أما Route Refresh فيطلب إعادة إعلان حالة التصدير. يعرّف RFC 5291 ORF كمدخلات ذات أنواع تُحمل مع ROUTE-REFRESH. ويوضح RFC 7543 كيف قد يؤدي Covering Prefix ORF إلى إنشاء عضوية RTC للحصول على مسارات مفقودة؛ إنه تركيب لاحق وليس شرطاً لـ RTC العادية.

الانتقائية ليست تفويضاً أمنياً

ينص RFC 4684 صراحة على أن مرشحات الإخراج المشتقة من RT membership ليست مخصصة للأمن. بين المجالات الإدارية يجب تطبيق مرشحات مستقلة لـ NLRI الواردة والصادرة، وسياسة تحدد membership المقبولة نفسها.

العضوية ادعاء BGP من نظير. لا تصادق عميلاً، ولا تثبت عقداً، ولا تمنح حق تسمية أي RT، ولا تتحقق من مسار VPN. إذا وسع النظير اهتمامه وتعامل المرسل معه كإذن، توسع الإفصاح بلا أساس.

يجب أن يغطي التحكم المستقل namespaces RT المعتمدة، وأدوار النظراء، وتحويل RT عند الحدود، ومرشحات membership الواردة وVPN NLRI الصادرة، وحدود الحالة والتسجيل والتراجع. تستطيع RTC العمل بكفاءة داخل هذه الحدود، ولا تستطيع إنشاءها.

سلسلة إثبات في الاتجاهين

يساعد نموذج Adj-RIB-In وLoc-RIB وAdj-RIB-Out في RFC 4271 على عدم جعل لقطة واحدة دليلاً على العملية كلها. مع RTC يجب تطبيقه على عائلتي membership وVPN.

يبدأ الإثبات من PE المستقبلة: نية VRF وimport RT المعتمدتان، وcapability، وUPDATE العضوية، والسياسة، وكل مسارات iBGP اللازمة. في RR تحفظ RTC RIB والمرشح الخاص بالنظير. ثم يُتبع مسار VPN من المصدر عبر Loc-RIB وAdj-RIB-Out إلى VPN RIB في PE.

تُختتم السلسلة بالاستيراد والاختيار والتسمية وnext hop وFIB واختبارات حزم إيجابية وسلبية. يجب تكرارها في السحب وانتقال RR والترقية، مع إثبات أن الرسم القديم انتهى فعلاً.

المصادر