همان iESI در یک سایت، یکتا میان سایتها: دوخت Junos

دو جفت دروازه به دو مرکز داده سرویس میدهند و کسی باید تصمیم بگیرد طراحی به چند مقدار interconnect ESI نیاز دارد. پاسخ یکی برای هر گروه دروازه است، نه یکی برای هر fabric و نه یکی برای هر دروازه. اشتباه در این کار fabricای میسازد که پیکربندیشده به نظر میرسد و forwarder اشتباه را انتخاب میکند، یا دو سایتی را ادغام میکند که قرار بود جدا بمانند. قاعده و استثناهایش ارزش دارد کنار فهرست دروازهها نوشته شود.

دو حوزه، دو قاعده

درون یک سایت، دروازههای interconnect افزونه بهعنوان یک نقطه پایان multihomed عمل میکنند، بنابراین یک interconnect ESI مشترک دارند. peerهای آنها باید یک عضو منطقی ببینند نه دو عضو مستقل. تمام منظور از مقدار مشترک همین است.

میان سایتها، هر گروه دروازه مقدار خودش را میگیرد. دو مرکز داده که یک شناسه را به اشتراک میگذارند در صفحه کنترل به یک گروه multihomed تبدیل میشوند، که معمولاً منظور یک طراحی دوخت در سراسر WAN نیست. دو سایت در یک گروه همچنین حالتهای خرابی یکدیگر را به ارث میبرند.

درون یک سایت: یک هویت برای گروه

به جفت، همان مقدار را روی هر دو peer، در همان بافت سرویس بدهید و آن را در فهرست شناسههای شبکه ثبت کنید نه در یک رشته گفتوگو. ناسازگاری میان دو عضو همان حالت خرابی است که گروهی از یک عضو و بدون هشدار آشکار میسازد. پیش از باور به یک نشست کارکننده، هر دو عضو را مقایسه کنید.

مدل پشتیبانیشده all-active است. همان مرجع عملیات single-active، شناسههای LACP مشتقشده بهطور خودکار و گزینههای source-bmac را برای این هویت دوخت کنار میگذارد، پس طراحیای که یکی از آنها را فرض کرده بود باید پیش از حتی انتخاب شناسه بازنگری شود. این محدودیت یک ورودی طراحی است، نه یک پانویس.

میان سایتها: مقادیر متفاوت، یا ادغام عامدانه

مقدار یکتا برای هر سایت دو گروه دروازه را جدا نگه میدارد. اگر قصد واقعاً گسترش یک گروه multihomed در سراسر سایتها باشد، آن معماری دیگری است با پیامدهای خاص خود برای تأخیر، خرابی و ارسال، و باید بهعنوان معماری تصمیمگیری شود نه بهعنوان انتخاب شناسه. آن تصمیم را پیش از پنجره نگهداری کتباً بخواهید.

تمایز موردنظر را در طرح بنویسید تا مهندس بعدی که یک الگوی سایت کارکننده را کپی میکند، شناسه آن را هم با خود وارد نکند.

دستور peer بخشی از هویت است

هر دروازه در گروه، peerهای محلی خود را با نشانی loopback فهرست میکند و آن رابطه در سطح جهانی EVPN زندگی میکند نه درون یک MAC-VRF منفرد. قرار دادنش در سلسلهمراتب اشتباه روش رایجی برای ساختن پیکربندیای است که commit میشود اما هرگز گروه را تشکیل نمیدهد. سلسلهمراتب مرجع را یک بار بخوانید و سپس به آن پایبند بمانید.

نام دستور هم جابهجا شد. Juniper دستور interconnect peer-gateways را در 24.2R1 تغییر نام داد و شکل مخصوص interconnect را برای interconnect مراکز داده در 24.4R1 بازگرداند. بنابراین قطعهای که از نسخه میانی گرفته شده میتواند نامی را به کار ببرد که نسخه مستقرشده نمیپذیرد، یا برعکس. نسخهای را که قطعه از آن آمده کنار خود قطعه ثبت کنید.

آنچه اشتراک یک iESI انجام نمیدهد

route targetها، VNIها یا نمونه EVPN محلی را برای شما تعریف نمیکند. آنها پیکربندی جداگانهای میمانند که باید در هر دو طرف توافق داشته باشد، و شناسهای که مطابقت دارد در حالی که route target مطابقت ندارد، گروهی میسازد که تشکیل میشود و چیزی حمل نمیکند. هر دو طرف آن تنظیمات را در همان گذر مقایسه کنید.

همچنین دسترسپذیری peer یا انتخاب designated forwarder را اثبات نمیکند. unicast و رفتار موردنیاز broadcast و multicast را در حالت عادی آزمایش کنید، سپس با حذف یک دروازه تکرار کنید تا عضو بازمانده گروه را تنها حمل کند.

همان اجرای دوم است که ثابت میکند گروه واقعی است.

عضویت مشاهدهشده و بافت سرویس را همراه با نتایج آزمون نگه دارید. تغییر بعدی شناسه آنگاه میتواند بهعنوان تغییر multihoming، که همان است، بازبینی شود نه بهعنوان ویرایش ظاهری یک رشته. نتایج تنها شاهدی است که نشان میدهد شناسه همان کاری را میکند که نقشه میگوید.