Маршрутизатор и ядро Linux выбирают путь в строгом порядке: сначала сравнивают длину совпавшего префикса, затем административную дистанцию или метрику. Метрика не может перевесить более точный маршрут. Если в таблице есть 192.168.1.0/24 и маршрут по умолчанию 0.0.0.0/0, пакет к 192.168.1.5 уйдёт по первому, даже когда у него метрика 4294967295, а у default 0.
В Linux метрика решает, какой из маршрутов с одинаковой длиной префикса попадёт в активную таблицу. Чем меньше число, тем выше приоритет. На оборудовании Cisco и других вендоров похожую задачу выполняет административная дистанция (AD), только работает она между источниками маршрута: подключённой сетью, статикой, OSPF, BGP, RIP.
Дальше - рабочие команды для Linux и Cisco IOS, таблицы значений, три сценария из практики (два провайдера, VPN как резерв, балансировка) и разбор ошибок, из-за которых трафик уходит не через тот интерфейс.
Как выбирается маршрут: правило longest prefix match
Алгоритм longest prefix match (LPM) означает: при поиске пути ядро или маршрутизатор сопоставляет адрес назначения со всеми записями таблицы и берёт ту, у которой самый длинный совпавший префикс. Метрика и административная дистанция на этом шаге не учитываются вообще. Правило одинаково работает в Linux, в Cisco IOS, на L3-коммутаторах и в большинстве вендорских прошивок.
Посмотреть таблицу в Linux можно командой ip route show, на Cisco - show ip route. Подробный разбор полей destination, netmask, gateway, interface и metric есть в материале про таблицу маршрутизации.
Пример работы longest prefix match
Возьмём таблицу из трёх записей:
| Префикс | Маска | Шлюз | Метрика |
|---|---|---|---|
| 0.0.0.0 | /0 | 10.0.0.1 | 100 |
| 192.168.1.0 | /24 | 10.0.0.2 | 500 |
| 192.168.1.128 | /25 | 10.0.0.3 | 900 |
Пакет к 192.168.1.5 совпадает со всеми тремя записями, но выигрывает /24: 24 бита длиннее, чем 0. Метрика 500 против 100 роли не играет. Пакет к 192.168.1.200 совпадает с /24 и /25, побеждает /25. Пакет к 10.5.5.5 не совпадает ни с чем, кроме default, и уходит через 10.0.0.1.
Отсюда практический вывод: если вы добавили маршрут к конкретной подсети, чтобы увести её через VPN или второй канал, метрики остальных записей уже не важны. Специфичный префикс перекроет default всегда, пока он есть в таблице. Проверить фактический выбор пути заранее помогает ip route get 192.168.1.200.
Метрика маршрута в Linux: управление приоритетом
Метрика в Linux - числовое значение от 0 до 4294967295, привязанное к конкретной записи. Ядро сортирует маршруты с одинаковым префиксом по возрастанию метрики и держит активным только лучший. Если метрику не указать, маршрут получает значение 0 и автоматически становится предпочтительным - частая причина сюрпризов при ручном добавлении записи рядом с маршрутом от DHCP.
Синтаксис добавления и удаления:
ip route add default via 192.168.1.1 metric 100 ip route del default via 192.168.1.1 metric 100 ip route show
Метрику часто выставляет не администратор, а клиент DHCP или менеджер сети: NetworkManager, systemd-networkd и dhclient добавляют default с собственным значением. Поэтому ручной маршрут без metric может неожиданно выиграть или проиграть автоматическому. Больше примеров работы с таблицами, шлюзами и метриками собрано в руководстве по статической маршрутизации через ip route.
Как задать метрику для маршрута по умолчанию
Схема с двумя каналами строится на разных метриках:
ip route add default via 192.168.1.1 metric 100 ip route add default via 192.168.2.1 metric 200
Активен маршрут через 192.168.1.1. Второй лежит в таблице и ждёт: как только первый исчезнет (например, упадёт интерфейс и ядро удалит связанные записи), в работу войдёт шлюз 192.168.2.1 без ручного вмешательства.
Метрика и несколько маршрутов к одной сети
Разные метрики дают отказоустойчивость, одинаковые - балансировку. Одинаковые метрики для одного префикса ядро само не объединит в ECMP: вторая команда вернёт «RTNETLINK answers: File exists». Равнозначные пути задают одной multipath-записью с несколькими nexthop:
ip route add default nexthop via 192.168.1.1 dev eth0 weight 1 nexthop via 192.168.2.1 dev eth1 weight 1
Linux распределяет потоки между nexthop по хешу (ECMP), поэтому отдельные TCP-сессии сохраняют свой путь. Для UDP, GRE и любых протоколов без привязки к соединению это не гарантировано: часть пакетов одной логической сессии может уйти через другой канал, и NAT на стороне провайдера такие пакеты разорвёт.
Административная дистанция в сетевом оборудовании
Административная дистанция показывает степень доверия к источнику маршрута. Значение от 0 до 255: чем меньше, тем предпочтительнее запись. AD применяется, когда к одной сети ведут маршруты от разных протоколов или от статики и протокола одновременно. Метрика же сравнивает варианты внутри одного источника, например два пути, полученные по OSPF.
Порядок принятия решения на Cisco: longest prefix match, затем наименьшая административная дистанция, затем метрика протокола. В Linux прямого аналога AD нет. Роль переключателя между источниками частично выполняют приоритеты правил ip rule и отдельные таблицы маршрутизации, о которых подробно рассказано в статье про принципы IP-маршрутизации.
Стандартные значения административной дистанции
Значения по умолчанию для оборудования Cisco:
| Источник маршрута | Административная дистанция |
|---|---|
| Connected (подключённая сеть) | 0 |
| Статический маршрут | 1 |
| EIGRP summary route | 5 |
| External BGP (eBGP) | 20 |
| EIGRP internal | 90 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| EIGRP external | 170 |
| Internal BGP (iBGP) | 200 |
У других вендоров и в отдельных версиях прошивок значения отличаются, поэтому перед настройкой стоит свериться с документацией конкретной платформы.
Как административная дистанция влияет на выбор маршрута
Классический пример конфликта: статический default с AD 1 и default, полученный по OSPF с AD 110. Победит статика, даже если OSPF предлагает путь с меньшей метрикой и меньшей задержкой. Так же ведёт себя iBGP с AD 200: он проигрывает OSPF и RIP, пока те не перестанут анонсировать тот же префикс.
Резервный статический маршрут строят через «плавающую» дистанцию. Основной путь приходит по OSPF, резервный прописан статикой с AD 250:
ip route 0.0.0.0 0.0.0.0 192.168.2.1 250
Пока OSPF анонсирует default, статика с AD 250 проигрывает и в таблицу не попадает. Как только анонс пропадает, статический маршрут становится активным. Скорость переключения здесь ограничена не таймерами протокола, а временем, за которое OSPF признает соседа недоступным.
Практические сценарии: два провайдера, VPN и резервный маршрут
Все три сценария ниже строятся на одном принципе: приоритет задаётся метрикой или дистанцией, а фактический выбор всегда проверяется командой ip route get.
Два провайдера: основной и резервный
Linux, разные метрики:
ip route add default via 192.168.1.1 metric 100 ip route add default via 192.168.2.1 metric 200
Cisco IOS, две статические записи с разной дистанцией:
ip route 0.0.0.0 0.0.0.0 192.168.1.1 1 ip route 0.0.0.0 0.0.0.0 192.168.2.1 2
Важная оговорка: маршрут исчезает только тогда, когда ядро или маршрутизатор теряет связь со следующим шлюзом. Если провайдер перестал пропускать трафик, но интерфейс и ARP-запись живы, default останется активным и переключения не произойдёт. Для реальной отказоустойчивости добавляют проверку доступности внешнего адреса и скрипт, который удаляет или меняет метрику маршрута, либо переводят схему на динамическую маршрутизацию.
VPN как резервный маршрут
Туннель ставят третьим по приоритету, чтобы он включался после двух проводных каналов:
ip route add default via 10.8.0.1 dev tun0 metric 300
Для маршрута через туннель обязательно указывать устройство, иначе ядро попытается искать шлюз 10.8.0.1 в основной сети и получит ошибку «Network is unreachable». Если нужен обратный порядок, когда VPN основной, а провайдер резервный, метрики меняют местами и дополнительно закрывают утечки трафика: маршрут по умолчанию через туннель плюс правила для адреса VPN-сервера в обход туннеля.
Автоматическое переключение между туннелем и физическим каналом без скриптов делают через динамическую маршрутизацию (BGP, OSPF поверх туннеля) либо через мониторинг, который поднимает и опускает интерфейс по результатам проверки доступности.
Балансировка нагрузки через два канала
В Linux балансировка задаётся multipath-записью с равными весами, как в примере выше. На Cisco две статические записи с одинаковой дистанцией дают два равнозначных пути:
ip route 0.0.0.0 0.0.0.0 192.168.1.1 1 ip route 0.0.0.0 0.0.0.0 192.168.2.1 1
По умолчанию CEF распределяет потоки по направлениям (per-destination), сохраняя путь для каждой сессии. Режим per-packet включают отдельной командой на интерфейсе и применяют редко: он даёт максимальную загрузку каналов, но ломает сессии с проверкой последовательности пакетов.
Балансировку усложняют асимметричная маршрутизация и NAT: обратный трафик может прийти через другой провайдер, и stateful-устройство на пути отбросит пакеты. Перед включением ECMP проверьте, что приложение переживает смену внешнего IP, а сервис не привязан к адресу источника. Для сценариев, где нужен не равнозначный выбор, а маршрут по адресу источника или метке, применяют несколько таблиц и правила ip rule; разбор такого подхода есть в статье про профили маршрутизации в Linux.
Типичные ошибки и как их избежать
Четыре ошибки встречаются чаще остальных.
- Специфичный маршрут перекрывает основной. Добавили /25 для отдельного сервера и забыли, что он забирает весь трафик этой подсети в обход шлюза по умолчанию. Метрика /25 может быть в разы хуже, выбор всё равно за ним.
- Конфликт метрик с DHCP или менеджером сети. Ручной default без metric получил 0 и перекрыл маршрут от NetworkManager с metric 100, либо наоборот: автоматическая запись оказалась приоритетнее, и настройка «не работает».
- Забыли про административную дистанцию при миграции протоколов. Старый статический маршрут с AD 1 остаётся в конфигурации и продолжает выигрывать у нового OSPF с AD 110, хотя анонсы приходят корректно.
- Нет проверки фактического пути. Конфигурация применена, таблица выглядит верно, но трафик уходит иначе из-за маршрута в другой таблице, правила ip rule или записи для IPv6. Каждый раз нужен контрольный запрос к конкретному адресу, а не просмотр таблицы целиком.
Как диагностировать выбор маршрута
В Linux ключевая команда показывает финальное решение ядра с учётом всех таблиц и правил:
ip route get 8.8.8.8 ip route get 8.8.8.8 from 192.168.1.10 ip -6 route get 2001:4860:4860::8888
Первая строка вывода содержит адрес назначения, выбранный шлюз, устройство и метку таблицы. Если ожидаемый интерфейс не совпал с реальным, ищите более длинный префикс в другой таблице или подходящее правило ip rule.
На Cisco аналогичную задачу решает show ip route 8.8.8.8: вывод покажет выбранный маршрут, протокол-источник и административную дистанцию с метрикой в квадратных скобках. Дополнительно проверяют путь на уровне оборудования командой traceroute, а в Linux - ip neigh, чтобы убедиться, что сосед по шлюзу разрешается в MAC-адрес.
Значения административной дистанции, синтаксис команд и поведение ECMP отличаются у разных вендоров и версий ядра. Перед изменениями в рабочей среде проверьте настройки в лаборатории или на тестовом узле и убедитесь, что у вас есть доступ к устройству вне изменяемого маршрута.
Рекомендации по настройке метрик для отказоустойчивости и балансировки
Ниже - набор правил, которые снижают вероятность неожиданного выбора пути.
- Для отказоустойчивости всегда разносите метрики: основной канал 100, резервный 200, туннель 300. Оставляйте свободный диапазон между значениями, чтобы позже вставить промежуточный маршрут без пересчёта всей схемы.
- Для балансировки используйте равные метрики и одну multipath-запись в Linux либо две статические записи с одинаковой AD на Cisco. Заранее проверьте, что приложения не привязаны к IP источника.
- При динамической маршрутизации задавайте административные дистанции так, чтобы предпочитаемый протокол имел меньшее значение, а резервный маршрут был «плавающим» с AD около 250.
- Не полагайтесь на то, что падение провайдера удалит маршрут. Добавьте проверку доступности внешнего адреса и автоматическое переключение метрики, иначе резервный канал останется неиспользованным.
- Фиксируйте выбранные значения в документации и в системе управления конфигурациями. Через полгода никто не вспомнит, почему у второго провайдера метрика 200, а не 150.
- После каждого изменения и после перезагрузки проверяйте результат командой ip route get или show ip route с конкретным адресом. Таблица целиком верный ответ не даёт.
- Для схем, где выбор зависит от источника, приложения или метки пакета, переходите на несколько таблиц маршрутизации и ip rule. Общая картина алгоритмов выбора пути с примерами для Linux, Cisco и L3-коммутаторов собрана в руководстве по маршрутизации IP-пакетов.
Начните с одного шага: посмотрите текущий вывод ip route show и выпишите метрики активных маршрутов. Если там есть записи с metric 0 рядом с маршрутами от DHCP или менеджера сети, порядок выбора пути уже отличается от задуманного, и это первое, что стоит привести к явной схеме.