تمت ترجمة هذه المقالة تلقائيًا من الإنجليزية.

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

ما حدث

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

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

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

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

السبب الجذري

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

ما قد تحتاج إلى القيام به

• إذا كانت جهازك الظاهري غير قابل للوصول إليه، فيرجى إيقافه وإعادة تشغيله من لوحة التحكم الخاصة بك. في معظم الحالات، سيؤدي ذلك إلى استعادة الاتصال.
• إذا كان لا يزال غير قابل للوصول إليه بعد الإيقاف وإعادة التشغيل، فيرجى الاتصال بالدعم وسوف نقوم بالتحقيق.
• إذا رأيت تحذيرًا بشأن تغيير مفتاح مضيف SSH عند الاتصال بجهازك الظاهري، فهذا متوقع. تمت إعادة تكوين الأجهزة الظاهرية على نطاق واسع للعمل مع الإعداد الجديد، وأعاد cloud-init إنشاء مفاتيح المضيف كجزء من هذه العملية. هذا هو السلوك القياسي لـ cloud-init عندما تتم إعادة تهيئة جهاز ظاهري - يمكنك قبول المفتاح الجديد بأمان.

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