الخلاصة

  • يسمح multipath لعدة مسارات مؤهلة بالمشاركة في التحويل المحلي، لكنه لا يضمن مضاعفة السعة أو استقلال المسارات أو تساوي البايتات.
  • يقرر BGP أهلية المرشحين، ويقرر الحل التكراري والعتاد أعضاء المجموعة، بينما يحدد الهاش ومزيج التدفقات مقدار الاستخدام.
  • يتطلب الإثبات تتبع Adj-RIB-In وRIB وFIB ثم عدادات كل عضو والطوابير وتجارب الفشل؛ صورة جدول التوجيه ليست السلسلة كاملة.

النسبة التي لم يَعِد بها جدول التوجيه

لنتخيل تجربة تفسيرية وليست حادثة حقيقية. اجتاز مساران إلى بادئة واحدة شروط multipath في جهاز محدد، وظهر عنوانا next hop داخل مجموعة ECMP. كتب تقرير التغيير أن الحمل سيتوزع بالتساوي. ثم وُجّه تدفق ضخم طويل العمر إلى العضو A، فامتلأ طابوره وبقي لدى B فائض.

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

تصف RFC 4271 عملية اختيار مسار مؤهل وتثبيته في Loc-RIB وتحديد القفزة المباشرة. تضيف تطبيقات multipath الشائعة محلياً مسارات أخرى استوفت شروطها؛ ولا تنشئ التزاماً بين النطاقات بأن يعلن كل نظير المجموعة نفسها أو يستخدمها. RFC 4271، القسم 9.1.2

أما كلمة «متساوٍ» فتتبع تعريف التطبيق. توثق Cisco مقارنات multipath مع بقاء best path واحد للإعلان. ويضع FRRouting فحص multipath بعد معايير سابقة ويتيح multipath-relax لتخفيف التطابق الكامل في AS_PATH، بينما توثق Arista سلوكاً افتراضياً مختلفاً لهذا التخفيف في سياق EOS المشار إليه. هذه شروط قبول محلية، وليست شهادة بتساوي السعة أو المخاطر أو نطاق الفشل. توثيق Cisco، توثيق FRRouting، توثيق BGP في Arista EOS

ثلاثة أحكام مستقلة

الحكم الأول هو الأهلية: هل المسار قابل للاستخدام، ومسموح به في السياسة، ومتكافئ حسب شروط المنصة؟ لا يمثل maximum-paths سوى سقف، ولا يثبت عدد الأعضاء الذين وصلوا إلى العتاد.

الحكم الثاني هو بناء المجموعة. يجب حل كل next hop تكرارياً وبرمجته في FIB ضمن حدود الشريحة. وقد يعبر عنوانان مختلفان النفق أو البطاقة أو الدائرة البعيدة نفسها؛ لذا لا يثبت عدد المسارات استقلالاً فيزيائياً.

الحكم الثالث يصدره الهاش لكل تدفق. تشرح RFC 2991 أن تثبيت حزم التدفق على مسار واحد يقلل إعادة الترتيب، وأن تغيير الأعضاء قد يحرك الحزم. وتحلل RFC 2992 خوارزمية hash-threshold. يمكن أن تتوزع معرفات التدفقات جيداً، بينما تبقى البايتات منحازة لأن أحجام التدفقات غير متساوية. RFC 2991، RFC 2992

إذن لا بد من إثبات ثلاثة أمور منفصلة: تأهل المسارات، وبرمجة الأعضاء، واستخدام الحركة لهم.

الهاش لا يرى إلا ما يكشفه المسار

تختلف الحقول المتاحة باختلاف عائلة العناوين والتغليف والعتاد والإعداد. يمكن لـ IPv6 flow label أن يضيف entropy عندما لا تكون ترويسات النقل متاحة. وتوضح RFC 6438 أيضاً كيف تحد الأنفاق والتجزئة والحمولات المعتمة من المعلومات. وقد تبدو محادثات داخلية كثيرة كتدفق خارجي واحد إذا تشاركت tuple خارجية واحدة. RFC 6438

لذلك لا تكفي عبارة «هاش خماسي». ينبغي تسجيل المنصة والعائلة والتغليف والحقول والبذرة والدقة. وتبين إعدادات Arista للبذور والاستقطاب وresilient ECMP أن هذه خصائص تطبيقية محلية، لا افتراضات عامة. توثيق Arista

كما يحكم مزيج الحركة النتيجة. تصف RFC 7424 إسقاط تدفقات كثيرة على روابط قليلة وتلفت إلى اختلال large flows. قد تتوازن آلاف الجلسات القصيرة، بينما يهيمن نسخ احتياطي أو تدفق مزامنة واحد لساعات. ولكل من الحزم والبايتات والطوابير والإسقاط والتأخير دلالة مختلفة. RFC 7424

ولا يعرف ECMP العادي تلقائياً أن رابطاً أوسع من الآخر. التوزيع الموزون أو التكيفي آلية أخرى تتطلب عقداً تشغيلياً وإثباتاً منفصلين.

رؤية عدة مسارات ليست استخدامها

يزيد ADD-PATH الرؤية. تسمح RFC 7911 بإعلان عدة مسارات للبادئة دون استبدال ضمني، لكنها لا تجبر المستقبل على تثبيتها معاً أو توزيع الحركة بنسبة محددة. ويمكن للجهاز في الاتجاه الآخر استخدام multipath محلياً مع إعلان best path واحد فقط. RFC 7911

أما PIC فيهيئ إصلاحاً سريعاً بعد الفشل؛ ولا يثبت أن المسار الاحتياطي يحمل حركة في الحالة العادية. ويفصل Junos في توثيقه بين اختيار BGP multipath وسياسة load balancing في جدول التحويل. كما أن تسمية «per-packet» التاريخية تشير غالباً في هذا السياق إلى هاش لكل تدفق، وليست إذناً بنثر الحزم بلا ضبط. توثيق Junos

من المرشح إلى الحزمة

يبدأ السجل بنطاق التغيير: البادئات والعائلات والنظراء والسقف والمالك وشرط التراجع. يحتفظ بمرشحي Adj-RIB-In ونتيجة المقارنة الدقيقة، ويسجل ما خُفف إذا استُخدم multipath-relax.

ثم يفحص الحل التكراري ونطاقات الفشل ومعرف مجموعة ECMP الفعلية وأعضاءها في العتاد. إذا عرض RIB مسارين وFIB عضواً واحداً، فالسؤال أولاً عن الحل أو السعة أو البرمجة، لا عن توزيع الهاش.

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

ولا ينتهي التراجع بحذف الأمر، بل بعودة المرشحين وRIB وFIB وسلوك الحزم إلى الحالة المطلوبة.