L3 Маршрутизация: статика и динамика
Коммутатор (L2) знает, как доставить кадр внутри одной сети. Но как пакет попадает из сети
10.0.1.0/24 в сеть 10.0.99.0/24 на другом конце страны? Это работа маршрутизатора.
Маршрутизация — сердце L3 и навык, который отличает «настроил по инструкции» от «понимаю, что происходит».
Это фундаментальный модуль: на нём стоят следующие два — OSPF и BGP.
«Заявка #43890. Филиал „Восток“ не видит новый сервер 10.42.1.170 в головном офисе: ping из филиала молчит. При этом старые серверы из той же стойки (10.42.1.10, 10.42.1.20) пингуются отлично. Сервер жив: айтишники филиала уже трижды его перезагрузили». Чувствуешь абсурд? Соседние адреса из одной стойки — одни ходят, один нет. Перезагрузка сервера тут не поможет: где-то на пути один из роутеров принимает другое решение для 10.42.1.170, чем для 10.42.1.10. Почему так бывает (спойлер: longest prefix match и забытая суммаризация), как найти виновный хоп за 5 минут — узнаешь в этом уроке и закроешь заявку в плейбуке.
- Как роутер принимает решение: правило longest prefix match и полный алгоритм выбора
- Анатомия записи таблицы маршрутизации (prefix, next-hop, AD, metric)
- Разница RIB и FIB (и что такое CEF) — то, что путают даже мидлы
- Рекурсивный lookup next-hop и почему «маршрут есть, а не пингуется»
- Статические маршруты: default, floating static, host route, null-route
- Administrative Distance — кто побеждает, и как её менять
- Динамика: IGP против EGP, distance-vector против link-state
- RIP / EIGRP / OSPF / IS-IS / BGP — кто на что и когда выбирать
- ECMP и как именно хешируется трафик по путям
- Полный конфиг-сценарий на 3 роутера от и до
- Мост в DevOps: то же самое в Linux (
ip route, policy routing) и в облаке
Модуль 2: внутри сегмента кадр доставляет коммутатор по MAC, а IP→MAC решает ARP — маршрутизатору это понадобится на последнем шаге, чтобы вручить пакет получателю. Модуль 3: между VLAN трафик ходит только через L3 — вот этот L3 мы сегодня и разбираем. Модуль 4: подсети и маски — язык таблицы маршрутизации; если /26 и «магическое число» ещё не в подкорке, вернись, без них longest prefix match не почувствовать.
1. Что такое маршрутизация и зачем
Маршрутизатор — это устройство с несколькими интерфейсами в разных сетях (L3-доменах). Его единственная задача: получить пакет, посмотреть IP назначения, найти в своей таблице маршрутизации лучшее совпадение и переслать пакет в нужный интерфейс или следующему роутеру.
Ключевой принцип: каждый роутер принимает решение независимо, hop-by-hop. Никто не знает весь путь целиком. Каждый знает только «куда передать дальше» (next-hop). Это как спрашивать дорогу: на каждом перекрёстке тебе говорят следующий поворот, а не весь маршрут до цели.
2. Как принимается решение: longest prefix match
В таблице может быть несколько записей, подходящих под адрес назначения. Роутер всегда выбирает самую специфичную — с самой длинной маской (longest prefix match, LPM). Чем длиннее префикс, тем «точнее» он описывает цель.
Пример. Пакет идёт на 10.0.99.7. В таблице:
| Маршрут | Маска (бит) | Подходит? | Выбор |
|---|---|---|---|
0.0.0.0/0 (default) | 0 | да (под всё) | — |
10.0.0.0/8 | 8 | да | — |
10.0.99.0/24 | 24 | да | ✅ победитель |
10.0.99.0/26 | 26 | нет (.7 вне .0–.63? да, входит) | зависит — см. ниже |
10.0.50.0/24 | 24 | нет | — |
Уточнение по строке /26: 10.0.99.0/26 покрывает .0–.63, значит .7 в него входит.
Тогда победил бы /26 — он ещё длиннее /24. Правило железобетонное: чем длиннее маска среди подходящих,
тем выше приоритет. Default /0 используется только когда ничего более специфичного не нашлось —
«маршрут последней надежды».
0.0.0.0/0 → R_A и 10.0.99.0/24 → R_B. Куда пойдёт пакет на 10.0.99.7?» —
к R_B, потому что /24 длиннее /0. LPM всегда побеждает, маски сравниваются до метрик и AD.
Полный порядок выбора маршрута
LPM — только первый шаг. Полный алгоритм роутера такой:
3. Анатомия таблицы маршрутизации
Посмотрим на реальный вывод Cisco show ip route и разберём по частям:
Разберём строку O 10.0.50.0/24 [110/20] via 10.0.12.2, 00:14:21, Gi0/1:
| Часть | Что значит |
|---|---|
O | Источник маршрута — выучен по OSPF (C=connected, L=local /32, S=static, B=BGP, D=EIGRP) |
10.0.50.0/24 | Префикс назначения и его маска |
[110/...] | Administrative Distance — доверие к источнику (см. §6) |
[.../20] | Metric — «стоимость» пути внутри этого протокола |
via 10.0.12.2 | Next-hop — кому передать пакет дальше |
00:14:21 | Сколько времени маршрут в таблице (uptime) |
Gi0/1 | Через какой интерфейс уходить (exit interface) |
ip route show.
Запись 10.0.50.0/24 via 10.0.12.2 dev eth0 — это ровно тот же next-hop + интерфейс.
Сервер в облаке маршрутизирует по точно таким же правилам, просто без красивых кодов C/S/O.
4. RIB и FIB — то, что путают даже мидлы
То, что показывает show ip route — это RIB (Routing Information Base), «база знаний»
управляющей плоскости (control plane). Сюда стекаются все маршруты от всех протоколов, здесь идёт выбор лучшего.
Но пересылать каждый пакет, перебирая RIB, было бы медленно.
Поэтому из RIB выжимается FIB (Forwarding Information Base) — оптимизированная таблица для «железной» пересылки на полной скорости. На Cisco механизм называется CEF. FIB уже содержит готовый ответ: «для такого префикса — такой выходной интерфейс и такой MAC next-hop», без рекурсии в момент пересылки.
show ip cef показывает FIB.show ip route есть, а трафик не идёт. Где смотреть?»show ip cef 10.0.99.0) — иногда RIB и FIB рассинхронились,
или next-hop в FIB не разрезолвился в MAC (нет ARP/смежности). RIB ≠ гарантия пересылки.5. Рекурсивный lookup и «маршрут есть, а не пингуется»
Когда у маршрута указан только next-hop IP (а не выходной интерфейс), роутер должен сначала выяснить: «а как добраться до самого next-hop?». Это рекурсивный lookup — ещё один поиск по таблице. Если next-hop никуда не резолвится — маршрут не установится, хотя ты его и прописал.
ip route 10.0.99.0 255.255.255.0 Gi0/1.
Роутер думает, что вся сеть 10.0.99.0/24 «прямо за интерфейсом», и шлёт ARP на каждый адрес — это «proxy-ARP ад».
На Ethernet всегда указывай next-hop IP (или связку interface+next-hop).
6. Статическая маршрутизация
Статический маршрут — ты руками прописываешь: «для такой-то сети next-hop вот этот». Просто, предсказуемо, не ест CPU и трафик на протокол. Минус — не адаптируется: если линк упал, статика всё равно указывает туда (если не настроен tracking).
Где статика реально уместна
- Default route к провайдеру — самый частый кейс. Тебе не нужен протокол, чтобы знать «весь интернет — туда».
- Stub-сети — площадка с единственным выходом. Динамика там избыточна.
- Маршрут к управляющему сегменту, который должен быть всегда фиксирован.
- Blackhole / null-route — выбросить мусорный или атакующий трафик дёшево, на уровне FIB.
Floating static route — резерв
Статике можно вручную задать AD выше, чем у основного маршрута. Тогда она «спит» и появляется в таблице, только если основной (например, OSPF) пропал. Это дешёвый backup-путь.
Статика + tracking — чтобы не было чёрных дыр
Проблема статики: интерфейс «up», но дальше по пути всё мертво — а статика всё равно шлёт туда. Решение — привязать маршрут к проверке доступности (IP SLA + object tracking): маршрут живёт, только пока пингуется цель.
7. Administrative Distance — кому верить
А что, если про одну и ту же сеть 10.0.99.0/24 роутер узнал двумя способами — например,
и по OSPF, и по BGP? Метрики разных протоколов несравнимы (у OSPF — cost, у RIP — хопы). Поэтому роутер
сначала сравнивает Administrative Distance — степень доверия к источнику. Меньше AD = больше доверия.
/24 по RIP (AD 120) победит /16 по OSPF (AD 110), потому что сначала сравнивается префикс.
AD можно менять — например, чтобы плавно мигрировать с одного протокола на другой:
8. Динамическая маршрутизация — зачем
В сети из 3 роутеров статику ещё можно держать в голове. В сети из 300 — нет: при каждом изменении пришлось бы руками править десятки таблиц, а при падении линка сеть «легла» бы до прихода инженера. Протоколы динамической маршрутизации решают это: роутеры сами обмениваются информацией о сетях, считают лучшие пути и перестраиваются автоматически за секунды, когда топология меняется (это называется convergence — сходимость).
Статика
- Полный контроль и предсказуемость
- Ноль нагрузки на CPU/линк
- Нет рисков протокольных атак
- Не адаптируется к сбоям
- Не масштабируется
- Ошибки человека = чёрные дыры
Динамика
- Авто-перестройка при сбоях
- Масштабируется на тысячи сетей
- Балансировка по путям (ECMP)
- Сложнее, ест ресурсы
- Нужно понимать и дебажить
- Требует защиты (auth, фильтры)
IGP против EGP — главное деление
Все протоколы делятся на две категории по зоне ответственности:
- IGP (Interior Gateway Protocol) — работает внутри одной автономной системы (AS), то есть внутри сети одной организации. Цель — быстро найти лучший путь. Сюда: OSPF, IS-IS, EIGRP, RIP.
- EGP — работает между автономными системами, то есть в масштабе всего интернета. Здесь главное не «самый быстрый путь», а политика (с кем дружим, через кого пускаем трафик). Сегодня EGP ровно один — BGP.
9. RIP / EIGRP / OSPF / IS-IS / BGP — когда что
| Протокол | Тип | Как считает | Где сегодня |
|---|---|---|---|
| RIP | IGP, distance-vector | Хопы (макс 15) | Legacy. Учить для общего понимания, в проде почти нет. |
| EIGRP | IGP, advanced DV | Composite (BW+delay) | Только Cisco. Жив в чисто-Cisco-сетях. Быстрая сходимость. |
| OSPF ⭐ | IGP, link-state | Cost (по полосе) | Стандарт де-факто для enterprise. Открытый. Учи глубоко. |
| IS-IS | IGP, link-state | Cost (metric) | Операторы и крупные ДЦ. Похож на OSPF, лучше масштабируется. |
| BGP ⭐ | EGP, path-vector | Политики (атрибуты) | Клей интернета. И всё чаще — внутри ДЦ (EVPN). Учи глубоко. |
Distance-vector против link-state
Distance-vector (RIP, EIGRP) — «слухи от соседей»: роутер верит тому, что рассказали соседи, и не видит топологию целиком. Отсюда медленная сходимость и риск петель (борются split-horizon, poison reverse). Link-state (OSPF, IS-IS) — каждый роутер строит у себя полную карту сети и сам считает кратчайшие пути (алгоритм Дейкстры). Поэтому link-state сходится быстрее и устойчивее к петлям.
10. ECMP — несколько путей одновременно
Если до одной сети есть два равноценных пути (одинаковый AD и одинаковая метрика), роутер может использовать оба сразу — это Equal-Cost Multi-Path. Пропускная способность складывается, а при падении одного линка трафик мгновенно идёт по второму.
Как именно балансируется — per-flow, не per-packet
Важная деталь: трафик раскидывается по потокам (flow), а не по пакетам. Роутер берёт хеш от набора полей (src/dst IP, часто + src/dst port) и по нему выбирает путь. Все пакеты одного TCP-соединения идут одним путём — иначе они бы переставлялись (reordering), и TCP решил бы, что это потери.
ECMP — фундамент дизайна современных дата-центров (Spine-Leaf): десятки равноценных путей между уровнями,
трафик «размазан» по всем. Это та же идея, что и multipath в Linux (ip route ... nexthop ... nexthop ...).
11. Сценарий целиком: три роутера, статика + default
Соберём всё вместе. Топология: офис (R1) — ядро (R2) — выход в интернет (R3 → провайдер).
10.0.0.0/16 ← R2. Без него пакет ИЗ офиса
дошёл бы до провайдера, но ответ не нашёл бы дорогу назад к 10.0.1.5 — и «интернет не работает», хотя
наружу пакеты уходят. Маршрутизация всегда двусторонняя.
12. Packet walk: что происходит с пакетом по пути
Хост 10.0.1.5 открывает 1.1.1.1. Пошагово:
- Хост видит:
1.1.1.1не в моей /24 → шлю на default gateway 10.0.1.1 (R1). ARP узнаёт MAC R1. - R1: LPM → подходит только
0.0.0.0/0 via 10.0.12.2. Переписывает dst MAC на R2, src MAC на свой, TTL 64→63, шлёт. - R2: то же,
0.0.0.0/0 via 10.0.23.2→ R3. TTL 63→62. - R3:
0.0.0.0/0 via 203.0.113.2→ провайдер. Тут же срабатывает NAT (см. модуль 10): src 10.0.1.5 → публичный IP. - Ответ идёт обратно: провайдер → R3 → (по маршруту 10.0.0.0/16) R2 → (10.0.1.0/24) R1 → хост.
traceroute видишь, на каком хопе пропал ответ — это и есть точка, где «follow the path» приводит к проблеме.
13. Мост в DevOps: маршрутизация, которую ты увидишь каждый день
Когда ты перейдёшь в DevOps, протоколы вроде OSPF трогать будешь редко, но сама модель маршрутизации останется ровно той же — и понимание из этого модуля станет твоим преимуществом:
- Linux:
ip route— та же таблица, default gateway, next-hop, метрики. Каждый под в Kubernetes маршрутизируется по этим правилам. - Policy routing в Linux: несколько таблиц (
ip rule,ip route ... table 100) — это аналог PBR. Часто нужно для multi-homing и VPN. - Облако (AWS/GCP): «Route Tables» у VPC — это та же таблица с LPM.
0.0.0.0/0 → igw— это default route к интернет-шлюзу, буквально как к провайдеру. - Kubernetes: CNI (Calico, Cilium) раздаёт маршруты до подов; Calico умеет анонсировать их по BGP — да, тот самый BGP из модуля 7.
- Cilium/eBPF: заменяет часть классической маршрутизации программой в ядре — но решение «куда слать пакет» принимается по тем же принципам.
DevOps-инженер без сетей видит «route table» в AWS как магию. Ты будешь видеть знакомую таблицу маршрутизации с longest prefix match и default route. Это и есть разница в зарплате.
14. Команды для практики
Cisco
Linux (то же самое на сервере)
15. Вопросы с собеседования
0.0.0.0/0 — куда слать всё, что не подошло под более специфичные маршруты. Не сработает, если
стоит флаг ip routing отключён, или у самого default next-hop недостижим (рекурсия не разрешилась).16. Частые ошибки джунов
ip route X Y Gi0/1 на multi-access заставляет роутер
ARP-ить каждый адрес сети. На Ethernet указывай next-hop IP.
17. Плейбук: «соседние адреса ходят по-разному» — закрываем заявку #43890
Возвращаемся к загадке: 10.42.1.10 и .20 из филиала пингуются, 10.42.1.170 — нет. Сервер жив. Ходим по пути, как учит follow-the-path:
traceroute 10.42.1.10 и traceroute 10.42.1.170
из филиала. До .10: филиал → WAN-роутер ГО → core → сервер. До .170: путь обрывается
на core (или уходит в неожиданный хоп — например, на старый роутер тестовой зоны).
Виновник — последний отвечающий хоп: у него для .170 другое решение.show ip route 10.42.1.10 → отвечает «10.42.1.0/24 via core».
show ip route 10.42.1.170 → отвечает «10.42.1.160/27 via 10.99.0.2» —
вот он, longest prefix match в действии: для .170 нашёлся более специфичный /27,
указывающий на старый роутер лаборатории. Год назад блок .160–.191 отдавали под стенд,
статику забыли убрать. LPM всегда выигрывает — /27 бьёт /24 независимо от AD и метрик.tracert до филиала.
Помни главное правило: маршрутизация двусторонняя. Даже починив путь «туда»,
можно остаться без пути «обратно» (и симптом будет тот же). В нашем случае обратный путь
в порядке — пакеты филиала просто не доезжали.no ip route 10.42.1.160 255.255.255.224 10.99.0.2 на core —
и .170 мгновенно доступен. Но не останавливайся: поищи ещё артефакты стенда
(show run | include ip route), задокументируй в IPAM, что блок .160/27 вернулся
в прод. Финальная запись в заявке: «Причина — устаревший статический маршрут /27 на core,
перекрывавший часть серверной подсети по правилу LPM. Маршрут удалён, конфигурация
проаудирована».18. Мини-лаба: маршрутизация у тебя под рукой
route print -4, Linux: ip route.
Найди: default (0.0.0.0/0 через роутер), connected-сеть (твоя подсеть, без next-hop),
loopback 127.0.0.0/8. У ПК с Wi-Fi и проводом одновременно увидишь метрики:
Windows предпочтёт интерфейс с меньшей — вот и «AD и метрика» в миниатюре.route add 1.1.1.1 mask 255.255.255.255 192.168.1.1 — теперь до 1.1.1.1 у тебя
два маршрута: /32 и default /0. Пинг идёт? Смотри route print —
выиграл /32 (LPM!). Теперь укажи заведомо мёртвый next-hop:
route change 1.1.1.1 mask 255.255.255.255 192.168.1.253 — пинг умер, хотя
default жив. Ты только что воспроизвёл заявку #43890 на своём столе. Уборка:
route delete 1.1.1.1.tracert 8.8.8.8 / traceroute 8.8.8.8: первый хоп —
твой роутер, дальше — сеть провайдера (возможно, 100.64.x.x — CGNAT из прошлого урока),
потом магистраль. Каждый из этих хопов знает только «кому дальше» — никто не знает пути
целиком. Звёздочки в середине при живом конце — не обрыв, а хоп, которому запретили
отвечать на TTL-expired.ip route get 8.8.8.8 — ядро покажет готовое
решение: «8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.42». Это FIB-ответ: маршрут
уже разрешён рекурсивно до интерфейса и src-адреса. Сравни с ip route (RIB-вид) —
и разница RIB/FIB из раздела 4 станет осязаемой.19. Словарик урока
| Термин | По-английски | Смысл в одну строку |
|---|---|---|
| Таблица маршрутизации | routing table, RIB | список «префикс → куда дальше»; роутер выбирает лучшее из известного |
| Правило длиннейшего префикса | longest prefix match, LPM | из подходящих маршрутов побеждает самый специфичный; /27 бьёт /24 всегда |
| Следующий хоп | next-hop | адрес соседнего роутера, которому вручается пакет; полного пути не знает никто |
| RIB / FIB | routing / forwarding information base | RIB — «что лучшее» (control plane), FIB — «как пересылать» (data plane, CEF) |
| Маршрут по умолчанию | default route, 0.0.0.0/0 | куда слать всё, что не подошло точнее; обычно — к провайдеру |
| Статический маршрут | static route | прописан руками; надёжен, но не реагирует на аварии без tracking |
| Плавающая статика | floating static | статика с завышенной AD — резерв, просыпающийся при смерти динамики |
| Административная дистанция | administrative distance, AD | доверие к источнику маршрута: connected 0, static 1, eBGP 20, OSPF 110… |
| Метрика | metric | сравнение путей внутри одного протокола (после LPM и AD) |
| IGP / EGP | interior/exterior gateway protocol | внутри автономной системы (OSPF, IS-IS) / между ними (BGP) |
| Вектор расстояния / состояние каналов | distance-vector / link-state | верю соседям на слово / строю полную карту и считаю Дейкстрой |
| Равноценные пути | ECMP | несколько маршрутов с равной ценой; поток «прибит» к пути хешем |
| Рекурсивный поиск | recursive lookup | next-hop сам ищется по таблице, пока не найдётся интерфейс |
| Нулевой маршрут | null route / blackhole | трафик в никуда — защита от петель суммаризации и мусора |
| Иди по пути | follow the path | метод диагностики: traceroute → таблица каждого хопа → в обе стороны |
20. Задачи на понимание
Задача 1. В таблице: 10.0.0.0/8 via A (OSPF, AD 110), 10.1.0.0/16 via B (RIP, AD 120), 10.1.2.0/24 via C (static, AD 1). Куда уйдёт пакет на 10.1.2.55? А на 10.1.9.9? А на 10.9.9.9?
10.1.2.55 → C (самый длинный /24; AD даже не смотрим). 10.1.9.9 → B (лучшее совпадение — /16; то, что у OSPF AD ниже, неважно — его префикс короче). 10.9.9.9 → A (только /8 подходит). Порядок всегда: LPM → AD → метрика.
Задача 2. Прописал ip route 0.0.0.0 0.0.0.0 203.0.113.1, но default в таблице не появился. Линк к провайдеру физически выключен. Почему маршрута нет и как сделать резервный default через LTE-модем (192.168.8.1), который включится сам?
Статика попадает в таблицу, только если next-hop разрешим: интерфейс к 203.0.113.1
лежит → рекурсивный lookup не удался → маршрут снят. Резерв: ip route 0.0.0.0 0.0.0.0
192.168.8.1 250 — floating static с AD 250. Пока основной default жив,
резерв спит; умер линк — LTE-маршрут всплывает автоматически. (Для отказа, при котором линк
«горит», а провайдер мёртв, — добавь IP SLA tracking.)
Задача 3. «Пингую сервер за три хопа — тишина. Traceroute доходит до последнего роутера, дальше звёздочки. На последнем роутере show ip route — маршрут до сервера есть, интерфейс up». Что проверишь следующим и почему именно это?
Обратный маршрут: на сервере (или его шлюзе) — есть ли путь к источнику пинга? Прямой путь доказан (traceroute доехал), значит, умирает ответ. Классика: серверу забыли прописать default gateway или на его шлюзе нет маршрута в сеть филиала. Правило: «не пингуется» = проверь ОБА направления; половина «загадок» — забытый обратный маршрут.
Задача 4. Между двумя ДЦ четыре равноценных линка (ECMP). Один толстый бэкап-поток занимает 9 Гбит/с и забил один линк, остальные три пустые. Почему балансировка «не работает» и что с этим делать?
ECMP балансирует per-flow: хеш от (src, dst, порты) прибивает поток к одному пути — иначе пакеты одного TCP-потока приходили бы вразнобой. Один слоновий поток = один линк, хоть их четыре. Решения: параллелить сам перенос (несколько TCP-сессий — например, многопоточный rsync/BBCP), или менять хеш-политику (L4-порты уже учитываются?), или таскать бэкапы в окно незагрузки. Это же явление увидишь в LAG из модуля 3.
Задача 5. Зачем на роутере-агрегаторе, суммаризирующем 10.20.0.0/16 наружу, держат маршрут 10.20.0.0/16 → Null0? Что случится без него, если внутренняя подсеть 10.20.55.0/24 упадёт?
Без null-route: пакет на мёртвую 10.20.55.9 приходит агрегатору, специфичного маршрута нет, но есть default наружу → пакет уходит обратно в сторону интернета → а там маршрут на 10.20/16 снова указывает на агрегатора → петля до истечения TTL, умноженная на весь мусорный трафик. Null0 — «дно»: всё, что попало в суммарный префикс, но не нашло живой специфики, тихо умирает на месте. Стандарт при любой суммаризации.
Задача 6. В Linux-контейнере ip route показывает only default via 169.254.1.1 dev eth0, и всё работает. Но 169.254.x.x — link-local, «немаршрутизируемый». Как это возможно?
Next-hop не обязан быть «маршрутизируемым» — он должен быть достижим на L2 через указанный интерфейс (ARP-резолвится). CNI-плагины (Calico и др.) вешают 169.254.1.1 на хостовую сторону veth и отвечают на ARP — контейнеру этого достаточно: пакет вручается хосту, дальше рулит таблица хоста. Отличная иллюстрация «маршрут — это указание НА соседа, а не описание пути».
- Роутер пересылает пакет по адресу назначения, hop-by-hop. Полный путь не знает никто; TTL −1 на каждом хопе.
- Порядок выбора: longest prefix match → AD (между протоколами) → metric (внутри протокола).
- RIB (show ip route) решает «что лучшее», FIB (show ip cef) пересылает каждый пакет.
- Next-hop only требует рекурсивного lookup; на Ethernet всегда указывай next-hop IP.
- Статика: default к провайдеру, host /32, null-route, floating static (высокий AD), + tracking от чёрных дыр.
- AD — доверие: Connected 0, Static 1, eBGP 20, EIGRP 90, OSPF 110, IS-IS 115, RIP 120, iBGP 200, 255 = не верить.
- IGP (OSPF/IS-IS/EIGRP/RIP) — внутри AS; BGP (EGP) — между AS, по политикам.
- Link-state (OSPF/IS-IS) строит полную карту и считает Дейкстрой; distance-vector верит соседям.
- ECMP — несколько равноценных путей; балансировка per-flow (один TCP-поток = один путь).
- Маршрутизация всегда двусторонняя — обратный маршрут обязателен.
- В Linux и облаке — та же модель:
ip route, policy routing, VPC route tables, default gateway.
Статика хороша, пока роутеров три и линков пять. На двадцати роутерах каждая новая подсеть — это двадцать раз «зайди и пропиши», а каждая авария — ручная работа в три часа ночи. Пора отдать это машине: OSPF сам найдёт соседей, сам построит полную карту сети, сам посчитает кратчайшие пути алгоритмом Дейкстры и сам перестроится при обрыве — за секунды. Следующий модуль — как это работает под капотом: Hello-пакеты, LSA, области и цена интерфейса.