EVPN VXLAN — распределенный анимаст-шлюз + подавление ARP + бесшумный хост

[jbekk]

Я работаю в среде, где дизайн был завершен до моего прихода. Это мой первый опыт настройки VXLAN, но у меня есть некоторый опыт работы с оверлеями/ACI/и т. д., поэтому я чувствую себя достаточно комфортно. Дизайн имеет 2 пограничных листа, 2 спина, 2 листа. Он имеет множество VLAN и VRF. Много внешней маршрутизации на пограничных листьях. Нет многосайтовой связи (полная сегментация L3 между сайтами).
В настоящее время мы находимся
в середине миграции
и сталкиваемся с
проблемами доступности уровня 2 на одной конкретной VLAN, где хост в старой сетевой структуре не может общаться с соседними хостами VLAN в новой структуре
. Все остальные межсетевые коммуникации работают нормально (как L2, так и L3). Некоторые основные замечания по настройке: Включен распределенный Anycast GW (
т. е. пересылка структуры anycast-gateway-mac xxxx.xxxx.xxxx + (на уровне SVI) режим пересылки структуры anycast-gateway
)
Обучение хостов осуществляется через BGP/EVPN
Подавление ARP включено для каждой VLAN interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 200002
suppress-arp
mcast-group 239.0.1.1
member vni 200003
suppress-arp
mcast-group 239.0.1.5
!
interface Vlan2
no shutdown
mtu 9216
no ip redirects
ip address 192.168.1.1/24
no ipv6 redirects
ip pim sparse-mode
ip pim neighbor-policy NONE*
fabric forwarding mode anycast-gateway Некоторые мысли, которые я хотел бы обсудить: С распределенным шлюзом Anycast SVI, следует ли мне настроить его
как
на пограничных,
так
и на листьевых узлах, если конечные хосты подключены к обоим типам узлов? В проекте шлюз Anycast GW находится
либо
на листьевом, либо на пограничном узле, но не на обоих. Во время миграции у нас есть хосты, подключенные к обоим. В конечном состоянии узлы для каждой VLAN не будут подключены к обоим типам. Я подозреваю, что конфигурация Anycast GW соответствует этому «конечному состоянию», но не будет работать на этапе миграции.
В случае с молчаливым хостом (т. е. хостом, который не общается, если с ним специально не обращаются), является ли лучшей практикой отключить подавление ARP на связанной VLAN, на которой находится молчаливый хост? Я считаю, что подавление ARP в сочетании с EVPN host-learning просто не работает, когда в смеси есть молчаливый хост. Более подробная информация о ситуации с молчаливым хостом приведена ниже... Проблема с молчаливым хостом Примечания: FHRP GW IP для VLAN по-прежнему находится в старой сети.
Некоторые хосты в VLAN подключены к новой структуре VXLAN, но не могут обмениваться данными с молчаливыми хостами в старой структуре (весь трафик уровня 2).
На пограничном листе, если я настрою IP SVI (не GW) на связанной VLAN и выполню ping тихого хоста, фабрика VXLAN обновится, чтобы обеспечить доступность тихого хоста, и все будет в порядке.
Пограничный узел — это место, где старая структура подключается к новой (соединение уровня 2 между ними).
В этой ситуации пересылка уровня 2 работает для других VLAN, только этот молчаливый хост не работает должным образом, пока я не настрою шлюз и вручную не настрою ping.

[Pavel Tarakanov]

С распределенным шлюзом Anycast SVI, следует ли мне настроить его
как
на пограничных,
так
и на листьевых узлах, если конечные хосты подключены к обоим типам узлов? В BGP EVPN рекомендуется использовать функцию шлюза anycast на всех VTEP. https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/103x/configuration/vxlan/cisco-nexus-9000-series-nx-os-vxlan-configuration-guide-release-103x/m_configuring_vxlan_93x.html Также CiscoLive, стр. 22 https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2022/pdf/BRKDCN-2106.pdf В случае с молчаливым хостом (т. е. хостом, который не обменивается данными, пока с ним не установлено специальное соединение), является ли лучшей практикой отключение подавления ARP в связанной VLAN, в которой находится молчаливый хост? Я бы сказал, что в случае правильно настроенного AGW (на всех листьевых коммутаторах и т. д.) он должен работать корректно с молчаливым хостом. В вашем случае лучший подход — настроить AGW на всех листьевых коммутаторах и, возможно, отключить подавление ARP до окончания миграции. (также лучше подумать, нужна ли вам вообще подавлять ARP, так как в обычных условиях трафик не очень большой).

[pwtn]

Я почти уверен, что столкнулся с очень похожей проблемой. Я только что опубликовал новую ветку по этому поводу, но, в основном, у меня есть два узла, соединенных через layer 2 bgp evpn. Первая VLAN работала нормально. Вторая VLAN имеет один очень тихий хост, поэтому MAC выходит из строя, и я теряю маршрут BGP и NVE-пирингование на стороне нетихого хоста. Я могу заставить его работать, настроив SVI на стороне неактивного хоста. Это работает даже тогда, когда SVI не имеет IP, что я даже не могу объяснить. Как только я удаляю SVI, MAC в конечном итоге снова выходит из строя, и я теряю маршрут BGP и пиринг NVE для VNI. Это похоже на логическую ошибку в программном обеспечении, потому что даже ARP, похоже, не «затопляется», пока нет пиринга NVE... а его не будет, пока не будет объявлен маршрут BGP... а он не будет объявлен, пока какой-то трафик не вернет тихий хост в таблицу MAC-адресов на VTEP. Похоже, что пиринг NVE должен основываться на наличии активной VLAN в базе данных, а не на записях в локальной таблице MAC-адресов.

[Dawei]

Хотя это может не относиться к случаям C9K, но для N9K, если VLAN имеет молчаливый хост, вам следует перераспределить прямой (подсеть SVI) в VRF арендатора.

[pwtn]

Проблема заключается в том, что у меня есть сеть EVPN уровня 2, то есть в BGP есть только маршруты хоста типа 2, а на VTEP не настроены SVI. Эта сеть EVPN уровня 2 просто соединяет два сегмента одной и той же VLAN, которые разделены маршрутизируемой сетью подслоя. В моем сценарии VTEP не нужно участвовать в маршрутизации IP-трафика для подсети, нам просто нужно, чтобы они пересылали кадры Ethernet между двумя сайтами и реплицировали кадры широковещания с помощью многоадресной подстилающей сети. Проблема с молчаливым хостом (по крайней мере, в реализации C9K) заключается в том, что VTEP на молчаливой стороне отзовет свои маршруты BGP, когда истечет время ожидания MAC-адреса, что приведет к отключению VNI-пиринга на громкой стороне. После исчезновения пиринга VNI VTEP на активной стороне, по-видимому, не может использовать подслой многоадресной рассылки для пересылки трафика BUM на другую сторону. Таким образом, активные хосты даже не могут «разбудить» неактивный хост с помощью ARP, чтобы запустить обновления BGP и активировать VNI. Создание SVI для VLAN на тихой стороне (даже без IP-адреса) кажется, сохраняет MAC-адрес в таблице и BGP в рабочем состоянии. Я не уверен, что это делает, похоже, что оно не должно ничего делать, но оно явно что-то делает. В идеале я не хочу развертывать шлюз anycast на каждом VTEP, и из руководства C9K по EVPN уровня 2 это не кажется необходимым, или, по крайней мере, в документации нет упоминания о том, как обращаться с молчаливыми хостами.

[Pavel Tarakanov]

Кроме того: Подавление ARP поддерживается для VNI только в том случае, если VTEP является хостом шлюза первого прыжка (распределенного шлюза Anycast) для этого VNI. VTEP и SVI для этой VLAN должны быть правильно настроены для работы распределенного шлюза Anycast, например, должен быть настроен глобальный MAC-адрес шлюза Anycast и функция шлюза Anycast с виртуальным IP-адресом на SVI.
Настройка подавления ARP должна совпадать во всей структуре. Для конкретного VNID все VTEP должны быть либо настроены, либо не настроены. https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/103x/configuration/vxlan/cisco-nexus-9000-series-nx-os-vxlan-configuration-guide-release-103x/m_configuring_vxlan_bgp_evpn.html Таким образом, для подавления ARP шлюз anycast должен быть настроен на всех VTEP.

[jbekk]

Я поднял этот вопрос несколько месяцев назад, но, поскольку этот пост вызвал некоторый резонанс, я хотел бы поделиться некоторой информацией. Ответ, данный Павлом, верный. Несколько советов, которые помогут другим избежать проблем... Anycast SVI необходимо настроить на всех листьевых узлах (BGW/LEAF), где конечные точки будут подключаться к VLAN. Это необходимо для правильной работы ARP-потоков между старыми и новыми коммутаторами. В моей ситуации GW оставался на старых маршрутизаторах в старой среде, поэтому у меня еще не было SVI на коммутаторах LEAF. Планировалось реализовать это в качестве перехода на Layer 3 позднее. Поэтому, если вы попали в такую ситуацию и ARP-подавление включено, временно настройте фиктивный неиспользуемый IP-адрес на узлах LEAF. Это позволит каждому узлу LEAF разрешать ARP для вас, даже если ARP-подавление включено. Когда вы перемещаете шлюз на коммутаторы VXLAN (т. е. в качестве шлюза Anycast). Каждый узел Leaf (к которому подключены устройства в VLAN) нуждается в IP-адресе шлюза, настроенном на соответствующем Anycast SVI. ARP не пересылаются узлами LEAF, когда включено подавление ARP. Первый узел Leaf, который видит ARP, попытается разрешить ARP, но не будет пересылать его другим узлам LEAF. Ознакомьтесь с командой «
show bgp l2vpn evpn
» на коммутаторах Nexus. Она показывает, как коммутатор будет маршрутизировать трафик L2, предназначенный для IP (т. е. пакеты) и/или MAC-адреса (т. е. кадры).
Очень
полезно для понимания, работает ли ARP.
Запустите «
show arp
» на каждом листьевом узле, чтобы понять, работает ли разрешение ARP на каждом LEAF-узле. Я не могу вспомнить подробности по памяти, но есть некоторые странные вещи с запуском пингов с узлов LEAF. Не думайте, что пинг будет работать только потому, что узел LEAF имеет правильный шлюз Anycast. КАЖДЫЙ коммутатор имеет тот же IP-адрес и будет перехватывать пакеты ответа на обратных потоках.
Это все, что я могу вспомнить на данный момент. Надеюсь, это поможет.

[Pavel Tarakanov]

ARP-запросы не пересылаются узлами LEAF, когда включено подавление ARP. Первый узел LEAF, который видит ARP-запрос, попытается разрешить ARP, но не будет пересылать его другим узлам LEAF. ARP-запросы не пересылаются, если коммутатор имеет запись в кэше ARP. В противном случае они должны пересылаться как обычно. Также, несколько полезных команд для кэша подавления ARP: «ip arp suppression-cache clear remote vlan <vlan> <ip>» «ip arp suppression-cache download
remote vlan <vlan> <ip>» >Я не могу вспомнить подробности из памяти, но есть некоторые странные вещи с запуском пингов с LEAF-узлов. Действительно, это не является достоверным тестом, так как ответ на ping может быть использован другим коммутатором с тем же IP-адресом. Здесь есть два варианта: - ping от клиента к AGW - настроить Loopback с уникальным IP в арендаторе и использовать его в качестве источника.