Привязать нетегированный порт доступа к правильному EVPN VNI

Обычный Ethernet-хост отправляет нетегированные кадры, и EVPN-фабрика всё равно должна переносить их в правильном сервисе арендатора. Порт доступа классифицирует кадр в локальный сегмент, VTEP сопоставляет этот сегмент с VNI, а удалённое подключение представляет кадр так, как его ожидает хост. VLAN и VNI обозначают разные части этого пути и не обязаны иметь общий номер. Выполняйте приведённый ниже runbook по порядку, потому что ошибка на любом шаге даёт одинаковый симптом: хост отправляет и ничего не получает.

Проследить один кадр через фабрику

Для простого сервиса на основе VLAN иллюстративный путь выглядит так:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

Номера VLAN и VNI — это примеры, а не правило. Локальный VLAN — это классификация на входе, существующая на одном коммутаторе; L2VNI — это идентификатор overlay-сервиса, который понимают оба VTEP. Спецификация overlay RFC 8365 держит идентификатор сервиса отдельно от того, как подключён хост, и называет три формы: на основе VLAN, сгруппированную и осведомлённую о VLAN.

Настроить классификацию на входе

У хоста есть адрес, и он ничего не достигает, тогда как сам порт виден. Определите, в каком режиме подключения порт на самом деле находится — порт доступа, несущий нетегированные кадры, или trunk с native VLAN — и задайте именно его явно. Нетегированный кадр всё равно покидает порт внутри именованного локального сегмента, и этот сегмент является решением, а не побочным эффектом платформы. Откройте текущую конфигурацию порта и прочитайте классификацию, которая у него действительно есть, вместо того чтобы доверять заводскому значению, которое вы никогда не задавали.

На типичном коммутаторе последовательность такова: смена режима и назначение VLAN доступа, после чего проверка, что порт действительно активен и находится в этом состоянии. Если порт является trunk, native VLAN обрабатывает нетегированные кадры, и это другая конфигурация с другими режимами отказов. Запишите и режим, и VLAN, прежде чем двигаться дальше.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

Настроить VTEP и сопоставление VNI

VTEP добавляет инкапсуляцию VXLAN и VNI. Хост не генерирует этот заголовок и не должен знать, что сервис существует.

Сопоставьте локальный VLAN с L2VNI в поддерживаемой платформой форме команды и держите это сопоставление согласованным на обоих концах сервиса. L2VNI арендатора и L3VNI, используемый для маршрутизации между подсетями, — разные объекты, и смешивание их номеров ломает маршрутизацию, не затрагивая путь L2; и помните, что работающий underlay-маршрут к удалённому VTEP относится ещё к одному слою настройки.

Если сопоставление неверно, кадр всё равно попадает в фабрику и просто оказывается в неправильном сервисе. Поэтому проверка является проверкой сервиса, а не проверкой связи.

Настроить представление на выходе

На дальнем конце полученный сервис нужно превратить обратно в то, что ожидает хост: чистый Ethernet на порту доступа, конкретный тег на trunk, которым вы управляете, и обработка внутреннего тега, соответствующая выбранной модели сервиса. Проверьте список разрешённых VLAN на trunk, прежде чем винить overlay, потому что тег, который выходной trunk не разрешает, отбрасывается после того, как overlay уже выполнил свою работу. Подтвердите, что удалённый хост ожидает именно то представление, которое получает, а не то, что предполагала ваша схема.

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

Читайте вместе локальное обучение MAC, маршрут сервиса EVPN и сопоставление удалённого подключения и управляйте обнаружением соседей, нужным приложению, а не только ping. MAC-адрес, изученный в другом домене моста, может быть там вполне корректным и всё же указывать на неправильный сервис.

Проверить на одной паре хостов

Поднимите одну пару хостов и докажите полный путь, прежде чем добавлять вторую пару. Затем прочитайте состояние на обоих VTEP и подтвердите, что один и тот же идентификатор сервиса появляется на обоих концах.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

Для каждого конца запишите четыре значения: представление порта, локальный сегмент, L2VNI и обратное представление на выходе. Эта запись позволяет следующему инженеру увидеть, почему у хоста простое нетегированное соединение, тогда как фабрика несёт сервис арендатора. Если изменение не удаётся, верните порт к предыдущему VLAN и повторите тест на той же паре, чтобы откат был известным состоянием, а не догадкой.