Лишние NIC сыплют NIC_DOWN

Симптом

• Пачка ERROR NIC_DOWN по нескольким портам (enp…/eth…), события висят LIVE.
• В GUI интерфейсов больше, чем портов: на 8 портов — 16 записей (дубли eth* и enp*).
• Рядом NIC_NOT_FOUND по портам NOTMANAGED/NOTFOUND и NOLINK по порту без кабеля.
• На S3 и модель событие не влияет, но шумит в мониторинге и маскирует настоящий отказ порта.

Что проверить первым (read-only)

1. Линк по портам: bash ip -br link show Ожидается UP у портов с кабелем и DOWN без LOWER_UP у неподключённых.

2. Линк и скорость по спорному порту: bash ethtool <IF> | grep -E 'Speed|Link detected' Ожидается Link detected: no — кабеля нет, порт не сломан.

3. Что в модели: bash sudo curl -sk --cert <CERT> --key <KEY> \ https://127.0.0.1:8443/model/machine/<MGUID>/nic/ \ | jq '.nic[] | {device,status,macaddress}' Ожидается DOWN/NOTFOUND у лишних, UP/BONDED у рабочих.

4. Кто эмитит событие: bash grep -i 'network_interfaces_status' /opt/ampli/var/log/mona/mona.log | tail -10 Ожидается запись чекера по этому порту: событие модельное, не от драйвера.

5. Нет ли настоящего отказа: порт с кабелем, который DOWN, — уже не «лишний NIC»; дальше идти по статье про storage-кольцо.

6. Сверка с проектом подключения. По схеме площадки выписать порты, которые должны быть заняты, и сравнить с выводом ip -br link. Ожидается: занятые порты совпадают с проектом один к одному, остальные — кандидаты в NOTMANAGED. Такая сверка заодно ловит ошибку «кабель в чужом порту», которая иначе всплывёт позже как разрыв кольца.

Причина

1. Чекер считает DOWN отказом

Чекер network_interfaces_status.py проверяет только {UP, DOWN, BONDED} и репортит любое из них. Порт без линка штатно в DOWN и попадает в ту же корзину, что реально упавший.

2. Модель знает больше портов, чем подключено

Инвентарь перечисляет все порты платформы, включая неподключённые. Плюс ошибка установки: профиль описывает eth0..eth7, а ОС называет порты enp… — в модели обе записи. Отсюда «16 NIC на 8 портов». Скан при этом не «лишние» записи не удаляет: он только добавляет и обновляет, поэтому разбирать список нужно вручную, а не ждать, что инвентаризация сама всё приведёт в порядок.

3. NIC_NOT_FOUND и NOLINK — та же семья

Рядом с NIC_DOWN обычно идут NIC_NOT_FOUND (порт есть в модели, но не сопоставлен с железом или помечен NOTFOUND) и NOLINK (порт без линка). Все три — про отсутствие кабеля или про расхождение инвентаря, а не про отказ адаптера. Хронический характер таких событий (месяцами по одним и тем же MAC) — признак именно этой семьи, а не «плавающего» железа. Разбирать их нужно вместе: пока в модели остаются записи о неподключённых портах, чекер будет находить их каждым циклом.

4. Почему нельзя «выключить порт»

Действие nic down на пустом порту падает: load_settings() требует хотя бы одну сетевую секцию → ValueError: Insufficient settings to configure interface. Остаётся смена статуса в модели.

5. Почему NOTMANAGED — штатный путь

NOTMANAGED — допустимое состояние NIC в модели; для сканера оно в NO_UPDATE_STATES (NOTMANAGED, DECOMMISSIONED, DISABLED) и не перезаписывается. Чекер пропускает все статусы, кроме {UP, DOWN, BONDED}; при пустом списке правило само снимает событие. Закрытие — на следующем цикле монитора (в наших условиях 600 с).

Решение (штатное)

1. Определить лишние порты пунктами 1–3: нет кабеля, нет линка, статус DOWN/NOTFOUND.
2. Перевести в NOTMANAGED по одному, с проверкой ответа: bash sudo curl -sk --cert <CERT> --key <KEY> -X PUT \ -H 'Content-Type: application/json' -d '{"status": "NOTMANAGED"}' \ https://127.0.0.1:8443/model/machine/<MGUID>/nic/<NGUID>/ Ожидается 200; без Content-Type: application/json тот же PUT даёт 400.
3. Проверить, что сканер не вернул статус после ближайшей инвентаризации — повторный GET по NIC показывает NOTMANAGED.
4. Дождаться цикла чекера: LIVE NIC_DOWN по этим портам исчезает (наблюдали 8 → 4 → 0).
5. Не трогать порты с кабелем — их статус менять нельзя, иначе порт выпадет из проверки.

Если штатный путь недоступен

Временная мера, не штатно. Если правка модели недоступна (нет доступа к Model API), допустимо закрыть событие действием ignore с записью в журнал. Событие вернётся на следующем цикле — это не устранение, а пауза до получения доступа.

Проверка

• ip -br link и ethtool подтверждают отсутствие линка на этих портах.
• GET /model/machine/<MGUID>/nic/ → NOTMANAGED у лишних, UP/BONDED у рабочих.
• LIVE NIC_DOWN по этим портам — 0; новых нет за цикл (600 с).
• Порты с кабелем остаются в проверке и не показывают DOWN.
• Повторный GET NIC через час: статусы лишних портов всё ещё NOTMANAGED, инвентаризация их не вернула в DOWN. Если вернула — проверить, что правка пришлась на документ NIC, а не на копию.

Профилактика

• До установки переписать профиль машины на реальные имена enp* или убрать NIC из профиля — скан создаст их сам.
• После установки провести чистку лишних записей (в нашем образе — пост-установочный скрипт чистки FAN/NIC через Model API).
• Не оставлять в модели порты без кабеля в статусе DOWN: сразу NOTMANAGED.
• Сверять список интерфейсов модели с проектом подключения при приёмке.

Источники и дата

• Software Documentation Center (доступ 2026-11-07).
• Наша практика (обезличено): 6 портов без линка переведены в NOTMANAGED на 3-нодном кластере; LIVE NIC_DOWN закрылись в течение цикла (8 → 4 → 0).
• Обновлено: 2026-11-07.