Коротко — причина в том, что член порта (или сам агрегат) периодически «падает/поднимается», из‑за чего коммутатор каждый раз добавляет/убирает физический порт в/из Po10. Каждое такое изменение — событие в топологии, STP видит его и начинает пересчёт/TCN → кратковременная потеря связи / обновление MAC‑таблицы. Лог «Port te2/0/11 added to Po10» как раз это показывает.
Возможные конкретные причины и как проверить/устранить
1) LACP flapping (микроперерывы в LACP)
- Причины: несогласованные режимы LACP на сторонах (оба passive), несоответствие параметров (скорость, режим, allowed VLANs), раскрытие агрегата на сервере (bond) с неправильной конфигурацией, таймеры LACP (slow=30s/fast=1s).
- Как проверить: на свитче — show lacp / show etherchannel / show port-channel / посмотреть логи вокруг времени падения (порт удаляется/добавляется). На сервере — посмотреть конфиг bonding (или zVirt NIC team), логи драйвера, что он шлёт/получает LACPDU.
- Что сделать: привести режимы в соответствие (на одном конце active, на другом active или пассив по согласованию), установить lacp rate=fast на обеих сторонах при необходимости, привести скорость/duplex/MTU/allowed VLANs одинаковыми.
2) Агрегация на несколько шасси (MC‑LAG / MLAG) vs обычный LACP
- Если сервер крутит LACP на два физических коммутатора, а ваша модель кластера НЕ поддерживает multi‑chassis LAG, это создаёт петлю и STP будет блокировать порты/перевыбирать корень. В кластере Eltex надо понять, сделан ли именно распределённый LAG (MC‑LAG) или Po10 только на одном члене — неправильная топология/настройка даст флаппинг.
- Проверка: как физически разведены кабели? на какие шасси идут? show stack/cluster/virtual-chassis и show etherchannel суммарно.
- Решение: либо соберите LACP только к одному члену кластера, либо включите/настройте корректный MC‑LAG/virtual-chassis, либо используйте статическую агрегацию, поддерживаемую обеими сторонами.
3) Проблемы уровня физики / драйвера
- Плохой кабель/повреждённый SFP, ошибки порта → периодические падения интерфейса и повторное добавление в Po.
- Проверка: counters, CRC, errors, show interface te2/0/11 counters, посмотреть syslog на ошибки физических интерфейсов.
- Решение: заменить кабель, проверить трансиверы, снизить скорость если надо.
4) Баг в прошивке
- Eltex 6.6.10 может содержать баг на LACP/порт‑чэннелах. Поискать известные баги релиза и при возможности обновить прошивку.
- Проверка: release notes, поддержка Eltex.
5) STP/PortFast и политика
- Port‑channel к серверу обычно «краевой» порт — можно включить edge/portfast, чтобы уменьшить задержки перехода в forwarding при его поднятии. Но это не уберёт саму причину флаппинга; только ускорит восстановление.
- Важно: PortFast не предотвращает TCN при смене членства агрегата, но уменьшит время, когда порт застрянет в слушающем/обучающем состояниях.
Что нужно сбросно посмотреть и прислать (если хотите — помогу анализировать)
- Конфигурация интерфейса и Po10: show running-config interface te2/0/11, show run port-channel Po10
- Вывод по агрегатам: show etherchannel summary (или show lacp neighbor / show lacp)
- Логи вокруг события (несколько строк до и после)
- Конфиг серверного bonding/zVirt (какой режим, lacp_rate, интерфейсы, какие IP/VLAN)
- show spanning-tree brief / show spanning-tree detail для Po10
Рекомендованные шаги для быстрого устранения
1. На сервере проверить bonding: убедиться, что режим 802.3ad и lacp_rate=fast (если поддерживается). На свитче установить fast LACP, если есть опция.
2. Убедиться, что оба конца LACP в одном и том же режиме (обычно active/active).
3. Если каналы идут на два физических шасси — либо перенести оба кабеля на один член кластера, либо настроить MC‑LAG/stack правильно.
4. Проверить физику (кабели/SFP) и статистику ошибок.
5. При подозрении на баг — обновить прошивку и/или обратиться в поддержку Eltex.
Если пришлёте конфигурации Po10, выводы show lacp и логи вокруг времени падения — разберу конкретнее и укажу точное место проблемы и настройки.