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

Для внутренней сети предприятия базовый выбор такой: OSPF там, где оборудование разное, EIGRP там, где вся сеть построена на Cisco. Для стыковки с провайдерами и партнёрскими автономными системами (AS) стандарт один: BGP. Три протокола решают разные задачи, и попытка заменить один другим на том же месте обычно даёт либо лишнюю нагрузку на оборудование, либо пропавшие маршруты.

OSPF собирает карту сети в LSDB и считает кратчайшие пути по алгоритму Дейкстры (SPF). BGP работает как path-vector между автономными системами и оперирует атрибутами пути. EIGRP с алгоритмом DUAL заранее держит резервные маршруты и переключается на них без полного пересчёта. Ниже: метрики каждого протокола, скорость сходимости, требования к CPU и памяти, таблица сравнения и логика выбора под конкретную топологию.

Команды и схемы в статье опираются на устоявшуюся практику эксплуатации сетей и внутренние руководства базы знаний admin-wiki. Реализации протоколов у вендоров расходятся в деталях, поэтому изменения в продакшене проверяйте на стенде: часть параметров по умолчанию отличается даже между версиями прошивок одного производителя.

Зачем нужна динамическая маршрутизация и когда она оправдана

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

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

• в сети больше 3-5 маршрутизаторов или L3-коммутаторов, и наборы статических маршрутов на них перестали совпадать;
• есть резервные каналы и нужен автоматический переход на них за секунды, а не за время реакции дежурного;
• требуется распределение трафика по нескольким равнозначным путям (ECMP);
• сеть мультивендорная или растёт за счёт новых площадок;
• филиалы связаны через VPN-туннели, и адресация меняется чаще, чем хотелось бы.

В малой сети до трёх устройств с единственным выходом в интернет статические маршруты и default route проще и надёжнее: нет таймеров, нет соседства, нечему рассыпаться. Динамический протокол добавляет постоянный фоновый обмен служебными пакетами, расход CPU на пересчёт маршрутов и память под базы данных протокола. Для двух-трёх устройств это чистые накладные расходы без выигрыша.

Обратная сторона статики проявляется при росте: каждая новая подсеть требует правки на всех транзитных узлах, а ошибка в одном маршруте даёт петлю или чёрную дыру. Порог, после которого ручное сопровождение становится дороже, обычно наступает на 5-7 устройствах с двумя и более путями между сегментами.

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

OSPF: принципы работы, метрики и области применения

OSPF (Open Shortest Path First) относится к link-state протоколам: каждый маршрутизатор рассылает hello-пакеты, обменивается объявлениями о состоянии каналов (LSA), собирает из них базу LSDB и получает карту топологии, одинаковую у всех соседей внутри одной области. Маршруты считаются по алгоритму Дейкстры, а не по слухам от соседей, поэтому петель в штатной работе не возникает.

Ключевые сущности: области (area), где area 0 объявлена магистральной и все остальные области подключаются к ней; типы LSA от первого (router) до пятого (external), которые описывают маршрутизаторы, сети, сводные префиксы и внешние маршруты; hello-пакеты, поддерживающие соседство. Метрика одна: cost, обратно пропорциональная пропускной способности интерфейса. Административная дистанция OSPF по умолчанию 110.

Протокол поддерживают практически все вендоры и открытые реализации, включая FRR и Quagga, поэтому OSPF выбирают для мультивендорной корпоративной сети, дата-центра и любой среды, где оборудование закупается у разных поставщиков. Нагрузка на CPU и память растёт с числом маршрутов и соседей: домен из сотен маршрутизаторов в одной области перегружает пересчёт SPF, поэтому топологию делят на области.

Как OSPF строит таблицу маршрутизации: от hello до SPF

1. Маршрутизатор рассылает hello-пакеты на multicast-адреса 224.0.0.5 и 224.0.0.6 (протокол IP 89) и слушает их на интерфейсах, где OSPF включён.
2. Параметры в hello должны совпасть: area ID, тип сети, hello/dead таймеры, аутентификация. При совпадении соседи доходят до состояния 2-Way, а в широковещательных сегментах выбирают DR и BDR.
3. Дальше идёт обмен: состояния ExStart, Exchange, Loading. Соседи передают друг другу LSA и синхронизируют LSDB. Соседство становится Full, когда базы совпали.
4. Каждый маршрутизатор запускает SPF по своей LSDB и выбирает путь с минимальной суммой cost по всем транзитным интерфейсам.

При изменении топологии пересчитывается не вся карта: запускается частичный SPF, затрагивающий только изменившуюся ветку. Пример: до сети 10.10.20.0/24 ведут два пути, через интерфейсы с cost 1 и cost 10. В таблицу попадает маршрут с cost 1, второй хранится как резервный вариант расчёта и используется после пересчёта.

Если соседство не поднимается, проверяйте по порядку: MTU на интерфейсах (при расхождении сосед застревает в ExStart), номер области, hello/dead таймеры, тип сети (broadcast против point-to-point) и параметры аутентификации. Отдельная частая причина: интерфейс попал в режим passive там, где сосед нужен.

Метрики и настройка стоимости в OSPF

Cost считается как reference bandwidth, делённая на пропускную способность интерфейса. По умолчанию reference bandwidth равен 100 Мбит/с, поэтому на гигабитном и десятигигабитном интерфейсах cost получается одинаковым и равным 1: протокол перестаёт различать эти каналы и может направить трафик в узкое место.

Два способа исправить это:

• задать reference bandwidth глобально командой auto-cost reference-bandwidth (например, 10000 для сети с 10G-каналами);
• выставить cost вручную на конкретном интерфейсе командой ip ospf cost.

Пример: путь через 1 Гбит/с получает cost 1, путь через 100 Мбит/с получает cost 10 при стандартном reference bandwidth. Суммарный cost маршрута складывается по всем интерфейсам на пути, поэтому длинный маршрут с быстрыми каналами может проиграть короткому с медленными. Ручное значение cost полезно на границе с внешними сетями, когда нужно продавить трафик в конкретный канал.

Типичные ошибки в этой части: reference bandwidth оставили по умолчанию при парке из 10G-интерфейсов; cost выставили на одном конце канала и забыли про второй; изменили reference bandwidth только на части устройств, из-за чего трафик пошёл асимметрично.

BGP: принципы работы, метрики и области применения

BGP (Border Gateway Protocol) работает как path-vector между автономными системами. Сессии устанавливаются по TCP-порту 179, что даёт надёжную доставку обновлений и возможность держать соседство через несколько транзитных устройств. Вместо одной метрики протокол оперирует набором атрибутов пути, а таблица маршрутов измеряется сотнями тысяч префиксов.

Сходимость BGP заметно медленнее, чем у OSPF и EIGRP: сказываются таймеры, политика фильтрации и объём таблицы. Зато масштабируемость глобальная, именно поэтому BGP связывает провайдеров и наполняет таблицу маршрутизации интернета. Типовые сценарии: стыковка с провайдерами через eBGP, мультихоминг с двумя и более аплинками, распространение маршрутов внутри дата-центра и между площадками через iBGP. Как протоколы уживаются в одной сети и обеспечивают отказоустойчивость, описано в руководстве BGP и OSPF: совместная работа и отказоустойчивость.

Внутри маленькой офисной сети BGP избыточен: он требует политики, фильтрации и понимания атрибутов, а выигрыша перед OSPF или EIGRP не даёт. Его место там, где есть автономная система, свои префиксы для анонса и несколько внешних партнёров.

eBGP и iBGP: в чём разница и когда что применять

eBGP работает между разными автономными системами: связь с провайдером, партнёром, второй площадкой компании с собственным AS. По умолчанию пакеты eBGP отправляются с TTL 1, то есть сосед должен быть прямо подключён. Административная дистанция eBGP равна 20, поэтому его маршруты выигрывают у внутренних протоколов.

iBGP работает внутри одной AS. Логика распространения требует, чтобы каждый маршрутизатор получал маршрут напрямую от соседа, поэтому нужен либо полный mesh сессий, либо route reflector, который перераспределяет маршруты между клиентами. next-hop по умолчанию не меняется: маршрутизатор внутри AS может получить маршрут с недостижимым next-hop и отбросить его, поэтому на границе настраивают next-hop-self. Административная дистанция iBGP равна 200.

Пример: у компании два провайдера, с каждым поднят eBGP, наружу анонсируется своя сеть /24, внутрь принимаются маршруты или default route. Внутри дата-центра iBGP на граничных и внутренних маршрутизаторах распространяет внешние префиксы до серверных сегментов.

Атрибуты BGP и управление трафиком

Порядок сравнения маршрутов в BGP идёт от локальных атрибутов к глобальным:

1. weight: локальный атрибут, выше значение приоритетнее, действует только в пределах одного устройства;
2. local preference: передаётся внутри AS, большее значение выигрывает, влияет на исходящий трафик;
3. локально заданный маршрут против полученного по BGP;
4. короткий AS-path: меньше номеров AS в пути, тем предпочтительнее маршрут;
5. origin: IGP лучше EGP, EGP лучше incomplete;
6. MED: влияет на входящий трафик соседней AS, по умолчанию сравнивается только для маршрутов от одного соседа;
7. предпочтение eBGP перед iBGP и выбор по меньшему IGP-метрику до next-hop.

Практический пример: чтобы исходящий трафик уходил через провайдера A, для его маршрутов поднимают local preference до 200, оставляя у маршрутов провайдера B значение 100. Обратная задача, повлиять на входящий трафик, решается удлинением AS-path или атрибутом MED, но итоговое решение остаётся за провайдером.

Без фильтрации BGP опасен. Обязательный минимум: prefix-list на анонсы наружу, лимит принятых префиксов с соседа (maximum-prefix), отказ от перераспределения внутренних маршрутов без route-map. Ошибка в анонсах приводит к блокировке со стороны провайдера или к тому, что чужая AS начнёт слать трафик через вашу сеть. Асимметричная маршрутизация после неаккуратной настройки local preference перегружает один канал и ломает проверки на файрволах.

EIGRP: принципы работы, метрики и области применения

EIGRP относят к advanced distance-vector протоколам: он распространяет вектор расстояний, но хранит данные о топологии и умеет быстро подставлять резервный маршрут. Разработан Cisco и на оборудовании других вендоров либо отсутствует, либо работает с ограничениями. Пакеты идут по протоколу IP 88 на multicast-адрес 224.0.0.10. Административная дистанция 90 для внутренних маршрутов и 170 для внешних.

Метрика композитная: по умолчанию учитываются пропускная способность и суммарная задержка, а коэффициенты K2, K4 и K5 выключены. Протокол поддерживает неравноценную балансировку через множитель variance и фильтрацию анонсов на stub-маршрутизаторах. Типовые сценарии: сеть целиком на Cisco, филиалы, концентраторы VPN, где важна быстрая реакция на обрыв туннеля. Практические конфигурации, включая stub, суммирование и аутентификацию, собраны в гайде EIGRP: алгоритм DUAL, настройка и оптимизация.

Алгоритм DUAL и концепция feasible successor

DUAL (Diffusing Update Algorithm) держит для каждой сети два типа маршрутов. Successor, это лучший маршрут с минимальной метрикой, он попадает в таблицу маршрутизации. Feasible successor, это резервный маршрут, который удовлетворяет условию допустимости: его заявленное расстояние меньше текущего расстояния до сети, измеренного от основного маршрута. Если условие выполняется, сосед гарантированно не находится в петле через нас.

При обрыве основного маршрута feasible successor встаёт в таблицу сразу, без запросов к соседям. Если допустимого резерва нет, маршрут переходит в активное состояние: маршрутизатор рассылает запросы, ждёт ответы и только потом пересчитывает путь. В этот промежуток трафик до сети не доставляется. Пример: два пути до 10.20.0.0/16 с метриками 25600 и 51200; первый становится successor, второй остаётся feasible successor и включается в работу при падении основного канала.

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

Метрики EIGRP и настройка K-значений

Формула метрики по умолчанию выглядит так: (10^7 / минимальная полоса пропускания на пути + суммарная задержка) * 256. Полоса берётся в килобитах, задержка суммируется по всем интерфейсам пути в единицах, которыми оперирует конфигурация интерфейса. Компоненты load и reliability в расчёт не входят, пока не изменены K-значения.

Значения по умолчанию: K1=1, K3=1, K2=K4=K5=0. Если на двух соседях наборы K-значений различаются, соседство не поднимется, и в логах появится сообщение о несовпадении параметров. Изменение K-значений требует перезапуска процесса EIGRP, а в распределённой сети это означает кратковременный разрыв соседства на всех устройствах, где меняются параметры. Меняйте их одновременно по всей площадке в окно обслуживания.

Для распределения трафика по неравноценным путям используют variance: множитель задаёт, во сколько раз метрика резервного маршрута может отличаться от лучшего. Условие допустимости при этом всё равно проверяется, поэтому в балансировку попадут только корректные пути.

Сравнение OSPF, BGP и EIGRP: таблица и ключевые различия

Сводка по параметрам, которые чаще всего решают выбор:

Различия в нагрузке на оборудование связаны с объёмом хранимых данных. OSPF держит LSDB и дерево SPF, расход растёт с числом узлов и маршрутов в области. BGP хранит варианты путей и атрибуты для каждого префикса, поэтому требует заметно больше памяти и чувствителен к числу сессий. EIGRP держит таблицу топологии с successor и feasible successor, а при активном состоянии маршрута нагрузка кратковременно подскакивает на рассылке запросов.

Развёрнутое сравнение протоколов с разбором RIP, OSPF, EIGRP и BGP по метрикам и сходимости собрано в руководстве практическое сравнение протоколов динамической маршрутизации. Ориентироваться только на таблицу при выборе нельзя: две сети с одинаковым числом маршрутизаторов могут требовать разных протоколов из-за парка оборудования и требований к сходимости.

Как выбрать протокол под задачу: сценарии и логика решения

Порядок решения укладывается в пять шагов:

1. Посчитайте масштаб: число маршрутизаторов и L3-коммутаторов, количество подсетей, ожидаемый рост на год вперёд.
2. Проверьте парк оборудования: один вендор или несколько, поддерживаются ли нужные протоколы на всём парке, включая филиальные устройства.
3. Определите требования к сходимости: сколько секунд простоя допустимо при обрыве магистрали.
4. Оцените внешние стыки: есть ли подключения к провайдерам, партнёрским сетям, облачным провайдерам.
5. Сверьте ресурсы: свободная память и CPU на граничных устройствах, размер таблиц, наличие лицензий.

Дальше сценарии выглядят так. Малый офис до 5 устройств с одним выходом: статика и default route. Средний офис или кампус на Cisco: EIGRP либо OSPF. Дата-центр с оборудованием разных вендоров: OSPF внутри, BGP на границе. Мультихоминг с двумя провайдерами: eBGP наружу, iBGP или OSPF внутрь. Филиальная сеть через VPN: OSPF или EIGRP на концентраторе со stub-профилем на филиалах.

Внутренняя сеть предприятия: OSPF или EIGRP?

OSPF выбирают, когда оборудование разное или появится не сейчас, а через год: протокол открытый, его понимают все вендоры и open-source решения вроде FRR. Плата за универсальность: более длинная настройка, необходимость следить за областями и типами LSA, чуть более медленная реакция на обрыв по сравнению с EIGRP.

EIGRP выбирают в среде, где всё оборудование Cisco и важна предсказуемая быстрая сходимость: конфигурация короче, резервные маршруты встают в работу мгновенно. Плата: привязка к вендору. Переход с EIGRP на OSPF в такой сети делают через перераспределение маршрутов, а не одномоментной заменой протокола. Прямой совместимости между ними нет: без redistribute они просто не увидят маршруты друг друга.

Стыковка с провайдерами: почему здесь только BGP

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

Пример схемы: компания с двумя провайдерами поднимает eBGP с каждым, анонсирует свой блок /24 и принимает либо default route, либо полную таблицу. Выбор между двумя вариантами приёма зависит от памяти устройства. Полная таблица даёт лучший выбор пути, но требует ресурсов, default route вдвое упрощает маршрутизацию, зато весь трафик уходит в один аплинк при отсутствии второго маршрута.

Ошибки на этом этапе стоят дорого: анонс лишних префиксов без prefix-list приводит к блокировке со стороны провайдера, а отсутствие лимита maximum-prefix позволяет случайной утечке чужой таблицы занять всю память и уронить сессию.

Типичные ошибки при настройке и как их избежать

• OSPF: несовпадение hello/dead таймеров, разные area ID, разные типы сети и MTU на двух концах линка. Проверяйте состояние соседства после каждого изменения интерфейса.
• OSPF: разные маски на интерфейсах одной подсети или интерфейс в passive там, где нужен сосед. Симптом: соседство то появляется, то пропадает.
• OSPF: reference bandwidth по умолчанию в сети с 10G-каналами. Трафик идёт не по самому быстрому пути, а по первому с минимальным cost.
• BGP: отсутствие фильтрации анонсов и приёма. Как минимум prefix-list наружу, лимит префиксов внутрь, запрет перераспределения без route-map.
• BGP: неверный номер AS у соседа или перепутанный remote-as при настройке iBGP. Внутренние сессии строят по номеру своей AS, внешние по номеру партнёра.
• BGP: петли и недостижимый next-hop внутри AS при iBGP без route reflector и без next-hop-self на границе.
• EIGRP: несовпадение K-значений или номера AS. Соседство не поднимается, в логах видны сообщения о несовпадении параметров.
• Любой протокол: взаимное перераспределение без фильтров на двух точках сразу, что даёт петлю маршрутов и рост таблицы.

Общие правила профилактики: аутентификация на всех соседствах, passive interface на всех интерфейсах без соседей, лимиты на число принятых маршрутов, резервная копия конфигурации перед правками и схема сети с указанием адресов, областей и номеров AS.

Проверка и диагностика: команды и подходы

Набор команд для быстрой проверки по каждому протоколу:

• OSPF: show ip ospf neighbor показывает состояния соседей, норма это Full; show ip ospf database выводит содержимое LSDB по типам LSA; show ip route ospf фильтрует таблицу маршрутизации по маршрутам протокола.
• BGP: show ip bgp summary даёт состояния сессий (Idle, Active, Established), счётчики принятых и отправленных префиксов и возраст последнего сброса; show ip bgp выводит таблицу с атрибутами; show ip bgp neighbors показывает детали конкретной сессии.
• EIGRP: show ip eigrp neighbors выводит список соседей с состоянием UP, временем работы и счётчиком очереди; show ip eigrp topology показывает successor и feasible successor; show ip route eigrp фильтрует маршруты протокола.

Как читать вывод. Состояние OSPF ExStart или Exchange держится дольше пары секунд: ищите расхождение MTU и параметров аутентификации. Сессия BGP застряла в Active: нет IP-связности с соседом или закрыт TCP-порт 179. Счётчик префиксов упал до нуля при Established: сосед применил фильтр или у вас лимит maximum-prefix. Ненулевой Q Cnt у соседа EIGRP говорит о перегрузке канала или нехватке ресурсов на устройстве.

Проверка пути идёт привычными средствами: ping до next-hop, traceroute до удалённой сети, просмотр полной таблицы маршрутизации. Команды debug выдают детальный поток событий, но на загруженном устройстве они поднимают загрузку CPU и могут уронить сессию. Включайте их точечно, с таймаутом и на одном устройстве, а на граничных маршрутизаторах предпочитайте логирование и счётчики ошибок.

Взаимодействие протоколов и перераспределение маршрутов

Перераспределение (redistribute) передаёт маршруты одного протокола в другой. На выбор маршрута при этом влияет административная дистанция: connected 0, статика 1, eBGP 20, EIGRP внутренний 90, OSPF 110, RIP 120, EIGRP внешний 170, iBGP 200. Меньшее значение означает приоритет, поэтому внешние маршруты eBGP всегда выигрывают у внутренних протоколов.

Типовой сценарий: на границе OSPF и BGP внешние маршруты передаются внутрь через redistribute bgp в OSPF под route-map. Фильтр пропускает только нужные префиксы, а весь остальной трафик уходит по default route. Обратное перераспределение OSPF в BGP делают только для собственных сетей и с явным prefix-list.

Опасности: взаимное перераспределение на двух устройствах сразу создаёт петлю и раздувает таблицу; перераспределение без фильтра может вылить полную внешнюю таблицу во внутренний протокол и уронить его по памяти. Защита, которую стоит настроить сразу: route-map с явным deny по умолчанию, метка (tag) на перераспределённых маршрутах с отказом принимать их обратно, лимиты на число маршрутов. Логику взаимодействия протоколов и разбор таблиц на реальных схемах удобно держать под рукой в руководстве маршрутизация данных в сети: работа маршрутизатора, OSPF и BGP.

Требования к оборудованию и лицензиям

OSPF поддерживают практически все платформы, включая программные реализации FRR и Quagga на серверах под Linux. Требования к ресурсам умеренные и зависят от числа соседей, размера LSDB и частоты изменений топологии.

BGP требователен к памяти и CPU. Полная таблица маршрутизации интернета измеряется сотнями тысяч префиксов, и для нескольких сессий с полным приёмом нужен запас RAM, а маршруты должны поместиться в FIB на уровне таблицы коммутации (TCAM) в аппаратных платформах. На бюджетных устройствах полная таблица может не поддерживаться, и тогда выбор один: принимать default route вместо полного набора префиксов.

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

Лицензии стоит проверять до закупки: на части платформ BGP и расширенные функции маршрутизации закрыты отдельной лицензией или пакетом, а EIGRP в некоторых линейках проходит как отдельная опция. Сверьте матрицу лицензий и версию прошивки с планами по протоколам: обновление парка ради поддержки BGP дешевле спланировать заранее, чем менять схему маршрутизации после закупки.