Страница 1 из 3

Mikrotik vrrp медленное переключение

Добавлено: 25 ноя 2014, 12:47
Senter
Пробую сделать резервирование средствами vrrp на тестовом стенде(2 mikrotik 915Ui 2HnD v6.22).

M1-Master:

Код: Выделить всё

/interface vrrp
add interface=br1 name=vrrp-lan priority=250 vrid=100 preemption-mode=no version=3 v3protocol=ipv4
/ip address
add address=10.10.10.254/24 interface=br1 network=10.10.10.0
add address=10.10.10.1/32 interface=vrrp-lan network=10.10.10.1


M2-Slave

Код: Выделить всё

/interface vrrp
add interface=br1 name=vrrp-lan priority=200 vrid=100 preemption-mode=no version=3 v3protocol=ipv4
/ip address
add address=10.10.10.253/24 interface=br1 network=10.10.10.0
add address=10.10.10.1/32 interface=vrrp-lan network=10.10.10.1


В остальном настроен только dhcp-server.

Схема:
Изображение

Оба роутера доступны по адресам 10.10.10.253 и 10.10.10.254 соответственно.
Ситуация 1: работают master и slave - отвечает master
Ситуация 2: master отключен - проходит неопределенное время(от нескольких секунд до нескольких минут), пока не заработает slave
Ситуация 3: master снова подключен - slave перестает отвечать, проходит неопределенное время, пока не начнет отвечать master.

Пробовал: использовать 2 версию протокола(с паролем и без), включать preemption-mode на master, использовать eth-интерфейс вместо bridge, использовать у master адрес 10.10.10.1 в качестве основного. Не помогло, переключение всеравно занимает время. Подскажите, что я делаю не правильно.

Re: Mikrotik vrrp медленное переключение

Добавлено: 25 ноя 2014, 17:26
DeLL
VRRP у меня нормально работает только на 6.18
Делайте даунгрейд и пробуйте еще)
У меня работает вторая версия с секундным интервалом без пароля

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 09:28
Senter
Действительно, на 6.18 переключается мгновенно. Хотя нет, опять плохо стали переключаться. Точнее даже так. С Master на Slave переключается мгновенно, а когда master возвращается то переключение обратно не происходит(и slave Тоже не отвечает по 10.10.10.1). Единственная мысль, что дело в Н/У свиче который не может нормально обработать одинаковые mac-адреса на разных портах, но хаба для проверки увы нет.

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 10:46
DeLL
Если у вас настройка

Код: Выделить всё

preemption-mode=no

То при возвращении мастера в строй передача ему прав быть главным не произойдет. Смените на "YES"

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 10:50
Senter
То при возвращении мастера в строй передача ему прав быть главным не произойдет. Смените на "YES"

Сейчас так настроено, не спасает.

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 11:12
DeLL
У меня сейчас на тестовом стенде отрабатывает вроде нормально, но у меня поднято сразу 4 VRRP интерфейса. Скоро собрался ставить в продакшн

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 11:26
Senter
А что у вас за модели микротиков?

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 12:54
DeLL
RB 2011UiAS-RM
После обеда смогу еще потестить с разными настройками.
Раньше выставлял проверку 10 раз в секунду - были глюки

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 13:49
vviz
DeLL писал(а):Если у вас настройка

Код: Выделить всё

preemption-mode=no

То при возвращении мастера в строй передача ему прав быть главным не произойдет. Смените на "YES"

Произойдет, если мастер владелец виртуального адреса. Этот параметр нужен для борьбы Slave между собой, имхо.

Re: Mikrotik vrrp медленное переключение

Добавлено: 26 ноя 2014, 13:58
vviz
Senter писал(а):Действительно, на 6.18 переключается мгновенно. Хотя нет, опять плохо стали переключаться. Точнее даже так. С Master на Slave переключается мгновенно, а когда master возвращается то переключение обратно не происходит(и slave Тоже не отвечает по 10.10.10.1). Единственная мысль, что дело в Н/У свиче который не может нормально обработать одинаковые mac-адреса на разных портах, но хаба для проверки увы нет.


Думается, такого состояния быть не должно, vrrp не позволяет уст-вам отвечать на виртуальный МАС, если они в режиме бэкапа. Могу предположить, что на на свиче поднят STP, который блокирует порт, когда увидит на нем тот же МАС адрес, что и на другом, на входящем фрейме.