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

Сценарии использования протокола VRRP в схеме с балансировкой трафика и несколькими vlan в локальной сети.

23января 2018

Введение

В первой части статьи рассмотрены принципы работы протокола виртуального маршрутизатора VRRP и его реализация в операционной системе MikroTik RouterOS. Рассмотрены простейшие сценарии использования протокола в локальной сети.

В рамках второй части статьи будут описаны более сложные схемы применения протокола виртуального маршрутизатора: схема с балансировкой трафика локальной сети между несколькими маршрутизаторами, схема с использованием нескольких vlan.

Также будет рассмотрено поведение сети при потере связности между системными маршрутизаторами и конфигурация двух виртуальных маршрутизаторов в локальной и внешней сетях.

Пример балансировки нагрузки локальной сети с помощью VRRP

Усложним стандартную схему, представленную в первой части статьи, добавив ещё одно клиентское устройство PC2 с ip-адресом 192.168.25.105 и шлюзом по умолчанию 192.168.25.253.

Пример VRRP с балансировкой:

Пример VRRP с балансировкой

Данная схема демонстрирует один из вариантов балансировки, когда часть пользователей получает доступ в Интернет через шлюз 192.168.25.254, а другие – через 192.168.25.253, при этом маршрутизаторы R1 и R2 будут объединены в два виртуальных маршрутизатора с разными ip-адресами. Схема будет реализована через два vrrp-интерфейса с разными идентификаторами vrid. При этом на маршрутизаторах будет настроен разный приоритет, чтобы R1 являлся master для vrid с ip-адресом 192.168.25.254, а R2 – для vrid с ip-адресом 192.168.25.253.

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

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

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

R1:

Вам помогла эта статья?

Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!

/interface vrrp
add interface=ether4 name=vrrp2_ether4 vrid=125
/ip address
add address=192.168.25.253 interface=vrrp2_ether4 network=192.168.25.253

R2:

/interface vrrp
add interface=ether4 name=vrrp2_ether4 priority=254 vrid=125
/ip address
add address=192.168.25.253 interface=vrrp2_ether4 network=192.168.25.253

Анализ VRRP

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

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

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

Из иллюстраций видно, что для vrrp1 с vrid=25 маршрутизатор R1 выбран master, тогда как для vrrp2 с vrid=125 master’ом выбран R2.

Тестирование

Проверим отказоустойчивость схемы, отключив LAN-интерфейс маршрутизатора R2 (команда “/interface ethernet set ether4 disabled=no”).

Демонстрация команды ping на клиентском устройстве PC1:

На PC2, шлюзом для которого является ip-адрес 192.168.25.253, закреплённый за vrrp2, master в котором является R2, потерялось 2 пакета при проверке доступности Интернет-ресурса. После этого связь была восстановлена и пакеты начали проходить через R1 по левому плечу схемы. PC1 при этом не потерял ни одного пакета.

Маршрутизатор R1 в этот момент становится master для двух vrid:
Проверка определения ролей на маршрутизаторе R1

Пример использования VRRP в сети с несколькими vlan

Рассмотрим схему, когда в локальной сети используется несколько vlan. Клиентское устройство PC1 ассоциировано с vlan=25 (подсеть 192.168.25.0/24), PC2 – с vlan=26 (подсеть 192.168.26.0/24). Маршрутизаторами по умолчанию в этих сетях являются устройства с адресами 192.168.25.254 и 192.168.26.254 соответственно.

Для обмена служебными сообщениями между R1 и R2 выделена подсеть 10.0.100.0/24 в native vlan (vlan=1), ether4 интерфейс R1 ассоциирован с ip-адресом 10.0.100.1, ether4 интерфейс R2 – c ip-адресом 10.0.100.2, а vrrp-интерфейс – с ip-адресом 10.0.100.254.

Пример VRRP с использованием нескольких vlan:

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

Порты коммутатора eth1 и eth2 настроены как гибридные: транком разрешены 25 и 26 vlan, акцессом — 1 vlan. Такая конфигурация используется для обеспечения L2-связности между маршрутизаторами, поддерживающими VRRP. Порты eth3 и eth4 сконфигурированы как порты доступа для 25 и 26 vlan соответственно.

При настройке протокола VRRP с несколькими vlan интерфейс vrrp ассоциируется с LAN-интерфейсом (ether4 на R1 и R2), а vlan-интерфейсы ассоциируются с vrrp-интерфейсом.

Структура интерфейсов:

Vlan-интерфейсам присваиваются ip-адреса соответствующие шлюзам по умолчанию. Таким образом, в случае, если vrrp-интерфейс будет в статусе backup, то ассоциированные с ним vlan-интерфейсы будут неактивны, тогда как на master-маршрутизаторе vlan будут в статусе running. Это позволит добиться желаемой отказоустойчивой схемы.

R1:

/interface vrrp
add interface=ether4 name=vrrp_1_ether4 priority=254 vrid=100
/interface vlan
add interface=vrrp_1_ether4 name=vlan_25_ether4 vlan-id=25
add interface=vrrp_1_ether4 name=vlan_26_ether4 vlan-id=26
/ip address
add address=172.16.1.2/30 interface=ether1 network=172.16.1.0
add address=192.168.25.254/24 interface=vlan_25_ether4 network=192.168.25.0
add address=192.168.26.254/24 interface=vlan_26_ether4 network=192.168.26.0
add address=10.0.100.1/24 interface=ether4 network=10.0.100.0
add address=10.0.100.254 interface=vrrp_1_ether4 network=10.0.100.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:

/interface vrrp
add interface=ether4 name=vrrp_1_ether4 vrid=100
/interface vlan
add interface=vrrp_1_ether4 name=vlan_25_ether4 vlan-id=25
add interface=vrrp_1_ether4 name=vlan_26_ether4 vlan-id=26
/ip address
add address=172.16.2.2/30 interface=ether1 network=172.16.2.0
add address=192.168.25.254/24 interface=vlan_25_ether4 network=192.168.25.0
add address=192.168.26.254/24 interface=vlan_26_ether4 network=192.168.26.0
add address=10.0.100.2/24 interface=ether4 network=10.0.100.0
add address=10.0.100.254 interface=vrrp_1_ether4 network=10.0.100.254
/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

Тестирование

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

Статусы интерфейсов на маршрутизаторе R1:

Статусы интерфейсов на маршрутизаторе R2:

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

Проверка доступности сети Интернет с клиентского устройства PC2:

Состояние интерфейсов на маршрутизаторе R2:

Как видно на рисунках 11 и 12, маршрутизатор R2 стал master, его vlan-интерфейсы перешли в статус running. Клиентское устройство в этот момент ощутило кратковременный перерыв связи, потеряв два пакета.

Ситуация с потерей связности между системными маршрутизаторами

Обратимся к стандартной схеме, представленной в первой части статьи. Смоделируем ситуацию, когда системные маршрутизаторы R1 и R2 теряют связность при передаче служебных сообщений протокола VRRP. При таких обстоятельствах vrrp-интерфейсы обоих маршрутизаторов получат роль master и в сети будет одновременно функционировать два шлюза с одинаковыми ip- и MAC-адресами.

Стандартная схема применения VRRP:

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

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

Конфигурация SW1:

/interface bridge
add name=br_common
/interface bridge filter
add action=drop chain=forward packet-type=multicast
/interface bridge port
add bridge=br_common interface=ether1
add bridge=br_common interface=ether2
add bridge=br_common interface=ether4
/system identity
set name=SW_1

Проанализируем распределение ролей между маршрутизаторами.

Проверка статуса vrrp-интерфейса на R1:

Проверка статуса vrrp-интерфейса на R2:

Как и предполагалось, оба интерфейса получили роль master и в локальной сети одновременно функционируют два маршрутизатора, выполняющие функцию стандартных. При этом связность клиентских устройств с сетью Интернет сохраняется.

Проверка доступности интернет-ресурса с PC1:

Для анализа происходящего обратимся forwarding-таблице коммутатора:
Проверка forwarding-таблицы коммутатора

На рисунке демонстрируется 2 вывода forwarding-таблицы коммутатора SW1, отфильтрованные по MAC-адресу виртуального маршрутизатора. Видно, что MAC-адрес шлюза ассоциирован сначала с ether1-интерфейсом, а затем с ether2, т.е. vrrp-интерфейсы на маршрутизаторах R1 и R2 «ведут борьбу» за ассоциацию с соответствующим портом в таблице коммутатора и пользовательские пакеты поочерёдно перенаправляются через оба маршрутизатора (распределение носит случайный характер). Проверим эту гипотезу, отключив интерфейс в сторону провайдера на маршрутизаторе R1 (команда /interface ether set ether1 disabled=yes):
Проверка доступности интернет-ресурса на PC1

На рисунке виден большой процент потерь пользовательских данных в моменты, соответствующие наличию записи в forwarding-таблице коммутатора о соответствии MAC-адреса виртуального маршрутизатора порту ether1 в сторону R1.

Пример использования VRRP в LAN и WAN

Рассмотрим пример схемы, в которой требуется настроить работу протокола VRRP в локальной сети и на участке сети между LAN и сетью провайдера. В данной схеме используется один канал провайдера и один дополнительный коммутатор по сравнению со стандартной схемой.

Пример схемы сети с использованием VRRP на LAN и WAN:

Предположим, что для связи с сетью провайдера используется подсеть 172.16.0.0/30, в локальной сети — 192.168.25.0/24, а для передачи служебных сообщений между маршрутизаторами подсети 10.0.1.0/30 и 10.0.2.0/30 в LAN и WAN соответственно.

Конфигурация

Настройки маршрутизаторов для данной схемы:

R1:

/interface vrrp
add interface=ether4 name=vrrp1_ether4 priority=254 vrid=25
add interface=ether1 name=vrrp2_ether1 priority=254 vrid=125
/ip address
add address=10.0.2.1/30 interface=ether1 network=10.0.2.0
add address=10.0.1.1/30 interface=ether4 network=10.0.1.0
add address=192.168.25.254/24 interface=vrrp1_ether4 network=192.168.25.0
add address=172.16.0.2/30 interface=vrrp2_ether1 network=172.16.0.0
/ip firewall nat
add action=src-nat chain=srcnat comment=WAN_NAT to-addresses=172.16.0.2
/ip route
add distance=1 gateway=172.16.0.1
/system identity
set name=R_1

R2:

/interface vrrp
add interface=ether4 name=vrrp1_ether4 vrid=25
add interface=ether1 name=vrrp2_ether1 vrid=125
/ip address
add address=10.0.2.2/30 interface=ether1 network=10.0.2.0
add address=10.0.1.2/30 interface=ether4 network=10.0.1.0
add address=192.168.25.254/24 interface=vrrp1_ether4 network=192.168.25.0
add address=172.16.0.2/30 interface=vrrp2_ether1 network=172.16.0.0
/ip firewall nat
add action=src-nat chain=srcnat comment=WAN_NAT to-addresses=172.16.0.2
/ip route
add distance=1 gateway=172.16.0.1
/system identity
set name=R_2

Анализ

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

Статус vrrp-интерфейсов на маршрутизаторе R1:

Статус vrrp-интерфейсов на маршрутизаторе R2:

Проверка доступности интернет-ресурсов на PC1:

Тестирование

Рассмотрим ситуацию, когда выходит из строя интерфейс ether4 на маршрутизаторе R1. Роли будут распределяться следующим образом: в локальной сети R2 будет master, а в WAN роль master будет принадлежать R1 и связность клиентских устройств с сетью Интернет будет утеряна, поскольку стандартный маршрут в сторону провайдера на R2 не будет активен.

Проверка доступности интернет-ресурсов на PC1:

Таблица маршрутизации на R2:

В таких обстоятельствах трафик должен проходить следующими путями:

От клиента: PC1 — R2 — R1 — R3;
К клиенту: R3 — R1 — R2 — PC1.

Достичь автоматического изменения схемы прохождения трафика можно прописав дополнительные маршруты с бОльшими дистанциями:

R1:

/ip route
add distance=100 dst-address=192.168.25.0/24 gateway=10.0.2.2
R2:
/ip route
add distance=100 gateway=10.0.2.1

После добавления маршрутов схема по-прежнему является нерабочей, поскольку source NAT настроен на обоих маршрутизаторах на один и тот же адрес, выдаваемый интернет-провайдером. Обойти это можно, изменив конфигурацию следующим образом:

R2:

/interface vrrp
set vrrp1_ether4 on-backup="/ip firewall nat set [find comment=WAN_NAT] disabled=no" on-master=\
"/ip firewall nat set [find comment=WAN_NAT] disabled=yes"

Поясним логику прохождения трафика:

PC1 формирует ip-пакет с src-address=192.168.25.100 и dst-address=8.8.8.8;
Пакет попадает на маршрутизатор R2, поскольку он выбран master в LAN-сегменте;
R2 не находит маршрута к 8.8.8.8 и должен отправить пакет используя маршрут по умолчанию;
Поскольку в WAN-сегменте R2 получил роль backup, то маршрут напрямую к провайдеру не активен. В таких условиях R2 будет использовать маршрут по умолчанию с бОльшей дистанцией на адрес 10.0.2.1. При отправке пакета не используется NAT, т.к. соответствующее правило в firewall отключено в момент, когда R2 был выбран master в локальной сети;
Пакет попадает на R1, который переправляет его в сторону провайдера в соответствии с маршрутом по умолчанию. NAT при этом используется;
Пакет достигает назначения, маршрутизатора R3. R3 обрабатывает пакет и посылает ответ, который проходит по обратному пути. Проверим корректность конфигурации, запустив проверку доступности интернет-ресурса на PC1 и отключив интерфейс ether4 на R1 (команда /interface ethernet set ether4 disabled=yes).

Проверка доступности интернет-ресурса на PC1:

На иллюстрации видно, что конфигурация отработала корректно — при смене схемы прохождения трафика было потеряно 2 пакета.

Рассмотренный пример является частным случаем из множества возможных сценариев при использовании подобной схемы сети. Для повышения надёжности сети в других сценариях требуется более детальная проработка конфигурации.

Заключение

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

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

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

Анализ VRRP

Тестирование

Пример использования VRRP в сети с несколькими vlan

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

Тестирование

Ситуация с потерей связности между системными маршрутизаторами

Пример использования VRRP в LAN и WAN

Конфигурация

Анализ

Тестирование

Заключение

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