Динамическая маршрутизация простыми словами: OSPF, BGP и выбор пути

Зачем сети обмениваться маршрутами

Представим офис с сетью 10.10.0.0/24 и филиал с 10.20.0.0/24. Между ними есть основной и резервный пути. Чтобы пакет попал в филиал, каждый промежуточный маршрутизатор должен знать следующий шаг, а для ответа нужен обратный путь.

При изменении связи динамический протокол может обновить информацию и дать устройствам пересчитать подходящие маршруты. Доступность приложения дополнительно зависит от адресации, фильтров, NAT, VPN, DNS и самого сервера. Наличие записи в таблице не доказывает, что сотрудник сможет провести документ в 1С.

Статика и динамика: когда сложность оправдана

Для одного офиса с одним выходом динамический протокол может не дать заметной пользы. Для десятков сетей и нескольких путей ручное сопровождение становится трудным. Эти подходы совмещаются: например, динамика внутри сети и явно заданный маршрут по умолчанию на границе.

Протокол стоит вводить ради конкретной задачи, а не вместо документации. Без IP-плана, границ ответственности и доступа для восстановления автоматический обмен лишь быстрее распространит ошибку.

Префикс, next hop, RIB и FIB: что видит маршрутизатор

• Префикс: сеть назначения, например 10.20.0.0/24.
• Next hop: следующий узел на пути; это не обязательно конечный сервер.
• RIB: сведения о маршрутах и кандидатах, из которых выбирают подходящие.
• FIB: данные, используемые для фактического продвижения пакетов в данной реализации.

В обычной IP-маршрутизации более специфичный совпавший префикс имеет приоритет перед менее специфичным. Для адреса 10.20.0.10 запись 10.20.0.0/24 точнее, чем 10.0.0.0/8 и 0.0.0.0/0. Политическая маршрутизация и VRF меняют контекст выбора, поэтому учитывают таблицу, источник и правила.

Полученный маршрут может не стать активным: причиной бывают предпочтение другого источника, недостижимый next hop или фильтр. В FRR роль управления маршрутами и передачей их ядру описана в Zebra. Просмотр BGP-таблицы и таблицы пересылки — разные проверки.

IGP и BGP: внутренняя топология и политика между доменами

IGP — семейство протоколов для внутренней маршрутизации в административном домене: сюда относятся OSPF, IS-IS, RIP и EIGRP. У них разные модели, возможности и ограничения.

BGP связывают с обменом достижимостью между автономными системами и политикой. Но он используется и внутри одной AS как iBGP, в том числе в архитектурах ЦОД. Поэтому фраза «BGP только для интернета, OSPF только для офиса» слишком груба.

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

OSPF: карта связей и расчёт стоимости пути

OSPF — link-state IGP. Маршрутизаторы обмениваются сведениями о связях; в соответствующей области формируется база состояния, по которой рассчитываются пути. Стоимость пути складывается из метрик его участков в рамках правил протокола.

• Соседи и смежность: устройства должны согласовать необходимые параметры. Не любой видимый сосед обязан иметь Full на широковещательном сегменте: состояния зависят и от ролей DR/BDR.
• Области: помогают организовать масштабирование; между областями действуют отдельные правила.
• Cost: административно заданная или рассчитанная по настройкам величина. Это не автоматический замер текущей задержки приложения.
• Версии: OSPFv2 обычно рассматривают для IPv4, OSPFv3 — прежде всего для IPv6; поддержку семейств и расширений проверяют в реализации.

Основы приведены в RFC 2328 и FRR OSPFv2. Для диагностики полезно различать существование соседа, обмен базой, рассчитанный маршрут и фактическую передачу пакетов.

Пример OSPF: два участка дешевле одного

Условная схема: R1 связан с R2 со стоимостью 10, R2 с R3 — 10, а прямой R1–R3 имеет стоимость 50. Для сравнимых внутриобластных путей до одного назначения путь через R2 имеет сумму 20 и предпочтительнее прямого 50.

После потери связи R1–R2 и пересчёта может остаться прямой путь 50. Это не означает, что протокол стал хуже работать: изменился доступный набор. Пример предполагает корректный обмен, достижимость назначения и отсутствие других правил, которые меняют сравнение.

Цифры не обозначают миллисекунды и не описывают скорость каналов. В скачиваемом IP-плане сети соединений и LAN заданы отдельно. Это схема для обсуждения и будущего стенда, а не готовый конфиг, применённый к рабочим маршрутизаторам.

BGP: достижимость, атрибуты и политика

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

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

Базовый протокол описывает RFC 4271, реализацию — FRR BGP. Сессия Established ещё не подтверждает получение нужных маршрутов и их использование.

IS-IS: ещё один link-state IGP

IS-IS тоже строит представление о связях и рассчитывает пути. Он применяется, в частности, в крупных операторских и магистральных сетях. Его уровни L1/L2 не следует путать с уровнями модели OSI.

Для IP-маршрутизации используют соответствующие расширения и поддержку конкретной платформы. Выбор между IS-IS и OSPF зависит от архитектуры, операционной практики, функций и совместимости, а не от лозунга «один всегда быстрее».

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

RIP и EIGRP: разные distance-vector подходы

RIP можно встретить в существующих и учебных сетях; выбирать его для нового крупного проекта только ради простоты не стоит. EIGRP также нельзя объявить универсальной заменой OSPF без учёта платформ и команды сопровождения.

Смотрите RIPv2, RFC 2453 и описание EIGRP, RFC 7868. Второй документ имеет информационный статус и сам по себе не означает одинаковую поддержку всеми вендорами.

Метрика протокола и предпочтение источника — разные вещи

Стоимость OSPF нельзя напрямую сравнить с длиной AS_PATH или числом переходов RIP как с одной общей единицей. Внутри протокола действуют его правила; между источниками одного префикса платформа применяет своё предпочтение, часто называемое administrative distance или route preference.

Затем при пересылке конкретного пакета важны совпавший префикс и выбранный контекст. Например, более специфичная /24 не становится менее специфичной из-за того, что default route получен от «предпочтительного» источника.

Проверяйте реальные значения и порядок выбора на своей платформе. Переносить таблицу административных предпочтений одного вендора на другого без сверки нельзя.

Сходимость: обнаружить, сообщить, пересчитать, установить

Между физическим отказом и новым рабочим путём есть несколько этапов. Обрыв интерфейса, недоступность соседства и проблема дальше по сети обнаруживаются по-разному. После обнаружения нужны обмен сведениями, расчёт и обновление пересылки.

BFD может ускорять обнаружение проблем пути в поддерживаемой схеме, но не является заменой протокола маршрутизации и не проверяет проведение документа в приложении. Слишком агрессивные интервалы при перегрузке способны давать нестабильность. Назначение описано в FRR BFD.

Измеряйте фактические потери, время восстановления и поведение сессии. Нельзя обещать фиксированное число миллисекунд только по названию OSPF или BGP. Сохранившаяся таблица маршрутов также не гарантирует, что обратный путь и межсетевой экран готовы к новой схеме.

Петли, перераспределение и лишние объявления

Маршруты могут образовать нежелательную обратную связь при ошибочном redistribution между протоколами или доменами. Защита от петель внутри одного механизма не делает любую комбинацию политик безопасной.

• Явно определяют, какие префиксы можно принять и объявить, включая default route.
• Для redistribution задают направление, фильтры, метрики и при необходимости маркировку маршрутов.
• Проверяют суммаризацию: агрегат не должен создавать иллюзию достижимости отсутствующих сетей без продуманного поведения.
• Учитывают пересекающиеся подсети филиалов и область VRF; одинаковые адреса не исправляются обменом маршрутами.

В BGP особенно важны фильтры префиксов и ограничения приёма. Практики защиты описывает RFC 7454. Разрешить соседу объявлять всё — не нейтральная начальная настройка.

Маршрутизация не заменяет firewall, VPN и контроль доступа

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

• Разрешают протокол и соседства только на предусмотренных интерфейсах и адресах.
• Используют поддерживаемые механизмы защиты соседства и управляющей плоскости.
• Не формируют соседства с пользовательскими LAN без задачи; режим passive выбирают по проекту.
• Ограничивают доступ к управлению и фиксируют изменения политик.

OSPF использует IP-протокол 89, а не «TCP-порт 89». BGP обычно использует TCP 179. Эти сведения помогают проверить фильтры, но не являются готовой политикой безопасности для любой сети.

ECMP и резервный путь: не то же самое, что round robin

Если протокол и платформа допускают несколько равнозначных путей, возможно ECMP. Распределение часто выполняется по потоку с использованием хеша, а не строгим чередованием каждого пакета. Алгоритм и условия зависят от реализации.

Несколько путей не означают, что одно TCP-соединение автоматически получит сумму скоростей каналов. Изменение набора путей может повлиять на потоки. При stateful firewall и NAT учитывают асимметрию, состояние и адреса.

Если запасной путь дороже, он может ждать отказа основного вместо одновременного распределения. Круговой выбор получателей отдельно разобран в статье round robin; переносить его картинку на любую маршрутизацию нельзя.

Офис, филиалы, ЦОД и провайдер: разные задачи

Команды диагностики: от адреса до приложения

Ниже — диагностика, а не включение протокола. Используйте команды в своём согласованном контуре; 10.20.0.10 и 10.20.0.0/24 относятся к нашему условному IP-плану. Требуются установленные инструменты и права просмотра. Вывод и доступность отдельных полей зависят от версии.

Linux: что реально выберет хост

ip -br address
ip route show
ip route get 10.20.0.10
ip rule show

ip -br address показывает адреса, ip route show — маршруты, ip route get — результат поиска для назначения, ip rule show — правила выбора таблиц. Результат поиска сам по себе не является проверкой передачи пакетов. Семантика описана в ip-route.

FRR: соседи OSPF и полученные маршруты

vtysh -c 'show ip ospf neighbor'
vtysh -c 'show ip ospf route'
vtysh -c 'show ip route 10.20.0.0/24'

Проверяйте ожидаемых соседей и рассчитанные пути, затем наличие выбранного маршрута в общей таблице. Увидеть соседство недостаточно; Full также не является обязательным состоянием для каждой пары на любом типе сегмента.

FRR: сессия и конкретный префикс BGP

vtysh -c 'show bgp ipv4 unicast summary'
vtysh -c 'show bgp ipv4 unicast 10.20.0.0/24'

Сводка показывает состояние соседств и счётчики, просмотр префикса — сведения о полученных путях. Дальше проверяют фильтры, предпочтение, next hop и установку в пересылку. Не выполняйте сброс соседства ради диагностики без понимания последствий.

MikroTik RouterOS 7

/routing/ospf/neighbor/print detail
/routing/bgp/session/print detail
/ip/route/print detail where dst-address="10.20.0.0/24"

Команды показывают соседей OSPF, BGP-сессии и интересующий маршрут. Синтаксис и свойства сверяют с веткой RouterOS: OSPF и BGP. Не переносите конфигурационные команды между RouterOS 6 и 7 без проверки.

Windows: маршрут и TCP-доступ

Get-NetRoute -AddressFamily IPv4
Test-NetConnection -ComputerName 10.20.0.10 -Port 443 -InformationLevel Detailed

Первый вывод показывает маршруты IPv4, второй проверяет TCP-порт выбранного сервиса. Test-NetConnection не подтверждает прикладную авторизацию или корректность документа. Пакеты к адресу и сервису отправляйте только там, где такая проверка согласована.

Как принять работу и проверить переключение

1. Сохранить IP-план, ожидаемые соседства, объявления, фильтры и рабочий путь.
2. Проверить маршрут туда и обратно, firewall/NAT/VPN и реальную операцию пользователя.
3. В согласованном окне смоделировать конкретный отказ: интерфейс, соседство, удалённый участок или весь узел.
4. Зафиксировать время обнаружения, изменение маршрутов, потери, ошибки и нагрузку оставшегося пути.
5. Вернуть связь и проверить устойчивость возврата, отсутствие петель и лишних объявлений.
6. Обновить мониторинг, контакты и план восстановления доступа.

Не начинайте с отключения рабочего uplink по удалённой сессии без альтернативного управления и возврата. Реальные результаты сохраняют отдельно от нарисованной схемы: в этой статье показана модель, а не протокол испытания оборудования.

IP-план примера и карточка проверки

Поможем спроектировать и сопровождать сеть

Вопросы и ответы