الملخص

  • تقول Breizh-IX إنها تُنشئ قوائم بادئات صارمة كل ليلة، وتتحقق من سجلات ROA، وتحترم خيار «Never via route servers» في PeeringDB. ويضيف ملخص عرض RS-API في RIPE 93 فحص حجم الإعلان وسؤال صاحب الشبكة عن رغبته في إعادة توزيعه.
  • تصف PeeringDB ذلك الخيار بأنه إشارة على نقطة التبادل أن تقرأها بانتظام وتنفذها. وجود الإشارة في صفحة العضو يسبق القرار الفعلي داخل خادم التوجيه.

ثلاث بوابات، والبوابة الأخيرة بيد العضو

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

في الملخص الأصلي لعرض RIPE 93 يضع Evann Dreumont وAlarig Le Lay من Breizh-IX ثلاثة أسئلة أمام مشروع RS-API. هل يضم سجل IRR المسار في مجموعة العميل؟ هل عدد المسارات منطقي، ولا سيما إذا جلبت مجموعة متداخلة قسماً هائلاً من جدول التوجيه العالمي؟ وهل يريد العميل أن يعيد خادم المسارات الإعلان عنه؟ الإجابة الثالثة لا تنتجها نتيجة البحث الأولى ولا الحساب الثاني.

يساعد RFC 7947 على فهم الرهان. خادم المسارات وسيط لتبادل معلومات BGP بين ثلاثة مشاركين أو أكثر في نقطة تبادل. بدلاً من فتح جلسة مستقلة مع كل جار، يتصل العضو بالوسيط. تلك وفورات تشغيل حقيقية، لكنها تجعل سياسة التوزيع في الوسيط مؤثرة في أكثر من علاقة واحدة. كائن التسجيل يصف مساراً متوقعاً؛ أما تفويض الوسيط لعرضه على الآخرين فقرار منفصل يجب أن يصل إلى إعداداته.

بين مربع الاختيار وآلة البث ساعة ومسؤول

يسرد موقع Breizh-IX الرسمي ما تقول الجمعية غير الربحية في رين إنها تطبقه اليوم. تُبنى قوائم البادئات ليلاً باستخدام bgpq4 في الوضع الصارم، وتُرفض البادئة التي لا كائن route لها. وتتحقق الخوادم من ROA عبر RPKI التابع لسجلات الإنترنت الإقليمية ومن سمة OTC؛ ويتحقق الخادم الثاني كذلك من ASPA. وتذكر الجمعية صراحة أنها تحترم خيار PeeringDB الذي يمنع الإعلان عبر خوادم المسارات. هذه تصريحات المشغّل عن ضوابط قائمة. أما RS-API فهو في ملخص المؤتمر تصميم لأتمتة فحوص يصعب إبقاؤها يدوية مع نمو الأعضاء.

في الأسئلة الشائعة الرسمية لدى PeeringDB يحمل الحقل اسم info_never_via_route_servers. وتصفه المؤسسة بأنه تلميح لنقطة التبادل، مع مطالبتها بفحصه وتطبيقه بصورة منتظمة. يضع العضو اختياره؛ تحفظه قاعدة البيانات؛ وعلى مشغّل النقطة أن يجلبه ويفسره ويضعه في سياسة الخادم ويراقب التنفيذ. لا ينتقل الأمر من شاشة العضو إلى BGP بمجرد حفظ الصفحة.

وهنا تظهر مشكلة الوقت. قد يغيّر العضو خياره بعدما استوردت نقطة التبادل آخر نسخة. كما أن إعادة إنشاء قائمة IRR ليلاً لا تثبت موعد قراءة خيار PeeringDB ولا ساعة تحميله على كل خادم. لا تعرض المصادر العامة المفحوصة سلسلة زمنية لكل تعديل لدى Breizh-IX، ولا يسند هذا المقال حادثة فعلية إليها. ما يلزم لإثبات احترام القرار واضح: توقيت تعديل العضو، وتوقيت جلبه، ونسخة الإعدادات التي عملت به، والإعلانات الخارجة بعدها.

ولفحص العدد فخ مختلف. قد يُوسع البرنامج AS-SET بدقة، لكن مجموعة فرعية تسحب أعداداً من المسارات لم يتوقعها أحد. إذا رفع المشغّل حدّ max-prefix إلى رقم فلكي، لم يعد الحد اختباراً مفيداً. يعرض ملخص RS-API الفكرة بوصفها وسيطاً يجمع أدوات قائمة ويقارن المعلومات المعلنة بحالة التوجيه. لا ينشر شيفرة عامة أو عدد مستخدمين أو قياساً للنتائج. إن عرضاً مستقبلياً ذا قيمة سيكشف أي رابط في المجموعة ضخّم القائمة، ومن أجاز الحد، وكيف يرجع المشغّل عن قرار خاطئ.

إيصال واحد لكل قرار توزيع

الإيصال الجيد لا يكتفي بوسم «مقبول». يسجل مجموعة AS-SET وكائنات route المستخدمة، وحجم القائمة بعد التوسع، والحد المطبق، وقيمة خيار PeeringDB ووقت جلبها، ونسخة السياسة المحمّلة على كل خادم، والجهات التي استلمت الإعلان. عند الرفض يفهم العضو أي باب أغلق. وعند القبول يعرف باسم أي تفويض تحدث الخادم.

تبقى قاعدة الغياب مجهولة في المواد المنشورة: ماذا يفعل RS-API إذا تعذر جلب الخيار، أو قَدُمَت قيمته، أو تعارضت السجلات؟ بيان هذه القاعدة مع سجل تنفيذ مؤرخ سيحسم موضع السلطة. الحساب الآلي يفيد في وزن القائمة؛ قرار نشر مسار العضو للآخرين يحتاج سنداً مستقلاً.

المصادر