ملخص

  • في 26 أكتوبر، شرح Ondřej Caletka من RIPE NCC إعداداً في BIRD يضيف رقم الشبكة المحلية إلى مسار فحص ASPA.
  • وتحذّر الشريحة 57 من أن الإضافة نفسها تكسر التحقق التصاعدي في جلسة مع ندّ جانبي.

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

يعرض برنامج RIPE 93 الرسمي درس Caletka في 26 أكتوبر. وفي شرائحه الأصلية يظهر المثال aspa_check(aspas, bgp_path.prepend(2121), false) لمسار جاء من مزوّد عبور. الرقم 2121 هو رقم الشبكة المحلية في المثال، أما false فيختار التحقق باتجاه النزول. يرفض المثال النتيجة غير الصالحة، ويشير تعليق فيه إلى إمكان طباعة النتيجة أولاً للمراقبة.

ينتهي المسار الوارد عادة عند جار BGP؛ رقم الشبكة المستقبلة لم يدخل المسار بعد. تشرح الشريحة 57 موضعي النسيان: عميل لم يضع شبكتك ضمن مزوّديه، أو شبكتك لم تضع مزوّد العبور ضمن قائمتها. حين يُضاف رقمك إلى مسار الفحص تصبح هذه الوصلة المحلية مرئية. لا يعني ذلك أن إعلان BGP الوارد كان يحمل رقمك منذ البداية.

أما الندّ الجانبي فله وضع آخر. شرح فريق BIRD الأصلي يوصي بالإضافة لدى العملاء والمزوّدين ويستثني الأنداد. ويبيّن أن هذا اختيار تشغيلي في BIRD؛ مسودة IETF للتحقق من ASPA لا تفرض إضافة رقم الشبكة المحلية، بل تتناول فحص العلاقة المحلية بصورة منفصلة.

يفصل دليل RIPE NCC بين المزوّد الحقيقي والندّ العادي في بيانات ASPA. وينبغي أن يظل هذا الفصل حياً في سياسة الموجّه. قالب واحد لجميع الجيران قد يختصر الكتابة، لكنه يوزّع السؤال الخطأ على الجلسات بسرعة مدهشة.

المصادر الأصلية