المسار الذي عاد حاملاً رقم نظامه المستقل

الخلاصة

• يعامل BGP ظهور ASN المحلي في AS_PATH كدليل على حلقة؛ يغيّر allowas-in حكم المستقبل، بينما يغيّر as-override المسار قبل صدور الحكم.
• قد يخدم الأسلوبان مواقع تشترك في ASN، لكنهما لا يصادقان على البادئة ولا يثبتان التحويل. وتظل صلاحيات Route Target وSite of Origin وتفويض البادئة منفصلة.
• يتطلب الاستثناء القابل للتدقيق حفظ المسار قبل التغيير وبعده، وتحديد الجار وAFI/SAFI وعدد مرات الظهور، وفحص ضوابط الموقع والبادئة، ثم تتبع Loc-RIB وFIB والحزم والتراجع.

الرفض كان صحيحاً

لنفترض مثالاً تفسيرياً لا حادثة واقعية. يستخدم الفرعان A وB رقم ASN نفسه خلف شبكة مزود. يعلن A بادئة، وينقلها المزود إلى B. يجد موجه B رقمه داخل AS_PATH فيرفض المسار. الجلسة قائمة والمسار موجود لدى PE، لكنه غير قابل للاستخدام في الفرع.

هذه ليست مشكلة توافق غامضة. تفرض RFC 4271 استبعاد المسار الذي يحتوي ASN المحلي من عملية القرار، وتضع التشغيل الذي يسمح باستقبال الرقم المحلي خارج نطاقها. الرسالة التي يحملها المسار هي أنه سبق أن عبر نطاق التوجيه نفسه. RFC 4271

يظهر حلان. يسمح العميل بعدد محدود من ظهور رقمه عند الاستقبال، عبر allowas-in أو allow-own-as. أو يستبدل المزود ظهور ASN العميل قبل الإعلان إليه، عبر as-override.

ليس هذان مفتاحين متساويين. الأول يبقي المسار ويغيّر قاعدة قبول المستقبل. والثاني يغيّر الدليل كي لا تعمل قاعدة الرفض الأصلية. في الأول يملك العميل سلطة الاستثناء؛ وفي الثاني يحوز المزود عهدة تاريخ المسار.

AS_PATH دليل لا توقيع

يساعد AS_PATH على كشف الحلقات واختيار المسار، لكنه لا يوقع على الطريق الفيزيائي. توضح RFC 4272 أن كل speaker يتحقق أساساً من ASN الخاص به، لا من كل انتقال مزعوم، وأن المسارات الكاذبة أو المختصرة قد تغيّر الاختيار أو تسمح بحلقات. لذلك تزداد قيمة الدليل عندما تحفظ نسخته قبل السماح به أو تغييره. RFC 4272

يغيّر allowas-in القبول. وقد توفر المنصة حداً لعدد مرات الظهور أو نطاقاً للجار أو المجموعة أو عائلة العناوين أو origin أو route-map. توثق FRRouting عدداً من هذه القيود. وتصف RFC 7938 الوظيفة بأنها متاحة على نطاق واسع لكنها غير موحدة ضمن تصميم مركز بيانات يعيد استخدام ASNs خاصة. سلامة ذلك المثال مرتبطة بطوبولوجيته ولا تمنح رقماً آمناً عاماً. توثيق FRRouting لـBGP، RFC 7938

أما as-override فيغيّر الإعلان الصادر. توثق FRRouting وJunos استبدال كل ظهور يطابق ASN النظير برقم المزود المحلي. وتشير Junos إلى أن تكرار الرقم نتيجة prepend من العميل يُستبدل أيضاً. قد يبقى الطول قريباً، لكن الهوية التي تفسر مواضعه تُفقد. توثيق FRRouting لـBGP، Junos as-override

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

العضوية وأصل الموقع والتفويض

في RFC 4364 يحدد Route Target أهلية مسارات VPN للاستيراد. ويحدد Site of Origin الموقع الذي تعلم منه المسار، ويُستخدم لمنع إعادته إلى CE في الموقع نفسه عند تطبيقه كما ينبغي. أما تفويض البادئة فيسأل إن كان لذلك الاتصال حق إعلان الشبكة أصلاً. RFC 4364

لا يعوض RT دليل self-AS المفقود؛ فقد يوزع مساراً دائرياً بدقة على الأعضاء المطلوبين. ويقترب SoO من مشكلة حلقة الموقع، لكنه لا يعمل إلا إذا أضيف وطُبق باتساق في كل الاتصالات المعنية ولم يوجد مسار يتجاوزه. كما أنه لا يصادق على العميل أو البادئة.

تحذر وثائق IOS XR الحالية، في سيناريو L3VPN الموصوف، من أن AS override يفقد المعلومات وقد يؤدي إلى حلقات، وتستخدم SoO كضابط تعويضي. هذه حجة للتصميم المحدد، لا ضمان لكل شبكة. توثيق Cisco IOS XR لـBGP

وتفصل RFC 9835 أيضاً بين as-override وallow-own-as والحد الأقصى للظهور وSite of Origin في نموذج YANG. لا يضمن النموذج سلوكاً متطابقاً بين الأجهزة، لكنه يثبت أنها قرارات مستقلة. RFC 9835

عهدة المسار من الإعلان إلى الحزمة

ابدأ بالحالة الصارمة: احفظ Adj-RIB-Out في A وAdj-RIB-In لدى PE والمسار في PE البعيد قبل التصدير، ثم عرض الرفض وسببه self-AS في B. إن كانت الخدمة VPN فسجل RD وRT كخصائص عضوية، لا كإثبات للأصل.

في استثناء الاستقبال، افحص السياسة الفعلية بعد وراثة المجموعة: الجار الدقيق وAFI/SAFI والعدد المسموح وخيار origin-only إن وجد وشروط البادئة أو route-map. يجب أن يبقى مسار شاهد خارج النطاق مرفوضاً.

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

بعد ذلك تحقق مستقلاً من تفويض البادئة وRT وSoO وأي اتصال مواز أو route reflector أو redistribution قد يتجاوز نقطة المنع. تذكر RFC 6368 أن remapping أو قبول الرقم الذاتي قد يسببان مشكلات عندما يستخدم العميل BGP داخلياً لأغراض أخرى؛ الأثر قد يتعدى جلسة PE–CE. RFC 6368

القبول لا يساوي التسليم. تحقق من الاختيار في Loc-RIB ومن الحل التكراري وFIB أو العتاد ومن حركة مضبوطة في الاتجاهين. وينبغي لاختبار فشل آمن أن يكشف عودة غير متوقعة من دون خلق دوران خطير. تبين RFC 7705، في سياق ترحيل ASN، أن تغيير التاريخ قد يسمح بمسار كانت قاعدة self-AS ستوقفه. ليست مواصفة لـas-override، لكنها تحذر من اعتبار ظهور المسار نجاحاً. RFC 7705

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