الخلاصة

  • يعرّف RFC 10039 خاصية BGP اختيارية انتقالية برمز 36 تحمل تسلسلاً من قيم DOMAIN-ID ضمن حالات ربط EVPN/IPVPN التي فُعّلت لها الخاصية.
  • يستطيع المستقبل كشف عودة المسار إلى نطاقه، ويستطيع بعد Local Preference تفضيل D-PATH الأقصر، لكن التسلسل ليس توثيقاً لهوية النطاقات ولا قياساً لحركة الحزم.
  • يلزم فصل أربعة أدلة: صحة إعداد الهوية، وحفظ السمات عند الحدود، وتنفيذ RIB/FIB، واختبار التسليم ثنائي الاتجاه في سياق المستأجر.

عندما تكون القصة في جدول BGP مقنعة والخدمة معطلة

تصل إلى النطاق C وجهة VPN تحمل D-PATH يذكر A ثم B. لا يظهر معرّف C في القائمة، فلا يرى المستقبل حلقة. تفوز الوجهة وفق السياسة المحلية وتبدو النتيجة سليمة في لوحة التحكم، بينما لا تصل حزم المستأجر.

لا يوجد تناقض بين المشهدين. الخاصية تصف ما أعلنته تحديثات BGP عن النطاقات التي عبرتها. أما الحزمة فتخضع بعد ذلك لاختيار RIB، وبرمجة FIB، وحل القفزة التالية، والتغليف والسياسات الخاصة بالمستأجر. يمنع D-PATH نوعاً من الغموض في المستوى الأول، لكنه لا يراقب المستويات التالية.

هوية إدارية لا شهادة رقمية

يحمل كل مقطع في D-PATH نوع عائلة الخدمة وتسلسل قيم DOMAIN-ID. عندما تصدّر بوابة مساراً إلى نطاق آخر، تضيف قيمة تمثل نطاقها. ويشترط التصميم أن تستخدم جميع بوابات النطاق الواحد القيمة نفسها، وأن تختلف القيم بين نطاقات البوابات المختلفة.

غير أن DOMAIN-ID قيمة مبهمة يحددها المشغل. لا يكتشف البروتوكول تلقائياً أن بوابتين تنتميان إلى النطاق نفسه، ولا ينسق القيم بين مؤسستين. إذا انقسم نطاق واحد بين قيمتين فقد تمر حلقة حقيقية. وإذا اشترك نطاقان في قيمة واحدة فقد يُرفض مسار مشروع باعتباره حلقة.

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

الانتقالية لا تعني سلامة السلسلة

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

في نموذج No Propagate لا يحمل المسار المرسل إلى النطاق التالي D-PATH. وفي Uniform Model يستمر التسلسل عبر الحدود. لذا لا تكفي ملاحظة غياب الخاصية لإعلان عطل قبل معرفة نموذج الربط. وبالمثل، وجودها لا يثبت أن route targets أو الملصقات أو VNIs وبقية سمات الخدمة حُفظت.

إذا كانت الخاصية مشوهة، يطبق RFC 10039 معاملة treat-as-withdraw. يمنع ذلك إدخال معلومات غير صالحة في الاختيار، لكنه قد يجعل مشكلة توافق برمجي تظهر كاختفاء واسع للوجهات. أثناء الترقية ينبغي مراقبة السحب الفعلي وأخطاء التحليل، لا الاكتفاء برسالة تقول إن الرمز 36 مدعوم.

اختيار الأقصر ليس حكماً على الجودة

بعد مقارنة Local Preference، يمكن لخوارزمية أفضل مسار أن تفضل التسلسل الذي يحتوي قيماً أقل من DOMAIN-ID. ويُعامل المسار الذي لا يحمل D-PATH على أن طوله صفر في هذه الخطوة. تبقى السياسة المحلية أسبق، ولذلك يمكن لمسار أطول أن يفوز إذا منحته المؤسسة تفضيلاً أعلى.

عدد النطاقات ليس زمناً أو مسافة أو سعة. وقد يفوز المسار الأقصر ثم لا يُبرمج في FIB، أو تُفقد القفزة التالية، أو يستخدم ملصقاً أو VNI غير صحيح، أو تمنعه سياسة في مستوى البيانات. النتيجة تخبرنا لماذا فاز إعلان، ولا تخبرنا إن كانت جلسة المستأجر قد نجحت.

أربع نقاط تحقق لواقعة واحدة

أولاً، تُجمع قيم DOMAIN-ID من كل البوابات وتُقارن داخل النطاق وبين النطاقات. تشمل المراجعة حالة الأجهزة الانتقالية أثناء الاستبدال.

ثانياً، تُقارن تحديثات BGP على جانبي كل حد. يُفحص التسلسل ونوع عائلة الخدمة والسمات اللازمة لتكوين VPN. هذه المقارنة تحدد أين تغير الإعلان بدلاً من الاكتفاء بصورة الجدول النهائي.

ثالثاً، يُتبع المسار من الاستقبال إلى RIB المختارة ثم إلى FIB المنفذة. تُراجع القفزة التالية والملصق وVNI والنفق على الجهاز الذي يمرر الحركة فعلاً.

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