الخلاصة

  • رقم النظام المستقل 0 هو «لا هوية» محجوزة: لا يجوز أن يعرّف النظير نفسه به في OPEN، ولا أن يظهر في AS_PATH أو AS4_PATH أو AGGREGATOR أو AS4_AGGREGATOR. أما ORIGIN بقيمة 0 فهو ترميز صحيح لـ IGP.
  • يوزع RFC 7607 إجراء الرفض بحسب الموضع: إجهاض الاتصال عند ادعاء النظير AS 0، ومعاملة مسارات UPDATE التي تحمل الصفر في AS_PATH كمسحوبة، أو إسقاط سمة التجميع أو الانتقال غير الصالحة مع مواصلة معالجة بقية UPDATE.

في بداية حادثة افتراضية، أعطت ثلاث منصات مراقبة ثلاث صور متعارضة. الأولى قالت إن الجار لا يصل إلى حالة Established ويرسل الجهاز Bad Peer AS. الثانية قالت إن الجلسة سليمة لكن مجموعة من البادئات اختفت. الثالثة أبقت البادئة في الجدول، وسجلت أن AGGREGATOR حُذف.

كان الصفر موجودا في الحالات الثلاث. لم يكن موجودا في المكان نفسه.

تلك هي الفكرة المركزية في RFC 7607. يحظر المعيار AS 0 في هوية النظير وأربع سمات UPDATE، لكنه لا يمنح المستقبل حق إسقاط كل شيء كلما رأى الرقم. فالشيء الذي فقد معناه قد يكون محاولة اتصال، أو reachability حملها UPDATE، أو سمة واحدة لا تؤثر بذاتها في اختيار المسار.

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

محجوز لا يعني مؤقتا

يسجل سجل أرقام الأنظمة المستقلة لدى IANA الرقم 0 بوصفه Reserved ويحيل إلى RFC 7607. ويبين سجل الأرقام ذات الغرض الخاص أن الأرقام الخاصة لا تتساوى في الاستعمال: AS_TRANS 23456 للانتقال إلى أربعة أوكتتات، ونطاقات للتوثيق، ونطاقات للاستخدام الخاص، وأرقام أخيرة محجوزة.

لا ينتمي AS 0 إلى فئة «نستخدمه الآن ونصححه لاحقا». لا يعني مجهول الهوية ولا شبكة خاصة ولا حقل ASN فارغا. عندما تحوّل قاعدة بيانات null إلى 0، أو يملأ قالب متغيرا مفقودا بالصفر، تتحول راحة برمجية إلى ادعاء بروتوكولي ممنوع.

من المفيد إيقاف الخطأ عند توليد الإعداد. توثق Juniper في شرحها لأرقام AS ذات الأربعة بايت أن commit يفشل عند استخدام أرقام مقيدة ومنها 0 ضمن النطاق الموصوف. لكن نظافة إعداد الجهاز المحلي لا تثبت نظافة ما يرسله جار أو route server أو إصدار قديم. يجب أن يبقى parser والاستجابة عند الاستقبال صحيحين.

الصفر في OPEN يرفض النظير

يعرّف RFC 4271 حقل My Autonomous System في رسالة OPEN. يقرر RFC 7607 أن استقبال الصفر بوصفه peer AS يفرض إجهاض الاتصال وإرسال NOTIFICATION بالرمز OPEN Message Error والرمز الفرعي Bad Peer AS. كما يمنع الراوتر من بدء اتصال وهو يدعي أنه AS 0.

وحدة الفشل هنا هي المجاورة التي لم تتأسس. لا توجد مسارات صالحة داخل جلسة Established كي تُحمى. يجب حفظ OPEN المستلم، وNOTIFICATION المرسل، والاتجاه، والطرفين، والتوقيت، ومحاولات الاتصال المتكررة، والإعداد الذي كتب الصفر.

تعطيل فحص peer AS ليس حلا انتقاليا مشروعا. لا يوجد مالك لـ AS 0 يستطيع منح استثناء. إن احتاجت عملية دمج إلى رقم محلي بديل، فعليها استخدام ASN حقيقي مناسب وآلية local-as مدروسة، مع فحص أثرها في OPEN وAS_PATH.

الصفر في AS_PATH يرفض reachability

يعتبر RFC 7607 رسالة UPDATE التي تحتوي AS 0 في AS_PATH رسالة malformed ويحيلها إلى RFC 7606. الإجراء المحدد لـ AS_PATH غير الصالح هو treat-as-withdraw: تعامل كل المسارات في UPDATE كما لو سُحبت وتزال من Adj-RIB-In.

تبقى الجلسة عادة قائمة. بذلك لا تتحمل آلاف البادئات الصحيحة كلفة خطأ في إعلان واحد. الحفاظ على الجلسة لا يعني التساهل مع AS 0؛ بل يعني حصر الرفض في المعلومات التي لم يعد ممكنا الوثوق بها.

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

يمكن لسياسة حدودية أن تضيف حماية. تقدم وثائق FRRouting مثالا لقائمة bogon ASN تطابق _0_ داخل AS_PATH. لكنها لا ترى peer AS في OPEN ولا تثبت ما حدث لسمات AGGREGATOR أو AS4.

الصفر في سمة التجميع يسقط السمة

يحمل AGGREGATOR رقم AS وعنوان speaker الذي أنشأ aggregate. يحظر RFC 7607 الصفر في موضع ASN، لكن RFC 7606 يحدد attribute discard لسمة AGGREGATOR غير الصالحة. تُحذف السمة وتستمر معالجة UPDATE.

قد يبقى المسار إن اجتاز الفحوص الأخرى. لذلك يمكن لجهازين متوافقين أن ينتجا نتيجتين مختلفتين أمام وصف عام مثل «AS0 داخل UPDATE»: الصفر في AS_PATH يسحب المسار، والصفر في AGGREGATOR يحذف السمة.

بقاء المسار لا يعفي المصدر. فقدت معلومة عن التجميع وظهر مولّد يكتب قيمة ممنوعة. يجب تسجيل الحقل والإجراء والجار والوقت، ثم إصلاح النظام الكاتب.

يعرّف RFC 6793 AS4_PATH وAS4_AGGREGATOR لتمرير معلومات ASN ذات الأربعة أوكتتات بين speakers بقدرات مختلفة. يجعل RFC 7607 الصفر فيهما malformed ويطبق إجراءات RFC 6793. في السياق المحدد، تُسقط السمة، ويسجل الخطأ محليا، وتستمر UPDATE.

لا يمكن تفسير هذه السمات بلا OPEN وقدرات الأربعة أوكتتات. فإذا كان الطرفان NEW فلا ينبغي أن يتبادلا AS4_PATH أو AS4_AGGREGATOR أصلا. ظهور السمة قد يكون خطأ قبل فحص الصفر. ولذلك يجب ربط رسالة UPDATE برسائل OPEN التي سبقتها.

ORIGIN 0 يكشف جودة الرصد

يستخدم RFC 4271 القيمة 0 في ORIGIN بمعنى IGP، والقيمة 1 لـ EGP، و2 لـ INCOMPLETE. هذه القيمة صحيحة ولا تعني أن origin ASN هو AS 0.

منصة تجمع كل ما يسمى origin أو كل قيمة رقمية صفر في فهرس واحد قد تخلط ORIGIN وASN المشتق من AS_PATH والـ default route والـ metric. ينتج ضجيج، ثم تُخمد القاعدة، ثم تختفي مخالفة حقيقية داخل الضجيج.

اختبار regression المناسب يضم حالة ORIGIN 0 صحيحة وخمس حالات ASN 0 في المواضع المحظورة. يجب أن يقبل النظام الحالة الصحيحة، وأن يسمي الحقل والإجراء في كل حالة ممنوعة. منع كل byte قيمته صفر ليس التزاما بالمعيار، بل فقدان للمعنى.

الحد الأدنى للسجل هو PDU أو تمثيل بلا فقد، ونوع الرسالة، وtype code للسمة، والاتجاه، والجار، وAFI/SAFI، والقدرات، والإصدار، والطابع الزمني. يمكن للواجهة أن تقول «اكتشاف AS0»، بشرط بقاء الحقل الأصلي قابلا للاسترجاع.

AS 0 ROA مسار سلطة مختلف

يعرّف RFC 6482 ROA بوصفه كائنا موقعا يحتوي asID وتفويضات بادئات. ويوضح RFC 6483 أن صاحب المورد يستطيع نشر ROA بقيمة AS 0 ليعلن أن البادئة وmore-specifics التابعة لها لا ينبغي استخدامها في التوجيه.

لا يمنح ذلك AS 0 حق إنشاء مسار. يبين RFC 6907 أن مسارا صحيحا لا يمكن أن يحمل origin ASN 0، ولذلك لا يمكن لأي مسار أن يطابق AS 0 ROA. يصبح إعلان صادر عن ASN حقيقي Invalid إذا وُجدت تغطية ولم يطابق أي ROA مرشح الأصل والطول الحقيقيين.

لكن RFC 6483 يسمح بتعايش AS 0 ROA مع ROA لأرقام قابلة للتوجيه. إذا طابق أحدها البادئة وmaxLength والأصل الفعلي، فالنتيجة Valid. لا يلغي كائن AS 0 تفويضا إيجابيا مطابقا.

كما تختلف الساعة. تعالج OPEN وUPDATE داخل الجلسة، أما ROA فيمر بالنشر وشهادات RPKI والجمع وcache الـ relying party. قد يصل تصحيح BGP قبل تغير نتيجة ROV أو بعدها. يجب حفظ خطين زمنيين مترابطين لا دمجهما في حالة واحدة تسمى AS0.

إثبات ما دخل وما اختير وما خرج

يتيح BMP في RFC 7854 مراقبة UPDATE وحالة الجار وAdj-RIB-In قبل السياسة وبعدها. يثبت pre-policy ما أرسله الجار، ويثبت post-policy ما أبقاه المستقبل. غياب أحدهما يمنع فصل خطأ المصدر عن نجاح الاحتواء.

يضيف RFC 9069 مراقبة Loc-RIB، أي المسارات التي اختارها Decision Process. ولا يثبت ذلك FIB أو وصول الحزم. عند ادعاء أثر خدمي، يجب إضافة دليل data plane.

يضيف RFC 8671 Adj-RIB-Out قبل السياسة وبعدها. وهكذا يصبح شرط عدم نشر AS 0 قابلا للاختبار عند كل مخرج مهم. لا يثبت collector واحد الغياب عالميا، لكنه يساعد على بناء محيط محدد قابل للتدقيق.

يقدم RFC 7454 الإطار العام لمرشحات الدخول والخروج وAS-path، بينما يعطي RFC 7607 الإجراء الخاص بالقيمة. ملف الإثبات الكامل يربط الرسالة الأصلية، وقدرات الجار، والإجراء، وفروق RIB، والاختيار، وFIB عند الحاجة، والمخارج، وسبب التوليد، ثم الرسالة المصححة.

المصادر