الخلاصة

  • يوصي تقرير LACNIC المنشور في 13 أكتوبر باستقبال مسارات BGP كاملة عبر الألياف وقبول مسار افتراضي واحد فقط عبر LEO كي يحمل القمر الصناعي الحركة عند تعطل مسار الألياف.
  • قاعدة التوجيه لا تكشف انقطاع الكابل من تلقاء نفسها. يذكر التقرير تمارين، لكنه لا يسمّي نشرًا لدى مشغّل أو مهلة سحب للمسار أو اختبار سعة أو نتيجة استعادة.

سياسة توجيه بعد الاجتماع

انعقد CaribNOG 32 في ويلمستاد، كوراساو، من 7 إلى 9 أكتوبر. ويقول تقرير LACNIC المنشور في 13 أكتوبر إن Alejandro Acosta وNicolás Antoniello قادا جلسة تقنية بعد مقدمة قدمها Mark Kosters، المسؤول التقني في ARIN. ويربط التقرير النصائح بتعرض شبكات الكاريبي للكابلات البحرية والعواصف ومخاطر أخرى. هذا وصف صادر عن LACNIC، وليس مسحًا مستقلًا لشبكات الجزر.

التوصية محددة: الاتصال بمسار ألياف بحرية واحد على الأقل، ويفضل أكثر من مسار؛ استقبال جدول BGP كامل عبر الألياف؛ وقبول مسار افتراضي فقط عبر وصلة أقمار صناعية منخفضة المدار. يفترض أن تحمل الوصلة الفضائية الحركة عند تعطل مسار الألياف. وتحذر LACNIC من أن وصلة LEO واحدة قد لا تكفي لحركة عدد كبير من مزودي الخدمة، لكنها لا تنشر سعة أو نمط حمل أو اختبارًا يحدد هذا الحد.

ما زال شرط سحب المسار غير واضح

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

لذلك يصبح سؤال الكشف والسحب أساسيًا: هل يكفي سقوط الواجهة المادية؟ هل ينتظر المشغّل انقطاع جلسة BGP، أم يستخدم BFD أو مسبارًا نشطًا للخدمة؟ كم تبقى المسارات قبل سحبها؟ وكيف تُمنع التحويلات المتكررة عند تذبذب الألياف؟ يعرض تقرير LACNIC الترتيب المرغوب، لكنه لا يذكر هذه المعايير ولا يسجل اختبارًا في شبكة عاملة.

لكل أداة وظيفة أضيق

يتناول التقرير التحقق من أصل المسار عبر RPKI، وضوابط تسرب المسارات في BGP، وBFD. تتحقق RFC 6811 من أن AS منشأ البادئة مخوّل بها؛ ولا تتحقق من المسار الكامل AS_PATH. وتعتمد آلية RFC 9234 على اتفاق جيران eBGP على الأدوار ووضع علامات على المسارات، إضافة إلى سياسة المشغّل. ولا تثبت أي منهما وحدها قابلية الوصول أو نشر الإعداد.

وتقول LACNIC إن BFD قد يخفض الكشف من نحو 90 ثانية إلى أجزاء من الثانية. لكن RFC 5880 يجعل الزمن تابعًا لفواصل الإرسال المتفاوض عليها ولمعامل الكشف؛ ولا يقدم التقرير إعدادات. كما يحتاج اكتشاف MTU لمسار IPv6 إلى مرور رسائل ICMPv6، كما تشرح RFC 8201. ويذكر التقرير تمارين DNSSEC والتحقق من أصل المسار عبر RPKI؛ وهذا دليل تدريب، لا اعتماد إنتاجي.

تثبت المواد المنشورة وجود توصية وتمارين. لكنها لا تبين عدد الشبكات التي تطبقها، أو كفاية سعة LEO وقت انقطاع كابل، أو مدة عودة الحركة.

المصادر: تقرير LACNIC بعد الحدث؛ جدول CaribNOG 32؛ RFC 6811؛ RFC 9234؛ RFC 5880؛ RFC 8201.