Диагностика и мониторинг динамической маршрутизации: практические инструменты от CLI до Grafana

Сбой динамической маршрутизации может парализовать работу сети за считанные секунды. В ноябре 2024 года мелкий BGP-инцидент в Рунете привел к массовым проблемам с доступностью, наглядно показав, насколько критично умение быстро диагностировать и контролировать протоколы OSPF и BGP. Это руководство предоставляет полный арсенал инструментов для системных администраторов и DevOps инженеров: от набора CLI команд для экстренной проверки состояния соседства до развертывания полноценной системы proactive мониторинга на основе Prometheus и Grafana для FRRouting. Вы научитесь интерпретировать вывод команд, анализировать логи протоколов и выявлять корневые причины инцидентов, сократив время простоя сети.

От инцидента к диагнозу: как быстро локализовать проблему в маршрутизации

Когда сеть «падает», первая задача - быстро оценить масштаб и локализовать проблему. Диагностику нужно начинать с простых проверок, постепенно углубляясь. При любых манипуляциях в рабочей среде соблюдайте осторожность: некорректные изменения конфигурации могут усугубить ситуацию. Используйте этот checklist для первых минут после инцидента: проверьте доступность соседних узлов, состояние протоколов маршрутизации и таблицы маршрутов.

Первичный осмотр: базовые CLI команды для проверки состояния соседства

Первым делом подключитесь к маршрутизатору и проверьте состояние протоколов. Для FRRouting, который часто используется в Linux-средах, основные команды выполняются в оболочке vtysh.

Команды для проверки OSPF:

vtysh
show ip ospf neighbor
show ip ospf database
show ip route ospf

Ключевой вывод команды show ip ospf neighbor - столбец State. Статус Full указывает на успешное установление соседства. Состояния Down, Init или 2-Way сигнализируют о проблемах на канальном уровне, с таймерами или аутентификацией.

Команды для проверки BGP:

vtysh
show ip bgp summary
show ip bgp neighbors [IP-адрес] advertised-routes
show ip route bgp

В выводе show ip bgp summary обратите внимание на столбец State. Статус Established означает рабочее соседство. Число в столбце PfxsRcd показывает количество полученных префиксов. Резкое изменение этого числа или статус Active, Idle указывают на проблему.

Общая проверка таблицы маршрутизации выполняется командой show ip route или через native Linux ip route show. Убедитесь, что ожидаемые сети присутствуют и имеют правильный шлюз.

Пример проблемного вывода OSPF:

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.1      1   Init/DROTHER    00:00:35    10.0.1.2        eth0

Состояние Init означает, что маршрутизатор получил Hello-пакет от соседа, но не увидел собственный ID в списке соседей в ответном пакете. Частая причина - несовпадение параметров интерфейса, таких как MTU или маска подсети.

Анализ логов протоколов: поиск корневой причины сбоя

Если CLI команды показали проблему, следующий шаг - анализ логов. Логи протоколов содержат детальную последовательность событий, которая приводит к сбою.

В FRRouting логи маршрутизации обычно направляются в syslog. Убедитесь, что в конфигурации включено логирование для нужных демонов (ospfd, bgpd). В файле /etc/frr/daemons проверьте, что для демонов не установлен параметр -s (отключение syslog). Детализацию можно увеличить, настроив уровень логирования в vtysh:

vtysh
configure terminal
log syslog informational
end

Типичные сообщения об ошибках и их значение:

Bad MD5 digest или Authentication failed: Ошибка аутентификации между соседями. Проверьте совпадение паролей и типа аутентификации (MD5, SHA).
%OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on eth0 from FULL to DOWN: Соседство разорвано. Причина может быть в потере линка, сбое на удаленной стороне или таймерах.
%BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down (Peer closed the session): BGP сессия закрыта пиром. Анализируйте логи на удаленном узле и проверьте доступность по TCP порту 179.
Prefix withdrawn в логах BGP: Удаленный пир отозвал анонс префикса. Это может быть плановым изменением или признаком нестабильности.

Кейс анализа: Предположим, соседство OSPF постоянно «мигает» (переходит из Full в Down и обратно). В логах видна последовательность: установление соседства, затем сообщение OSPF: Send hello to 224.0.0.5 on eth0 failed. Это указывает на проблему на канальном уровне - возможно, перегрузка интерфейса, физические проблемы с кабелем или некорректный MTU, приводящий к фрагментации и потере пакетов. Подобный анализ логов помогает быстро перейти от симптома к причине.

Для комплексного анализа логов с разных узлов можно использовать централизованные системы, такие как ELK Stack или Grafana Loki. Наш практический гайд по анализу логов содержит готовые команды grep и awk для быстрого поиска паттернов сбоев.

Системный мониторинг: предотвращение инцидентов с Prometheus и Grafana

Ручные проверки - это реактивный подход. Проактивный контроль состояния сети требует системы мониторинга, которая круглосуточно отслеживает ключевые метрики. Принцип, аналогичный работе NetBlocks, использующей глобальную сеть зондов для мониторинга доступности, можно применить внутри инфраструктуры. Архитектура решения проста: FRRouting экспортирует метрики, Prometheus их собирает и хранит, а Grafana визуализирует данные на информативных дашбордах.

Настройка экспорта метрик из FRRouting

Начиная с версии 8.x, FRRouting включает встроенный Prometheus exporter. Для его активации выполните конфигурацию в vtysh:

vtysh
configure terminal
frr defaults prometheus-exporter
service prometheus-exporter port 9348
end
write memory

Эта команда включает экспортер по умолчанию и задает порт 9348. Для более детальной настройки можно указать, какие демоны экспортировать:

vtysh
configure terminal
prometheus-exporter ospfd
prometheus-exporter bgpd
end

После применения конфигурации проверьте доступность метрик:

curl http://<IP_маршрутизатора>:9348/metrics

В ответе вы увидите список метрик, например:

frr_ospf_neighbor_state{area="0.0.0.0",interface="eth0",neighbor_id="192.168.1.1"} (значение 1 = Full, 0 = Down).
frr_bgp_peer_state{afi="ipv4",peer="10.0.0.2",safi="unicast",vrf="default"} (значение 6 = Established).
frr_bgp_prefixes_received_count{peer="10.0.0.2"} - счетчик полученных префиксов.

Для версий FRRouting 7.x встроенного экспортера может не быть. В этом случае используйте внешние инструменты, например, frr_exporter от сообщества, который парсит вывод CLI команд.

Развертывание стека мониторинга: Docker Compose для быстрого старта

Для быстрого развертывания тестового или демонстрационного стенда используйте Docker Compose. Этот подход минимизирует время настройки и снижает риск ошибок из-за различий в окружениях.

Создайте файл docker-compose.yml со следующим содержимым:

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    ports:
      - "9090:9090"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

Затем создайте конфигурационный файл Prometheus prometheus.yml для сбора метрик с FRRouting:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'frr'
    static_configs:
      - targets: ['<IP_вашего_FRR_маршрутизатора>:9348']
        labels:
          role: 'edge-router'
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Запустите стек командой docker-compose up -d. Prometheus будет доступен на порту 9090, Grafana - на порту 3000. Важно: данная конфигурация предназначена для тестовых целей. В production среде необходимо настроить аутентификацию, TLS и обеспечить отказоустойчивость. Подробнее о построении отказоустойчивых систем мониторинга читайте в нашем руководстве по наблюдаемости для высоконагруженных систем.

Создание полезных дашбордов в Grafana для OSPF и BGP

После настройки источников данных в Grafana создайте дашборд для визуализации состояния маршрутизации.

1. Панель состояния соседства OSPF: Используйте запрос frr_ospf_neighbor_state и тип визуализации «Stat». Настройте цветовые пороги (Thresholds): green = 1 (Full), red = 0 (Down). Это дает мгновенную визуальную индикацию здоровья всех OSPF-сессий.

2. График количества BGP префиксов: Используйте метрику frr_bgp_prefixes_received_count с визуализацией «Time series». Резкие падения графика до нуля указывают на потерю BGP-сессии, а постепенные изменения могут говорить об изменениях в маршрутной политике у провайдера.

3. Карта состояния BGP пиров: Создайте таблицу (визуализация «Table») с запросом, отображающим метки peer и текущее значение состояния frr_bgp_peer_state. Добавьте преобразование полей (Transform) для маппинга числовых значений (например, 6) на текстовые («Established»).

4. Настройка алертов: В Grafana создайте правило оповещения для метрики frr_ospf_neighbor_state. Условие: WHEN last() OF query(A, 1m, now) IS BELOW 1. Это создаст алерт, если соседство OSPF перейдет в состояние, отличное от Full (значение 1), и продлится более 1 минуты. Оповещения можно настроить на отправку в Telegram, Slack или email. Базовую настройку алертинга можно выполнить по инструкции из статьи «Стек мониторинга серверов: настройка Prometheus, Grafana и оповещений в 2026 году».

Чек-лист и методология: структурированный подход к отладке

Систематизация процесса диагностики минимизирует хаотичные действия и снижает риск ошибок. Используйте этот последовательный чек-лист при возникновении проблем с маршрутизацией.

Проверка базового состояния (CLI):
- Проверьте физическую и канальную связность (ping, ip link show).
- Выполните команды проверки соседства OSPF/BGP (show ip ospf neighbor, show ip bgp summary).
- Убедитесь в наличии ожидаемых маршрутов в таблице (show ip route или ip route show).
Анализ логов:
- Изучите логи демонов маршрутизации (journalctl -u frr или /var/log/syslog).
- Ищите сообщения об ошибках аутентификации, изменении состояния соседства, отзыве префиксов.
- Сопоставьте временные метки в логах с моментом возникновения проблемы.
Реклама
Проверка конфигурации и окружения:
- Сравните конфигурации на обоих концах сессии (таймеры hello/dead, MTU, параметры аутентификации).
- Для BGP проверьте политики фильтрации (prefix-list, route-map) и параметры анонсов.
- Проверьте загрузку CPU и память на маршрутизаторах, наличие сетевых потерь.
Использование данных мониторинга (если система развернута):
- Проанализируйте исторические графики в Grafana: когда именно упало соседство или изменилось количество префиксов?
- Проверьте, совпадает ли это время с другими событиями (релизы, изменения конфигурации, пики нагрузки).

Типовые корневые причины и их симптомы:

Ошибки аутентификации: Соседство не устанавливается (OSPF/BGP), в логах - сообщения Bad MD5 digest.
Проблемы с линками/MTU: Соседство «мигает», в логах - ошибки отправки пакетов.
Некорректные анонсы/фильтрация: BGP сессия Established, но часть префиксов отсутствует в таблице маршрутизации.
Перегрузка ресурсов: Высокая загрузка CPU на маршрутизаторе, тайм-ауты в протоколах.

Адаптация под вашу среду: версии FRRouting и масштабы сети

Представленные методы универсальны, но их реализация зависит от версии ПО и масштаба инфраструктуры.

Различия в версиях FRRouting:

Компонент / Настройка	FRRouting 8.x и новее	FRRouting 7.x и старше
Prometheus exporter	Встроенный, настраивается в `vtysh`	Отсутствует. Требуется внешний `frr_exporter`.
CLI команды (BGP)	`show bgp ipv4 summary`	`show ip bgp summary` (может отличаться)
Конфигурация логирования	`log syslog [уровень]`	Часто настраивается через параметры демона в `/etc/frr/daemons`

Выбор инструментов в зависимости от масштаба:

CLI диагностика подходит для всех: от энтузиастов с домашней сетью до администраторов крупных B2B-инфраструктур для первоначальной «скорой помощи».
Система мониторинга на Prometheus/Grafana целесообразна для средних и крупных сетей, где критично предотвращать инциденты, а также для proactive контроля состояния. Для небольших сетей можно использовать упрощенный подход, например, скрипты, периодически выполняющие CLI команды и отправляющие алерты. Наш гайд по системам мониторинга производительности поможет выбрать подходящий стек.

Для масштабирования мониторинга крупной B2B-инфраструктуры рассмотрите:

Развертывание Prometheus в режиме высокой доступности (HA).
Использование service discovery (например, Consul) для автоматического добавления новых маршрутизаторов в мониторинг.
Внедрение единого дашборда Grafana с фильтрацией по дата-центрам или ролям устройств.

Итоговый выбор методов диагностики и мониторинга зависит от ваших задач, доступных ресурсов и требуемого уровня контроля. Начните с базовых CLI команд и анализа логов, затем внедряйте автоматизированный мониторинг для ключевых сегментов сети, чтобы перейти от реакции на сбои к их предотвращению.