Принцип работы протокола VRRP

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 позволяет организовать отказоустойчивость шлюза по умолчанию, повысив надежность сети. А в случае использования нескольких виртуальных маршрутизаторов можно и балансировать нагрузку между реальными маршрутизаторами. Скорость реакции на отказ может быть сокращена за счет уменьшения таймеров.
  • +20
  • 14.7k
  • 9
Support the author
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    0
    «VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами.» — это псевдобалансировка. Фактически мы получаем два разных виртуальных маршрутизатора. Это усложняет администрирование сети и ведёт к ошибкам. Почему бы не сравнить VRRP с GLBP, который действительно балансирует трафик в рамках одного виртуального маршрутизатора?
      +1
      Спасибо за замечание! Действительно, в VRRP нет истинной балансировки, и не всегда разумно применять сценарий с двумя виртуальными маршрутизаторами, но иногда это бывает удобно. Например, в сценариях, когда устройства получают статический конфиг (фермы серверов).

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

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

      0
      Мне интересно, а чисто с точки зрения обывателя чем этот VRRP лучше HSRP (standby group)?
        0
        VRRP это открытый стандарт, RFC 2338. Если у вас не только оборудование известного вендора, то лучше использовать VRRP за его открытость.
        Хотя, в целом, VRRP и HSRP очень похожи. Однако, в VRRP короче таймеры по умолчанию и виртуальный маршрутизатор может быть владельцем VIP(IP интерефейса совпадает с VIP). А в HSRP другие роли у маршрутизаторов и по умолчанию preempt выключен.
        Если же у вас оборудование того самого вендора, то думаю, лучше взять GLBP, как заметили выше, в нем больше фич.
          0
          Как уже было замечено VRRP — открытый стандарт. Он работает на всех производителях (условно). Но у «того» производителя, в VRRP будут сложности с NAT, PolicyBasedRouting и прочими сложносочиненными конфигами. В сложных конфигурациях (а простых наверное не бывает) лучше переходить на HSRP.
          0
          У вас не описан кейс с отказом одного из uplink’ок к Rx — ISP, если такое произойдёт вы получите black hole. Компьютеры на схеме имеют одинаковые ip.
            0
            Действительно, в случае отказа одного из uplink’ов будет black hole. Для таких случаев можно настроить IP SLA или подобный функционал.

          Only users with full accounts can post comments. Log in, please.