إصلاح FRRouting لقيم النطاق الترددي يجعل الترميز جزءاً من اختبار التحديث

الخلاصة

• تتضمن إصدارات FRRouting رقم 10.7.1 و10.6.2 و10.5.5، المنشورة في 25 أغسطس 2026، الإصلاح #22681 لمعالجة قيم كبيرة في مجتمع النطاق الترددي الممتد ضمن BGP.
• يبقى سقف العدد الصحيح الخام مقصوداً في النمط القديم، بينما يحافظ نمط IEEE على مجموع أكبر. كما تختلف الاختبارات في مدى تحققها من المرسل والمستقبل، ولا يثبت أي منها توزيع حركة البيانات الفعلي.

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

تورد ملاحظات الإصدارات 10.7.1 و10.6.2 و10.5.5 الإصلاح نفسه بتاريخ 25 أغسطس. يتعلق الأمر بكيفية تمثيل النطاق الترددي في سمة BGP، وليس بقياس يثبت أن منفذاً بسرعة 100 غيغابت كان عاجزاً عن تجاوز 34 غيغابت. الخلط بين الرقم المعلن وقدرة الوصلة يحوّل إصلاحاً حسابياً محدداً إلى وعد أداء لا تسنده هذه المصادر.

من أين جاء هذا السقف؟

يوضح طلب الدمج #22681، الذي دُمج في 28 يوليو، أن BGP كان يحتفظ بالقيمة داخلياً في عدد صحيح غير موقّع بعرض 64 بت، لكن بعض الدوال المساعدة كانت تضيقها إلى 32 بت عند الترميز أو فك الترميز أو العرض. كذلك كان مسار استبدال النطاق الترددي التراكمي يفرض الحد الأقصى للعدد الصحيح غير الموقّع ذي 32 بت دون تمييز النمط.

الوحدة هنا هي البايت في الثانية. والحد الأقصى، 4,294,967,295 بايت في الثانية، يعادل نحو 34.36 غيغابت في الثانية. أما صيغة IEEE المستخدمة على الشبكة فهي أيضاً بعرض 32 بت، لكنها عدد بفاصلة عائمة له مجال تمثيل مختلف. يحدد RFC 10005 هذه الصيغة ذات الأوكتتات الأربعة ووحدتها.

يوسع الإصلاح المعالجة الداخلية ذات الصلة، ويجعل تقييد المجموع مشروطاً باستخدام نمط العدد الصحيح الخام القديم. لا يغير ذلك صيغة النقل إلى 64 بت، ولا يجعل الأعداد العائمة قادرة على تمثيل كل عدد صحيح بدقة تامة. لذلك لا تكفي عبارة «إلغاء حد النطاق الترددي» لوصف ما تغير فعلاً.

جمع واحد ونتيجتان متوقعتان

تستخدم اختبارات الانحدار المعدلة مدخلين، 30,000 و100,000 ميغابت في الثانية، من جارَي BGP داخليين. مجموعهما الدقيق هو 16,250,000,000 بايت في الثانية. وبعد تحويل المدخلين والمجموع إلى الدقة العائمة المفردة، تصبح القيمة 16,249,999,360. هذا الفرق الصغير تقريب طبيعي، وليس عودة إلى تضييق العدد الصحيح الذي عالجه الإصلاح.

في النمط القديم، القيمة المطلوبة هي بدلاً من ذلك 4,294,967,295 بايت في الثانية. يتوقع الاختبار المصحح بلوغ هذا السقف، بدلاً من نتيجة اقتطاع أدنى كانت متوقعة سابقاً. اشتراط ما يعادل 130 غيغابت في الثانية في النمطين سيجعل اختبار القبول يرفض سلوكاً صحيحاً في أحدهما.

أُعيد التحقق من هذه الحسابات بصورة مستقلة لإعداد المقال، لكننا لم نشغّل طوبولوجيا اختبارات FRRouting. قراءة ما يؤكده الاختبار تختلف عن إجراء تجربة مستقلة على الموجّهات أو على شبكة عميل.

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

المجموع ليس مجرد نسخة من المدخلات

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

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

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

لا تقدم المصادر التي راجعناها حتى 8 سبتمبر، الساعة 12:40 بتوقيت UTC، عدداً للعملاء المتأثرين، أو حادثة إنتاج، أو زيادة مقاسة في السرعة، أو مصفوفة كاملة للإصدارات المتأثرة. الملاحظات الثلاث تثبت إدراج الإصلاح في تلك الإصدارات، ولا تحسم وضع جميع الإصدارات الأخرى.

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