Той самий 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. Поміщення його в неправильну ієрархію — поширений спосіб отримати конфігурацію, яка фіксується, але ніколи не утворює групу. Прочитайте довідкову ієрархію один раз і потім дотримуйтеся її.

Ім’я інструкції теж змінилося. Juniper перейменував інструкцію interconnect peer-gateways у 24.2R1 і відновив специфічну для interconnect форму для interconnect центрів даних у 24.4R1. Тому фрагмент із проміжного релізу може використовувати ім’я, яке розгорнута версія не приймає, або навпаки. Запишіть реліз, з якого взято фрагмент, поруч із самим фрагментом.

Чого не робить спільне використання iESI

Воно не визначає за вас route target, VNI або локальний екземпляр EVPN. Вони залишаються окремою конфігурацією, яка має збігатися з обох боків, і ідентифікатор, що збігається, тоді як route target не збігається, створює групу, яка утворюється і нічого не несе. Порівняйте обидва боки цих налаштувань за один прохід.

Воно також не доводить доступність peer-ів або вибір designated forwarder. Перевірте unicast і потрібну поведінку broadcast та multicast у звичайному випадку, потім повторіть, прибравши один шлюз, щоб член, який залишився, ніс групу сам.

Саме другий прогін доводить, що група реальна.

Зберігайте спостережуване членство та контекст сервісу разом із результатами тестів. Тоді пізнішу зміну ідентифікатора можна розглядати як зміну multihoming, чим вона і є, а не як косметичне виправлення рядка. Результати — єдиний доказ того, що ідентифікатор робить те, що сказано на схемі.