Что такое OSPF: соседи, области и настройка маршрутизации

OSPF: какую задачу решает протокол

OSPF — внутренний протокол динамической маршрутизации. Он помогает маршрутизаторам узнавать топологию и выбирать пути к сетям без отдельной статической записи на каждом узле. Это полезно, когда офис, филиал и серверная связаны несколькими каналами и изменения нужно распространять согласованно.

• Филиалы: появились новые подсети — нужно объявить их другим площадкам.
• Два пути: при отказе основной связи нужен пригодный резерв.
• Рост сети: стоимость ручного сопровождения статических маршрутов становится заметной.

Для двух устройств с единственным каналом статика может быть проще. OSPF не создаёт резервный кабель, не заменяет firewall и не делает приложение отказоустойчивым. Внешнюю политику обмена с автономными системами обычно рассматривают отдельно, например через BGP. Общая картина — в обзоре динамической маршрутизации.

От соседства до передачи пакета

Каждый узел строит представление о связях своей области и рассчитывает дерево кратчайших путей. Полученный маршрут ещё сравнивается с другими источниками и устанавливается в таблицы платформы. Поэтому «сосед зелёный» и «сервер доступен» — разные утверждения.

В FRR процесс ospfd работает с OSPF, а zebra связывает протоколы с маршрутизацией Linux. Сам Linux должен разрешать IPv4 forwarding. Эта статья посвящена OSPFv2 для IPv4; параметры OSPFv3 и IPv6 нельзя механически переносить из примера.

Учебная сеть: офис, транзит и филиал

Возьмём три Linux-маршрутизатора с FRR 10.4. Все транзиты находятся в area 0.0.0.0. На каждом соединении ровно два устройства, поэтому явно задаём point-to-point. Управление вынесено в отдельный интерфейс: во время проверки отказа оно не должно зависеть от отключаемой связи.

Это проект лабораторной настройки, сверенный с документацией FRR ветки 10.4 на 13 ноября 2026 года. Сборка FRR, конфигурационный парсер и реальные соседства при подготовке не запускались; вывод ниже описывает ожидаемый результат, а не замер выполненного стенда.

IP-план и имена интерфейсов

• R1 ↔ R2: r12 — 10.255.12.1/30, r21 — 10.255.12.2/30; cost 10 в обе стороны.
• R2 ↔ R3: r23 — 10.255.23.1/30, r32 — 10.255.23.2/30; cost 10.
• R1 ↔ R3: r13 — 10.255.13.1/30, r31 — 10.255.13.2/30; cost 50.
• LAN офиса: R1 lan0 — 10.10.0.1/24. LAN филиала: R3 lan0 — 10.20.0.1/24.
• Loopback: 10.255.0.1/32, .2/32 и .3/32; такие же значения назначены router-id.

r12 и остальные имена — условные имена уже существующих интерфейсов. В виртуальной среде каждый транзит должен быть отдельным L2-сегментом. Подключить все NIC к одному общему bridge — значит построить другую топологию. Не включайте эти сети в рабочую инфраструктуру без проверки пересечений адресов.

Router ID — идентификатор процесса OSPF, а не адрес шлюза клиента. Он должен быть уникальным; явное назначение делает поведение понятнее после перезагрузки или добавления NIC.

Что проверить до включения OSPF

ip -br address
ip -br link
ip route show
sysctl net.ipv4.ip_forward
sudo vtysh -c 'show version'
systemctl status frr --no-pager

• ip -br address показывает адреса и имена NIC: сопоставьте их с IP-планом.
• ip -br link показывает состояние линка и MTU. Поднятый интерфейс не доказывает доступность удалённого узла.
• ip route show фиксирует исходные маршруты, включая default и записи от других служб.
• sysctl читает разрешение пересылки IPv4; для маршрутизатора нужно значение 1.
• show version определяет фактическую версию FRR; состояние systemd помогает понять, запущен ли пакет.

Сохраните конфигурацию сети, FRR, firewall и способ возврата. Нужны консоль или другой канал управления. Пример предполагает установленный FRR 10.4; установку пакета и репозитория выбирают по конкретному дистрибутиву, а не смешивают инструкции разных ОС.

Адреса Linux: пример для R1

ip address add 10.255.12.1/30 dev r12
ip link set dev r12 up
ip address add 10.255.13.1/30 dev r13
ip link set dev r13 up
ip address add 10.10.0.1/24 dev lan0
ip link set dev lan0 up
ip address add 10.255.0.1/32 dev lo
ip link set dev lo up
sysctl -w net.ipv4.ip_forward=1

Каждая команда ip address add добавляет указанный адрес на существующий интерфейс, а ip link set … up административно включает его. Loopback даёт стабильный адрес узла. sysctl -w включает пересылку пакетов между интерфейсами. Это изменения текущего состояния; после перезагрузки их нужно восстановить постоянной конфигурацией сетевой службы.

Команды R2 и R3 находятся в ZIP. Они не создают интерфейсы и не проверяют их подключение. Повторный add для существующего адреса даст ошибку: сначала смотрите фактическое состояние, не очищайте адреса вслепую. На рабочем сервере менеджер сети может перезаписать ручные настройки. Сохранение IP-адресов и сохранение FRR — отдельные операции.

Запуск ospfd и вход в консоль FRR

sudoedit /etc/frr/daemons
# В файле пакета включить: zebra=yes, ospfd=yes, vtysh_enable=yes
sudo systemctl restart frr
sudo vtysh
configure terminal

sudoedit открывает файл управления демонами. Проверьте наличие параметров и формат установленного пакета; не заменяйте весь файл тремя строками. Перезапуск FRR применяет состав включённых процессов и может затронуть другие протоколы. Выполняйте его на выделенном стенде или в согласованном окне.

vtysh открывает общую консоль, а configure terminal переводит её в режим настройки. Дальнейшие блоки — команды FRR, не Bash. Вводите их частями и проверяйте сообщения об ошибках. Не вставляйте конфигурацию R1 в R2 или в действующий маршрутизатор без адаптации.

Полная логика R1: включаем только нужные интерфейсы

hostname R1
log syslog informational
service integrated-vtysh-config
!
key chain OSPF-LAB
 key 1
  key-string REPLACE_WITH_GENERATED_SECRET
  cryptographic-algorithm hmac-sha-256
 exit
exit
!
interface r12
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
 ip ospf hello-interval 10
 ip ospf dead-interval 40
 ip ospf authentication key-chain OSPF-LAB
 ip ospf cost 10
exit
!
interface r13
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
 ip ospf hello-interval 10
 ip ospf dead-interval 40
 ip ospf authentication key-chain OSPF-LAB
 ip ospf cost 50
exit
!
interface lan0
 ip ospf area 0.0.0.0
 ip ospf passive
 ip ospf cost 1
exit
!
interface lo
 ip ospf area 0.0.0.0
 ip ospf passive
exit
!
router ospf
 ospf router-id 10.255.0.1
 log-adjacency-changes detail
exit
!

key chain создаёт набор ключей, key 1 выбирает идентификатор, а HMAC-SHA-256 задаёт алгоритм проверки служебных пакетов. Строка REPLACE_WITH_GENERATED_SECRET — обязательный заменяемый маркер. До запуска замените его одинаковым сгенерированным секретом на трёх узлах этого примера; используйте защищённый канал передачи и защищайте сохранённый конфиг.

• ip ospf area 0.0.0.0 включает OSPF на конкретном интерфейсе. Не используется широкое объявление всех connected-сетей.
• point-to-point задаёт тип выделенной связи: выборы DR/BDR на ней не нужны.
• hello-interval 10 и dead-interval 40 задают секунды. Параметры согласованы на обоих концах; это учебные значения, не SLA восстановления.
• ip ospf cost назначает направленную стоимость выхода. У резервной связи она выше.
• ip ospf passive на LAN и loopback оставляет объявление сети, но не строит соседство с клиентами.
• router ospf и ospf router-id задают процесс и уникальный ID; журналирование фиксирует изменения соседств.

При изменении router-id уже работающего процесса может понадобиться его контролируемый перезапуск: заранее планируйте разрыв соседств. На чистом стенде назначайте ID до их установления.

R2 и R3: какие параметры меняются

hostname R2
log syslog informational
service integrated-vtysh-config
!
key chain OSPF-LAB
 key 1
  key-string REPLACE_WITH_GENERATED_SECRET
  cryptographic-algorithm hmac-sha-256
 exit
exit
!
interface r21
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
 ip ospf hello-interval 10
 ip ospf dead-interval 40
 ip ospf authentication key-chain OSPF-LAB
 ip ospf cost 10
exit
!
interface r23
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
 ip ospf hello-interval 10
 ip ospf dead-interval 40
 ip ospf authentication key-chain OSPF-LAB
 ip ospf cost 10
exit
!
interface lo
 ip ospf area 0.0.0.0
 ip ospf passive
exit
!
router ospf
 ospf router-id 10.255.0.2
 log-adjacency-changes detail
exit
!

R2 обслуживает два транзита стоимостью 10. Его LAN в этом примере нет. Для R3 в ZIP подготовлен полный файл: router-id 10.255.0.3, r32 к R2 с cost 10, r31 к R1 с cost 50, lan0 10.20.0.1/24 с passive и cost 1.

На паре R1–R2 должны совпасть area, тип сети, Hello/Dead и параметры ключа. Адреса различаются, но находятся в одной /30. Между R2–R3 и R1–R3 действует тот же принцип. Совпадение router-id, напротив, является ошибкой. Полные три конфигурации и команды адресации приложены, чтобы не собирать R3 из догадок.

Вход в настройку не означает её сохранения. Сначала проверьте текущий конфиг, соседей и пересылку; затем выполните end, show running-config, write memory в vtysh. Эта команда сохраняет FRR, но не постоянные адреса Linux и не firewall. Не публикуйте вывод с действующими секретами.

Почему стоимость к LAN равна 21, а не 20

Сравниваем внутрозонные маршруты одного типа к одному префиксу. Стоимость задаётся на исходящих интерфейсах и суммируется по пути. Для сети 10.20.0.0/24 добавляем стоимость LAN-интерфейса R3, равную 1. Поэтому нельзя подписать цену пути к маршрутизатору и выдать её за полную метрику сети за ним.

Ручные стоимости делают пример воспроизводимым. При расчёте от полосы согласуйте reference bandwidth на устройствах: иначе быстрые каналы могут получить одинаковую стоимость или несогласованные оценки. OSPF не измеряет текущую загрузку и не перекидывает трафик с занятого линка только потому, что он занят. Для равных путей возможен ECMP, но это не обещание удвоить скорость одного соединения.

Проверка: сосед, база, маршрут, пакет

sudo vtysh -c 'show ip ospf neighbor'
sudo vtysh -c 'show ip ospf interface'
sudo vtysh -c 'show ip ospf database'
sudo vtysh -c 'show ip ospf route'
sudo vtysh -c 'show ip route 10.20.0.0/24'
ip route get 10.20.0.10
ping -c 5 -I 10.10.0.1 10.20.0.1

• neighbor: в целой треугольной P2P-схеме на каждом R ожидаем двух Full-соседей.
• interface: проверяем area, тип, стоимость, Hello/Dead и passive.
• database: видим полученные LSA; ospf route показывает расчёт OSPF.
• ip route в FRR показывает результат выбора между источниками; ip route get — решение ядра для указанного адреса.
• ping с источником: на R1 проверяет также обратный путь к офисной LAN. Цель .1 — интерфейс R3, не приложение на конечном сервере.

Следующий этап — соединение от настоящего клиента к нужному сервису в филиале. Для ядра при VRF, policy routing или нескольких адресах диагностику уточняют по реальному контексту. Готовый текст вывода не приложен: эти команды в FRR-стенде здесь не исполнялись.

Области, DR/BDR и типы маршрутов

Для трёх узлов достаточно одной backbone area 0. Многообластная сеть нужна по требованиям масштаба и управления, а не ради красивой схемы. ABR связывает области; транзит межобластной маршрутизации опирается на backbone. Суммаризацию проектируют на соответствующих границах и проверяют, что агрегат не скрывает недоступные сети.

• Внутри области: устройства работают с её link-state базой и вычисляют SPF.
• Между областями: действуют объявления и правила межобластной маршрутизации.
• Внешние E1/E2: появляются при импорте маршрутов; их нельзя сравнивать с любым intra-area маршрутом только по одной цифре cost.
• Broadcast Ethernet: применяются роли DR и BDR. Состояние 2-Way между двумя DROther может быть нормальным.
• Point-to-point: в нашем примере выборов DR/BDR нет; Full — ожидаемый результат для каждой пары.

DR — роль обмена служебной информацией сегмента, а не главный шлюз для всего трафика. Stub и NSSA меняют состав допустимых объявлений; их параметры должны быть согласованы. Начните с корректной однообластной схемы, а затем обоснуйте необходимость усложнения.

Защита OSPF и границы доверия

OSPFv2 использует IP protocol 89, а не TCP/UDP-порт 89. Для обычного обнаружения соседей важна доставка служебного multicast в соответствующем L2-сегменте. На firewall разрешайте необходимые OSPF-пакеты только от ожидаемых соседей и на транзитных интерфейсах; рабочий межсетевой трафик контролируется отдельными правилами.

• LAN клиентов и управление не должны случайно стать площадкой для OSPF-соседей.
• Ключи генерируют, передают защищённо, учитывают и меняют по плану. Настоящий секрет не размещают в статье или ZIP.
• HMAC подтверждает подлинность служебного обмена при заданных условиях, но не шифрует пользовательские данные.
• Для недоверенного канала отдельно проектируют VPN, MTU, multicast/unicast-механизм и резервирование.
• Наблюдайте новые соседства, неожиданные префиксы, default route и частые изменения LSDB.

Один общий ключ упрощает изолированный учебный стенд. В эксплуатации границы ключей, ротацию и права на конфиги определяют отдельно. Не включайте redistribute connected, redistribute static или default originate без перечня разрешённых сетей и понимания точки импорта.

Соседство не поднимается: диагностика по состояниям

sudo vtysh -c 'show ip ospf neighbor detail'
sudo vtysh -c 'show ip ospf interface r12'
journalctl -u frr --since '-15 min' --no-pager
sudo tcpdump -ni r12 -c 30 'ip proto 89'

Команды выполняют на R1; на другом узле подставляют его интерфейс. neighbor detail уточняет состояние обмена, interface — параметры линка. journalctl показывает журнал службы за 15 минут; фактическое место логов зависит от настройки syslog пакета. tcpdump ограничивает захват 30 пакетами OSPF: если пакетов нет, команда может ждать до ручной остановки. Дамп обрабатывают как служебные данные.

• Соседа нет: интерфейс, адреса/маски, passive, area, protocol 89, доставка Hello и правильный L2-сегмент.
• Init: проверить одностороннюю доставку и наличие нашего ID в Hello соседа.
• 2-Way: сначала определить тип сети и роли; не чинить нормальное DROther-состояние как отказ.
• ExStart/Exchange: проверить MTU, повторяющиеся router-id, тип сети и двусторонний обмен.
• Loading: изучить запросы/повторные передачи LSA, потери и ресурсы устройства.
• Full, но LAN нет: включение LAN в area, LSDB, выбор в RIB, установка в FIB, forwarding, фильтры и обратный путь.

Не маскируйте MTU-проблему немедленным mtu-ignore. Сначала согласуйте MTU и проверьте реальную передачу крупных пакетов через весь туннель. Любое изменение конфигурации сопровождайте повторным чтением фактического состояния.

Испытание резерва и честный замер сходимости

# Только R1 в изолированной лаборатории, управление по другому пути
sudo ip link set dev r12 down
# После измерений восстановить соединение
sudo ip link set dev r12 up

До отключения запустите наблюдение с отдельного клиента и сохраните маршруты. После отказа ожидаем исчезновение соседства R1–R2 и путь R1–R3 к сети филиала, если резерв исправен. Метрика модели меняется с 21 на 51. Зафиксируйте время события, последний успешный и первый восстановленный ответ, потери, смену next hop и результат приложения.

Административное выключение локального интерфейса может обнаружиться быстрее, чем «тихий» обрыв за работающим портом. Hello/Dead, сигналы линка и BFD — разные способы обнаружения; затем нужны распространение изменений, расчёт и обновление пересылки. Поэтому тест down/up не доказывает такую же скорость при любом отказе.

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

Мониторинг, эксплуатация и типовые ошибки

• Соседи: количество, ожидаемые ID, интерфейсы, длительность стабильного состояния и причины перезапуска.
• Маршруты: присутствие целевых префиксов, метрика, next hop, отсутствие неожиданных объявлений.
• Каналы: ошибки, потери, MTU, задержка, загрузка и свободная ёмкость резерва.
• Устройства: CPU, память, перезапуски демонов, частота SPF и изменений LSDB.
• Бизнес: доступность 1С, телефонии и файлов; синтетические проверки дополняют реальные операции.

Сохраняйте историю и синхронизируйте время: при расследовании нужно сопоставить падение соседства с ошибками линка, изменением firewall, перегрузкой узла и жалобами сотрудников. Снимок «сейчас всё зелёное» не объясняет ночной инцидент.

Частые ошибки: разная стоимость обратного направления, резерв на том же физическом кабеле, статический маршрут с более высоким предпочтением, случайный default, взаимная redistribution без политики и отсутствие проверки после перезагрузки. Быстрое соседство не компенсирует резерв, который не выдерживает производственную нагрузку.

Когда настройку можно считать принятой

1. Сверены адреса, интерфейсы, router-id, типы сети, area и параметры защиты.
2. Поднялись только ожидаемые соседства; нужные сети объявлены, лишние не появились.
3. Проверены расчёт OSPF, выбранный маршрут, FIB и обе стороны передачи.
4. Выполнены реальные операции клиента: документ 1С, звонок или обращение к файловому ресурсу.
5. Отдельно испытаны согласованные отказы линии и узла; записаны потери и время восстановления.
6. Проверен возврат без постоянных переключений, достаточность резерва и корректность сохранённых конфигов.
7. Подготовлены мониторинг, история изменений, контакты, инструкции и способ возврата.

«Команда принята CLI», «настройка сохранена», «соседство установлено» и «бизнес-сервис восстановился» фиксируют отдельно. Приложенный проект помогает подготовить такую проверку; он не заменяет испытание вашей ОС, сетевой платформы и приложения.

Первичные источники: OSPFv2 FRR 10.4, запуск демонов FRR, zebra, RFC 2328 и HMAC для OSPFv2. Правила конкретной реализации сверяют с установленной версией.

Скачать проект стенда и карточку приёмки

Архив не содержит рабочих паролей. До применения замените маркер ключа, адаптируйте имена NIC и проверьте все изменения на отдельном стенде.

Поможем настроить связность и сопровождать сеть

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