الملخص

  • تسجل ملاحظات إصدار PeeringDB 2.84.0، المؤرخة في 21 أكتوبر، إصلاح حذف شبكات واتصالات بنقاط تبادل لم يكن يصل إلى مستخدمي واجهة ?since=. تصف البلاغات الأصلية حذف سجلات netixlan حذفاً مباشراً، وتغير حالة بعض الشبكات إلى deleted من دون تقدم وقت updated.
  • أزال التعديل المدمج في 20 أكتوبر خطوة الحذف الجماعي وأضاف اختباراً يجعل واجهة API تعيد السجلات المحذوفة في التحديث التدريجي. يحتاج من يحتفظ بنسخة متباعدة منذ ما قبل الإصلاح إلى إعادة مزامنة كاملة، وفق صاحب البلاغ. لم تنشر PeeringDB عدداً للنسخ التي أعيد بناؤها.

حين يغادر السجل من دون أن يخبر الجيران

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

تشرح مواصفات واجهة PeeringDB آلية توفير الطلبات. يرسل العميل الوقت في ?since= ليحصل على الكائنات التي تغيرت بعده، ويمكنه طلب السجلات المحذوفة بحالة deleted مع قيمة موجبة لذلك الوقت. وتشرح الأسئلة الشائعة أن peeringdb-py يجلب نسخة كاملة أولاً، ثم التغييرات فقط. هذه الصفقة توفر نقل البيانات على الطرفين. شرطها أن تكون المغادرة تغييراً قابلاً للرؤية، لا عملاً منزلياً يختفي داخل قاعدة المصدر.

في 7 أكتوبر فتح Remco van Mook بلاغ PeeringDB رقم 2057 بعدما قارن نسخة تُحدث عبر ?since= بقوائم API الكاملة. وجد أن برنامج تنظيف الشبكات بحسب حالة تخصيصها لدى سجلات الإنترنت الإقليمية كان يحذف سجلات netixlan التابعة لشبكة دفعة واحدة قبل حذف الشبكة. يربط هذا السجل شبكة بشبكة LAN في نقطة تبادل. عملية الحذف الجماعي تجاوزت أسلوب الحذف الذي يبدل الحالة إلى deleted ويحدث الطابع الزمني. اختفى السجل من المصدر من غير شاهد يستطيع العميل التقاطه في سؤاله التالي عن التغييرات.

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

الأرقام تخص المقارنة التي أنتجتها

وجد صاحب البلاغ، خلال نحو ستة أشهر من المقارنة، 286 سجلاً من netixlan حذفت مباشرة وتتبع 125 شبكة. ووجد 46 شبكة تغيرت إلى الحذف من دون تحديث وقتها. هذا قياسه للمجموعة التي فحصها؛ لا توجد حصيلة منشورة لعدد كل العملاء المتأثرين أو القرارات التي اتخذت استناداً إلى البيانات القديمة. تكفي الأمثلة المعرّفة بالأرقام والأوقات لإثبات تكرار الآلية، من غير أن تتحول إلى رواية عن حادث توجيه لم تسجله المصادر.

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

دمجت PeeringDB في 20 أكتوبر التعديل 81ac767. أزال أمر الحذف الجماعي لاتصالات الشبكة، وترك مسار حذف الشبكة يتعامل مع توابعها. ثم أضاف اختباراً ينشئ شبكة واتصالين ونقطة تبادل وجهة اتصال تقنية، ويشغل تنظيف حالة RIR، ويتحقق من انتقال الشبكة والاتصالات إلى deleted وتقدم أوقاتها. الخطوة الأخيرة في الاختبار هي طلب GET /api/netixlan?since=... والتحقق من عودة السجلات المحذوفة. ذلك هو المكان الذي يجب أن يقع فيه النجاح: على حدود ما يراه مستهلك البيانات.

تضع ملاحظات إصدار PeeringDB تاريخ 21 أكتوبر على 2.84.0 وتصف البلاغ #2057 بأنه إصلاح لحذف كان يفوت مستخدمي المزامنة. جدول التخطيط في الصفحة نفسها ذكر 20 أكتوبر موعداً مستهدفاً للإنتاج. دمج التعديل في يوم، وظهور تاريخ الإصدار في يوم آخر، حدثان منفصلان. ما ثبت هو تغير الطريق الذي تسلكه عمليات الحذف الجديدة في الحالة المختبرة.

من يحمل عبء الماضي؟

السجل الذي حُذف مباشرة في الأشهر الماضية لم يعد موجوداً عند المصدر ليصدر منه الآن إشعار تأخر. كما أن حذفا بوقت updated يعود إلى 2022 لن يعبر مؤشراً زمنياً بدأ في 2026. لذلك يضع البلاغ إعادة المزامنة الكاملة على جانب العميل علاجاً للتباعد القديم. لا تقدم المصادر إيصالاً يبين أي النسخ المحلية أكملت ذلك. نشر عدد النسخ المعاد بناؤها سيغير تقدير حجم البيانات القديمة الباقية.

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

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

أزالت PeeringDB السجل من قاعدتها. الإصدار الجديد جعل الإزالة القادمة تصل إلى المستمع في المسار الذي اختُبر. يبقى على أصحاب النسخ القديمة أن يحصوا الأشباح التي لم تتلقَّ نبأ رحيلها.