Гайд по VRRP в MikroTik

    На текущий момент у MikroTik нет стекируемых решений, либо протоколов для аппаратной синхронизации и переключения устройств. Даже решений с несколькими линиями питания не так много. Поэтому если у вас появилась задача сделать аппаратное резервирования, то вариантов у MikroTik очень и очень не много (и работать они будут далеко не так как хочется), один из них vrrp.


    Что нужно значть про VRRP


    VRRP (Virtual Router Redundancy Protocol) — открытый стандарт для объединения группы маршрутизаторов в один виртуальный маршрутизатор с целью увеличения доступности. На wikipedia говорится про "шлюз по умолчанию", но на деле это может быть совершенно любой маршрутизатор.


    MikroTik поддерживает две версии протокола vrrp (v2 и v3), в 3 версии присутствует поддержка IPv6, но не работает аутентификция (по крайней мере так написано на wiki).


    При создании vrrp интерфейса необходимо указать ID для виртуального роутера (VRID), он может принимать значения 0-255. Один реальный маршрутизатор может быть частью нескольких виртуальных маршрутизаторов VRRP.


    Каждому маршрутизатору в составе VRID необходимо выставить приоритет (Priority). Маршрутизатор с наибольшим приоритетом будет выбран в качестве master и станет держателем virtual ip (адрес по которому с маршрутизатором будут связываться другие устройства в сети).


    Master маршрутизатор раз в секунду (можно изменить) отправляет сообщения о свой активности на multicast адрес 224.0.0.18 (IPv6: FF02:0:0:0:0:0:0:12) в качестве mac получателя указан 00:00:5E:00:01:XX (IPv6: 00:00:5E:00:02:XX), где XX — 16-ричное представление VRID.


    Virtual IP — адрес виртуального маршрутизатора, настраивается на vrrp интерфейсе.


    В составе виртуального маршрутизатора может быть больше двух роутеров, при этом стандарт открыт и в теории можно использовать оборудование разных вендеров.


    Еще пара замечаний


    VRRP не отвечает за синхронизацию конфигурации, либо состояния соединений. Мало того у MikroTik нет встроенных средств для подобного функционала. Можно отлавливать изменения на master через log, создавать файл с измененными секциями, средствами fetch отправлять файлы на backup, который будет по таймеру проверять наличие файлов выполнять их. Либо использовать сторонний diff-сервер, который будет раз в день сравнивать конфигурацию и заливать изменения на backup, но все это выходит за рамки vrrp.


    Основная схема применения описанных ниже схем — использования двух (или более) роутеров запитанных от различных (независимых) линий питания с бесшовным переключением при проблемах на одной из линий.


    Схема 1. Резервирование с участием двух провайдеров


    Предварительный конфиг MikrotTik master:


    /interface ethernet
    set [ find default-name=ether1 ] name=eth1-wan
    set [ find default-name=ether2 ] name=eth2-vrrp
    /ip address
    add address=1.1.1.2/30 interface=eth1-wan
    /ip route
    add distance=1 gateway=1.1.1.1
    /system identity
    set name=vrrp-master

    Предварительный конфиг Mikrotik Backup:


    /interface ethernet
    set [ find default-name=ether1 ] name=eth1-wan
    set [ find default-name=ether2 ] name=eth2-vrrp
    /ip address
    add address=2.2.2.2/30 interface=eth1-wan
    /ip route
    add distance=1 gateway=2.2.2.1
    /system identity
    set name=vrrp-backup

    Добавление vrrp на vrrp-master:


    [Interfaces]->[VRRP]->[+]
    name: vrrp100(можно любое)
    interface: eth2-lan
    VRID: 100
    Priority: 150
    Auth: ah
    Pass: testvrrp
    Version: 2


    VRRP работает на интерфейсе локальной сети, поэтому имеет смысл поставить аутентификацию для защиты от диверсий.


    Добавление служебного ip:
    [IP]->[Address]->[+]
    interface: eth2-vrrp
    address: 10.10.10.1/32


    В данной конфигурации не обязательно использовать /32 адреса т.к. адрес рабочей подсети и служебные адреса vrrp не пересекаются. При использовании адресов из рабочей подсети (например 192.168.100.251 — master; 192.168.100.252 — backup) использование /32 является обязательным условием, в противном случае у вас могут образоваться ECMP маршрут до lan подсети и все будет работать очень плохо.

    Если служебные и реальные адреса совпадают, есть еще одна особенность. Роутер у которого на реальном интерфейсе будет настроен virtual ip в независимости от приоритета считается master.


    Добавление рабочего ip:


    Virtual IP в терминологии VRRP.
    [IP]->[Address]->[+]
    interface: vrrp100-lan
    address: 192.168.100.1/24



    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp100-lan password=testvrrp priority=150 version=2 vrid=100
    
    /ip address
    add address=10.10.10.1/32 interface=eth2-vrrp
    add address=192.168.100.1/24 interface=vrrp100-lan

    Добавление vrrp на vrrp-backup:


    [Interfaces]->[VRRP]->[+]
    name: vrrp100-lan
    interface: eth2-vrrp
    VRID: 100
    Priority: 100(ниже чем у master)
    Preemption mode: off
    Auth: ah
    Pass: testvrrp
    Version: 2


    Preemption mode — настройка для backup роутера. Если включено, то роутер не будет возвращать управление роутеру с большим приоритетом, при появлении такового в сети.


    Добавление служебного ip:


    [IP]->[Address]->[+]
    interface: eth2-vrrp
    address: 10.10.10.2/32


    Добавление рабочего ip:


    [IP]->[Address]->[+]
    interface: vrrp100-lan
    address: 192.168.100.1/24


    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp100-lan password=testvrrp priority=100 version=2 vrid=100 preemption-mode=no
    
    /ip address
    add address=10.10.10.2/32 interface=eth2-vrrp
    add address=192.168.100.1/24 interface=vrrp100-lan

    После настройки произойдет согласование — роутеры обменяются hello и решат чей priority выше.
    Состояние vrrp-master([R]unning, [M]aster)



    Состояние vrrp-backup([B]ackup)



    Выше я постарался максимально наглядно назвать интерфейсы, чтобы не было путаницы при добавлении правил firewall и пр. За локальную сеть отвечает интерфейс vrrp100-lan. за технический трафик vrrp отвечает интерфейс eth2-vrrp. Если на интерфейсе локальной сети используются vlan, то настраивать его необходимо на vrrp интерфейсе.


    Схема 2. Резервирование и балансировка с участием двух провайдеров


    Предыдущая схема работает хорошо, но один из провайдеров висит в воздухе и не используется практически никогда, можно исправить ситуацию используя несколько default route в сети. Раздать пользователям различные default router можно средствами dhcp, либо вбив статикой. В любом случае конфигурация получается не гибкой. Но это пример хорошо показывает работу роутера в нескольких виртуальных маршрутизаторах vrrp.


    Берем за основу предыдущую схему и добавляем дополнительный vrrp интерфейс.


    На vrrp-master:



    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp200-lan password=testvrrp priority=100 version=2 vrid=200 preemption-mode=no
    
    /ip address
    add address=192.168.100.2/24 interface=vrrp200-lan

    На vrrp-backup:



    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp200-lan password=testvrrp priority=150 version=2 vrid=200
    
    /ip address
    add address=192.168.100.2/24 interface=vrrp200-lan

    Здесь не совсем уместно использовать терминологию master/backup т.к. теперь оба роутера одновременно являются и тем и другим по отношению к разным vrid.


    Результат для vrrp-master:



    Результат для vrrp-backup:



    Схема 3. Резервирование с участием одного провайдера


    Предварительный конфиг MikroTik Master:


    /interface ethernet
    set [ find default-name=ether1 ] name=eth1-wan
    set [ find default-name=ether2 ] name=eth2-vrrp
    /ip address
    add address=1.1.1.2/30 interface=eth1-wan
    /ip route
    add distance=1 gateway=1.1.1.1
    /system identity
    set name=vrrp-master

    Предварительный конфиг Mikrotik Backup:


    /interface ethernet
    set [ find default-name=ether1 ] name=eth1-wan disabled=yes
    set [ find default-name=ether2 ] name=eth2-vrrp
    /ip address
    add address=1.1.1.2/30 interface=eth1-wan
    /ip route
    add distance=1 gateway=1.1.1.1
    /system identity
    set name=vrrp-backup

    Важно: на mikrotik vrrp-backup по умолчанию отключен eth1-wan интерфейс.


    Базовая конфигурация VRRP схожа со случаем с двумя провайдерами.


    Настройка vrrp-master:


    С vrrp все аналогично.



    Но появляется дополнительный скрипт в [System]->[Schedulers], который при загрузке на несколько секунд отключает wan интерфейс. Это позволяет избежать коллизий (если на backup сменен mac) либо бана на свиче оператора.



    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp100-lan password=testvrrp priority=150 version=2 vrid=100
    
    /ip address
    add address=10.10.10.1 interface=eth2-vrrp
    add address=192.168.100.1/24 interface=vrrp100-lan
    /system scheduler
    add name=wan-off on-event="/interface set eth1-wan disabled=yes\r\
        \n:delay 3\r\
        \n/interface set eth1-wan disabled=no" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

    Настройка vrrp-backup:


    Все аналогично, но в скриптах vrrp появляются действия для переключения состояния eth1-wan.



    И добавляется sheduller, который отключает eth1-wan при загрузке (если нужно vrrp включит его сам).



    Консольный вариант:


    /interface vrrp
    add authentication=ah interface=eth2-vrrp name=vrrp100-lan on-backup="/interface set eth1-wan disabled=yes\r\
        \n" on-master="/interface set eth1-wan disabled=no" password=testvrrp preemption-mode=no version=2 vrid=100
    
    /ip address
    add address=10.10.10.2 interface=eth2-vrrp
    add address=192.168.100.1/24 interface=vrrp100-lan
    
    /system scheduler
    add name=wan-off on-event="/interface set eth1-wan disabled=yes" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

    Если провайдер ограничивает доступ по mac, то не забываем изменить его на интерфейсе backup роутера.


    В такой схеме у нас появляется слабое место — свитч перед wan интерфесами. Можно договориться с провайдером, что он проведет вам два провода и они будут подключены к различным сегментам его сети с пробросами vlan и т.д. Либо… поставить пассивный тройник, да это ужасная порнография и при старте любого из роутеров будет пара коллизий, но работоспособно (если не включать руками eth1-wan на backup роутере).


    И конечно, можно использовать vrrp на wan интерфейсе (если настройки по статике), но тогда установки дополнительного свича, либо переговоров с провайдером не избежать.


    Схема 4. Резервирование с участием одного WISP провайдера


    Вам может показаться, что vrrp это странное недоразумение, которому нельзя придумать применение вне лаборатории без костылей. На самом деле есть одна схема, она очень похожа на предыдущую, но построена на wireless мостах.


    Со стороны провайдера есть ap-bridge (желательно с широкой зоной покрытия). Со стороны клиента есть две тарелки (например SXT с одинм ether) разнесенные по различным мачтам (или углам здания), которые питаются от различных линий питания, но предоставляют доступ в интернет для одной подсети.


    Настройки полностью аналогичны предыдущей схеме, только wan интерфейсом станет wlan1, а lan интерфейсом ether1. Тарелки можно настроить максимально статично, а всем трафиком управлять на дополнительном устройстве за ними. Это вполне работая анти-вандальная схема, без дополнительного взаимодействия с провайдером.

    Поделиться публикацией
    Комментарии 14
      0

      Очень узкое применение у vrrp, сам протокол "сырой". Как быть с виланами? Пппое? Маркировками и пр.?

        0

        Виланы вешаются на интерфейс VRRP, когда интерфейс неактивен — виланы автоматически тоже.
        Пппое что? Клиент или сервер?
        Что с маркировками не так? Раскройте мысль, пожалуйста.

        0

        Эххх, когда же все начнут использовать в документациях 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 вместо 1.1.1.1 и 2.2.2.2?
        Уже не раз натыкался на проблемы из-за использования 1.1.1.1 в качестве адресов для туннелей… Все ж берут и копипастят примеры из документации, и почти никогда не меняют их.

          0

          С запуском CloudFlare Public DNS вообще подобное боком вылазит =)
          В Беларуси национальный оператор Белтелеком несколько лет назад использовал подсеть 1.0.0.0/8 как серые адреса абонентов. Что уж говорить о более мелких операторах.

            0

            Да, я именно на проблемы с CloudFlare и натыкался…
            А провайдеры… Ну, чтобы провайдеры использовали что-то отличное от 10/8, 192.168/16 172.16/12 я пока еще не встречал. Вспоминается только Hamachi, который раздавал клиентам адреса из неаллоцированых блоков, раньше было 5/8, сейчас 25/8. В общем, такое себе использовать реальные адреса "внутри сети", а уже тем более, в документации...

              0
              Ну, чтобы провайдеры использовали что-то отличное от 10/8, 192.168/16 172.16/12 я пока еще не встречал.

              Провайдеры для ната вроде как 100.64.0.0/10 должны использовать, и по моему как минимум мобильный билайн так делает.
                0

                Судя по RFC — да, но по сути сеть провайдер которая за натом является приватной сетью, и использовать перечисленные диапазоны не возбраняется.
                На счет билайна ничего не скажу, давно не имел с ним дела, но лет 8 назад они выдавали адреса из сети 172.16/12. Возможно что-то изменилось.

          +1
          mac адреса у виртуальных роутеров вот такие: 00-00-5E-00-01-{VRID} — для IPv4,
          00-00-5E-00-02-{VRID} — для IPv6, в последнем октете стоит номер виртуального роутера. Это описано в RFC5798: tools.ietf.org/html/rfc5798
          С VLANами всё очень просто — ставятся многоуровневые свичи, которые поддерживают VRRP, если на них денег нету, то сабжевые устройства умеют маршрутизировать пакетики между VLANами и VRRP тогда запускается на соответствующих интерфейсах.
            0
            00-00-5E-00-01-{VRID} — для IPv4,
            00-00-5E-00-02-{VRID} — для IPv6

            спасибо за дополнение, добавил в текст.
            0
            Вчитался, проникся и написал ещё дополнение:
            00-00-5E-00-01-{VRID} и 00-00-5E-00-02-{VRID} — это mac адреса самих виртуальных роутеров, а физический роутер для посылки служебных пакетов VRRP использует групповой mac адрес получателя 01-00-5E-00-00-12 для IPv4 и 33-33-00-00-00-12 для IPv6.
            При отправке IPv4 пакетов с групповым адресом получателя через ethernet младшие 23 (двадцать три!) бита адреса получателя копируются в младшие 23 бита mac адреса, а старшие 25 бит ставятся 01-00-5E-0, то есть 224.0.0.18 отображается в 01-00-5E-00-00-12. При передаче IPv6 пакетов в mac копируются 32 младших бита адреса, старшие 16 бит — 33-33, таким образом из FF02::12 получается 33-33-00-00-00-12.
              0

              Кстати, интерфейсы VRRP ещё можно использовать для получения нескольких адресов по DHCP от провайдера на одном Ethernet-интерфейсе: https://forum.mikrotik.by/viewtopic.php?t=322
              Адреса будут запрашиваться для MAC'ов 01-00-5E-00-0N-XX.

                0
                Немного странно у Вас получается, redundancy для роутеров есть, а коммутатор ведущий в локальную сеть — один. Наверх кстати тоже можно сделать vrrp если провайдер даст /29 и два порта.
                  0
                  а коммутатор ведущий в локальную сеть — один

                  Это уже другой вопрос.

                  Наверх кстати тоже можно сделать vrrp если провайдер даст /29 и два порта.

                  Согласен. Но потребуется связываться с провайдером, возможно они денег больше захотят и т.п.
                    0

                    Тогда ещё надо не забыть синхронизировать VRRP "наверх" и "наниз", чтобы не оказалось, что внешний адрес висит на одном роутере, а внутренний — на другом :)

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое