الخلاصة

  • ربطت BGPMon مشكلات الوصول إلى خدمات Google في 12 مارس 2015 بتسرب مسارات، حيث تعلمت Hathway AS17488 بادئات منشؤها Google ثم سربتها إلى Airtel AS9498 [1].
  • كانت النافذة المرصودة قصيرة، من 08:58 إلى 09:14 بتوقيت UTC، لكن BGPMon ذكرت أن 336 بادئة IPv4 من Google تأثرت [1].
  • استخدم RFC 7908 لاحقا تسرب Hathway-Airtel مثالا على نشر بادئات نظير إلى مزود عبور، مع انقطاع واسع في خدمات Google في أوروبا وآسيا [2].
  • لا يفترض هذا المقال نية خبيثة ولا يخترع أرقام مستخدمين أو خسائر داخلية. السطح القابل للمساءلة هو مرشحات العملاء، والتحقق من العلاقة، وسياسة التصدير، والإنذارات، ودليل الإصلاح.

ماذا حدث

وصفت BGPMon الحادث على أنه انقطاع في خدمات Google ظهر في تقارير المستخدمين وبيانات التوجيه. أظهر تحليلها أن كثيرا من المسارات إلى بادئات Google تغيرت بين 08:58 و09:14 بتوقيت UTC لتتضمن Airtel AS9498 في الهند [1].

التفصيل المهم هو أن البادئات بقيت منشؤها Google AS15169. لذلك لم يكن الأمر اختطاف منشأ بسيطا تتظاهر فيه شبكة أخرى بأنها Google. المشكلة كانت في منتصف المسار، أي في علاقة التوجيه. كتبت BGPMon أن Google كانت تتبادل المسارات مع Hathway AS17488، وأن Hathway سربت هذه المسارات إلى مزود العبور Airtel AS9498، ثم نشرت Airtel الإعلانات إلى نظراء في نقاط تبادل الإنترنت [1].

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

لماذا يهم

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

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

كما يوضح الحادث أن RPKI Origin Validation وحدها لا تكفي. إذا بقي المنشأ Google AS15169، فقد ينجح فحص المنشأ بينما يبقى المسار خاطئا. المساءلة هنا في العلاقة: من تعلم المسار، ومن كان مخولا بتصديره، ومن فضله، وما الدليل الذي يمنع النوع نفسه من المسارات لاحقا.

الطبقة التقنية

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

وضعت BGPMon المسار حول Google AS15169 وHathway AS17488 وAirtel AS9498. وذكرت أيضا أن Airtel نشرت الإعلانات إلى نظراء في نقاط تبادل الإنترنت، وأن بعض الشبكات قد تفضل مسار Airtel لأن مسارات العملاء قد تكون مفضلة على مسارات peering [1]. لذلك يقع سطح التحكم بين local preference واقتصاد علاقة العميل/المزود ونظافة التصدير.

الدليل الموثوق للإصلاح يشمل قوائم البادئات المسموح بها، وroute maps، وحدود max-prefix، ووسوم العلاقة، وكائنات IRR/RPKI، وإنذارات التسرب، وأول وآخر ظهور، ورسائل السحب، والتحقق من المجمعات العامة بعد الإصلاح.

من تأثر

قالت BGPMon إن التقارير أشارت أساسا إلى مستخدمين أوروبيين وهنود، واستخدم RFC 7908 لغة أوسع عن انقطاع خدمات Google في أوروبا وآسيا [1][2]. وقدمت Vice الحادث لاحقا كشرح لكيف يمكن لنظام التوجيه العالمي أن يحول اختيار المسار إلى انقطاع يراه المستخدمون [3].

هذه المصادر تدعم صياغة تأثير على قابلية الوصول. لكنها لا تدعم أرقام مستخدمين مخترعة، أو خسائر مالية، أو ادعاء أن كل خدمات Google توقفت عالميا. أقوى دليل عام هو مسار AS وعدد البادئات والنافذة الزمنية.

ما الذي ينبغي مراقبته

أول إشارة هي قدرة المشغلين على تسمية فئة الفشل: مرشح بادئات العملاء، تصدير مسار من نظير، local preference، كائن مسار، استثناء مؤقت، أو إنذار لم يعمل. عبارة عامة عن إصلاح مشكلة توجيه لا تثبت تغير التحكم.

الإشارة الثانية هي الضوابط الواعية بالعلاقة. عرف RFC 7908 المشكلة. وتتحرك آليات مثل BGP Roles وOnly-to-Customer وأساليب ASPA في اتجاه جعل نطاق المزود والعميل والنظير قابلا للتحقق لا مجرد ذاكرة تشغيلية.

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

Sources

[1] BGPMon, "What caused the Google service interruption?", https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, "Problem Definition and Classification of BGP Route Leaks," https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, "Anatomy of a Globe-Spanning Google Outage," https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/