Один и тот же 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, чем оно и является, а не как косметическую правку строки. Результаты — единственное доказательство того, что идентификатор делает то, что сказано на схеме.