نفس iESI داخل الموقع وفريد بين المواقع: تقطيع Junos

زوجان من البوابات يخدمان مركزَي بيانات، ولا بد من أن يقرر أحد كم قيمة interconnect ESI يحتاجها التصميم. الجواب هو قيمة واحدة لكل مجموعة بوابات، لا واحدة لكل fabric ولا واحدة لكل بوابة. والخطأ في ذلك ينتج fabric يبدو مهيأً وينتخب المُوجِّه الخاطئ، أو يدمج موقعين كان يُقصد بهما أن يبقيا منفصلين. والقاعدة واستثناءاتها تستحقان التدوين بجانب قائمة البوابات.

نطاقان، قاعدتان

داخل الموقع، تعمل بوابات interconnect المكررة كطرف نهائي واحد متعدد التوصيل، لذا تتشارك قيمة interconnect ESI واحدة. ويجب أن يرى نظراؤها عضوًا منطقيًا واحدًا لا عضوين مستقلين. وهذا هو جوهر القيمة المشتركة.

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

داخل الموقع: هوية واحدة للمجموعة

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

النموذج المدعوم هو all-active. ويستثني المرجع نفسه تشغيل single-active والمعرّفات المشتقة تلقائيًا لـ LACP وخيارات source-bmac لهوية التقطيع هذه، لذا فالتصميم الذي افترض أحد تلك يحتاج إلى مراجعة قبل اختيار المعرّف أصلًا. وهذا القيد مدخل تصميم لا حاشية.

بين المواقع: قيم مختلفة، أو دمج متعمد

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

اكتب التمييز المقصود في الخطة، حتى لا يستورد مهندس لاحق ينسخ قالب موقع عامل معرّفه معه.

بيان الند جزء من الهوية

كل بوابة في المجموعة تسرد نظراءها المحليين بعنوان loopback، وتلك العلاقة تعيش على مستوى EVPN العام لا داخل MAC-VRF فردي. ووضعها في الهرمية الخطأ طريقة شائعة لإنتاج تهيئة تُثبَّت لكنها لا تُشكّل المجموعة أبدًا. اقرأ هرمية المرجع مرة، ثم الزمها.

اسم البيان انتقل أيضًا. أعاد Juniper تسمية بيان interconnect peer-gateways في 24.2R1 وأعاد الصيغة الخاصة بـ interconnect لترابط مراكز البيانات في 24.4R1. لذا قد يستخدم مقتطف مأخوذ من الإصدار الوسيط اسمًا لا يقبله الإصدار المنشور، أو العكس. سجّل الإصدار الذي جاء منه المقتطف بجانب المقتطف نفسه.

ما لا يفعله تقاسم iESI

لا يعرّف لك route targets ولا VNIs ولا نسخة EVPN المحلية. تبقى تلك تهيئة منفصلة يجب أن تتفق على الجانبين، فالمعرّف الذي يتطابق بينما لا يتطابق route target ينتج مجموعة تتشكل ولا تحمل شيئًا. قارن جانبي تلك الإعدادات في المرور نفسه.

ولا يثبت إمكانية الوصول بين الندّين ولا انتخاب designated forwarder. اختبر unicast وسلوك broadcast و multicast المطلوب في الحالة الطبيعية، ثم أعد الاختبار بإزالة بوابة واحدة لتحمل العضو الباقي المجموعة وحده.

ذلك التشغيل الثاني هو ما يثبت أن المجموعة حقيقية.

احتفظ بالعضوية الملاحظة وسياق الخدمة مع نتائج الاختبار. ويمكن حينها مراجعة أي تغيير لاحق للمعرّف كتغيير في multihoming، وهو كذلك، لا كتعديل تجميلي لسلسلة نصية. والنتائج هي الدليل الوحيد على أن المعرّف يفعل ما يقوله الرسم.