Маршрутизация. OSPF в Mikrotik RouterOS

По Вики: OSPF(англ. Open Shortest Path First) — протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology) и использующий для нахождения кратчайшего пути алгоритм Дейкстры.

Для чего нужен OSPF и как применять его на сетях, построенных на Mikrotik RouterOS, мы и рассмотрим в этой статье.

Все, кто работал с сетями, имеющими более одной подсети (провайдеры, компании с филиалами, несколько vlan и т.д.) знают о необходимости существования маршрутов из одной сети в другую. Иначе пакеты в соединении будут просто улетать на шлюз по умолчанию и дропаться где-то в интернете.

Для тех же, кто с этим не знаком, поясню. Представьте, что мы внезапно захотели попасть из Челябинска в Киев, не имя при этом ни карты, ни навигатора. Поедем по указателям - не зря же их ставили.

Таким образом посмотрев на 10-20-100 укзателей мы рано или поздно доберемся до Киева - пакет от отправителя ушел к адресату. Сделали там все свои дела и захотели обратно домой в Челябинск - приложение обработало пакет и отправило ответ инициатору соединения. Но дорогу то мы не помним (в пакете нет никаких данных о прохождении пути. На самом деле есть намеки на это, но с помощью них нельзя восстановить путь пакета). Не беда - поедем по указателям.

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

Итак, мы, инкапсулированные в автомобиль - это данные, инкапсулированные в IP-пакет. Перекрестки на дороге - маршрутизаторы, подключенные к разным сетям (дорогам). А указатели на перекрестках - таблицы маршрутизации отдельных маршрутизаторов, знающие куда повернуть, чтобы попасть в ту или иную точку. И если в одну сторону мы доедем по указателям, а в другую указателей не будет, то пиши пропало - до исходной точки не доберемся. Значит, маршруты до общающихся сетей должны быть прописаны на обеих сторонах. И очень важно понимать, что дорог-маршрутов может быть несколько. И если один перекресток-маршрутизатор в ремонте, то предыдущий может послать нас в объезд, но сначала он должен узнать, что его сосед сломался. И если мы ездим по разным дорогам, значит и время пинга у нас будет разное.

Итак, с маршрутами разобрались. Теперь поговорим о дорожниках, ставящих указатели.

Статические указатели на дорогах - хорошо. Но расстояние между Челябинском и Киевом 2400 км. А значит и указателей должно быть не меньше 24 - по одному на каждые 100 км. И если на одном из перекрестков идет ремонт, необходимо внести изменения на два смежных указателя. А вероятность одновременного ремонта на 24 перекрестах весьма высока. То есть нужна отдельная бригада дорожников, меняющих указатели.

Было бы неплохо соединить все указатели в  сеть и позволить им самим оценивать ситуацию на своих участках и передевать эти данные между собой. К сожалению великие и ужасные службы обслуживания дорог об этом ещё не додумались, да и вряд ли это надо - деньги то пилить не получится. А вот айтишники придумали технологии, позволяющие динамически изменять таблицы маршрутизации и обмениваться этой информацией. Эти технологии называются Протоколы Динамической Маршрутизации. И один из них - OSPF, предназначенный для обмена информацией внутри одной автономной системы - AS.

Термины и работа OSPF хорошо описаны в вики микротика. Но я осмелюсь кое-что повторить и перефразировать.

Допустим, есть следующая сеть.

Как видим, к сети 172.16.1.0 можно попасть двумя путями: через R2  и через связку R3+R4. Cost’ы, написанные возле каждого линка задают стоимость линка, своеобразный аналог параметра distance в ip-route. Чем ниже значение cost’а, тем выше вероятность того, что трафик пойдет по этому пути. Но как видно на следующем рисунке суммарная стоимость обоих маршрутов к сети 172.16.1.0 составляет 20. Так по какому же пути пойдет трафик?

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

Сделать, чтобы OSPF “заработал” в Mikrotik RouterOS очень просто - нужно лишь добавить в backbone на каждом роутере в Routing - OSPF - Networks все ваши сети, между которыми вы хотите динамическую маршрутизацию и “оно заработает”.

Но мы ведь хотим управлять процессом. Тот, кто не хочет управлять дальше может не читать. Остальным - добро пожаловать!

Рассматривать будем сеть, типичную для организации с несколькими филиалами. Имеем центральный офис (Headquarter на схеме, для краткости будем звать его ЦО) с сетью 192.168.0.0/24 (что я, кстати, не рекомендую при дефолтных настройках OSPF. Почему - скажу ниже). В ЦО расположены все основные элементы инфраструктуры - контроллер домена, сервер удаленного доступа, почтовый сервер и т.д. Все филиалы должны иметь доступ ко всем этим сервисам.

Несколько филиалов (Branche на схеме, для краткости - СП - Структурное Подразделение) с адресами 192.168.X.0/24. Между ЦО и каждым СП шифрованный туннель SSTP (или любой другой VPN)  - адреса в туннелях из подсети 192.168.255.0/24 (192.168.255.10 - ЦО, 192.168.255.1 - СП1, 192.168.255.2 - СП2, ...). Между филиалами связь не нужна, т.к. все службы в ЦО. Когда филиалов 3, нам легко добавить 3 маршрута на роутер в ЦО и по одному на каждый из роутеров СП. Итого 6 движений мышкой. А что если СП у нас не 3, а 33 и необходимы маршруты от каждого каждому, а ещё есть подрядчики с доступом к нескольким СП? Тут и приходит на помощь OSPF.

Кому надо “быстро и пофиг как оно работает”, могут пойти по схеме, предложенной выше - добавить в backbone все свои сети.

Почему именно backbone? Backbone в переводе с английского - хребет, позвоночник. OSPF оперирует понятиями Area (область), Autonomous System (AS, автономная система). AS - все сети, которые принадлежат вам и между которыми может работать ваш протокол динамической маршрутизации. Area - часть этой сети. На картинке ниже показана одна AS с тремя Area, одна из которых - backbone (Area 0 с ID 0.0.0.0). Каждая Area имеет свой ID, похожий на IP адрес. Backbone всегда имеет ID 0.0.0.0. Все области в OSPF должны иметь линк с backbone. Иначе ничего работать не будет.

В нашем примере мы решили долго не думать и загнать все в backbone. По большому счету это ничем не грозит и работать будет. Но если провайдер отдает одному из ваших филиалов частный адрес из 192.168.0.0/16 (192.168.18.27/29, например), то в вашей таблице маршрутизации появится сеть провайдера. И если кто-то с другой стороны провайдера использует такие же настройки (или просто указал маршрут к вашим сетям), то он сможет беспрепятственно попасть в вашу сеть. А уж случайно это сделали или намеренно - узнаете когда данные из вашей БД всплывут в интернете.

В этом случае можно использовать авторизацию на каждом интерфейсе Routing - OSPF - Interfaces.

Или указать, что интерфейс, смотрящий к провайдеру будет в пассивном режиме.

Теперь поговорим о том, как сделать “правильно” - не вещать свои сети куда попало и позволить грамотно траблшутить работу OSPF.

Как мы говорили выше, каждая область имеет свой ID. Также и каждый участник OSPF имеет свой ID. По умолчаню он выставляется автоматически и выбирается из IP адресов, присвоенных интерфейсам роутера. Но нам надо проставить его в ручную, чтобы была какая-то логика в именовании и мы всегда знали откуда пришел запрос. Ставится это в Routing - OSPF - Instances - Router ID.

В нашей схеме имеется несколько областей. Как мы выяснили, основная область, соединяющая все остальные - backbone. Именно в этой области летают пакеты от одного роутера к другому, позволяющие обмениваться маршрутной информацией. Значит, этой областью должны быть туннели, соединяющие СП и ЦО, что видно на рисунке ниже.

Таким образом, нам необходимо выделить на каждом маршрутизаторе по две зоны - backbone и свою локальную сеть. На примере ЦО:

routing ospf area add name=Area0 area-id=192.168.0.0

routing ospf network add area=Area0 network=192.168.0.0/24

routing ospf network add area=backbone network=192.168.255.0/24

И точно так же на остальных маршрутизаторах, только заменив Area-ID, Area name и network на свои.

Теперь на каждом маршрутизаторе можем увидеть маршруты ко всем остальным сетям с буквами D и o в описании, что означает, что эти маршруты D - динамические (прилетели в резудльтате работы протоколов динамической маршрутизации) и o - из протокола  OSPF.

Таким образом мы произвели простую и надежную настройку протокола динамической маршрутизации. У OSPF ещё имеется куча дополнительных настроек, таких как приоритет роутера, стоимость интерфейса, время определения состояний и многое, многое другое. Это позволяет очень гибко настроить маршрутизацию под свои нужды, но тема эта очень обширная и выходит за рамки этого и так очень растянувшегося поста. Если читатели проявят желание, то в будущем можно будет подробно расписать (почти) все нюансы применения OSPF.

Картинки с wiki.mikrotik.com, blog.globalknowledge.com и других ресурсов, а также свои скриншоты и схемы, нарисованные с помощью сервиса draw.io

Статья написана мной для lanmarket.ua