Привет, Хабр!
Сегодня рассказываем об одном любопытном кейсе в крупном заказчике, который столкнулся со странным поведением при построении свой сети с NSX-T от VMware. Проблема была связана с реализацией Bridge между сегментом GENEVE и физической сетью. В целом, это известный и востребованный механизм, а также он помогает закрыть часть вопросов, когда нужно «подружить» Overlay и физическую сеть без роутинга. До решения докопались – об этом читайте ниже во всех подробностях.
Сначала была…терминология
В первую очередь давайте разберемся, о чем идет речь:
VMware NSX-T — Software Define Network (SDN) — средство для программной реализации сетевой инфраструктуры для среды виртуализации.
GENEVE (Generic Network Virtualization Encapsulation) — это современный протокол инкапсуляции, разработанный для виртуализации сетей в дата-центрах. Основное назначение GENEVE — обеспечить универсальную, гибкую и расширяемую платформу инкапсуляции трафика поверх IP-сетей, аналогично VXLAN, NVGRE и другим протоколам, но без их ограничений.
Network bridge (сетевой мост) — аппаратное или программное средство, позволяющее соединить две L2-сети, чтобы подключенные устройства к ним взаимодействовали так, как будто они находятся в единой сети передачи данных.
Техническая сторона вопроса
Начнем с Bridge — схематично это выглядит так:
Четыре виртуальные машины на схеме взаимодействуют, как будто они находятся в единой L2-сети благодаря Edge-ноде (bridge VM). Она как раз обеспечивает «склеивание» этих сетей. То есть Edge выступает как Gateway между сетями, потому что именно эта сущность отвечает за передачу трафика между ними. Естественно, это не тот привычный Gateway, который мы знаем в L3-сетях.
В нашей статье мы не будем рассматривать применимость и процесс настройки такой конфигурации — она есть, и заказчик ожидает от нее функционирования, описанного вендором. На начальном этапе диагностики все выглядело штатно и ничего не вызывало подозрений. Проблема проявлялась в момент периодического обрыва соединения между ВМ в Overlay-сегменте. При этом стоило отключить Bridge — и проблема переставала воспроизводиться.
Диагностика 1.0
Начали с анализа конфигурации, или с ответа на базовый вопрос: «А должно ли оно вообще работать на этой инфраструктуре?» Мы собрали информацию о версиях ПО, моделях оборудования, версиях микрокода и т.п. Критичных недостатков не нашли.
А теперь погрузимся в техническое досье.
Хосты: Huawei 2288H V5, версия прошивки актуальная (8.60), в списке поддерживаемого оборудования.
Сетевые карты: Intel(R) Ethernet Controller E810-XXV for SFP, в списке поддерживаемого оборудования.
Конфигурация сетевых карт различалась на хостах. На некоторых из них использовался драйвер i40en, который отсутствовал в матрице совместимости для этой карты в версии ESXi 7.0 U3. На других использовался правильный драйвер icen, но устаревшей версии. Версия микрокода отличалась между хостами от старой до почти актуальной. Приводим пример для наглядности:
Intel(R) Ethernet Controller E810-XXV for SFP
Driver Info:
NICDriverInfo:
Bus Info: 0000:1a:00:0
Driver: i40en
Firmware Version: 3.33 0x80000f09 255.65535.255
Version: 1.11.1.31
Intel(R) Ethernet Controller E810-XXV for SFP
Driver Info:
NICDriverInfo:
Bus Info: 0000:3b:00:0
Driver: icen
Firmware Version: 4.20 0x8001778c 1.3346.0
Version: 1.11.3.0Дальше проверили статистику сетевых адаптеров, где использовался неактуальный для карты драйвера i40en. Здесь мы увидели ошибки (см. везде, где csumErr>0):
statistics for vmnic5:
Packets received: 17575814333
Packets sent: 3631200285
Bytes received: 213920161325999
Bytes sent: 3040563998738
Receive packets dropped: 0
Transmit packets dropped: 3
Multicast packets received: 145085227687
Broadcast packets received: 56702606
Multicast packets sent: 212070
Broadcast packets sent: 48130
Total receive errors: 583794
rxq0: totalPkts=39132256668 totalBytes=52984870441846 nonEopDescs=0 allocRxBufFail=0 csumErr=114039
rxq1: totalPkts=2978994761 totalBytes=2807054323782 nonEopDescs=0 allocRxBufFail=0 csumErr=1900886
rxq2: totalPkts=17548308 totalBytes=2241587230 nonEopDescs=0 allocRxBufFail=0 csumErr=20264
rxq3: totalPkts=18590526 totalBytes=2173003607 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq4: totalPkts=52415322 totalBytes=36329387189 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq5: totalPkts=987184 totalBytes=1396854664 nonEopDescs=0 allocRxBufFail=0 csumErr=7
rxq6: totalPkts=19453 totalBytes=9503929 nonEopDescs=0 allocRxBufFail=0 csumErr=9
rxq7: totalPkts=467 totalBytes=64392 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq8: totalPkts=46869994606 totalBytes=63606052380631 nonEopDescs=0 allocRxBufFail=0 csumErr=115334
rxq9: totalPkts=22154733770 totalBytes=30058993915763 nonEopDescs=0 allocRxBufFail=0 csumErr=116087
rxq10: totalPkts=37111956111 totalBytes=50350881802937 nonEopDescs=0 allocRxBufFail=0 csumErr=144747
rxq11: totalPkts=4189004119 totalBytes=2845332063968 nonEopDescs=0 allocRxBufFail=0 csumErr=1968393
rxq12: totalPkts=3059676827 totalBytes=2467730561388 nonEopDescs=0 allocRxBufFail=0 csumErr=1902820
rxq13: totalPkts=6951411455 totalBytes=7332226621085 nonEopDescs=0 allocRxBufFail=0 csumErr=1854472
rxq14: totalPkts=5253324 totalBytes=1346238845 nonEopDescs=0 allocRxBufFail=0 csumErr=5592
rxq15: totalPkts=61031142 totalBytes=8438827098 nonEopDescs=0 allocRxBufFail=0 csumErr=14212
rxq16: totalPkts=8143647 totalBytes=5548849517 nonEopDescs=0 allocRxBufFail=0 csumErr=4244
rxq17: totalPkts=10875879 totalBytes=717808877 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq18: totalPkts=32 totalBytes=2163 nonEopDescs=0 allocRxBufFail=0 csumErr=0Количество ошибок не превышает уровня 0,0033% от полученного числа пакетов. Некоторые не воспринимают это всерьез, а зря.
Примечание инженера поддержки: некоторые специалисты считают, что величина менее 1% — это несущественная погрешность. Помните: наличие ошибок говорит об их наличии и вероятных проблемах.
На хостах, где использовался драйвер icen, статистика была значительно лучше:
Packets received: 7373650
Packets sent: 4969060
Bytes received: 8447114701810
Bytes sent: 1996620984
Receive packets dropped: 0
Transmit packets dropped: 0
Multicast packets received: 6185074637
Broadcast packets received: 2487373
Multicast packets sent: 10224
Broadcast packets sent: 128475
Total receive errors: 0
Receive length errors: 0
Receive over errors: 0
Receive CRC errors: 0
Receive frame errors: 0
Receive FIFO errors: 0
Receive missed errors: 0
Total transmit errors: 0
Transmit aborted errors: 0
Transmit carrier errors: 0
Transmit FIFO errors: 0
Transmit heartbeat errors: 0
Transmit window errors: 0
txq0: totalPkts=2173008 totalBytes=1702166091 restartQueue=3 txBusy=0 queueFull=0 pktDropped=0
txq1: totalPkts=2234623 totalBytes=210634743 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq2: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq3: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq4: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq5: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq6: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq7: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq8: totalPkts=0 totalBytes=0 restartQueue=157 txBusy=0 queueFull=0 pktDropped=0
txq9: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq10: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq11: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq12: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq13: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq14: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq15: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq16: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq17: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq18: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq19: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq20: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq21: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq22: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq23: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq24: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq25: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq26: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq27: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq28: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq29: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq30: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
txq31: totalPkts=0 totalBytes=0 restartQueue=0 txBusy=0 queueFull=0 pktDropped=0
rxq0: totalPkts=1694879343 totalBytes=2293636721800 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq1: totalPkts=423 totalBytes=116639 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq2: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq3: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq4: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq5: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq6: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq7: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq8: totalPkts=1930937971 totalBytes=2619979761376 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq9: totalPkts=865436278 totalBytes=1171243353797 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq10: totalPkts=1675204536 totalBytes=2274196147626 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq11: totalPkts=102932 totalBytes=6262576 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq12: totalPkts=934 totalBytes=195877 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq13: totalPkts=125897 totalBytes=7643852 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq14: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq15: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq16: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq17: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq18: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq19: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq20: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq21: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq22: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq23: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq24: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq25: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq26: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq27: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq28: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq29: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq30: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0
rxq31: totalPkts=0 totalBytes=0 nonEopDescs=0 allocRxBufFail=0 csumErr=0Рекомендации по актуализации драйверов и прошивок мы направили заказчику. Но коллективный разум нашей команды решил, что между найденными ошибками и проблемой связи нет.
Сетевое оборудование: отечественное решение*.
*Вендора мы намеренно называть не стали, чтобы у читателя не возникало взаимосвязи между нашей проблемой и производителем. Его команда активно подключалась к диагностике, что внесло свой вклад в поиск решения. Сразу спойлер: наша проблема не связана с этим продуктом.
Диагностика 1.1
Переходим к анализу логов. Собрали необходимые данные со следующих узлов:
ESXi-хостов: здесь работали ВМ в сегменте Overlay. В этом месте мы должны были убедиться в корректном взаимодействии NSX на хостах с Control Plane. Помимо этого, проверили логи ядра гипервизора на ошибки в работе сетевой части.
ESXi-хостов Edge-кластера, где работали Edge Transport Nodes. Эти хосты не были «подготовлены» для NSX (не имели на себе установленных компонент NSX), так как все необходимые действия производятся именно на стороне ETN. Но нам важно понимать, все ли функционировало штатно.
NSX manager'ов — тут проверили валидность информации по профилям, сегментам и интерфейсам нод, которые участвовали в нашей схеме (рис. 1).
Кластеров Edge Transport Node (ETN) для проверки корректности работы моста и настроенных на них N-VDS.
В результате анализа собранной информации мы обнаружили поведение системы, описанное в одной из статей Broadcom. Не ищите.
Согласно статье, такого поведения на текущих версиях быть не должно.
В чем же суть проблемы?
В нашем случае проблема воспроизводилась на версии NSX-T и 3.2.3.1 и 4.x. При взаимодействии компонент NSX-T на ESXi с Control Plane хосты строят у себя три таблицы с данными о ВМ, которые работают в рамках Overlay-сетей:
TEP table содержит информацию обо всех хостах (их vTEP-интерфейсах), на которых запущены ВМ, подключенные к сегментам NSX-T.
MAC table хранит информацию о MAC-адресах ВМ и их «привязке» к vTEP-адресам хостов.
ARP table предназначена для сокращения BUM-трафика в инфраструктуре NSX-T, так как информация о всех MAC виртуальных машин и так известна в рамках транспортной зоны.
Как сказано в статье, для старых версий проблема решается с помощью включения Advanced Settings на ESXi хостах Edge кластера ReversePathFwdCheckPromisc. Чтобы понять, зачем нужен этот параметр и что он делает, нам стоит сделать небольшое техническое отступление и детальнее рассмотреть один механизм.
На схеме (рис. 2) сделан акцент именно на ESXi-хост, где находится активная ETN-нода, через которую работает созданный Bridge. Опишем детальнее составные части этого решения (см. - картинку):
1. ESXi-хост с 4, например, аплинк-портами (их может быть больше – это не принципиально).
2. Две порт-группы на vDS, к которым подключается ETN. Группа слева имеет настройки сервисного vLAN для работы в рамках OverlayTZ, вторая использует vLAN для взаимодействия с «внешним миром». Для второй группы необходимо дополнительно включить Promiscuous mode и Forged Transmits или MAC Learning.
3. Два N-VDS на стороне ETN. В рамках одного из них находится TEP-интерфейс ETN-ноды и обрабатывается Overlay-трафик — он будет в Overlay TZ. Второй будет подключен к vLAN TZ.
4. Два физических свича — к ним подключены аплинки PG vDS, которые связывают ETN с внешней физической сетью. Аплинки другой PG имеют аналогичные подключения, но для упрощения схемы мы это опустим.
5. За физическими свичами на правой части схемы живет некая инфраструктура, на которой существуют VM_C и VM_D.
Теперь представим, что ВМ_B хочет «поговорить» с ВМ_С. Что при этом произойдет?
VM_B инициирует ARP-запрос с MAC-адресом VM_C. Так как информации об этом MAC в ARP-таблице сегмента нет, этот пакет отправится на ETN для поиска адреса на другом конце Bridge-сегмента.
ETN ретранслирует этот ARP во «внешний мир».
Физический свич ищет информацию об искомом MAC-адресе в своей таблице MAC-адресов. Если не обнаружит, отправит ARP во все порты, кроме того, откуда он получил этот ARP-пакет.
Если первый свич не нашел в своей таблице MAC информацию о нужном адресе, происходит пересылка ARP на второй свич, который тоже «не в курсе». Вследствие этого, согласно заложенной логике отправит ARP во все порты. Именно здесь и появляется необходимость настройки ReversePathFwdCheckPromisc. Так как в большинстве случаев администраторы используют включение Promiscuous mode и Forged Transmits, полученный пакет на аплинк хоста со второго свича будет по умолчанию распознан как ARP из «внешнего мира» в сторону нашего Bridged-сегмента. Эта опция отвечает за проверку и предотвращение возврата подобных пакетов обратно виртуальной машине, которой в данном случае является ETN.
Когда сетевое оборудование на правой части схемы все же получает ответ от VM_C, необходимая информация возвращается на VM_B, а ARP-записи сохраняются в таблице коммутатора.
Все последующие сетевые взаимодействия между VM_B и VM_C пойдут по тому же маршруту, так как на стороне ESXi-хостов появится запись в таблице Host Kernel Entry, которая будет говорить о нахождении MAC-адреса VM_C за vTEP ETN.
Технических деталей много не бывает: продолжаем
Для упрощения рассмотрели сегмент с двумя подключенными ВМ, которые находились на разных хостах (рис. 4).
Вывод команды get logical-switch <VNI> mac-table показывает нам MAC-адреса всех ВМ в данном сегменте. При этом ВМ, расположенные на текущем хосте, отображаются в таблице LCP Local Entry, а ВМ, расположенные на других хостах, — в таблице LCP Remote Entry. Столбец Outer IP показывает, за каким vTEP числится та или иная ВМ. Таким образом, когда ВМ с MAC-адресом 00:50:56:93:1f:ca инициирует сетевые обращения в сторону машины 00:50:56:93:31:d7, ESXi-хост, где живет источник, на основании этих данных запаковывает пакеты ВМ в GENEVE и отправляет хосту с адресом 10.xx.yy.120, и наоборот.
Диагностика 1.3
Когда мы подробно рассмотрели матчасть, возвращаемся к анализу.
Что же происходило при воспроизведении проблемы у заказчика? Взяли тестовый стенд:
MAC-адрес одной из ВМ (00:50:56:b0:96:c6) отображается в таблице LCP Remote Entry. Значит, ESXi-хост знает, что эта ВМ живет в рамках того же сегмента, но на хосте с vTEP 192.xx.yy.11. Но при этом в таблице Host Kernel Entry тот же MAC числится за IP-адресом vTEP ETN (192.xx.yy.15). Как только появляется запись в таблице Host Kernel Entry, сетевая доступность ВМ на удаленном хосте теряется. То есть ВМ с MAC 00:50:56:b0:5d:98 не сможет «достучаться» до ВМ с MAC 00:50:56:b0:96:c6. Хост будет отправлять пакеты в сторону ETN, вместо отправки инкапсулированных в GENEVE пакетов на хост 192.xx.yy.11.
Занимательно: в этот момент по поводу происходящего хост 192.xx.yy.11 думает то же самое. Этот хост знает, что ВМ живет на нем, но он так же имеет запись в Host Kernel Entry, что этот MAC «засветился» совершенно в другом месте – на ETN.
В этот момент у нас сразу же появилось предположение: проблема связана с ARP-пакетами, которые отправляются с ВМ 00:50:56:b0:96:c6 во «внешний мир». Мы быстро установили, что проблема появлялась, как только ВМ-источник в Overlay инициировал подключение к адресу, который не отвечал или вообще не существовал в рамках L2-домена. Мы решили снять дамп трафика, где увидели два типа ARP:
1. ARP, которые пересылались с хоста, где жил ВМ-источник, инкапсулированы в GENEVE и отправлялись не как broadcast-трафик, а на конкретный destination:
2. ARP, который уходит с ETN во вне:
Проанализировав, мы поняли: на ETN из vLAN-сети попадает обратный ARP-пакет. Он благополучно пересылался на хосты в рамках сегмента NSX-T. Когда хосты получали эти пакеты, они добавляли запись в таблицу Host Kernel Entry. Соответствующая запись говорила о том, что источник живет где-то за vTEP ETN, потому что отправленный ARP-пакет пришел именно с ETN. Так как таблица Host Kernel Entry является более приоритетной, трафик между ВМ шел в неверном направлении. При этом параметр ReversePathFwdCheckPromisc оставался включенным.
Мы сняли дамп входящего трафика со switchport, к которому был подключен vLAN-интерфейс ETN, и выдвинули предположение. А что если проблема кроется в сетевом оборудовании? Оно не находит MAC-адрес у себя в таблице и отправляет ARP-пакет во все порты, в том числе и туда, откуда этот пакет изначально пришел.
Вендор сетевого оборудования, который тоже проводил свое расследование, поделился своими данные. Они оказались другими. Так, в дампах, на стороне ESXi «обратные» ARP'ы были, а в дампах сетевого оборудования — нет.
Зеркалируя трафик в другие порты свича и вставляя дополнительные свичи посередине (между ESXi и свичем, откуда в обратку прилетал ARP), мы не нашли источник возвращающихся ARP-пакетов на стороне физической сети.
Парадокс-отступление инженера: ARP'ы есть, но ARP'ов нет.
В этот момент заказчик постепенно актуализировал конфигурацию сетевых карт согласно выданным ранее рекомендациям. В процессе мы заметили: проблема не воспроизводилась на некоторых хостах. Залезли в Release Notes для рекомендованного драйвера. Ответ оказался на поверхности:
Bug Fixes / Enhancements:
-------------------------
Updated Health Status message.
Fixed secondary queues usage for fragmented IP packets.
Added per-queue stats for Native mode.
Fixed Broadcast packets forwarding rules to avoid ARP loopback issue for VMDQ traffic.
Именно драйвер сетевой карты ESXi отправлял обратные ARP-пакеты и «ломал» сетевое взаимодействие между ВМ в рамках одного сегмента NSX-T.
Выводы:
Для того, чтобы понять, что именно этот фикс исправит проблему, потребовались: детальная диагностика, стендирование и разворачивание дамп-кампании.
Даже если информация о проблеме и решении находится у вас прямо под носом, частенько путь к ней долог и тернист.
Удачи с диагностикой! Немного саморекламы – не знаете, как проверить и что искать в VMware, приходите к нам.
До встречи!
Алексей Радченко
Директор центра компетенций VMware, «Инфосистемы Джет»