Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги. Наш сегодняшний рассказ мы начнем с небольшой истории.
Было 2 часа ночи, когда инженер из отдела сетевой инфраструктуры крупного европейского провайдера IPTV получил вызов. Мониторинг показывал странную картину: каналы вещания на десятках тысяч клиентских устройств начали «рассыпаться» — видео фризилось, аудио пропадало, а через 3 минуты 20 секунд после каждой перезагрузки сервиса всё повторялось заново, словно по расписанию. Симптомы выглядели так, будто кто‑то каждый раз выдергивал и вставлял обратно оптоволоконный патчкорд. Но логов ошибок не было. Или почти не было.
Это не выдуманный сценарий. Это реальная проблема, которая преследует владельцев и администраторов сетевых карт Intel X710 (и родственных им X722, XXV710) на протяжении последних нескольких лет. И сегодня мы разберем её до костей — от физики работы ASIC‑чипа до строчки кода в драйвере FreeBSD, которая одной правкой убила мультикаст в половине дистрибутивов.
Кто такой Intel X710 и почему он вообще существует
Прежде чем говорить о багах, нужно понять, с каким зверем мы имеем дело. Intel X710 — это сетевая карта из семейства Fortville, построенная на чипе «Ethernet Controller XL710». Её ключевая особенность — аппаратная виртуализация и offload‑функции.
В отличие от «тупых» NIC‑карт, которые просто пересылают байты туда‑обратно, X710 — это маленький компьютер на PCIe‑шине. У него есть:
Собственный процессор (микроконтроллер) для управления очередями.
Специализированный ASIC для обработки VLAN, VXLAN, checksum.
Таблицы фильтрации (MAC/VLAN/мультикаст) в аппаратной памяти.
Механизм VMDq для виртуализации.
Именно этот «интеллект» и создает проблемы. Потому что, когда железо пытается быть слишком умным, но при этом в его прошивке есть баги — всё превращается в ад.
Симптоматика: что чувствует инженер до диагноза
Давайте пройдем путь диагностики так, как это видел тот самый инженер. В логах системы всплывает строчка, от которой у любого, кто работал с X710, холодеет кровь:
Лог повторяется каждые несколько секунд. На первый взгляд, ничего страшного — обычное изменение режима мультикаст. Но опытный глаз понимает: эта строчка появляется не просто так.
Она появляется тогда, когда драйвер пытается что‑то починить. А когда драйвер пытается чинить — значит, что‑то сломано.
Инженер запускает netstat -g и видит, что IGMP‑группы на интерфейсе есть. tcpdump -i ixl0 igmp показывает, что join‑запросы уходят в сеть, а ответы приходят. Wireshark на соседней ноде фиксирует входящий мультикаст‑трафик. Но приложение на этой ноде его не получает.
Классическая ситуация, описанная на форумах Intel и Netgate: IGMP join прошел, bind есть, трафик в сеть пришел, но NIC его отбрасывает на входе.
Самое интересное: если включить promiscuous mode на интерфейсе (ip link set ixl0 promisc on), трафик внезапно появляется. Выключить promisc — исчезает. Это железный (буквально) аргумент в пользу того, что проблема именно в аппаратной фильтрации NIC, а не в сетевом стеке ОС.
Перед тем как уходить глубже в мультикаст, фильтры и поведение сетевых карт, можно свериться с базой: пройти вступительный тест к курсу «Сетевой инженер. Базовый уровень». Это быстрый способ понять, где лучше подтянуть матчасть.
Анатомия аппаратного мультикаст‑фильтра
Чтобы понять, почему это происходит, нужно залезть внутрь X710 и посмотреть, как он обрабатывает мультикаст. В обычном режиме сетевой стек ОС получает все пакеты, которые пришли на MAC‑адрес интерфейса, на broadcast‑адрес и на те мультикаст‑группы, на которые интерфейс явно подписан. Всё вроде бы просто.
Но X710 с включенной VMDq (Virtual Machine Device Queues) пытается быть эффективнее. Он не отправляет в драйвер пакеты с мультикаст‑адресами, на которые никто не подписан. Для этого у него есть:
Perfect filters — точные совпадения MAC‑адресов (обычный unicast).
Multicast address table — таблица мультикаст‑адресов, загружаемая драйвером. Обычно имеет размер до 256 записей.
Promiscuous multicast mode — режим, в котором NIC пропускает все мультикаст‑пакеты без фильтрации.
Проблема: при использовании VMDq мультикаст‑трафик должен реплицироваться аппаратно в несколько RX‑очередей (по одной на каждую VM или приложение). И вот в этом механизме репликации и кроется баг.
Что происходит в момент «Disabled multicast promiscuous mode»
Драйвер в какой‑то момент решает, что можно выключить мультикаст и использовать точные фильтры (perfect filters). Он загружает в NIC таблицу мультикаст‑адресов. Но где‑то внутри ASIC происходит сбой: не все адреса из таблицы правильно загружаются в аппаратную память фильтрации.
Некоторые группы просто «выпадают». После этого NIC начинает отбрасывать пакеты в этих группах. При этом сам IGMP join — это управляющий трафик, он идет на 224.0.0.1 (all hosts) или 224.0.0.2 (all routers) и всегда пропускается. А вот трафик с данными на конкретной группе — блокируется.
Драйвер, видя, что трафик не идет, паникует и включает promiscuous mode. Оттуда лог «Enabled...». Потом снова пытается вернуться к нормальной фильтрации. Цикл замыкается.
Хронология эпидемии: как один коммит убил мультикаст
А теперь — самое интересное. В определенный момент проблема перестала быть случайным багом и стала тотальной эпидемией. Почему? Потому что кто‑то «починил» драйвер.
В 2023–2024 годах в драйвер Intel для FreeBSD (ixl) был внесен коммит, который изменил логику управления мультикастом. Конкретно — коммит D40860 в репозитории FreeBSD.
Раньше драйвер вел себя консервативно: при любых сомнениях включал мультикаст. После коммита логика стала агрессивнее — драйвер чаще пытался использовать точные фильтры, полагая, что NIC в актуальных версиях прошивки работает корректно.
Но NIC не работал корректно, и в результате:
pfSense 2.7.1 и 2.7.2 — мультикаст сломался.
OPNsense 24.7 и выше — та же проблема.
Апстрим FreeBSD — та же проблема.
Но реверт этого коммита (возврат к старой логике) полностью решал проблему.
Впрочем, X710 известен не только мультикаст‑проблемами. Это целый «зоопарк» багов, которые делают жизнь инженеров «интересней» (в смысле китайской пословицы «пусть вы живете в интересные времена»).
TX Hang и фатальный сброс uplink
Одна из самых частых проблем на Windows и ESXi — сообщение «TX hang detected! Reset Uplink». Симптомы: сеть «пропадает» на несколько секунд, затем восстанавливается. В больших кластерах это выглядит как массовый флаппинг линков.
Причина: при определенных условиях (часто — при прохождении пакетов меньше 64 байт) TX‑очередь NIC впадает в ступор. Драйверный watchdog таймаутится и инициирует аппаратный reset. NIC перезагружается, очередь очищается, связь восстанавливается.
VXLAN checksum — когда железо не может посчитать
Еще один баг, описанный в багтрекере DPDK: X710 не умеет правильно считать outer UDP checksum для VXLAN‑пакетов. Причем в IPv4 — норм, в IPv6 — ноль. Это официально подтверждено даташитом X710:
“Tunneling UDP headers and GRE header are not offloaded while the X710/XXV710/XL710 leaves their checksum field as is”.
То есть если вы используете VXLAN с IPv6 транспортом и надеетесь, что NIC сам посчитает контрольную сумму — ваши пакеты будут отбрасываться на приемной стороне.
Как лечить (и жить дальше)
Теперь перейдем к практической части. Если у вас X710, и он ведет себя странно, вот дорожная карта лечения, от быстрых костылей до полного излечения (по материалам анализа H3C и Broadcom).
Уровень 1. Экстренное лечение (5 минут, стоп‑кровотечение)
Открываем Device Manager (или пишем ethtool) и отключаем:
Large Send Offload V2 (IPv4 и IPv6) — это дает наибольший эффект при TX Hang.
Energy Efficient Ethernet — серверу не нужен, а выключает нестабильный LPI.
Если используете виртуализацию — отключаем VMQ.
На Linux это делается через ethtool:
ethtool -K ixl0 tx offethtool --set-eee ixl0 eee off
На Windows — через свойства NIC в оснастке.
На FreeBSD/pfSense/OPNsense — через ifconfig или sysctl (зависит от версии драйвера).
Уровень 2. Среднесрочный (план на неделю)
Обновляем драйвер... Да, как это не очевидно! Во многих случаях проблема решается именно переходом на актуальную версию. Для pfSense/OPNsense — проверяем, не попали ли мы под коммит D40860. Если да — либо ждем патч, либо (для OPNsense) применяем реверт из GitHub.
Отключаем энергосбережение PCIe в BIOS/OS (переводим схему питания в High Performance).
Уровень 3. Радикальный (перманентное решение)
Обновляем firmware (NVM) карты. Это самое важное. Старые версии (4.00, 4.10) — проблемные. Актуальные (9.10+, 9.50+, а лучше 6.50+ для серии 700) содержат исправления многих багов.
Важное предупреждение: не качайте прошивку с сайта Intel, если карта стоит в сервере HPE, Dell, H3C, Lenovo. Берите только у того вендора, чей сервер вы используете. Intel‑прошивка может убить карту или сделать её неработоспособной в фирменном сервере. Это подтверждено на H3C и Dell.
После обновления — можно попробовать вернуть обратно LSO, Checksum Offload и другие функции. Но EEE лучше оставить выключенным навсегда.
Что в итоге: мораль для инженера
Intel X710 — это пример современного железа, которое стало слишком сложным для своего же блага. В погоне за offload‑функциями и виртуализацией инженеры Intel создали устройство, чье корректное поведение зависит от тонкого баланса версий прошивки, драйвера и даже операционной системы.
И главный урок здесь не в том, что «не надо покупать X710». Потому что купить другую карту часто невозможно (они встроены в серверы HPE, Dell, H3C по умолчанию). Урок в другом:
Когда ваша сетевая карта начинает вести себя странно, не смотрите сначала на L2-коммутаторы, на BGP, на маршрутизацию. Посмотрите на логи драйвера и выключите LSO.
Это не путь джедая. Это путь инженера, который пережил ночь с X710 и теперь знает, что «Disabled multicast promiscuous mode» в логах — это не диагностика, это приговор.
Проблемы вроде странного multicast, внезапных флаппов и «невидимых» сетевых отказов редко решаются одним чек‑листом. Но разобраться в сетевой базе, архитектуре ЦОД и подходах к инцидентам точно помогает. У OTUS есть несколько бесплатных открытых уроков по близким темам: можно познакомиться с преподавателями‑практиками, уточнить вопросы по инфраструктуре и посмотреть, как такие темы разбирают на курсах.
24 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
7 июля, 20:00. «Особенности балансировки трафика ЦОД, чтобы не случилось "все упало, все пропало"». Записаться
22 июля, 20:00. «VLAN на пальцах: изоляция трафика и маршрутизация». Записаться
Больше тем и дат можно найти в дайджесте открытых уроков.
Статье по теме
Если хочется продолжить разбор инфраструктурных проблем — от сетевых уровней до контейнеров и кластеров, можно посмотреть ещё несколько материалов:
«Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3» — базовый разбор того, как пакеты проходят через канальный и сетевой уровни.
«Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают» — о настройках, которые редко мешают локально, но быстро всплывают в продакшене.
«Kubernetes: архитектура и абстракции — полный гайд» — обзор ключевых сущностей Kubernetes и того, как они складываются в рабочую инфраструктуру.