Как проверить нарушения или проблемы со статическими маршрутами?

«Как проверить нарушения или проблемы со статическими маршрутами?» — вопрос из категории Сети, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Проблемы со статическими маршрутами обычно возникают из-за конфликтов, неправильных метрик или изменений в сети. Вот мой алгоритм диагностики.

1. Проверка актуальной таблицы маршрутизации:

# Показать все маршруты, включая статические
ip route show
# Или для конкретной таблицы, если используется policy-based routing
ip route show table <table_name_or_id>

# Проверить, какой маршрут будет использован для целевого IP
ip route get <destination_ip>
# Пример: ip route get 10.10.20.5

Если ip route get показывает не тот интерфейс или шлюз, который вы ожидаете, — есть проблема.

2. Поиск конфликтов и дубликатов:

# Ищем дублирующиеся или перекрывающиеся маршруты (например, два маршрута до одной сети)
ip route show | grep "<target_network>"

# Проверяем, не переопределён ли маршрут более специфичным (с большей маской, например /32)
ip route show | grep -E "/32|/128"

3. Диагностика доступности следующего прыжка (шлюза):

# Проверяем, доступен ли шлюз, указанный в статическом маршруте
ping <gateway_ip_from_route>
arp -n <gateway_ip_from_route>  # Проверка ARP-записи

# Трассировка до целевой сети, чтобы увидеть весь путь
traceroute -n <destination_ip_in_target_network>
mtr -n <destination_ip_in_target_network>  # Более продвинутая утилита

4. Проверка влияния динамической маршрутизации (если используется):

# Если на сервере запущен демон динамической маршрутизации (Bird, FRR, Quagga)
systemctl status bird  # или frr, zebra

# Просмотр протокольных маршрутов (например, BGP)
vtysh -c "show ip bgp"  # для FRR
birdc show route        # для Bird

Динамические протоколы (OSPF, BGP) могут переопределять статические маршруты с другими метриками.

5. Распространённые причины проблем:

  • Неправильная метрика (metric): Маршрут с меньшей метрикой имеет приоритет. Нужно сравнить ip route show.
  • Отсутствие шлюза в ARP: Шлюз недоступен в локальном сегменте L2.
  • Конфликт с маршрутом по умолчанию (default via).
  • Проблемы с политиками маршрутизации (ip rule). Проверить: ip rule list.
  • Аплинк (основной интерфейс) down. Проверить: ip link show.

Решение: После нахождения конфликта нужно отредактировать статический маршрут, задав правильную метрику или исправив шлюз, и применить изменения (ip route add/change/replace).