Маршрутизация L3: как IP-маршрутизаторы строят таблицы маршрутов и выбирают путь

Маршрутизатор решает, куда отправить пакет, по трём последовательным правилам: ищет самый длинный совпадающий префикс, сравнивает административную дистанцию источников маршрута, и только потом метрику внутри протокола. Совпадение всех трёх параметров включает балансировку ECMP. MAC-адреса за пределами локального сегмента на выбор пути не влияют: маршрутизатор переписывает их на каждом хопе.

Практическая задача выглядит так: пакет к 10.1.1.5 при наличии маршрутов 10.0.0.0/8, 10.1.0.0/16 и 10.1.1.0/24 уйдёт по третьему, потому что /24 — самый длинный префикс. Если бы к сети 10.1.1.0/24 существовали записи от статики и от OSPF, победила бы статика с административной дистанцией 1 против 110 у OSPF. Метрика OSPF в этом сравнении не участвовала бы вообще.

Что такое маршрутизация L3 и как маршрутизатор выбирает путь

Маршрутизация L3 работает с IP-пакетами и таблицей маршрутов. Хост отправляет кадр на MAC-адрес шлюза, маршрутизатор снимает заголовок канального уровня, читает destination IP и ищет в таблице запись, которая покрывает этот адрес. Дальше он подставляет MAC-адрес следующего хопа и отправляет кадр в нужный интерфейс.

Ключ к корректному выбору пути — адресация. Запись в таблице маршрутов описывает сеть назначения в формате CIDR: адрес плюс длина префикса. Маска /24 покрывает 256 адресов, из которых один адрес сети и один широковещательный остаются служебными. Маска /16 покрывает 65536 адресов. Чем длиннее префикс, тем уже диапазон и тем специфичнее маршрут.

Алгоритм выбора маршрута: от префикса до метрики

1. Маршрутизатор берёт destination IP из заголовка пакета.
2. Находит в таблице все записи, чей префикс покрывает этот адрес. Для 10.1.1.5 подойдут 0.0.0.0/0, 10.0.0.0/8, 10.1.0.0/16 и 10.1.1.0/24.
3. Оставляет запись с самой длинной маской, это и есть longest prefix match.
4. Если к одному префиксу есть маршруты от разных источников, сравнивает административную дистанцию и берёт наименьшую.
5. При равной дистанции сравнивает метрику протокола: cost в OSPF, составную метрику в EIGRP, длину AS-Path в BGP.
6. При равной метрике устанавливает несколько next hop и балансирует трафик по ECMP.

Обратите внимание на порядок шагов: административная дистанция работает только среди маршрутов к одинаковому префиксу. Маршрут 0.0.0.0/0 с дистанцией 1 никогда не обыграет 192.168.1.0/24 с дистанцией 1, потому что нулевой префикс короче. Это самая частая причина путаницы при чтении таблицы маршрутов.

Административная дистанция и метрика: в чём разница

Административная дистанция (AD) показывает доверие к источнику маршрута. Это статическое число: его задаёт вендор по умолчанию или администратор вручную, и оно не меняется при изменении топологии. Метрика измеряет стоимость пути внутри одного протокола и пересчитывается при изменениях в сети: например, cost в OSPF зависит от пропускной способности интерфейса.

Значения по умолчанию, принятые в оборудовании Cisco, выглядят так:

Официальная документация Cisco подтверждает ключевые значения: internal EIGRP имеет дистанцию 90, OSPF — 110, и при одинаковом префиксе маршрутизатор выберет EIGRP, потому что 90 меньше 110 (Understand Administrative Distance — Cisco). Полная таблица значений, включая IS-IS 115, встречается в учебных материалах по CCNA (Administrative Distance (AD) — CCNA Mastery); для конкретной платформы и версии IOS её стоит сверять с документацией вендора.

В FRR административная дистанция решает, какие маршруты попадут в RIB: выбирается маршрут с наименьшей дистанцией по протоколу-источнику. Документация FRR прямо указывает, что разработчики постарались выбрать те же значения, что и в других наборах протоколов, однако точный числовой список для connected, static, OSPF и RIP в приведённых материалах не зафиксирован — перед переносом конфигурации сверяйтесь с документацией вашей версии FRR (Zebra — FRR latest documentation).

Пример работы правила: до сети 172.16.0.0/16 есть статический маршрут и маршрут, выученный по OSPF с cost 10. Победит статический, потому что 1 меньше 110. Метрика OSPF, какой бы маленькой она ни была, в сравнение не попадает. Если такое поведение нежелательно, статический маршрут убирают, повышают ему дистанцию или используют маршрут с флагом floating static, у которого AD вручную выставлена выше протокольной.

Устройство таблицы маршрутов: как читать ip route и route print

Маршрутизатор хранит кандидатов в RIB, а победившие записи попадают в FIB, по которой работает быстрый путь обработки пакетов. В Linux RIB смотрят командой ip route show, в Windows — командами route print или netstat -rn.

ip route show
default via 192.168.1.1 dev eth0 proto static metric 100
10.10.0.0/16 via 192.168.1.2 dev eth0 proto static metric 50
172.16.0.0/12 via 192.168.1.2 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

Поля таблицы маршрутов и их значение

Разберём строку default via 192.168.1.1 dev eth0 proto static metric 100 по элементам. default означает префикс 0.0.0.0/0. via 192.168.1.1 — адрес next hop, то есть шлюз, которому надо передать пакет. dev eth0 — интерфейс выхода. proto static показывает, кто добавил маршрут: ядро (kernel), статика, DHCP или демон протокола. metric 100 — метрика, при равных значениях у нескольких маршрутов включается балансировка.

Четвёртая строка отличается: в ней нет via, а есть scope link и src. Так выглядит маршрут к сети, подключённой напрямую. Шлюз не нужен, потому что получатель достижим через ARP в том же сегменте, а src фиксирует адрес источника для исходящих пакетов.

Флаги маршрутов удобнее смотреть устаревшей командой route -n: U означает, что маршрут активен, G — что пакет идёт через шлюз, H — что запись описывает отдельный хост, а не сеть. Сочетание UG читается как активный маршрут через шлюз. Команда route сохранилась во многих дистрибутивах, но для настройки применяйте ip route: пакет iproute2 развивается, а net-tools давно не обновляется.

В Windows вывод route print состоит из колонок Network Destination, Netmask, Gateway, Interface и Metric. Строка 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.10 25 означает маршрут по умолчанию через шлюз 192.168.1.1 на интерфейсе 192.168.1.10 с метрикой 25. Метрика в Windows складывается из метрики интерфейса и метрики маршрута, поэтому при нескольких адаптерах выигрывает тот, у которого суммарное значение меньше.

Маршрут по умолчанию и его роль

Маршрут 0.0.0.0/0 применяется, когда ни один другой префикс не совпал с адресом назначения. Если такого маршрута нет, ядро отбросит пакет и вернёт ICMP network unreachable. Проверить это можно командой ip route get с адресом внешнего хоста.

Несколько маршрутов по умолчанию с равной метрикой устанавливаются одновременно и балансируются, что используют для подключения двух провайдеров. В Linux метрику задают явно при добавлении маршрута, потому что значение по умолчанию зависит от порядка добавления записей. В Windows суммарную метрику удобнее задавать в свойствах адаптера, иначе после перезагрузки приоритет может сместиться.

Linux поддерживает несколько таблиц маршрутизации. Команда ip rule show показывает правила выбора таблицы: правило 0 смотрит в local, правило 32766 — в main, правило 32767 — в default. Пока в систему не добавлены свои правила, весь трафик обрабатывает main. Подробные примеры работы с таблицами, шлюзами и метриками собраны в руководстве по настройке маршрутизации в Linux.

Статическая маршрутизация: настройка и типичные ошибки

Статические маршруты применяют там, где топология предсказуема: два-три маршрутизатора, фиксированные каналы, простые филиалы. Такой маршрут не меняется сам, не потребляет CPU на обмен служебными пакетами и предсказуем при разборе инцидентов. Платой становится ручная правка при любом изменении схемы.

Как добавить статический маршрут в Linux и Windows

В Linux маршрут добавляют командой ip route add:

ip route add 10.10.0.0/16 via 192.168.1.2 dev eth0
ip route add 10.10.0.0/16 via 192.168.1.2 dev eth0 metric 50
ip route replace 10.10.0.0/16 via 192.168.1.3 dev eth0
ip route del 10.10.0.0/16

Команда replace удобна тем, что не выдаёт ошибку при существующем маршруте к тому же префиксу, а переписывает запись. Изменения через ip route add живут до перезагрузки или до перезапуска сетевого сервиса. Чтобы маршрут сохранился, его прописывают в конфигурации: в netplan секцией routes, в NetworkManager через nmcli, в systemd-networkd файлом .network, в RHEL-подобных системах файлом route-eth0 в каталоге сетевых скриптов.

В Windows команду нужно запускать от имени администратора:

route add 10.10.0.0 mask 255.255.0.0 192.168.1.2
route -p add 10.10.0.0 mask 255.255.0.0 192.168.1.2
netsh interface ipv4 add route 10.10.0.0/16 "Ethernet" 192.168.1.2
route print

Ключ -p делает маршрут постоянным и переживает перезагрузку. Команда netsh даёт тот же результат, но привязывает маршрут к интерфейсу по имени, что снижает риск ухода трафика не в тот адаптер. Больше сценариев с route и netsh, включая настройку VPN, разобрано в шпаргалке по управлению маршрутизацией в Windows.

Типичные ошибки при настройке статических маршрутов

1. Неверная маска. Маршрут 10.10.0.0/24 вместо /16 покрывает только 256 адресов, и остальные уйдут по маршруту по умолчанию, возможно, не туда. Проверка: ip route get 10.10.5.7 покажет выбранный маршрут и next hop.
2. Отсутствие обратного маршрута. Пакеты доходят до сервера, а ответы не возвращаются, потому что на удалённой стороне нет маршрута к источнику. Симптом — ping проходит в одну сторону. Проверка: tcpdump на входящем интерфейсе и таблица маршрутов удалённого узла.
3. Конфликт с динамическим протоколом. Статический маршрут с дистанцией 1 перекрывает выученный по OSPF. Если статика указывает на нерабочий шлюз, трафик уходит в чёрную дыру, хотя протокол предлагал живой путь. Решение: либо удалить статику, либо задать ей более высокую дистанцию.
4. Потеря маршрута после перезагрузки. ip route add не сохраняется. Проверка: ip route show после reboot или grep по файлам конфигурации сети.
5. Шлюз не из локальной подсети. Ядро вернёт ошибку Nexthop has invalid gateway, потому что next hop должен быть достижим через интерфейс выхода.
6. Ошибка в параметре dev. Маршрут уходит в другой интерфейс, и трафик либо отбрасывается, либо утекает в сторону.
7. Случайный blackhole. Команды ip route add blackhole, unreachable и prohibit используют для блокировки трафика. Тип blackhole молча отбрасывает пакеты, unreachable отвечает ICMP host unreachable, prohibit возвращает ICMP admin prohibited. Забытый маршрут такого вида выглядит как необъяснимая потеря связности.

Перед правками сохраните текущее состояние: ip route show > /root/route-backup.txt в Linux и route print > backup.txt в Windows. Это даёт точку возврата, если связь с удалённым сервером пропадёт прямо во время настройки.

Динамическая маршрутизация: OSPF, BGP, EIGRP

Динамические протоколы строят маршруты сами и перестраивают их при отказах. Выбор зависит от масштаба сети и от того, нужно ли обмениваться маршрутами с внешними организациями.

OSPF: настройка и проверка на Linux (FRR)

OSPF устанавливает соседство через hello-пакеты, по умолчанию каждые 10 секунд, и считает соседа потерянным после 40 секунд молчания. Документация Cisco IOS подтверждает: hello-интервал по умолчанию равен 10 секундам для Ethernet (30 секунд для nonbroadcast-сетей), а dead-интервал по умолчанию вчетверо больше hello (Cisco IOS IP Routing: OSPF Command Reference). Все маршрутизаторы в одной зоне должны видеть друг друга в area 0, которая служит магистралью. Пример конфигурации для FRR:

interface eth1
 ip ospf cost 10
!
router ospf
 network 10.0.0.0/24 area 0
 network 192.168.10.0/24 area 0
 passive-interface eth0
!

Проверка после применения:

show ip ospf neighbor
show ip ospf interface eth1
show ip ospf route
show ip route ospf

Соседство не поднимется при несовпадении area ID, интервалов hello, типа сети или MTU на интерфейсах. Расхождение MTU — классическая причина состояния ExStart, когда маршрутизаторы не могут обменяться описаниями базы. Метрика cost считается как отношение референсной пропускной способности к пропускной способности интерфейса. Референсное значение по умолчанию в Cisco IOS — 100 Мбит/с, поэтому на каналах 10 Гбит/с и выше его поднимают вручную командой auto-cost reference-bandwidth, иначе все быстрые линки получат одинаковый cost. Точное значение по умолчанию для вашей платформы и версии ПО стоит сверить с документацией.

BGP: когда нужен и как настроить базово

BGP применяют для обмена маршрутами между автономными системами, а внутри крупных сетей — для передачи маршрутов между площадками. Протокол не выбирает путь по пропускной способности канала: решение строят по атрибутам. Документация Cisco описывает первый шаг алгоритма выбора best path так: предпочитается путь с наибольшим WEIGHT, причём WEIGHT — параметр, специфичный для Cisco и локальный для маршрутизатора, на котором он настроен (Select BGP Best-path Algorithm — Cisco). Полная последовательность сравнения (local preference, локально созданные маршруты, длина AS-Path, origin, MED, предпочтение eBGP перед iBGP) в приведённых материалах не подтверждена построчно, поэтому при разборе конкретного выбора пути опирайтесь на документацию вашей версии IOS или на RFC о BGP best path selection.

router bgp 65000
 bgp router-id 10.0.0.1
 neighbor 192.168.1.2 remote-as 65001
 network 10.0.0.0/24
!

Проверка состояния сессии и принятых маршрутов:

show ip bgp summary
show ip bgp
show ip bgp neighbors 192.168.1.2 advertised-routes

Отдельного внимания требуют фильтры. Ошибка в политике анонса приводит к тому, что наружу уходят чужие или внутренние префиксы, а внутрь попадает полная таблица интернета, которая нагружает память. Практика: prefix-list на входящем и исходящем направлениях, ограничение max-prefix, отказ от приёма префиксов с приватных диапазонов, а также фильтрация по AS-Path. В iBGP next hop по умолчанию не меняется, поэтому маршрутизатор без прямого доступа к внешнему сегменту не установит маршрут без команды next-hop-self на граничном узле.

EIGRP: особенности и применение

EIGRP создан Cisco, алгоритм DUAL позволяет держать заранее рассчитанный резервный путь и переключаться на него без пересчёта топологии. Метрика составная и по умолчанию учитывает bandwidth и delay, а при необходимости добавляются load и reliability. Протокол поддерживает VLSM и быструю сходимость, поэтому распространён в корпоративных сетях на оборудовании одного вендора.

router eigrp 1
 network 10.0.0.0
 no auto-summary
!

В новых версиях IOS классическую форму записи заменяет router eigrp с именем процесса и address-family. Открытая реализация EIGRP существует в FRR, но покрывает не весь функционал вендорской версии, поэтому в гетерогенной сети разумнее строить внутреннюю маршрутизацию на OSPF: он одинаково работает у разных производителей и проще диагностируется.

Диагностика маршрутизации: traceroute, ip route get и типичные проблемы

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

Как использовать traceroute и ip route get

traceroute работает через TTL: первый пакет уходит с TTL 1, первый маршрутизатор уменьшает его до нуля и возвращает ICMP time exceeded, второй отвечает на пакет с TTL 2, и так до цели. В Linux традиционный метод traceroute по умолчанию отправляет UDP-датаграммы; man-страница traceroute(8) отмечает, что такие пакеты часто фильтруются firewall'ами, и что утилита поддерживает также методы ICMP ECHO (флаг -I) и TCP SYN (traceroute(8) — Linux manual page). Конкретный метод по умолчанию может зависеть от реализации и версии утилиты, поэтому при разборе инцидента проверяйте, какой режим используется. Звёздочки в выводе означают, что узел не отвечает на служебные пакеты: политика фильтрации ICMP ещё не говорит о потере трафика.

traceroute 8.8.8.8
traceroute -I 203.0.113.10
tracert 8.8.8.8
mtr 8.8.8.8

Команда ip route get показывает решение для конкретного адреса ещё до отправки трафика:

ip route get 10.1.1.5
10.1.1.5 via 192.168.1.2 dev eth0 src 192.168.1.10
ip route get 8.8.8.8 from 10.0.0.5 iif eth1
ip -6 route get 2001:db8::1

Вторая форма полезна при подмене адреса источника и при нескольких таблицах: результат покажет, какое правило выбрано и какой шлюз будет использован. mtr объединяет ping и трассировку, накапливает статистику потерь по хопам и помогает отличить постоянный обрыв от кратковременных всплесков. Последовательность шагов для разбора инцидента с примерами команд и чтением дампов собрана в руководстве по диагностике проблем маршрутизации.

Типичные ошибки маршрутизации в продакшене

1. Асимметричная маршрутизация. Пакеты идут к цели по одному пути, а ответы возвращаются по другому. Трафик может ходить, но firewall с отслеживанием соединений будет рвать сессии. Диагностика: ip route get на обеих сторонах, сравнение путей в traceroute от источника и к источнику.
2. Маршрутная петля. Два маршрутизатора указывают друг на друга как на next hop для сети, которой нет ни у одного из них. Признак — TTL exceeded в выводе traceroute и резкий рост загрузки CPU на обоих узлах.
3. Blackhole из-за отсутствия обратного маршрута. Сервер отвечает через маршрут по умолчанию, который ведёт не туда, и трафик пропадает. Помогает проверка таблицы маршрутов на стороне получателя.
4. Конфликт статики и динамики. Статический маршрут с дистанцией 1 незаметно перекрывает протокольный, и при отказе шлюза сеть теряет связность, хотя протокол знает рабочий путь.
5. Проблемы MTU. Небольшие пакеты проходят, крупные с флагом DF отбрасываются, если ICMP fragmentation needed блокируется фильтром. Симптом — установка TCP-соединения без передачи данных.
6. Отброс по rp_filter. Ядро Linux проверяет обратный путь для входящих пакетов. При асимметричной схеме пакеты с неожиданного интерфейса отбрасываются, и в логах появляются записи о martian source.

Различить сбой маршрута, DNS, firewall, VPN и MTU помогает последовательная проверка слоёв, описанная в чеклисте по диагностике маршрутизации на сервере.

Практический чек-лист: настройка маршрутизации без ошибок

1. Выпишите сети и маски на обоих концах канала. Ошибка в длине префикса обходится дороже всего: маршрут формально работает, но покрывает не тот диапазон.
2. Выберите способ маршрутизации: статика для двух-трёх узлов, OSPF для внутренней сети, BGP для связи между автономными системами.
3. Добавьте маршруты и сразу сохраните конфигурацию в постоянное хранилище: netplan, nmcli, systemd-networkd или route -p add.
4. Проверьте решение командой ip route get для адреса цели. Результат должен совпасть с ожидаемым шлюзом и интерфейсом.
5. Убедитесь, что на удалённой стороне есть маршрут возврата к источнику.
6. Проверьте путь целиком через traceroute или mtr и зафиксируйте вывод до изменений и после.
7. Проверьте крупные пакеты отдельным тестом, чтобы исключить проблему MTU.
8. Протестируйте схему в лаборатории или на тестовом сегменте, и только потом переносите конфигурацию в продакшен.

Проверка на стороне самого маршрутизатора, включая ip addr, ip route, nft и tcpdump, разобрана в материале о диагностике Linux-маршрутизатора.

Синтаксис команд, значения административных дистанций и референсная пропускная способность различаются между вендорами и версиями ПО. Перед переносом примеров в рабочую сеть сверьте параметры с документацией вашей платформы: команды FRR, Cisco IOS и сетевых стеков Linux совпадают лишь частично, а изменение дистанции или метрики может незаметно перестроить всю схему маршрутизации.