Дублирование локальных маршрутов в FRR: последствия

Дублирование локальных маршрутов в FRR (v10.5) — это не просто визуальный мусор в выводе show ip route: оно может вызвать флуктуации RIB/FIB, усиленную нагрузку на zebra и ядро Linux, а в ряде случаев — потерю пакетов или асимметричную доставку трафика. В описанном баге FRR повторно добавляет локальные записи при изменении параметров интерфейса (например, MAC), из‑за чего появляются множественные L* и C* для одного префикса (см. баг‑репорт). Если такое состояние будет поддерживаться годами, вероятны хроническая деградация производительности, шум в мониторинге и риск неправильной рекламы маршрутов по протоколам.

Содержание

• Почему появляются дубликаты локальных маршрутов в FRR (v10.5)
• Какие проблемы и последствия вызывает дублирование локальных маршрутов в FRR
• Как дублирование проявляется в выводе show ip route и в ядре Linux
• Диагностика: команды и шаги для выявления причины
• Рекомендации: краткосрочные обходы и долгосрочные решения
• Практические сигнатуры мониторинга и автоматизация детектирования
• Источники
• Заключение

Почему появляются дубликаты локальных маршрутов в FRR (v10.5)

В приведённом примере и в баг‑репорте описан сценарий: при изменении параметров сетевого интерфейса (часто — MAC‑адреса) FRRouting заново регистрирует локальные маршруты для IP‑адресов интерфейса, не удаляя предыдущие записи. Иными словами, zebra/netlink‑обработка создаёт повторные записи L (local) и C (connected) для одного и того же префикса вместо корректной замены/обновления. Подробности и обсуждение см. в баг‑репорте на GitHub: https://github.com/FRRouting/frr/issues/20337.

Технически причина связана с тем, как FRR синхронизирует свою RIB с таблицами ядра через netlink: дублированные или неправильно обработанные уведомления приводят к «дубликатам» на уровне RIB/RIB‑печати.

Какие проблемы и последствия вызывает дублирование локальных маршрутов в FRR

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

• Повышенная загрузка контрольной плоскости и CPU zebra

• Частые повторные операции добавления/удаления маршрутов приводят к росту числа netlink‑событий. zebra обрабатывает больше сообщений, растёт загрузка CPU, особенно на узлах с большим количеством интерфейсов или адресов.

• Флуктуации RIB ↔ FIB и кратковременные разрывы трафика

• Дубликаты в RIB могут не синхронизироваться с FIB ожидаемо; в результате выбранный для форвардинга маршрут может периодически меняться — пакеты теряются или соединения сбрасываются.

• Чёрные дыры и некорректная реклама маршрутов

• Как в вашем примере, может появиться статический/blackhole маршрут (S unreachable) или неправильная интерпретация next‑hop при экспорте в OSPF/BGP (в выводе видно rmapsrc). Это приведёт к недоступности подсетей локально или у соседей.

• Асимметрия маршрутизации и потеря сессий

• Когда разные записи предлагают разные интерфейсы/next‑hop, пакеты могут уходить через один путь, а возвращаться — по другому, что ломает stateful‑сервисы (NAT, TCP).

• Насыщение netlink / потеря обновлений

• При большом количестве повторений netlink‑очереди могут переполняться; часть событий будет отброшена, что ухудшит согласованность между ядром и FRR.

• Увеличение объёма логов и ложные срабатывания мониторинга

• Автоматика (скрипты, средства мониторинга) начнёт генерировать оповещения на каждый «флэп» — оператор теряет сигнал среди шума.

• Возможное накопление внутренних структур или утечки памяти (в худшем случае)

• Если баг приводит к удержанию старых описателей маршрутов в памяти zebra, со временем может быть деградация памяти/ресурсов.

Заметьте: степень проявления зависит от интенсивности изменений интерфейсов и от количества таких префиксов в сети. Однократные дубликаты — не катастрофа; постоянные повторения — проблема.

Как дублирование проявляется в выводе show ip route и в ядре Linux

В выводе команды FRR вы увидите множественные строки с тем же префиксом, помеченные как L (local) и C (connected). Примерно так, как в вашем логе: несколько L * 192.168.5.1/32 и C * 192.168.5.1/32 с разными временными метками.

Что смотреть:

• Знаки и метки: L — local, C — connected; * обычно помечает FIB‑запись (маршрут, установленный в ядре); >* — выбранный маршрут. Легенда в вашем выводе поясняет это.
• Временные метки: разные timestamps показывают моменты создания/обновления записей — помогает понять частоту события.
• ip route show table local — покажет локальные маршруты в таблице ядра (table local). Сравните с vtysh -c "show ip route".

Практический контроль:

• Если в выводе FRR много одинаковых строк, но в ip route show table local ядра видна только одна «реальная» запись — значит проблема в RIB/отображении или в синхронизации; если и в ядре появляются дубли, тогда kernel‑уровень тоже засорён.

Диагностика: команды и шаги для выявления причины

Пошаговый подход — от быстрого обнаружения до корневого анализа.

1. Быстрая проверка дубликатов

vtysh -c "show ip route 192.168.5.1/32"
ip -4 route show table local | grep "192.168.5.1"

2. Наблюдение netlink / link‑событий в реальном времени

# следим за изменениями маршрутов/локальных записей
ip monitor route

# следим за изменениями link/MAC
ip monitor link

3. Просмотр логов FRR / zebra

journalctl -u frr -f
# или
tail -F /var/log/frr/zebra.log

4. Корреляция с изменениями интерфейса

ip -o link show dev test0
ip -4 addr show dev test0
dmesg | grep -i link

Сверьте времена из show ip route и моменты изменения MAC/интерфейса: совпадают ли они? Если да — это подтверждает сценарий из баг‑репорта: https://github.com/FRRouting/frr/issues/20337.

5. Глубже — мониторинг netlink‑пакетов (для опытных)

• Используйте strace/perf на процессе zebra, снимите логи netlink, соберите отладочные сообщения для разработчиков FRR, если нужно.

6. Проверка окружения

• Провайдер виртуализации/обёртки сети: миграции ВМ, hot‑plug, мультикаст‑агенты, cloud‑агенты могут менять MAC/интерфейс. Отключите/исследуйте такие процессы.

Рекомендации: краткосрочные обходы и долгосрочные решения

Краткосрочно (оперативно, пока ищете исправление):

• Вручную очистите ситуацию в контролируемое окно обслуживания:
• Перезапустите zebra или весь сервис FRR: systemctl restart frr (или соответствующий для вашей системы). Это снимет временные дубликаты, но приведёт к кратковременной потере маршрутизации — планируйте окно.
• При возможности и осторожно — удалить лишние записи в таблице ядра через ip route del ..., но это рискованно и требует точной проверки.
• Включите временное оповещение: скрипт, который считает вхождения префикса в vtysh -c "show ip route" и шлёт alert при >1.

Долгосрочно (устранение корня):

• Обновление/патч FRR: следите за обсуждением и фиксом в баг‑репорте и примените исправление в версии FRR, где баг закрыт. См. баг на GitHub: https://github.com/FRRouting/frr/issues/20337.
• Искоренение причины изменения интерфейса: устраните источники, которые меняют MAC/параметры (на уровне hypervisor, контейнерной платформы, cloud‑агентов). Стабильные интерфейсы — ключ.
• В тестовой среде прогоните нагрузочные сценарии: имитируйте смену MAC/перезапуски интерфейсов, посмотрите, как FRR ведёт себя после обновления.
• Автоматизация: скрипт‑монитор, который при повторном обнаружении дубликатов либо аккуратно рестартует только zebra, либо уведомляет инженера. Пример простого детектора:

#!/bin/bash
PREFIX="192.168.5.1/32"
CNT=$(vtysh -c "show ip route" | grep -c "$PREFIX")
if [ "$CNT" -gt 1 ]; then
 logger "FRR duplicate local routes for $PREFIX: $CNT"
 # действие: оповещение, либо (в крайнем случае) перезапуск zebra
fi

• Документируйте процедуру аварийного восстановления и интегрируйте её в runbook.

Важно: перед массовым применением любой автоматизации тщательно протестируйте, чтобы не внести дополнительных рисков.

Практические сигнатуры мониторинга и автоматизация детектирования

Что мониторить:

• Количество записей одного префикса в выводе show ip route (скрипт/экспортер).
• Частота появления netlink‑событий (пик = потенциальный флэп).
• Количество рестартов zebra/frr.
• Рост CPU zebra и общего использования памяти на узле.
• Появление blackhole/неожиданных статических маршрутов в таблице.

Пример идеи для Prometheus (через node textfile exporter):

• Скрипт считает дубликаты и пишет метрику frr_local_route_duplicates{prefix="192.168.5.1/32"} 2
• Правило алерта: если метрика > 1 более 5 минут → P1 alert.

Такой подход быстро выдаёт сигнал до того, как дубликаты вызовут серьёзные проблемы.

Источники

1. https://github.com/FRRouting/frr/issues/20337

Заключение

Дублирование локальных маршрутов в FRR (v10.5) — не просто косметическая проблема: при постоянном появлении дубликатов вероятны флуктуации RIB/FIB, рост нагрузки на zebra и ядро, потеря пакетов, асимметрия маршрутизации и шум в мониторинге. Первое — обнаружить и коррелировать события с изменениями интерфейсов (MAC), второе — либо временно очистить/перезапустить сервисы, либо (лучше) применить корректирующий патч/обновление FRR и устранить источник изменения интерфейсов. Наблюдайте за метриками, автоматизируйте детектирование и тестируйте исправления в лаборатории перед продом — так вы минимизируете риск длительной деградации сети.