Плавающий статический маршрут (floating static route) держит резервный канал описанным в конфигурации, но в таблицу пересылки не попадает, пока работает основной путь. Управляет этим формальный параметр: маршрутизатор Cisco сравнивает административную дистанцию (administrative distance, AD), ядро Linux сравнивает метрику маршрута. Меньшее значение выигрывает, поэтому резерв получает заведомо большее число и активируется только тогда, когда основной маршрут исчезает из таблицы.
Для филиала с двумя провайдерами схема укладывается в две-три строки конфигурации плюс, при необходимости, отслеживание доступности канала через IP SLA и track. Дальше: значения AD, примеры для Cisco IOS и Linux, сохранение настроек после перезагрузки, ограничения метода и признаки того, что пора включать OSPF, EIGRP или BGP.
Что такое плавающий статический маршрут и как он работает
В таблице маршрутизации для каждого префикса обычно остаётся один лучший путь, если не настроена балансировка равных маршрутов. Плавающий статический маршрут использует это правило: администратор описывает два маршрута к одной и той же сети, у одного приоритет минимальный, у второго завышенный. Пока первый путь валиден, второй не устанавливается вообще.
Событие переключения - потеря основного маршрута. На Cisco это происходит, когда интерфейс переходит в состояние down или когда срабатывает объект track. В Linux ядро убирает маршрут, когда интерфейс, через который он ведёт, теряет линк. После этого резервный маршрут встаёт в таблицу, и трафик уходит через второй канал без команд от администратора.
Аналогия простая: запасная дверь в цеху, открытая постоянно, но используемая только когда основная заблокирована.
Ограничение видно сразу. Без отслеживания доступности переключение сработает только при падении линка. Если провайдер перестал пропускать трафик, а интерфейс остался в состоянии up, статика ничего не заметит: маршрут по-прежнему валиден, и пакеты уходят в никуда. Для этого случая нужен track на Cisco или внешний мониторинг маршрута в Linux.
Административная дистанция: ключевой параметр выбора маршрута
Административная дистанция показывает, насколько маршрутизатор доверяет источнику маршрута. Диапазон значений 0-255, меньшее число означает большее доверие. Cisco применяет фиксированные значения по умолчанию:
| Источник маршрута | AD по умолчанию |
|---|---|
| Connected | 0 |
| Статический маршрут | 1 |
| eBGP | 20 |
| EIGRP (внутренний) | 90 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| iBGP | 200 |
Административную дистанцию статического маршрута задают вручную: число указывают после адреса следующего узла. Команда ip route 0.0.0.0 0.0.0.0 192.168.1.1 ставит маршрут с AD 1, а ip route 0.0.0.0 0.0.0.0 192.168.2.1 2 создаёт тот же маршрут с AD 2, который останется неактивным, пока жив первый.
Значение резерва выбирают по ситуации. Для двух локальных каналов хватает 2-5. Если статика подстраховывает маршрут, выученный по OSPF (AD 110), резервной статике ставят 250: при живом OSPF она в таблицу не попадёт, а при потере протокольного маршрута займёт его место. Обратная ошибка - оставить у резервной статики AD 1 и перекрыть динамическую маршрутизацию полностью.
Как таблица маршрутизации выбирает путь между префиксами разной длины и какие команды показывают итоговое решение, разобрано в материале про принципы IP-маршрутизации, таблицы, метрики и алгоритм Longest Prefix Match.
Метрика маршрута в Linux
В Linux нет административной дистанции. Ту же роль выполняет метрика маршрута: при нескольких маршрутах к одному префиксу ядро выбирает запись с наименьшей metric. Маршрут, добавленный без явной метрики, получает 0, поэтому команда ip route add default без дополнительных параметров способна перебить настроенные резервы.
Практика для двух шлюзов: основной default через 192.168.1.1 с metric 100, резервный через 192.168.2.1 с metric 200. При совпадении метрик у двух default-маршрутов ядро может раскладывать потоки по обоим шлюзам (multipath), и это уже балансировка, а не резервирование.
Второй момент, который часто упускают: метрика не проверяет доступность шлюза. Ядро реагирует на события интерфейса, а не на пропажу ответов от провайдера.
Настройка плавающих статических маршрутов на Cisco
Типовой филиал: два провайдера, роутер Cisco IOS, два физических интерфейса. Адресация взята из диапазонов для документации RFC 5737.
| Интерфейс | IP-адрес | Шлюз провайдера | Роль |
|---|---|---|---|
| GigabitEthernet0/0/0 | 192.168.1.2/30 | 192.168.1.1 | основной канал |
| GigabitEthernet0/0/1 | 192.168.2.2/30 | 192.168.2.1 | резервный канал |
Пример конфигурации с двумя провайдерами
interface GigabitEthernet0/0/0
ip address 192.168.1.2 255.255.255.252
no shutdown
interface GigabitEthernet0/0/1
ip address 192.168.2.2 255.255.255.252
no shutdown
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.2.1 2
Проверка: show ip route 0.0.0.0 покажет активный маршрут в виде S* 0.0.0.0/0 [1/0] via 192.168.1.1. Резервного в выводе не будет: он появится там только после активации, а до этого хранится в running-config. Полезно сразу посмотреть show ip route static и убедиться, что основной маршрут один.
Если убрать двойку из второй команды, оба маршрута получат AD 1, оба встанут в таблицу, и Cisco начнёт распределять трафик по двум провайдерам по назначению (per-destination load balancing). Резервирование в таком виде не работает: при падении одного канала часть сессий оборвётся.
Для резерва поверх динамического протокола дистанцию ставят выше протокольной. Пример для OSPF: ip route 0.0.0.0 0.0.0.0 192.168.2.1 250. Маршрут держится в конфигурации, но в таблицу попадёт только если OSPF перестанет предлагать свой default.
Тот же приём работает для WAN между площадками. Если подняты два GRE или IPSec-туннеля, маршрут до сети удалённого филиала прописывают через интерфейс туннеля A с AD 1 и через туннель B с AD 2, а на доступность удалённого конца ставят track. Так резервируется канал между офисами без динамической маршрутизации.
Использование track для мониторинга доступности
Track привязывает маршрут к результату проверки. IP SLA отправляет пробы на удалённый адрес, объект track следит за результатом, а маршрут получает ссылку на этот объект.
ip sla 1
icmp-echo 203.0.113.5 source-interface GigabitEthernet0/0/0
frequency 5
timeout 1000
threshold 2000
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
track 1 delay down 10 up 30
ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 1
ip route 0.0.0.0 0.0.0.0 192.168.2.1 2
Логика: пока пробы проходят, track 1 в состоянии Up, основной маршрут стоит в таблице. Если пробы перестают проходить, объект переходит в Down, маршрут снимается, и активируется резервный с AD 2. Параметры delay down 10 up 30 гасят флаппинг: маршрут не дёргается на коротких сбоях, а возврат к основному каналу происходит через 30 секунд после стабилизации.
Цель для проб выбирают так, чтобы она была достижима только через проверяемый канал: адрес в сети провайдера или стабильный узел за ним. Если цель отвечает и по другому маршруту, проверка не заметит аварию. ICMP проходит не всегда (фильтры, ограничение частоты на стороне провайдера), тогда IP SLA настраивают на tcp-connect к порту 443 или на http-запрос. Отследить только линк можно командой track 1 interface GigabitEthernet0/0/0 line-protocol, но такая проверка не увидит аварию за пределами первого участка.
Настройка резервных маршрутов в Linux
Сценарий: сервер с двумя сетевыми интерфейсами, eth0 смотрит в основной канал (192.168.1.2/24, шлюз 192.168.1.1), eth1 в резервный (192.168.2.2/24, шлюз 192.168.2.1).
Пример с ip route
ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 192.168.2.1 dev eth1 metric 200
Проверка и удаление:
ip route show default
ip route get 8.8.8.8
ip route del default via 192.168.2.1 dev eth1 metric 200
Вывод ip route show default покажет обе записи с их метриками, а ip route get 8.8.8.8 назовёт выбранный шлюз и укажет интерфейс, через который пойдёт пакет. Когда линк eth0 падает, ядро удаляет маршруты через этот интерфейс, и трафик автоматически идёт через 192.168.2.1. Если канал деградировал без потери линка, переключения не будет: нужен внешний мониторинг, например keepalived со скриптом проверки или скрипт, переставляющий маршруты командой ip route replace.
Расширенные сценарии, включая policy routing и диагностику, собраны в руководстве по настройке маршрутизации в Linux: ip route, netplan и systemd-networkd.
Сохранение настроек через netplan
Команды ip route живут до перезагрузки, поэтому постоянную конфигурацию описывают в netplan (Ubuntu), NetworkManager (RHEL, Fedora, Debian с NM) или systemd-networkd. Пример netplan для двух default-маршрутов:
network:
version: 2
ethernets:
eth0:
dhcp4: false
addresses: [192.168.1.2/24]
routes:
- to: default
via: 192.168.1.1
metric: 100
eth1:
dhcp4: false
addresses: [192.168.2.2/24]
routes:
- to: default
via: 192.168.2.1
metric: 200
В актуальных версиях netplan запись to: default заменяет прежнюю to: 0.0.0.0/0, хотя второй вариант тоже принимается. Конфигурацию применяют командой netplan apply, а для безопасной проверки на удалённом хосте - netplan try с автоматическим откатом по таймауту, если соединение потеряно.
В NetworkManager метрика default-маршрута задаётся командой nmcli connection modify "Profile1" ipv4.route-metric 100, а дополнительный маршрут добавляют так: nmcli connection modify "Profile2" +ipv4.routes "0.0.0.0/0 192.168.2.1 200", где третий параметр в строке - метрика. В systemd-networkd маршрут описывают в секции [Route] с параметрами Destination=0.0.0.0/0, Gateway= и Metric=; для маршрутов, полученных по DHCP, метрику задаёт параметр RouteMetric= в секции [DHCPv4].
Ограничения плавающих статических маршрутов
- Реакция только на локальные события. Без track или внешнего мониторинга переключение происходит при падении интерфейса, а не при аварии у провайдера.
- Один активный путь. Балансировки нет: работает либо основной канал, либо резервный, а полоса резерва простаивает.
- Нет данных о сети за пределами прямого подключения. Маршрутизатор не знает, что происходит на удалённом участке, поэтому возможны асимметричная маршрутизация и чёрные дыры, если авария случилась дальше первого хопа.
- Ручное масштабирование. Десять филиалов с двумя каналами и десятью префиксами в каждом дают две сотни статических записей, которые синхронизируют вручную.
- Ограниченные возможности политики. У статики нет атрибутов вроде local-preference или AS-path, доступных в BGP, и нет механизмов фильтрации маршрутов между узлами.
- Флаппинг. Без задержек на переключение частые сбои канала приводят к постоянной смене маршрутов и обрывам сессий, включая VPN и NAT.
- Пробы IP SLA добавляют трафик и зависят от выбранной цели: недоступная цель или цель, фильтрующая ICMP, даёт ложные срабатывания.
Общая картина выбора пути в больших сетях, где статики становится слишком много, разобрана в материале про принципы маршрутизации IP-пакетов: таблицы и алгоритмы выбора пути.
Когда переходить на динамическую маршрутизацию
Признаки, что статики перестаёт хватать:
- каналов или путей больше двух, и нужна балансировка трафика между ними;
- топология меняется регулярно: новые филиалы, перенос сетей, смена провайдеров;
- требуется быстрая сходимость после отказа, а IP SLA с частотой 5 секунд и задержками даёт переключение в десятки секунд;
- нужна политика на маршрутах: предпочтение канала, фильтрация префиксов, анонсы в две автономные системы;
- филиалов десятки, и ручная поддержка таблиц превращается в постоянный источник ошибок.
Протоколы закрывают эти задачи. EIGRP с AD 90 и OSPF с AD 110 подходят для корпоративной сети, eBGP с AD 20 нужен при работе с двумя провайдерами и для обмена полной таблицей, iBGP с AD 200 - внутри автономной системы. Все они распространяют маршруты сами и пересчитывают пути при изменениях, а BFD сокращает время обнаружения отказа до долей секунды. По умолчанию OSPF шлёт hello каждые 10 секунд и считает соседа потерянным через 40 секунд, поэтому на практике его дополняют BFD.
| Критерий | Плавающая статика | Динамическая маршрутизация |
|---|---|---|
| Балансировка нагрузки | нет, один активный путь | есть, включая ECMP |
| Реакция на аварию у провайдера | нужен track или внешний мониторинг | встроена, с BFD доли секунды |
| Масштабирование | ручное | автоматическое |
| Сложность настройки | минимальная | выше, нужен план адресации и защита от петель |
Для схемы «филиал плюс два провайдера» плавающая статика остаётся разумным выбором: конфигурация короткая, поведение предсказуемое, диагностика сводится к show ip route. Порог перехода - необходимость балансировки, быстрой сходимости или управления несколькими сегментами сети.
Подробное сравнение по сложности, управляемости и нагрузке есть в статье статическая и динамическая маршрутизация: сравнение схем для сети, а сценарии для офиса, дата-центра и VPN разобраны в материале статическая или динамическая маршрутизация: что выбрать.
Проверка и тестирование резервирования
Cisco: show ip route 0.0.0.0/0 подтверждает активный маршрут и его дистанцию, show ip route static показывает установленные статические маршруты, show track 1 и show ip sla statistics 1 - состояние проверки. Команда debug ip routing в продакшене опасна: она даёт большой объём вывода и нагружает CPU, её применяют точечно и с ограничением по времени.
Linux: ip route show даёт таблицу с метриками, ip route get 8.8.8.8 называет выбранный шлюз и интерфейс, traceroute и mtr показывают реальный путь пакета до цели.
Тест переключения проводят так: отключают основной интерфейс (shutdown на Cisco, ip link set eth0 down в Linux), убеждаются, что в таблице появился резервный маршрут, проверяют связность через ping и traceroute, затем поднимают интерфейс и следят за возвратом к основному каналу с учётом задержек track.
На удалённом сервере отключение интерфейса обрывает SSH-сессию, если она идёт через него. Подстраховка: заранее запущенная фоновая команда, которая вернёт линк через минуту, например sleep 60 && ip link set eth0 up &, или задача в планировщике at с обратной командой. Работы проводят в согласованное окно и с доступом через консоль или out-of-band.
Типичные ошибки и рекомендации
| Ошибка | Последствие | Как избежать |
|---|---|---|
| Резервный маршрут без увеличенной дистанции | оба маршрута активны, трафик распределяется, failover не работает | указать AD 2-250 для резерва |
| Резервный default в Linux без metric | метрика 0 перебивает основной маршрут | задавать metric явно, например 100 и 200 |
| Статика с AD 1 поверх OSPF как резерв | статика вытесняет протокол, при аварии дальше первого хопа возникает чёрная дыра | для резерва поверх динамики ставить AD выше 110, например 250 |
| Нет track или мониторинга | падение провайдера при поднятом линке не замечено | IP SLA плюс track, keepalived или скрипт проверки |
| Неудачная цель проб | ложные переключения либо вечно неактивный маршрут | цель, достижимая только через проверяемый канал, плюс дублирующая проверка tcp-connect |
| Правка маршрутов в живой сессии | потеря доступа к устройству | консоль, out-of-band, netplan try, отложенный откат |
| Настройки не сохранены | после перезагрузки резерва нет | netplan, NetworkManager, systemd-networkd вместо разовых команд ip route |
| Нет учёта переходов | сбои остаются незамеченными | syslog, SNMP-ловушки, EEM на Cisco, хранение конфигураций в git |
Минимальный набор действий перед вводом схемы в работу: проверить show ip route или ip route show после каждой правки, зафиксировать целевую дистанцию и метрику в документации, настроить оповещение о смене состояния track и повторить тест переключения на стенде с той же версией IOS или дистрибутива, что и в продакшене.
Для двух каналов и одной площадки плавающие статические маршруты решают задачу с минимальной конфигурацией. Как только появляется третий путь, требование балансировки или десятки филиалов, выгоднее сразу проектировать OSPF или BGP с BFD, чем поддерживать разрастающуюся таблицу статики вручную.