FHRP (First Hop Redundancy Protocol) — семейство протоколов, предназначенных для создания избыточности шлюза по умолчанию. Общей идеей для данных протоколов является объединение нескольких маршрутизаторов в один виртуальный маршрутизатор с общим IP адресом. Этот IP адрес будет назначаться на хостах как адрес шлюза по умолчанию. Свободной реализацией данной идеи является протокол VRRP (Virtual Router Redundancy Protocol). В этой статье рассмотрим основы протокола VRRP.


VRRP-маршрутизаторы объединяются в один виртуальный маршрутизатор. Все маршрутизаторы в группе имеют общий виртуальный IP (VIP) адрес и общий номер группы или VRID (Virtual Router Identifier). Один маршрутизатор может состоять в нескольких группах, каждая из которых должна иметь свою уникальную пару VIP/VRID.

В случае с Cisco виртуальный маршрутизатор задается на интересующем нас интерфейсе командой:

R1(config-if)# vrrp <group-number> ip <ip-address>

Все маршрутизаторы делятся на два типа: VRRP Master и VRRP Backup.

VRRP Master — это маршрутизатор, который занимается пересылкой пакетов для данного виртуальной группы.

VRRP Backup — это маршрутизатор, который ожидает пакет от Master. Если пакеты от Master перестают приходить, Backup пытается перейти в состояние Master.

Маршрутизатор становится Master, если имеет наивысший приоритет. Master постоянно рассылает сообщения на широковещательный адрес 224.0.0.18, чтобы сообщить Backup маршрутизаторам, что он работает. Master отправляет сообщения согласно таймеру Adver Timer, равный по умолчанию 1 секунде.


При этом в качестве MAC адреса отправителя используется адрес группы 00:00:5E:00:01:xx, где xx — VRID в шестнадцатеричном формате. В данном примере используется первая группа.


Если Backup маршрутизаторы не получают сообщения в течении трех Adver Timer (Master Down Timer), то новым Master становится маршрутизатор с наибольшим приоритетом, либо маршрутизатор с наибольшим IP. При этом Backup маршрутизатор с более высоким приоритетом перехватит роль Master с более низким приоритетом. Однако, когда у Backup отключен режим preempt, Backup не станет перехватывать роль у Master.

R1(config-if)# no vrrp <group-number> preempt

Если VRRP-маршрутизатор является владельцем VIP адреса, то он всегда перехватывает роль Master.

VRRP приоритет задается в значениях от 1 до 254. Значение 0 зарезервировано для случаев, когда Master необходимо снять с себя ответственность за маршрутизацию. Значение 255 устанавливается маршрутизатору владельцу VIP. Приоритет по умолчанию равен 100, но может задаваться административно:

R1(config-if)#vrrp <group-number> priority <priority 1-254>

Здесь мы можем увидеть приоритет маршрутизатора, когда он задан административно:


А тут представлен случай, когда маршрутизатор является владельцем VIP:


VRRP маршрутизатор может иметь три состояния: Initialize, Backup, Master. Эти состояния маршрутизатор последовательное меняет.

В состоянии Initialize маршрутизатор ожидает начала работы. Если этот маршрутизатор является владельцем VIP адреса (приоритет равен 255), то маршрутизатор отправляет сообщения о том что становится Master. Он также отправляет gratuitous ARP-запрос, в котором MAC-адрес источника равен адресу виртуального маршрутизатора. Затем он переходит в состояние Master. Если маршрутизатор не является владельцем VIP, то он переходит в состояние Backup.


В состоянии Backup маршрутизатор ожидает пакеты от Master. Маршрутизатор в этом состоянии не отвечает на ARP-запросы от VIP-адреса. Также он не принимает пакеты, у которых в качестве адреса назначения стоит MAC-адрес виртуального маршрутизатора.

Если Backup не получает сообщения от Master в течение Master Down Timer, то он отправляет VRRP сообщение о том, что собирается стать Master. Затем отправляет широковещательное VRRP сообщение, в котором MAC-адрес источника равен адресу этого виртуального маршрутизатора. В данном сообщении маршрутизатор указывает свой приоритет.

В состоянии Master маршрутизатор обрабатывает пакеты, адресованные виртуальному маршрутизатору. Он так же отвечает на ARP-запросы к VIP. Master рассылает VRRP сообщения каждые Adver Timer, чтобы подтвердить что он работает.

*May 13 19:52:18.531: %VRRP-6-STATECHANGE: Et1/0 Grp 1 state Init -> Backup
*May 13 19:52:21.751: %VRRP-6-STATECHANGE: Et1/0 Grp 1 state Backup -> Master

VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами. Для этого на одном интерфейсе создается две VRRP группы. Одной группе назначается больший приоритет, чем другой. При этом на втором маршрутизаторе приоритет задается противоположным образом. Т.е. если на одном маршрутизаторе приоритет первой группы равно 100, а второй группы — 200, то на другом маршрутизаторе приоритет первой группы будет 200, а второй 100.

Как сказано ранее, в каждой группе должен быть свой уникальный VIP. В итоге, мы получаем два ip адреса, обслуживаемые двумя маршрутизаторами, каждый из которых может служить шлюзом по умолчанию.


Половине компьютеров назначается один адрес шлюза по умолчанию, половине другой. Таким образом половина трафика будет идти через один маршрутизатор, а половина через другой. При выходе из строя одного из маршрутизаторов, второй перехватывает на себя работу обеих VIP.


Таким образом VRRP позволяет организовать отказоустойчивость шлюза по умолчанию, повысив надежность сети. А в случае использования нескольких виртуальных маршрутизаторов можно и балансировать нагрузку между реальными маршрутизаторами. Скорость реакции на отказ может быть сокращена за счет уменьшения таймеров.

Комментарии (6)


  1. Kolobokteam
    19.05.2019 15:36

    «VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами.» — это псевдобалансировка. Фактически мы получаем два разных виртуальных маршрутизатора. Это усложняет администрирование сети и ведёт к ошибкам. Почему бы не сравнить VRRP с GLBP, который действительно балансирует трафик в рамках одного виртуального маршрутизатора?


    1. KndK Автор
      19.05.2019 15:45

      Спасибо за замечание! Действительно, в VRRP нет истинной балансировки, и не всегда разумно применять сценарий с двумя виртуальными маршрутизаторами, но иногда это бывает удобно. Например, в сценариях, когда устройства получают статический конфиг (фермы серверов).

      GLBP прекрасный протокол, однако, у него есть одна беда — проприетарность. То есть в реальном случае его применение ограничено.


      1. dklm
        20.05.2019 12:02

        вроде я все понял =) и тут всплывает одно замечания = сервера должны находится в отдельном влане… делать два виртуальных роутера для одной подсети очень спорное решение, когда вы делаетет под каждый влан(подсеть) свои виртуальные роутеры тот тут все ок(не поспоришь)…


        1. KndK Автор
          20.05.2019 13:07

          Проблем нет, и VRRP, и HSRP, и GLBP замечательно будут работать на сабинтерфейсах. Вопрос архитектуры сети.


  1. UrbanRider
    19.05.2019 16:32

    Мне интересно, а чисто с точки зрения обывателя чем этот VRRP лучше HSRP (standby group)?


    1. KndK Автор
      19.05.2019 17:24

      VRRP это открытый стандарт, RFC 2338. Если у вас не только оборудование известного вендора, то лучше использовать VRRP за его открытость.
      Хотя, в целом, VRRP и HSRP очень похожи. Однако, в VRRP короче таймеры по умолчанию и виртуальный маршрутизатор может быть владельцем VIP(IP интерефейса совпадает с VIP). А в HSRP другие роли у маршрутизаторов и по умолчанию preempt выключен.
      Если же у вас оборудование того самого вендора, то думаю, лучше взять GLBP, как заметили выше, в нем больше фич.