مزوّدان علويان، ساعتان: تعدد الاتصالات يعيد المسار أسرع ويؤخر اختفاءه

الخلاصة

• بعد انتقال Invalid إلى Valid، وصلت الشبكات متعددة المزوّدين إلى استعادة الاتصال لدى نصف نقاط القياس خلال وسيط قدره 9 دقائق؛ احتاجت الشبكات ذات المزوّد الواحد إلى 12 دقيقة.
• عند الانتقال من Valid إلى Invalid انعكس الترتيب: استغرق فقدان الوصول لدى نصف نقاط القياس 42 دقيقة للشبكات متعددة المزوّدين و30 دقيقة للشبكات ذات المزوّد الواحد.

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

جاءت الأرقام من عرض في RIPE 93 عن انتقال تغيّرات حالة RPKI إلى مستوى البيانات. تتبعت الدراسة نحو 25 ألف تغيير في مستودع RIPE غيّر بيانات التحقق، ثم عزلت قرابة 1,500 حالة انتقال منفردة. بعد رصد تغيّر VRP، أُرسلت traceroutes من أكثر من 300 عقدة CAIDA Ark، وتكررت القياسات كل نحو ثلاث دقائق طوال ساعة.

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

طريق العودة أقصر مع مزوّد ثانٍ

بعد انتقال المسار من Invalid إلى Valid، بلغ وسيط استعادة الوصول لدى نصف نقاط القياس 9 دقائق للشبكات متعددة المزوّدين و12 دقيقة للشبكات ذات المزوّد الواحد. يشغّل كل مزوّد برنامج relying party الخاص به ويجلب البيانات وفق جدول مستقل. وجود مسارين مستقلين يزيد احتمال أن يلتقط أحدهما التفويض الجديد أولاً.

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

لا يجعل الاتصال الإضافي ROA صالحاً. يحدد ROA مصدر المسار المصرح به، ويحسب المدقق الحالة من الكائنات المنشورة. يظهر أثر تعدد المزوّدين بعد ذلك، حين تستوعب أجهزة التوجيه والسياسات الجديدة تلك الحالة.

طريق الخروج يطول بعد التحول إلى Invalid

حين انتقل المسار من Valid إلى Invalid انعكست النتيجة: بلغ الوسيط 30 دقيقة للشبكات ذات المزوّد الواحد و42 دقيقة متعددة المزوّدين حتى فقد نصف نقاط الرصد إمكانية الوصول. قد يحدّث أحد المزوّدين حالة RPKI ويتوقف عن إعلان المسار، بينما يظل آخر يعمل على الحالة القديمة ويواصل الإعلان عنه. المسار الاحتياطي الذي أسرع العودة يمدد الآن بقاء الإعلان.

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

شملت الدراسة حالات ذات مصدر واحد، واستبعدت الحالات التي يغطيها إعلان أكثر تحديداً. وانتهى تتبع traceroute بعد ساعة. الأرقام 9 و12 و30 و42 دقيقة هي وسائط تلك العينة المرصودة. سؤال التشغيل هو أي مزوّد اعتمد الحالة الجديدة وأيهم ما زال يعلن المسار.

لكل تغيير عدة ساعات

بين تعديل ROA وتغير الوصول تمر سلسلة من الخطوات: نشر الكائن، جلبه والتحقق منه، توزيع الحالة على أجهزة التوجيه، تطبيق السياسة المحلية، ثم استقرار مستوى البيانات. وقدّم عرض RIPE 93 هذه السلسلة كما هي: مراحل موزعة، لا زر واحد يتبدل في كل مكان.

راقب الفريق مصدر مستودع RIPE واستخدم مدققاً محسّناً. قال المتحدث إن الإشارة سبقت المدققات العامة التي قارنها بما لا يقل عن 57 ثانية، وبخمس دقائق عند الوسيط. أتاح ذلك بدء traceroutes قبل تفاعل جزء كبير من العينة. هذه ميزة في طريقة القياس، وليست تحكماً من RIPE NCC في جداول المدققات الأخرى.

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

المصادر: جلسة RIPE 93 وملخصها الرسمي؛ النص الرسمي للجلسة العامة في RIPE 93؛ RFC 6811: التحقق من مصدر بادئات BGP.