Стройте границу EVPN вокруг политики экспорта, а не подключений

Обычное допущение состоит в том, что модель подключения Layer 2 на границе определяет всё выше неё, поэтому проектирование начинается с пары vPC и идёт вверх. Обычно это заканчивается решениями о маршрутизации, принятыми случайно. Граница EVPN — это прежде всего граница маршрутизации: контекст маршрутизации арендатора встречается с внешним доменом маршрутизации, и то, что пересекает эту линию, является утверждением политики. Выберите маршруты, отношение ASN и пути отказов до того, как кто-либо начнёт спорить о port-channels. Модель подключения затем следует из требования, а не диктует его.

Начните с того, что пересекает границу

Запишите маршруты, которые должны быть видны с каждой стороны, направление их движения и того, кто утверждает изменение этого списка. Граница, которая принимает всё и анонсирует всё, не имеет политики, только кабель.

Затем назовите отказ, который вы собираетесь эксплуатировать: один uplink недоступен, один border leaf недоступен или весь внешний домен недостижим. Каждый ответ меняет, нужны ли вам два независимых соседа, общее подключение Layer 2 или и то и другое.

Только после того, как эти два списка существуют, вопрос о подключении становится разрешимым. До этого каждый механизм выглядит одинаково допустимым. После этого большинство из них исключают себя сами. В этом весь аргумент в пользу того, чтобы сначала сделать работу по маршрутизации.

Зафиксируйте границу ASN и peering

Фабрика с частными AS обычно устанавливает peering с публичным пограничным доменом через eBGP, и интересная часть — политика с обеих сторон. Решите, какие префиксы принимаются, какие анонсируются и какой AS path должен получить upstream.

RFC 6996 резервирует диапазон ASN для частного использования, и эти ASN не должны появляться в глобальных анонсах. Примените поддерживаемую платформой политику удаления или фильтрации и проверьте получившийся анонс, а не предполагайте, что устройство это сделало. Этот шаг также не даёт вам права анонсировать произвольный публичный префикс — это отдельный разговор с владельцем адресов.

Конфедерация или функция local-AS — это проектное решение для конкретной топологии. Ни то, ни другое не обязательно только потому, что фабрика и upstream используют разные роли ASN, а принятие одного без требования добавляет движущиеся части в каждое будущее изменение.

Uplink-и Layer 3 не нуждаются в multichassis LAG

Независимые маршрутизируемые интерфейсы со своими соседями BGP дают два ясных пути и два ясных домена отказа. vPC или другой multichassis LAG обслуживает требование подключения Layer 2 и является правильным инструментом, когда такое требование есть.

Общее правило о том, что каждая пограничная пара должна использовать vPC или должна его избегать, скрывает условия, которые на самом деле решают вопрос. Спросите, что должно нести подключение, и затем выберите механизм, который несёт это с наименьшим числом общих режимов отказа.

Политика маршрутизации, которую вы написали первой, не меняется при изменении механизма подключения, и это хороший признак того, что порядок был верным.

Экспортируйте только то, что нужно арендатору

Арендатору может понадобиться маршрут по умолчанию, набор выбранных внешних префиксов или гораздо большая таблица. Выбирайте этот объём исходя из реальной ёмкости пересылки и плоскости управления, а не из старого числа интернет-маршрутов, которое никто не перемерил.

Маршрут EVPN IP Prefix, обычно называемый Type 5 и определённый в RFC 9136несёт информацию о префиксе в overlay. Реализация по-прежнему нуждается в согласованной политике экспорта и импорта плюс разрешении next-hop, поэтому получение внешнего маршрута BGP на границе не означает, что каждый VRF арендатора его импортирует.

Не каждому leaf нужна полная таблица только потому, что граница её держит. Распределяйте то, что требует трафик арендатора, а остальное пусть держит граница.

Проверьте один префикс от начала до конца

Выберите представительный внешний префикс и проследите его через предполагаемый VRF границы, политику экспорта, контекст пересылки принимающего leaf и обратный путь к источнику арендатора. Префикс, который появляется в одном месте и не появляется в следующем, сразу локализует ошибку.

Подтвердите, как next hop разрешается через overlay, потому что маршрут, присутствующий с неразрешённым next hop, ничего не пересылает. Затем повторите проверку после изменения uplink, так как именно тогда политика и разрешение next-hop чаще всего расходятся.

Порядок работы: перечислите пересекающие маршруты, согласуйте политику ASN, выберите подключение под его реальную задачу, ограничьте экспорт для каждого арендатора, затем проверьте один префикс и его обратный путь.