+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

VRRP… это вообще работает?

VRRP… это вообще работает?, RouterOS

dirtonth

Guest

21.04.2006 11:55:00

Привет, ребята! Я пытаюсь настроить VRRP. RouterOS у меня 2.9.21. Сначала я сразу же попробовал VRRP с VLAN и Bridges, но это сразу же не сработало. Тогда я решил протестировать VRRP в самых базовых условиях. В итоге я получил следующее: пинг динамического IP работает, когда онлайн и мастер, и резерв. ARP показывает, что хост пингует мастера. Когда мастер уходит в оффлайн, пинг работает. ARP показывает, что хост пингует резерв (который теперь мастер). Когда мастер снова приходит в онлайн, пинг работает. ARP показывает, что хост всё ещё пингует резерв! Почему эти две коробки не используют общий виртуальный MAC-адрес для динамического адреса? Я прошерстил форум, искал информацию по VRRP, но большинство вопросов остаются без ответа… Может, Mikrotik подскажет, как это решить?

savage

Guest

21.04.2006 12:56:00

Видел такое уже кучу раз с VRRP на MT, и это одна из причин, почему я перестал его использовать. Им точно стоит добавить виртуальный MAC к адресу VRRP. Если изменить тайм-аут ARP-кэша до очень маленького значения (например, 1 секунда), это должно решить проблему.

aitsecurity

Guest

02.05.2006 01:48:00

Кажется, что-то не так. Я использовал HSRP – это как VRRP, но проприетарная технология, понимаешь, от Cisco, и работала просто отлично. VRRP — это открытая версия, и как бы, оригинальная. Я думаю, что VRRP должен работать, но почему у тебя не получается? А в HSRP в случаях 3 и 4, которые ты описал, все работает нормально: мастер снова берет на себя роль. Я использовал это для двух роутеров, двух коммутаторов и двух серверов, и в серверах по две сетевые карты — полная избыточность, и все работало просто замечательно. Когда время Hello было 3 секунды, и мастер не появлялся 10 секунд, запасной роутер брал на себя роль. Я думаю, VRRP работает лучше, потому что мне кажется, что Cisco скопировали это.

С уважением.

dirtonth Guest	#4 0 02.05.2006 07:55:00 Я написал в Mikrotik по поводу проблемы, и ребята сказали, что в релизе 2.9.24 будет обновление, которое это исправит. Жду этот релиз, чтобы перепроверить и выложить свои отзывы.

savage

Guest

02.05.2006 16:02:00

Было бы интересно посмотреть, как они это исправят. Надеюсь, они добавят виртуальный MAC-адрес или сделают так, чтобы MAC-адрес перемещался вместе с IP-адресом. Я сейчас совсем завал на новой работе, так что ПОЖАЛУЙСТА, выкладывайте свои находки после релиза. Очень хочу увидеть, как это исправят!!! – C

dirtonth

Guest

02.05.2006 19:10:00

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

abc123

Guest

03.05.2006 14:18:00

Вот почему можно настроить время ожидания ARP-кэша на этих двух портах. Есть несколько других механизмов, которые могут предотвратить "катастрофу" в случае, если ты описал и поддерживаешь желаемую функциональность.

savage

Guest

04.05.2006 19:54:00

И если у вас не управляемый 24-портовый коммутатор? Больновато приходится вручную выставлять меньший arp-cache timeout на всех системах. Что, если эти 22 системы получают свою IP-конфигурацию по DHCP на MT? MT не предоставляет опцию для установки arp-timeout в DHCP Scope. Если только у вас не интеллектуальные коммутаторы, практически невозможно настроить VRRP с рабочим конфигом на MT. К тому же, я не встречал ни одной (кроме MT) реализации VRRP, HRSP или любой формы HA Cluster-конфигурации, где требовалось, чтобы все узлы на локальной сети, получающие динамический адрес, имели уменьшенный LOCAL arp-cache timeout. MT должна вписываться в остальную часть, а не наоборот... Просто мысль.

nikhil Guest	#9 0 15.06.2006 06:09:00 Какие вообще есть варианты?

IntraLink

Guest

#10

05.05.2006 05:46:00

Идея с подключением двух управляемых коммутаторов, по одному к каждому MT-станку, мне нравится. Но реальная проблема — что в кэше ARP у клиентов. Так что, если они смогут создать виртуальный MAC-адрес, все проблемы исчезнут, верно? Или коммутатор выдаст ошибку, если MAC-адрес внезапно появится на другом порту? Я бы предположил, что нет, потому что я могу взять свой ноутбук, переключить его на другой порт, и он будет пинговать почти сразу…

nikmac

Guest

#11

05.05.2006 07:16:00

Привет, ребята! У меня всё получилось с кластером на isa2k & 2k4 и raptor, никаких проблем. Я в режиме unicast настроил VIP для внешних интерфейсов. Сначала я соединил все внешние интерфейсы через хаб, а потом поднял их на свитч. Таким образом, свитч регистрирует только один порт с MAC-адресом. Никаких проблем нет. А если я в режиме multicast подключил все внешние интерфейсы напрямую к свитчу, то у меня начинается flooding, но опять же без проблем. У меня MT v2.9.6. Первый сценарий (с хабом) я реализовал без проблем (свитч использует только один порт). Но вот микротик не имеет VMAC, только AGRES. ARP. Моя проблема — VIP в VPN. Я заметил, что connection tracking не мониторит IPsec (50) протокол, только tcp/udp. Вот в чем проблема, потому что после failback вторичный узел пытается подключиться к удаленному пиру. Спасибо, Никос.

nikhil Guest	#12 0 07.06.2006 12:12:00 Ты тестировал с 2.9.24?

nikmac

Guest

#13

08.06.2006 12:22:00

Да, я тестировал MT 9.24 и 9.25. Думаю, проблема в layer-2 коммутаторе в 9.24, но я обошел ее, сначала подключив MT к хабу. В 9.25 я заметил, что после failback второй MT (резервный узел) не регистрирует свой MAC-адрес в коммутаторе L2, и для успешной регистрации нужно отключить и снова включить интерфейс. Эта проблема не возникает в L3 коммутаторе.

savage Guest	#14 0 08.06.2006 12:25:00 VRRP до сих пор не работает в MT. В форумах полно сообщений на эту тему… Должно было быть исправлено в .24, но не было. Вышла версия .25, но в списке изменений ничего об этом не указано…

nikmac

Guest

#15

08.06.2006 12:50:00

В 9.25 проблема в том, что после failback второй узел не регистрирует основной MAC-адрес Ethernet и начинает "ловить" 00:00:5e:00:01:01. Этот MAC-адрес принадлежит первому узлу после failback. В итоге я теряю связь со вторичным узлом и вынужден отключать и снова включать VRRP на этом узле.

uldis Guest	#16 0 08.06.2006 14:43:00 VRRP сейчас не работает на VLAN-интерфейсах.

changeip

Guest

#17

14.06.2006 23:56:00

199 — это виртуальный IP-адрес. У него ВСЕГДА должен быть MAC-адрес 00-00-5e-00-01-01. После переключения и возврата ты увидишь, что реальный MAC перемешивается с виртуальным, что, безусловно, сбивает с толку клиентов. Изменение MAC-адресов на портах коммутатора — это не проблема, коммутатор просто узнает их на другом порту моментально. Клиенты должны прислушиваться к gratuitous ARP и узнавать новый MAC — думаю, это работает, кроме того, что MT вещает неправильные пары IP/MAC. C:\Documents and Settings\Tiffany>arp -a 10.20.1.199 00-30-48-56-0d-6c dynamic 10.20.1.212 00-30-48-56-0d-6c dynamic 10.20.1.213 00-00-5e-00-01-01 dynamic C:\Documents and Settings\Tiffany>arp -a 10.20.1.199 00-30-48-56-7b-58 dynamic 10.20.1.212 00-30-48-56-0d-6c dynamic 10.20.1.213 00-30-48-56-7b-58 dynamic C:\Documents and Settings\Tiffany>arp -a 10.20.1.199 00-00-5e-00-01-01 dynamic 10.20.1.212 00-00-5e-00-01-01 dynamic 10.20.1.213 00-00-5e-00-01-01 dynamic 2.9.25 - отправил в поддержку письмо с деталями конфигурации.

nikhil Guest	#18 0 15.06.2006 04:46:00 Нормис, Евгений, Сергейс, вы можете это прокомментировать?

savage

Guest

#19

15.06.2006 06:19:00

Только что обратил внимание… Первый пост в этой теме: 20 августа 2004 года. Сегодняшняя дата: 15 июня 2006 года. Шок!!! И проблема до сих пор не решена… Почти два года, и решения нет? Похоже, покупка сервисного контракта от Mikrotik тоже не поможет, раз это программный сбой, а не проблема с конфигурацией. Хм, ждать или купить пару Cisco 29xx? Выбор, выбор…

nikhil Guest	#20 0 15.06.2006 06:57:00 Cisco 29xx — это коммутатор, без VRRP. VRRP на 3600, кажется, поддерживается.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры