الخلاصة

  • ينقل RFC 9786 انتخاب DF من كل Ethernet Tag إلى منفذ ES واحد، لكنه لا يفحص جاهزية الخدمات المتعددة المجمعة عليه.
  • يتطلب Port Mode إجماعا على الخوارزمية وbitmap القدرات؛ ويمكن لإعلان مختلف من PE واحدة أن يعيد ES كله إلى الانتخاب الافتراضي.
  • حالة LACP ومزامنة ARP/ND وMAC وVRF وإعلانات P/B وFIB وحركة الحزم وقبول العميل أدلة مستقلة.

عندما يصبح المنفذ حاوية القرار

يعرّف RFC 9786 وضع Port-Active للنشط والاحتياطي عند مستوى واجهة EVPN متعددة الاتصال. بدلا من انتخاب [ES, Ethernet Tag] المرتبط بـ RFC 7432، تُحذف العلامة من الحساب. تحافظ PE واحدة على منفذ الوصول نشطا، وتضع البقية منافذها في الاحتياط؛ وتنتقل خدمات L2 وVPWS وL3 وIRB معه كوحدة واحدة.

يستطيع CE استخدام LAG واحد، على أن تعرض PEs معلمات LACP متطابقة: system ID وport priority وport key. يوفر ذلك مسارا حتميا على مستوى الواجهة، وهو مفيد عندما لا يلائم توزيع التدفقات متطلبات QoS. ولا يفرض الأسلوب ICCP أو LDP ولا يعتمد على underlay بعينه.

لكن تجميع التحكم يجمع أثر الخطأ أيضا. يجب على DF إبقاء الواجهة up وforwarding، وعلى non-DF حجب الاتجاهين لكل VLAN، إما بإنزال المنفذ أو بإبقائه LACP Out of Sync. هذه نتائج تنفيذية مطلوبة. أما نتيجة DF فتحدد صاحب الدور ولا تقيس ما إذا كان قد نفذه.

الإجماع يفتح الإجراء ولا يغلق الاختبار

يسجل IANA البت 5 كقدرة Port Mode DF Election. عند P=1 تعمل Modulo وHRW على ES بلا Ethernet Tag. ويمكن لتفضيلات RFC 9785 ترتيب المنافذ، كما يستطيع Don’t Preempt إبقاء صاحب الدور بعد عودة مرشح أعلى تفضيلا.

يحدد RFC 8584 معنى هذا الإعلان بدقة. لا تتبع PE الإجراء إلا إذا اتفقت جميع ES Route Type 4 المستلمة في الخوارزمية وbitmap. غياب community أو تكرارها أو اختلاف إعلان واحد يعني Algorithm 0 بلا قدرات. يسمي RFC 9786 هذا الشرط unanimity.

لذلك يمكن لتغيير PE واحدة أن يوسع الأثر إلى ES كله. يذكر قسم الأمن احتمالات توزيع غير عادل، وانقطاع، وفقد، وازدواج الحزم بعد fallback. إثبات إعداد العقدة المحلية وحدها لا يكفي؛ يلزم الاحتفاظ بكل إعلان كما شوهد وفي وقته.

حتى الإجماع الكامل يثبت اتفاق القاعدة فقط. لا تثبت نتيجة DF سلامة البصريات، ولا هوية LACP partner، ولا collecting/distributing، ولا تثبيت VRF أو adjacency أو FIB. لقد اختارت طبقة التحكم المسؤول؛ ولم تراقب نتيجة عمله.

للاحتياطي درجات جاهزية متعددة

قد يبقى منفذ standby بحالة down، ثم يحتاج إلى رفع الرابط واستقرار الشبكة عند تنشيطه. لذلك يوصي RFC 9786 بالمزامنة المسبقة: مخابئ ARP وNeighbor Discovery في IRB/L3، وربما جداول VRF، وجداول MAC في L2. الانتخاب لا ينفذ هذه المزامنة.

يبقي warm standby العضو في LACP Out of Sync فيختصر جزءا من زمن بدء الرابط. لكنه لا يثبت حداثة ARP/ND أو MAC أو FIB أو المسار البعيد. وبالعكس، لا تعني الجداول المتزامنة أن CE اختار العضو وبدأ collecting وdistributing. كل إشارة تغطي مرحلة محدودة.

تغطي Primary وBackup مرحلة أخرى. يعرّف RFC 8214 L2-Attr Extended Community، ويوصي RFC 9786 بوضع P أو B فقط في Ethernet A-D per-ES. وينبغي أن تتغلب قيمة الأب per-ES على per-EVI. يساعد ذلك PE البعيدة على تغيير المسار أسرع، لكن الإعلان ليس مشاهدة لعبور حزمة.

تتجاهل التطبيقات الأقدم من RFC 7432/RFC 8214 قيمة L2-Attr على per-ES وتواصل path resolution الافتراضي، مع رؤية Single-Active عبر ESI Label. قد تتخذ أجهزة ES المختلط قراراتها من معلومات مختلفة. ولهذا يجب إثبات مخزون القدرات وما استُقبل فعلا.

قد تفشل خدمة ويبقى DF كما هو

يعطل Port Mode أثر AC-DF: يجب أن تكون A صفرا مع P، ويُتجاهل A=1 المستلم. إذا فشلت sub-interface وسُحب Ethernet A-D per-EVI، لا يتغير انتخاب المنفذ. يفصل التصميم تقلب الخدمة عن قرار المنفذ، ويبرهن في الوقت نفسه أن ثبات DF لا يساوي سلامة الخدمة.

تحتاج العمليات إلى مشهدين مترابطين. يسجل مشهد المنفذ ESI والمشاركين والخوارزمية وbitmap والمؤقتات وDF/BDF وLACP وP/B per-ES. ويسجل مشهد الخدمة VLAN/EVI/VPWS/VRF وARP/ND وMAC وFIB والadjacency والعدادات والوصول البعيد واختبارات العميل. الأول يحدد سلطة التحكم، والثاني يثبت النتيجة.

يضبط RFC 9722 نوافذ التنشيط لتقليل بعض الفترات الانتقالية، لكنه لا يقيس تسليم التطبيق. يعالج RFC 9784 vES وحدود EVC/ENNI والسحب المجمع، بينما يعالج RFC 9785 التفضيل. يستخدم RFC 9786 بعض تلك الأدوات لسؤال مختلف هو إثبات الجاهزية بعد تجميع الخدمات خلف منفذ.

يثبت سجل RFC Editor وIETF Datatracker وبحث errata حالة الوثيقة. لم تعرض اللقطة في 11 سبتمبر 2026 errata مطابقة، لكنها لا تثبت تطبيق الموردين أو النشر أو زمن التقارب أو SLA.