КорзинаВ статье описаны основные механизмы протокола VRRP, особенности реализации и конфигурации в операционной системе RouterOS. Представлены простейшие сценарии использования протокола для повышения доступности услуг в локальной сети.
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-сегмента.
Для обмена служебными сообщениями маршрутизаторы должны находиться в одном широковещательном домене 192.168.25.0/24. Кроме того, адрес виртуального маршрутизатора также принадлежит этой сети, но с более узкой маской – 192.168.25.254/32 (если использовать одинаковые маски на физическом и виртуальном интерфейсах, относящихся к одной сети, то в таблице маршрутизации будет формироваться два connected-маршрута с поддержкой ECMP и протокол VRRP может работать некорректно).
В процессе обмена служебными сообщениями маршрутизаторы должны распределить между собой роли, выбрав какое из устройств будет в данный момент являться active, а какое находиться в резерве. Протокол подразумевает следующие роли:
- Master — маршрутизатор, являющийся активным в данный момент. Master-маршрутизатор выбирается исходя из большего приоритета, либо, если приоритеты совпадают, в соответствии с бОльшим ip-адресом интерфейса;
- Backup — маршрутизатор, являющийся резервным в данный момент. Backup-маршрутизаторами становятся все маршрутизаторы, не ставшие master;
- Owner — частный случай master, в котором ip-адрес виртуального маршрутизатора совпадает с ip-адресом интерфейса маршрутизатора. В официальной документации MikroTik такая конфигурация не рекомендуется.
Служебные сообщения инкапсулируются в 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-маршрутизатором в случае его выключения. |
| 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.
Конфигурация устройств
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_1R2:
На интерфейсе локальной сети 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:
Проверка определения ролей на маршрутизаторе 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 и пакеты ходят по правому плечу схемы.
Тестирования preemption-mode
Поскольку по умолчанию, при создании vrrp-интерфейса, опция preemption-mode активна, проверим её работу. Для этого совершим обратные манипуляции, активировав LAN-интерфейс на R1 (команда “/interface ethernet set ether4 disabled=no”):
На рисунке красным прямоугольником выделен момент восстановления маршрутизатора R1. Видно, что увеличилось время ответа, однако ни один пакет при этом не потерян.
Поскольку опция preemption-mode активна и маршрутизатор R1 имеет больший приоритет, то он должен стать master, а R2 – backup. Убедимся в корректности распределения ролей между маршрутизаторами.
Проверка определения ролей на маршрутизаторе R1:
Проверка определения ролей на маршрутизаторе 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.0R2:
/ip address set [find interface=ether4] address=10.0.0.2/30 network=10.0.0.0Проверим статус vrrp-интерфейсов на маршрутизаторах.
Проверка определения ролей на маршрутизаторе R1:
Проверка определения ролей на маршрутизаторе R2:
Как можно заметить, маршрутизаторы произвели обмен служебными сообщениями и роли распределились в соответствии с назначенными приоритетами, однако, если интернет-ресурс недоступен для устройств из локальной сети:
Дело в том, что на маршрутизаторах отсутствует маршрут к устройствам, находящихся в LAN:
Поскольку на системных маршрутизаторах используется адресация отличная от устройств в LAN, можно расширить маску на vrrp-интерфейсе, избежав потенциальных проблем с несколькими connected-маршрутами в локальную сеть.
R1 и R2:
/ip address set [find interface=vrrp1_ether4]
address=192.168.25.254/24 network=192.168.25.0Убедимся в восстановлении связи:
Заключение
В статье рассмотрены теоретические основы функционирования протокола VRRP и его реализация в RouterOS. Представлены простейшие сценарии использования протокола в локальных сетях: стандартная схема с двумя маршрутизаторами и стандартная схема с отличающейся адресацией на системных и виртуальном маршрутизаторе.
