الخلاصة

  • يرتب Highest-Preference وLowest-Preference في RFC 9785 أجهزة PE المؤهلة فقط، إذ تفترض المواصفة صراحة أنها جاهزة تشغيلياً قبل المقارنة.
  • الأهلية، والأفضلية المضبوطة، وقيمة in-use المعلنة، والفائز بالانتخاب، والتمرير المبرمج، ونتيجة العميل وقائع منفصلة.
  • يستطيع Don't Preempt تفادي انتقال ثانٍ عندما يعود PE المفضل، لكنه قد يُبقي شاغل الدور الحالي DF رغم أنه لم يعد الخيار الإداري الأول.

القيمة تختار الدور ولا تختبر الطريق

يتولى Designated Forwarder في وضع All-Active إرسال Broadcast وUnknown Unicast وMulticast نحو الجهاز أو الشبكة متعددة الارتباط. وفي وضع Single-Active تشمل مسؤوليته أيضاً unicast. يعرّف RFC 7432 هذا الدور، فيما يجعل RFC 8584 آلية الانتخاب قابلة للامتداد.

يضيف RFC 9785 ترتيبين يمكن للمشغّل التحكم بهما. تختار الخوارزمية 2 أعلى قيمة رقمية لـ Preference، وتختار الخوارزمية 3 أدناها. يمتد الحقل ذو الثنائيْن من 0 إلى 65535 وتكون قيمته الافتراضية 32767. ويسجل سجل IANA الخوارزميتين وقابلية D، أي Don't Preempt.

هذه سلطة مفيدة: يمكن خفض مرتبة DF الحالي قبل الصيانة أو تعديل الأفضلية بسياسة محلية ديناميكية. لكن الشرط المعياري يحدد معناها بدقة؛ فالترتيب يعمل على افتراض أن المرشحين جميعاً operationally ready. لا تثبت القيمة 500 صلاحية attachment circuit، ولا اكتمال جدول التمرير، ولا وصول الإطارات إلى العميل.

الأهلية تسبق المرتبة

لا يبدأ الانتخاب بمقارنة رقمين. تصف RFC 8584 اكتشاف أجهزة PE، وصيانة قائمة المرشحين، وانتظار DF_WAIT، ثم حساب الفائز. وعند تشغيل AC-DF يشترط RFC 9785 استلام مسارات Ethernet A-D per ES وper EVI الموافقة قبل إدراج PE مرشحاً للـ ES والوسم المعنيين.

هذا اختبار مضبوط للأهلية، لكنه دليل من مستوى التحكم. لا يرى اكتمال برمجة FIB، ولا الوجهة الفعلية لنسخ BUM، ولا فقدان unicast في Single-Active. حتى RFC 7432 يعالج فترة انتقالية قد يعتقد خلالها جهازان أنهما DF في الوقت نفسه. يحد split horizon من حلقة محتملة، لكنه لا يصدر إيصالاً من طرف إلى طرف.

يجب أيضاً أن تتسق الخوارزمية. إذا أعلن PE عن Highest-Preference وأعلن آخر Lowest-Preference، يعود جميع المشاركين إلى خوارزمية RFC 7432 الافتراضية. ولذلك فإن الاحتفاظ بعبارة «DF هو PE2» وحدها يمحو مجموعة المرشحين والخوارزمية ووقوع fallback وسبب كسر التعادل.

عدم الاستباق يحمي شاغل الدور

إذا تعطل PE عالي الأفضلية يتولى المرشح التالي الدور. وعندما يعود DF السابق، فإن استعادته الفورية للموقع تحدث تغييراً ثانياً في مستوى البيانات. يتيح Don't Preempt سلوكاً غير ارتدادي يبقي الشاغل الحالي بدلاً من فرض انتقال جديد.

بعد boot-timer أو hold-timer يفحص PE العائد مسارات Ethernet Segment التي استلمها ويختار PE مرجعياً. إذا كانت أفضليته المضبوطة ستزيح الشاغل، يستطيع إعلان operational in-use Preference موروثة من المرجع مع DP=0. يواصل الشاغل إعلان DP=1، فيفوز عند تساوي الأفضلية.

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

لهذا الخيار ثمن. قد يبقى DF جهازاً لم يعد الأفضل من ناحية السعة أو الموقع أو السياسة. ويمكن أن يغير سحب مسار أو فشل PE المرجعي أو تعديل صريح للأفضلية أو تعارض الخوارزمية الحساب مرة أخرى. وإذا عاد PE معلناً خوارزمية مختلفة فلن يحفظ Don't Preempt الحالة؛ بل يحدث fallback إلى الانتخاب الافتراضي.

من يملك الإعداد يملك مسؤولية الحركة

يوضح قسم الأمان في RFC 9785 أن الإعداد يمنح تحكماً مطلقاً في PE الفائز لكل Ethernet Tag. يستطيع مهاجم يصل إلى هذا الإعداد تعديل Preference وتحويل مسؤولية الحركة، كما يستطيع تعارض الخوارزميات تعطيل عدم الارتداد عبر fallback.

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

يؤكد RFC 9784 تطبيق خوارزميات الأفضلية على Virtual Ethernet Segments، لكن نطاق أعطال EVC وENNI وvESI وgrouping withdrawals مسائل لآلية مختلفة. كما أن تكرار مصدر multicast خارج نطاق هذا التحليل.

يثبت سجل RFC Editor وIETF Datatracker وبحث الأخطاء الذي لم يعرض نتائج مطابقة عند المراجعة حالة الوثيقة؛ ولا يثبت أي منها مدى التبني أو أداء الإنتاج.