Сценарии использования протокола VRRP в схеме с балансировкой трафика и несколькими vlan в локальной сети.
Введение
В первой части статьи рассмотрены принципы работы протокола виртуального маршрутизатора VRRP и его реализация в операционной системе MikroTik RouterOS. Рассмотрены простейшие сценарии использования протокола в локальной сети.
В рамках второй части статьи будут описаны более сложные схемы применения протокола виртуального маршрутизатора: схема с балансировкой трафика локальной сети между несколькими маршрутизаторами, схема с использованием нескольких vlan.
Также будет рассмотрено поведение сети при потере связности между системными маршрутизаторами и конфигурация двух виртуальных маршрутизаторов в локальной и внешней сетях.
Пример балансировки нагрузки локальной сети с помощью VRRP
Усложним стандартную схему, представленную в первой части статьи, добавив ещё одно клиентское устройство PC2 с ip-адресом 192.168.25.105 и шлюзом по умолчанию 192.168.25.253.
Пример 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:
/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:
Пример использования 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-таблице коммутатора:
На рисунке демонстрируется 2 вывода forwarding-таблицы коммутатора SW1, отфильтрованные по MAC-адресу виртуального маршрутизатора. Видно, что MAC-адрес шлюза ассоциирован сначала с ether1-интерфейсом, а затем с ether2, т.е. vrrp-интерфейсы на маршрутизаторах R1 и R2 «ведут борьбу» за ассоциацию с соответствующим портом в таблице коммутатора и пользовательские пакеты поочерёдно перенаправляются через оба маршрутизатора (распределение носит случайный характер). Проверим эту гипотезу, отключив интерфейс в сторону провайдера на маршрутизаторе R1 (команда /interface ether set ether1 disabled=yes):
На рисунке виден большой процент потерь пользовательских данных в моменты, соответствующие наличию записи в 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 и рассмотрены частные случаи сетевых аварий с примерами их превентивного решения для повышения доступности.