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

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

Нет комментариевПросмотров: 4914
18января 2018
все статьи

VRRP в MikroTik RouterOS

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

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

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

Принципы работы протокола VRRP

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

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

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

Схема использования VRRP в локальной сети

Для обмена служебными сообщениями маршрутизаторы должны находиться в одном широковещательном домене 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-пакет со следующими специфическими параметрами:

ПараметрЗначение
Номер протокола 112
ip-адрес отправителя ip-адрес интерфейса, ассоциированного с широковещательным доменом
ip-адрес получателя 224.0.0.18
TTL 255 (если получен служебный пакет со значением TTL, отличным от 255, пакет будет отброшен)

Сразу после этапа распределения ролей, 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, однако существует несколько зарезервированных значений:

Величина приоритетаЗначение
0

значение приоритета, формируемое в advertisement-сообщении master-маршрутизатором в случае его выключения.
Предназначено для ускоренного запуска процесса выбора master среди backup-маршрутизаторов, не дожидаясь down-interval

1-254 значения, доступные пользователю для конфигурации
255

значение приоритета owner-маршрутизатора (RouterOS позволяет вручную выставить данное значение, однако,
для совместимости с другим оборудованием, использование этого значения не рекомендуется)

100 значение приоритета по умолчанию

 

Preemption-mode

Рассмотрим ситуацию, когда маршрутизатор 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) возможны следующие настройки:

ПараметрЗначениеСовпадение на всех устройствахКомментарий
arp (disabled | enabled | proxy-arp | reply-only; Default: enabled) не требуется режим работы протокола arp на виртуальном маршрутизаторе
authentication (ah | none | simple; Default: none) требуется режим аутентификации
interface (string) не требуется имя интерфейса, ассоциированного с широковещательным доменом
interval (time [10ms..4m15s]; Default: 1s) требуется интервал рассылки служебных advertisement сообщений, формируемых master
mtu (Default: 1500) не требуется размер mtu
name (string) не требуется имя виртуального интерфейса
on-backup (script text) не требуется текст скрипта, запускаемый в случае перехода роли маршрутизатора из master в backup
on-master (script text) не требуется текст скрипта, запускаемый в случае перехода роли маршрутизатора из backup в master
password (string) требуется значение пароля при использовании аутентификации
preemption-mode (yes | no; Default: yes) требуется опция приоритетного режиме
priority (integer: 1..254; Default: 100) не требуется приоритет маршрутизатора
v3-protocol (ipv4 | ipv6; Default: ipv4) требуется используемый протокол (опция применяется только для vrrp ver.3)
version (integer [2, 3]; Default: 3) требуется версия протокола vrrp (в версии 3 добавлена поддержка ipv6)
vrid (integer: 1..255; Default: 1) требуется идентификатор виртуального маршрутизатора

Пример стандартной схемы 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. 
Пример стандартной схемы применения VRRP

Конфигурация устройств

R1:

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

/interface vrrp
add interface=ether4 name=vrrp1_ether4 priority=254 vrid=25
/ip address
add address=172.16.1.2/30 interface=ether1 network=172.16.1.0
add address=192.168.25.1/24 interface=ether4 network=192.168.25.0
add address=192.168.25.254 interface=vrrp1_ether4 network=192.168.25.254
/ip firewall nat
add action=src-nat chain=srcnat to-addresses=172.16.1.2
/ip route
add distance=1 gateway=172.16.1.1
/system identity
set name=R_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.

/interface vrrp
add interface=ether4 name=vrrp1_ether4 vrid=25
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=172.16.2.2/30 interface=ether1 network=172.16.2.0
add address=192.168.25.2/24 interface=ether4 network=192.168.25.0
add address=192.168.25.254 interface=vrrp1_ether4 network=192.168.25.254
/ip dhcp-client
add disabled=no interface=ether1
/ip firewall nat
add action=src-nat chain=srcnat to-addresses=172.16.2.2
/ip route
add distance=1 gateway=172.16.2.1
/system identity
set name=R_2

Анализ VRRP

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

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

Проверка определения ролей на маршрутизаторе R2:
Проверка определения ролей на маршрутизаторе 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”):
Демонстрация выполнения команды ping на клиентском устройстве

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

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

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

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


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

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

Тестирования preemption-mode

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

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

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

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

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

Пример стандартной схемы VRRP с отличающейся адресацией на виртуальном и системных маршрутизаторах

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

R1:

/ip address set [find interface=ether4] address=10.0.0.1/30 network=10.0.0.0
 

R2:

/ip address set [find interface=ether4] address=10.0.0.2/30 network=10.0.0.0
 

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

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

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

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

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

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

R1 и R2:

/ip address set [find interface=vrrp1_ether4]
address=192.168.25.254/24 network=192.168.25.0
 

Убедимся в восстановлении связи:
Проверка доступности на PC1

Заключение

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

поделиться материалом:

Читайте также

комментарии — 0