Резервирование маршрутизатора с использованием протокола VRRP

[Karroplan]

Лучше вместо обвязки вокруг vrrp у которого есть мноооого проблем, тем более в облаке, сделайте для доступный для клиентов балансировщик нагрузки. Я уже не знаю на чем у вас внутренний sdn (надеюсь он у вас есть), но вот у vmWare NSX есть встроенная функция балансировщика, причем распределенного. вместо того чтоб городить костыли вокруг протоколов с 20-летней историей начните использовать современные технологии.

[CMHungry]

балансировщики у VMWare — это программные решения, и ограничения реальные около 1-1.5 мппс. В случае VRRP мы это делаем на железных маршрутизаторах и можем переварить бОльшую нагрузку.

[evg_krsk]

«На конечном хосте прописывается адрес 12.34.56.78, на маршрутизаторе — .72» — 73 же.

UPD: и на картинке .72. amarao на вас нет :-)

[CMHungry]

спасибо, текст поправили, картинку поправим

[CMHungry]

Даунтайм будет, к сожалению.
В маршрутизаторе компоненты сами по себе redundant — два модуля управления, 4 блока питания, несколько модулей системной шины, несколько линейных карт.

По опыту — сервер имеет больше шансов сломаться, нежели чем маршрутизатор.

[tgz]

Скучно. Раз уж пишете про ЦОДы, рассказали бы как при дефиците IP раздавать на сервера /32.
Впрочем у вас же ждунипер, там такое не бывает.
И вообще ни один вендор до сих пор vrrp от используемой подсети не отвязал, так и городят костыли, нещасные…

[Sarge]

А что будет в случае падения VRRP-линка между маршами?

[CMHungry]

split-brain будет. Поэтому каналы резервированные между ними.