На текущий момент у 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 (адрес по которому с маршрутизатором будут связываться другие устройства в сети).

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

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

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

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

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

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

/interface ethernet set name=eth1-wan set 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 name=eth1-wan set 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:

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

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

Добавление служебного ip:
->->
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.
->->
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:

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

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

->->
interface: eth2-vrrp
address: 10.10.10.2/32

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

->->
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(unning, aster)

Состояние vrrp-backup(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 name=eth1-wan set 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 name=eth1-wan disabled=yes set 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 все аналогично.

Но появляется дополнительный скрипт в ->, который при загрузке на несколько секунд отключает 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) разнесенные по различным мачтам (или углам здания), которые питаются от различных линий питания, но предоставляют доступ в интернет для одной подсети.

Для защиты SIP-порта можно использовать анализ пакетов с помощью опции «content» в Firewall Mikrotik. Но, для начала, нам нужно узнать, что именно посылает наш сервер телефонии на неправильный логин и пароль. Для примера возьмем самый популярный сервер телефонии — Asterisk с веб-интерфейсом FreePBX. Перво-наперво можно изучить, какие именно стандартные ответы дает SIP-сервер:

SIP/2.0 400 Bad Request — запрос не понят из-за синтаксических ошибок в нем, ошибка в сигнализации, скорее всего что-то с настройками оборудования
SIP/2.0 401 Unauthorized — нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль
SIP/2.0 401 Expired Authorization — время регистрации истекло
SIP/2.0 402 Payment Required — требуется оплата (зарезервирован для использования в будущем)
SIP/2.0 403 No Such User — нет такого пользователя, ошибка в номере, логине или пароле
SIP/2.0 403 User Disabled — пользователь отключен
SIP/2.0 403 Wrong Guess — ошибка в пароле
SIP/2.0 403 Conflict — такой SIP-номер уже используется
SIP/2.0 403 Forbidden — абонент не зарегистрирован
SIP/2.0 403 Empty Route Set — нет ни одного шлюза в роутинге
SIP/2.0 403 Caller Not Registered — нет такого пользователя
SIP/2.0 403 Out of Look-Ahead Retries — перебор узлов закончен
SIP/2.0 403 Invalid Phone Number — нет такого направления
SIP/2.0 403 No Money Left on RFC Account — на счету нет денег для совершения звонка
SIP/2.0 404 Not found — вызываемый абонент не найден, нет такого SIP-номера
SIP/2.0 404 Undefined Reason — неопределенное направление
SIP/2.0 404 Unknown user account — логин и пароль не найдены
SIP/2.0 404 Out of Order — в заявке на маршрутизацию по этому направлению нет ни одного шлюза, проверьте настройку маршрутизации по этому направлению.
SIP/2.0 405 Method Not Allowed — метод не поддерживается, может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match — неправильная конфигурация кодеков
SIP/2.0 406 Not Acceptable — пользователь не доступен
SIP/2.0 407 Proxy Authentication Required — необходима аутентификация на прокси-сервере
SIP/2.0 408 Request Timeout — время обработки запроса истекло: Абонента не удалось найти за отведенное время
SIP/2.0 408 Login timed out — за отведенное время не получен ответ от сервера на запрос авторизации
SIP/2.0 410 No Route — вариант SIP/2.0 403 Empty Route Set; нет доступа к ресурсу: Ресурс по указанному адресу больше не существует
SIP/2.0 413 Request Entity Too Large — размер запроса слишком велик для обработки на сервере
SIP/2.0 415 No Media — звонок совершается неподдерживаемым кодеком
SIP/2.0 416 Unsupported Scheme — сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна
SIP/2.0 420 Bad extension — неизвестное расширение: Сервер не понял расширение протокола SIP
SIP/2.0 421 Extension Required — в заголовке запроса не указано, какое расширение сервер должен применить для его обработки
SIP/2.0 423 Interval Too Brief — сервер отклоняет запрос, так как время действия ресурса короткое
SIP/2.0 480 Invalid Phone Number — неправильный номер телефона, не соответствует к-во цифр или неправильный код страны или города
SIP/2.0 480 Destination Not Found In Client Plan — направления нет в тарифном плане абонента
SIP/2.0 480 Wrong DB Response — проблемы с центральной базой сети
SIP/2.0 480 DB Timeout — проблемы с центральной базой сети
SIP/2.0 480 Database Error — проблемы с центральной базой сети
SIP/2.0 480 Codec Mismatch — несоответствие кодеков
SIP/2.0 480 No Money Left on RFC Account — нет денег на счету, обратитесь к администратору сети!!!
SIP/2.0 480 Empty Route Set — пустое направление, нет принемающих шлюзов
SIP/2.0 480 No money left — недостаточно денег на счете
SIP/2.0 480 Temporarily Unavailable — временно недоступное направление попробуйте позвонить позже
SIP/2.0 481 Call Leg/Transaction Does Not Exist — действие не выполнено, нормальный ответ при поступлении дублирующего пакета
SIP/2.0 482 Loop Detected — обнаружен замкнутый маршрут передачи запроса
SIP/2.0 483 Too Many Hops — запрос на своем пути прошел через большее число прокси-серверов, чем разрешено
SIP/2.0 484 Address Incomplete — принят запрос с неполным адресом
SIP/2.0 485 Ambiguous — адрес вызываемого пользователя не однозначен
SIP/2.0 486 Busy Here — абонент занят
SIP/2.0 487 Request Terminated — запрос отменен, обычно приходит при отмене вызова
SIP/2.0 488 Codec Mismatch — нет шлюзов с поддержкой заказанного кодека
SIP/2.0 488 Private IP Address — адрес RTP media из сетей RFC1918
SIP/2.0 491 Request Pending — запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу
SIP/2.0 493 Undeciperable — сервер не в состоянии подобрать ключ дешифрования: невозможно декодировать тело S/MIME сообщения
SIP/2.0 499 Codec Mismatch — отсутствует кодек