Активно-резервный bond Linux на all-active EVPN: что ломается

Поставьте активно-резервный bond на сервер, а сегмент all-active Ethernet — на фабрику, и половина обратного трафика может исчезнуть, не сдвинув ни один счётчик ошибок. Ни одна из конфигураций сама по себе не ошибочна. Проблема в передаче между ними: одна сторона выбирает один порт, а другая предполагает, что каждый подключённый лист умеет доставлять. Проследите один кадр в каждом направлении, и несоответствие станет очевидным.

Что активно-резервный режим делает с входящим кадром

Режим bonding 1 держит ровно один slave в пути передачи и меняет его только при отказе текущего. Эта часть хорошо известна. Здесь важно приёмное поведение: ядро отдаёт кадр стеку, только если он пришёл на активный slave, а кадры, появившиеся на любом другом slave, отбрасывает. Эта all_slaves_active настройка существует именно для смягчения этого правила, и по умолчанию она выключена. ip -d link show bond0 печатает текущее значение рядом с режимом.

/proc/net/bonding/bond0 называет активный slave и сообщает состояние связи для каждого slave. Этот файл — единственный честный источник того, какой порт сейчас несёт трафик.

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

Что all-active multihoming делает с удалённым следующим хопом

EVPN multihoming описывает набор листов, разделяющих один сегмент Ethernet, идентифицируемый через ESI, и анонсирует этот сегмент остальной фабрике. В модели all-active удалённые peer устанавливают более одного следующего хопа для адресов сегмента. Unicast к серверу тогда может прийти на любой лист, и фабрика свободна выбирать по потоку. В этом весь смысл дизайна, и это же то допущение, которому должен соответствовать bond сервера.

Затопленный трафик подчиняется другому правилу. Листы выбирают назначенный forwarder на сегмент, поэтому broadcast, неизвестный unicast и multicast обычно входят через один из них. Так unicast и затопление принимают два отдельных решения, и только одно из них видно в состоянии bond хоста.

Где два выбора расходятся

Ядро выбирает активный slave по состоянию связи и собственной политике. Фабрика выбирает следующие хопы по маршрутам EVPN, а назначенный forwarder — по выборам среди листов. Ни один процесс не советуется с другим. Когда они выбирают разные листы, отказ зависит от направления: то, что сервер отправляет, выходит нормально, а ответы исчезают.

Есть два поддерживаемых выхода, и они не взаимозаменяемы. Дайте хосту bond, который фабрика может рассматривать как одно логическое подключение, что на практике означает bond LACP, согласованный с листами, и оба звена действительно активны вместе. Либо примите и доставку single-active от фабрики, чтобы сегмент следовал той же модели «один порт за раз», что и bond. Что не работает — сегмент all-active перед bond, который слушает только один порт, если только вы намеренно не включите приём на неактивных slave и не примете следующую за этим двойную доставку.

Почему резервный кабель продолжает выглядеть здоровым

Кабель, не несущий трафика, всё равно сообщает о поднятой связи, а резервный slave в bond создан выглядеть готовым. Операторы читают это как резервирование и перестают задавать вопросы.

Спросите вместо этого, какой физический порт использовал обратный кадр. На хосте считайте принятые пакеты по slave, а не по bond, потому что счётчик bond скрывает асимметрию. На листе посмотрите на записи продвижения моста для MAC сервера и на набор следующих хопов, который несёт маршрут EVPN. Если запись указывает на лист, чья связь с хостом резервная, дизайн доставляет в порт, который хост игнорирует. Это несоответствие конфигурации, а не аппаратная неисправность, и никакой мониторинг состояния связи этого не выявит.

Тестируйте доставку в обе стороны, а не состояние связи

Постройте матрицу с одной строкой на отказ и одним столбцом на направление, а затем заполняйте её доставленным трафиком, а не состоянием интерфейса. Строка один — нормальная работа, и именно там прячется несоответствие, потому что симптом выглядит как проблема приложения.

Затем уберите активное звено хоста, уберите один лист, уберите uplink этого листа и восстановите каждое по очереди. После каждого шага записывайте активный slave, состояние сегмента EVPN, удалённую запись продвижения и наблюдаемую пропускную способность в обоих направлениях. Лист, теряющий путь к фабрике, пока его звено хоста остаётся поднятым, — интересный случай, потому что подключение остаётся анонсированным и может тихо стать тупиком. Тестируйте свежими unicast-потоками и затопленным трафиком, от которого зависит приложение, потому что они используют разные решения о продвижении.

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