Применение VRRP в MikroTik RouterOS (часть 1)

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

• FHRP (first hop redundancy protocol — протокол резервирования первого транзитного участка) — семейство протоколов, используемых для повышения отказоустойчивости сети путём резервирования шлюза локальной сети. На момент написания статьи RouterOS поддерживает единственный протокол данного семейства — VRRP.
• VRRP (virtual router redundancy protocol — протокол резервирования виртуального маршрутизатора) — сетевой протокол, разработанный IETF (RFC 3768, RFC 5798), используемый для повышения доступности маршрутизатора, используемого в роли шлюза по умолчанию. Работа протокола базируется на объединении нескольких маршрутизаторов в виртуальное устройство на логическом уровне, что позволяет, в случае выхода из строя одного из маршрутизаторов, не производить переконфигурацию клиентских устройств.

В рамках статьи будут рассмотрены принципы работы протокола VRRP, описание реализации протокола в Микротик RouterOS и простейшие примеры использования в сетевых схемах.

На сети, имеющей избыточную топологию, выделяется несколько (два и более) маршрутизаторов, которые будут выполнять роль маршрутизатора по умолчанию для устройств из LAN-сегмента. На каждом из маршрутизаторов создаётся виртуальный интерфейс, которым присваивается одинаковые ip- и MAC- адреса.

Посредством обмена служебными сообщениями, среди маршрутизаторов выбирается active, который будет обрабатывать пакеты от хостов в LAN, предназначенные шлюзу по умолчанию. Остальные устройства становятся passive-маршрутизаторами, проверяющие доступность master-устройства. Таким образом, для конечных пользователей одновременно существует лишь один шлюз по умолчанию, представляющий из себя виртуальное устройство.

Рассмотрим схему на рисунке 1, условившись, что маршрутизаторы R1 и R2 используют протокол VRRP для LAN-сегмента. 

Для обмена служебными сообщениями маршрутизаторы должны находиться в одном широковещательном домене 192.168.25.0/24. Кроме того, адрес виртуального маршрутизатора также принадлежит этой сети, но с более узкой маской – 192.168.25.254/32 (если использовать одинаковые маски на физическом и виртуальном интерфейсах, относящихся к одной сети, то в таблице маршрутизации будет формироваться два connected-маршрута с поддержкой ECMP и протокол VRRP может работать некорректно).

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

• Master — маршрутизатор, являющийся активным в данный момент. Master-маршрутизатор выбирается исходя из большего приоритета, либо, если приоритеты совпадают, в соответствии с бОльшим ip-адресом интерфейса;
• Backup — маршрутизатор, являющийся резервным в данный момент. Backup-маршрутизаторами становятся все маршрутизаторы, не ставшие master;
• Owner — частный случай master, в котором ip-адрес виртуального маршрутизатора совпадает с ip-адресом интерфейса маршрутизатора. В официальной документации Микротик такая конфигурация не рекомендуется.

Служебные сообщения инкапсулируются в ip-пакет со следующими специфическими параметрами:

Сразу после этапа распределения ролей, master формирует gratuitous ARP request, предназначенный всем хостам в LAN. Данная операция необходима для заполнения arp-таблицы устройств локальной сети и forwarding-таблицы коммутатора. В качестве MAC-адреса отправителя используется сформированный виртуальный MAC-адрес 00:00:5E:00:01:**, где ** - номер идентификатора виртуального маршрутизатора VRID.

После распределения ролей master-маршрутизатор продолжает рассылку служебных сообщений для backup-маршрутизаторов с заданной периодичностью interval. В случае отсутствия служебных сообщений от master в течении down-interval (down-interval=3*interval), backup-маршрутизаторы повторяют процедуру распределения ролей, выбирая master среди существующих backup. В этот момент на пользовательских устройствах наблюдается кратковременный перерыв связи.

Приоритет (priority) — параметр, влияющий на процесс распределения ролей: устройства с бОльшим значением приоритета становится master. Значение приоритета является целым числом, лежащим в интервале от 1 до 255, однако существует несколько зарезервированных значений:

Рассмотрим ситуацию, когда маршрутизатор R1 в схеме на рисунке 1 имеет приоритет 254, а маршрутизатор R2 — 100. При конфигурации VRRP маршрутизатор R1 становится master, а R2 — backup. При выходе из строя R1, функцию master возьмёт на себя R2 в соответствии с логикой протокола.

Опция preemption-mode указывает на то, станет ли R1 master-маршрутизатором после восстановления: если опция активна, то при восстановлении работоспособности R1 будет заново запущен процесс распределения ролей и R1 станет master, а R2 — backup.

Owner-маршрутизаторы игнорируют сконфигурированное значение preemption-mode, принимая его равным “yes”.

При создании интерфейса виртуального маршрутизатора (меню /interface vrrp) возможны следующие настройки:

Рассмотрим схему, когда локальной сети есть два маршрутизатора R1 (192.168.25.1) и R2 (192.168.25.2), используемые как маршрутизаторы по умолчанию, R1 имеет больший приоритет, чем R2. Каждый из маршрутизаторов имеет доступ в Интернет, который в данной схеме эмулирует маршрутизатор R3, на котором создан loopback-интерфейс с ip-адресом 8.8.8.8. Клиентское устройство представлено персональным компьютером с ip-адресом 192.168.25.100. 

R1:

На интерфейсе локальной сети ether4 настраиваем работу протокола vrrp с vrid=25 и высшим приоритетом 254. Интерфейс в сторону провайдера ether1 ассоциируем с ip-адресом 172.16.1.2, настраиваем src-nat через этот ip-адрес и добавляем маршрут по умолчанию через адрес провайдера 172.16.1.1.

R2:

На интерфейсе локальной сети ether4 настраиваем работу протокола vrrp с vrid=25 и приоритетом по умолчанию 100. Интерфейс в сторону провайдера ether1 ассоциируем с ip-адресом 172.16.2.2, настраиваем src-nat через этот ip-адрес и добавляем маршрут по умолчанию через адрес провайдера 172.16.2.1. Интерфейс vrrp ассоциирован с ip-адресом шлюза по умолчанию 192.168.25.254, как и на маршрутизаторе R1.

Убедимся, что маршрутизаторы обменялись служебными пакетами, выбрав master.

Проверка определения ролей на маршрутизаторе R1:

Проверка определения ролей на маршрутизаторе R2:

На рисунках видно, что протокол vrrp активен на интерфейсах ether4, которые подключены к локальной сети. Маршрутизатор R1 является активным в данный момент (флаг R — running) и master (флаг M — master), а маршрутизатор R2 находится в резерве (флаг B — backup).

Запустим ping с клиентского устройства до адреса в сети Интернет 8.8.8.8 и отключим интерфейс ether4 на маршрутизаторе R1 (команда “/interface ethernet set ether4 disabled=yes”):

На рисунке видно, что при отключении интерфейса маршрутизатора R1 теряются два пакета, после чего связь восстанавливается.

В этот момент маршрутизатор R2 берёт на себя роль master для данного LAN-сегмента, а vrrp-интерфейс R1 становится неактивным, т.к. привязан к отключенному интерфейсу ether4.

Статус vrrp-интерфейса на маршрутизаторе R1 после отключения LAN-интерфейса:

Статус VRRP-интерфейса на маршрутизаторе R2 после отключения R1 от LAN-сегмента:

Таким образом, связность клиентского устройства с сетью Интернет, после отключения R1, устанавливается через маршрутизатор R2 и пакеты ходят по правому плечу схемы.

Поскольку по умолчанию, при создании vrrp-интерфейса, опция preemption-mode активна, проверим её работу. Для этого совершим обратные манипуляции, активировав LAN-интерфейс на R1 (команда “/interface ethernet set ether4 disabled=no”):

На рисунке красным прямоугольником выделен момент восстановления маршрутизатора R1. Видно, что увеличилось время ответа, однако ни один пакет при этом не потерян.

Поскольку опция preemption-mode активна и маршрутизатор R1 имеет больший приоритет, то он должен стать master, а R2 – backup. Убедимся в корректности распределения ролей между маршрутизаторами.

Проверка определения ролей на маршрутизаторе R1:

Проверка определения ролей на маршрутизаторе R2:

Протокол VRRP позволяет использовать адресацию на системных и виртуальном маршрутизаторе, относящиеся к разным подсетям, что бывает полезно в некоторых конфигурациях. Выделим для связности маршрутизаторов между собой подсеть 10.0.0.0/30 и изменим адресацию на интерфейсах локальной сети.

R1:

R2:

Проверим статус vrrp-интерфейсов на маршрутизаторах.

Проверка определения ролей на маршрутизаторе R1:

Проверка определения ролей на маршрутизаторе R2:

Как можно заметить, маршрутизаторы произвели обмен служебными сообщениями и роли распределились в соответствии с назначенными приоритетами, однако, если интернет-ресурс недоступен для устройств из локальной сети:

Дело в том, что на маршрутизаторах отсутствует маршрут к устройствам, находящихся в LAN:

Поскольку на системных маршрутизаторах используется адресация отличная от устройств в LAN, можно расширить маску на vrrp-интерфейсе, избежав потенциальных проблем с несколькими connected-маршрутами в локальную сеть.

R1 и R2:

Убедимся в восстановлении связи:

В статье рассмотрены теоретические основы функционирования протокола VRRP и его реализация в RouterOS. Представлены простейшие сценарии использования протокола в локальных сетях: стандартная схема с двумя маршрутизаторами и стандартная схема с отличающейся адресацией на системных и виртуальном маршрутизаторе.