L3 HSRP / VRRP — резервирование шлюза (FHRP)

В любом сегменте сети есть тихая единая точка отказа — шлюз по умолчанию. Умер один роутер — и целый этаж, офис или клиентский сегмент теряет связь с миром, хотя вся остальная сеть здорова. Протоколы семейства FHRP (First Hop Redundancy Protocol) — HSRP, VRRP, GLBP — решают эту проблему так элегантно, что пользователи не замечают аварию вовсе. Это тема CCNA, повседневность эксплуатации и источник классических ночных инцидентов — разберём до винтиков.

Что узнаешь

Почему «прописать два шлюза на хостах» — не решение, и что такое виртуальный IP + виртуальный MAC
HSRP: роли Active/Standby, выборы, priority и preempt, таймеры, состояния
Что происходит в момент аварии — по шагам, вместе с ролью gratuitous ARP
VRRP: чем отличается от HSRP и когда выбирать его (спойлер: когда не-Cisco)
GLBP и современный контекст: анонсы с двух ядер, VXLAN anycast-gateway — обзорно
Object tracking: как шлюз «понимает», что сам отрезан от мира, и уступает роль
Полные конфиги, чтение show standby, два плейбука типовых аварий

Вспомни из прошлых модулей

Модуль 2: хост перед отправкой «в чужую сеть» делает ARP-запрос на IP шлюза и дальше шлёт кадры на его MAC; ARP-записи живут в кэше. Gratuitous ARP — «объявление о себе без вопроса» — сегодня сыграет главную роль. Модуль 3: VLAN и «один broadcast-домен». Если это подзабылось — освежи: FHRP целиком построен на игре с ARP и MAC-адресами.

1. Проблема: шлюз — единая точка отказа

Представь сегмент: 200 рабочих станций, шлюз 10.1.10.1 — интерфейс роутера R1. Всё чужое (интернет, серверы, другие VLAN) хосты шлют на MAC этого интерфейса. Теперь R1 умирает: блок питания, дежурная перезагрузка, кривой апдейт — не важно. Что видит пользователь?

Внутри сегмента всё живо: соседи пингуются, принтер печатает (L2 работает — свитчи-то целы).
Наружу — тишина: пакеты «в чужие сети» уходят на MAC мёртвого роутера и умирают.
Рядом стоит полностью исправный R2, подключённый к тому же сегменту… и простаивает, потому что хосты о нём не знают: у них в настройках один шлюз — 10.1.10.1.

Наивные решения не работают, и понимать почему — важнее самих протоколов:

«Решение»	Почему плохо
Перенастроить шлюз на хостах руками	200 машин × ночь аварии. DHCP ускорит, но lease живут часами — простой всё равно огромный
Прописать на хостах два шлюза	Поведение ОС непредсказуемо: Windows/Linux не умеют честно и быстро «переключать» шлюзы; часть сессий молча умирает
Скрипт мониторинга, который меняет DHCP	Самодельный FHRP на костылях: медленно, хрупко, никто не поддержит

Правильная идея переворачивает задачу: не хосты должны узнавать о смене шлюза — шлюз должен «переезжать» между роутерами незаметно для хостов. Хосты как знали один IP и один MAC, так и знают. Меняется лишь то, какой физический роутер за ними стоит.

2. Виртуальный IP + виртуальный MAC — сердце FHRP

Два роутера объединяются в группу FHRP и совместно владеют парой «виртуальный IP + виртуальный MAC»:

Виртуальный IP (VIP) — например 10.1.10.1. Именно его прописывают хостам как шлюз. Реальные адреса роутеров — 10.1.10.2 (R1) и 10.1.10.3 (R2) — хостам вообще не интересны.
Виртуальный MAC — вычисляется из номера группы. Для HSRP v1: 0000.0c07.acXX (XX — номер группы hex), для VRRP: 0000.5e00.01XX. Увидел такой MAC в ARP-таблице — сразу знаешь: здесь FHRP, и даже какой именно.
В каждый момент времени ровно один роутер группы («активный») отвечает на ARP для VIP и реально пересылает трафик, пришедший на виртуальный MAC. Второй — на подхвате: слушает hello-пакеты активного и молчит.

Аналогия

FHRP = окно «Касса №1», за которым дежурят два кассира

Клиенты всегда подходят к окну с табличкой «Касса №1» (виртуальный IP+MAC). Кто из двух кассиров сидит за окном — клиентам всё равно и не видно. Основной кассир вышел — второй мгновенно пересаживается за то же окно, табличка не менялась, очередь ничего не заметила. Правило «кто сидит за окном» — это и есть протокол HSRP/VRRP.

3. HSRP: роли, выборы, таймеры

HSRP (Hot Standby Router Protocol) — проприетарный протокол Cisco, исторически первый и до сих пор самый распространённый в Cisco-сетях. Механика:

Роутеры группы обмениваются hello-пакетами (multicast 224.0.0.102 для v2, UDP 1985) каждые 3 секунды. Не слышно активного 10 секунд (hold) — он считается мёртвым.
Роли: Active (обслуживает VIP), Standby (первый в очереди на подхват), остальные (если роутеров больше двух) — Listen.
Выборы по priority (0–255, по умолчанию 100): выше — главнее. При равенстве — у кого больше IP-адрес интерфейса.
Состояния по пути к роли: Init → Learn → Listen → Speak → Standby → Active. В show standby ты видишь именно их.

! R1 — хотим сделать его основным R1(config)# interface Vlan10 R1(config-if)# ip address 10.1.10.2 255.255.255.0 R1(config-if)# standby version 2 R1(config-if)# standby 10 ip 10.1.10.1 ! виртуальный IP группы 10 R1(config-if)# standby 10 priority 110 ! выше дефолтных 100 → буду Active R1(config-if)# standby 10 preempt ! возвращать роль после восстановления (см. ниже!) ! R2 — резерв: достаточно указать группу и VIP R2(config)# interface Vlan10 R2(config-if)# ip address 10.1.10.3 255.255.255.0 R2(config-if)# standby version 2 R2(config-if)# standby 10 ip 10.1.10.1 R2(config-if)# standby 10 preempt

Проверяем — команда, которую ты будешь вводить на каждом дежурстве:

R1# show standby brief Interface Grp Prio P State Active Standby Virtual IP Vl10 10 110 P Active local 10.1.10.3 10.1.10.1 R2# show standby brief Vl10 10 100 P Standby 10.1.10.2 local 10.1.10.1

P — включён preempt; State — роль этого роутера; Active/Standby — кто есть кто в группе (с точки зрения этого роутера). Здоровая пара выглядит ровно так: один Active, один Standby, VIP совпадает.

Preempt — маленькая команда, большая политика

По умолчанию HSRP не отдаёт роль обратно: если R1 (priority 110) перезагрузился и вернулся, а Active уже R2 — R2 так и останется активным. preempt разрешает более приоритетному «отобрать» роль. Ставить ли его — вопрос политики: с preempt сеть всегда в «правильной» конфигурации, но восстановление R1 вызовет второе микропереключение. Обычно ставят — и на основном, и на резервном.

4. Момент аварии — по шагам

Вот что происходит в те секунды, когда R1 умирает (и почему пользователи ничего не замечают):

R2 перестаёт слышать hello

R1 молчит 10 секунд (hold-таймер; в проде часто тюнингуют до 1/3 с — hello 250 мс, hold 750 мс, тогда переключение почти мгновенное).

R2 объявляет себя Active

Переходит Standby → Active, вешает на свой интерфейс виртуальный MAC 0000.0c07.ac0a и начинает отвечать на ARP для 10.1.10.1.

Gratuitous ARP переучивает свитчи — ключевой шаг!

R2 рассылает gratuitous ARP с виртуальным MAC. Зачем? Хостам — незачем (у них в ARP-кэше и так «10.1.10.1 = вирт-MAC», ничего не изменилось!). А вот коммутаторам надо переучить MAC-таблицу: виртуальный MAC теперь живёт на другом порту. GARP обновляет это одним пакетом. Вспомни модуль 2 — вот где GARP зарабатывает свой хлеб.

Трафик течёт дальше

Хосты продолжают слать на тот же IP и тот же MAC. Для них не изменилось ничего — ни одной перенастройки, ни одного сброшенного ARP-кэша. Умерла железка — а сеть жива. Это и есть красота FHRP.

5. Object tracking: когда шлюз жив, но бесполезен

Коварный сценарий: R1 здоров, HSRP работает… но у R1 упал аплинк в сторону ядра/ интернета. Он гордо остаётся Active — и сливает весь трафик сегмента в чёрную дыру, пока полностью исправный R2 скучает. Лечение — tracking: следим за состоянием аплинка и при его падении снижаем свой priority, уступая роль:

R1(config)# track 1 interface Gi0/1 line-protocol ! следим за аплинком R1(config)# interface Vlan10 R1(config-if)# standby 10 track 1 decrement 20 ! аплинк упал → priority 110−20=90 ! 90 < 100 (priority R2) → R2 с preempt забирает Active. Аплинк вернулся → всё наоборот.

Track умеет следить не только за интерфейсом, но и за наличием маршрута и за доступностью адреса (IP SLA + ping) — «уступай роль, если не пингуется 8.8.8.8». Это уже прод-уровень зрелости конфига.

6. VRRP: то же самое, но стандарт

VRRP (Virtual Router Redundancy Protocol) — открытый стандарт (RFC 5798), делает ровно то же и живёт на всём: Cisco, Juniper, MikroTik, Linux (keepalived — да-да, VRRP держит виртуальные IP балансировщиков и кластеров, с ним ты встретишься и в DevOps). Отличия от HSRP — любимая таблица собеседующих:

	HSRP	VRRP
Происхождение	Cisco, проприетарный	открытый стандарт RFC 5798
Роли	Active / Standby	Master / Backup
Виртуальный MAC	`0000.0c07.acXX` (v1) / `0000.0c9f.fXXX` (v2)	`0000.5e00.01XX`
Multicast / протокол	224.0.0.2 (v1) / 224.0.0.102 (v2), UDP 1985	224.0.0.18, IP-протокол 112
Таймеры по умолчанию	hello 3 c / hold 10 c	advertisement 1 c — «из коробки» быстрее
Preempt по умолчанию	выключен	включён
VIP = реальный адрес интерфейса?	нельзя — VIP отдельный	можно (владелец адреса получает priority 255)

! VRRP на Cisco — почти дословно R1(config-if)# vrrp 10 ip 10.1.10.1 R1(config-if)# vrrp 10 priority 110 # VRRP на Linux — keepalived.conf (так живут балансировщики!) vrrp_instance VI_10 { state MASTER interface eth0 virtual_router_id 10 priority 110 virtual_ipaddress { 10.1.10.1/24 } }

Практическое правило выбора: чистая Cisco-сеть — HSRP (привычка и фичи), мультивендор или Linux — VRRP. Знать нужно оба: диагностика у них одинаковая до степени смешения.

GLBP и современный контекст — обзорно

GLBP (Cisco) добавляет балансировку: на ARP-запросы к одному VIP отвечает разными виртуальными MAC — трафик хостов размазывается по обоим роутерам. Красиво, но встречается редко; на собеседовании достаточно знать идею.
В современных фабриках ДЦ (VXLAN/EVPN — модуль 8) проблему решают иначе: anycast-gateway — один и тот же виртуальный IP/MAC шлюза настроен сразу на всех leaf-коммутаторах. FHRP там не нужен. А в классическом enterprise и у операторов HSRP/VRRP — по-прежнему рабочая лошадка №1.

7. Плейбук №1: «оба роутера стали Active» (split-brain)

Самая знаменитая авария FHRP. Симптомы: в логах мигают %HSRP-5-STATECHANGE … Standby -> Active, на обоих роутерах show standby brief показывает Active/local, в сегменте — конфликт MAC, у части хостов связь «то есть, то нет».

Пойми суть: они не слышат друг друга

Оба Active = hello-пакеты между роутерами не проходят, каждый честно решил «я один остался». Проблема не в HSRP — HSRP лишь индикатор разрыва L2 между ними.

Проверь L2-путь между роутерами

Пингуются ли реальные адреса (10.1.10.2 ↔ 10.1.10.3)? Нет — ищи разрыв: VLAN 10 не прописан/не разрешён на trunk между свитчами (самая частая причина!), порт в err-disable, физика. show vlan brief, show interfaces trunk.

Проверь совпадение параметров группы

Роутеры «не видят» друг друга и при несовпадении: номер группы, версия HSRP (v1 и v2 несовместимы — разные multicast-адреса!), VIP, аутентификация. Сверь конфиги построчно: show standby | include Group|Virtual|Auth.

Не бывает ли это ACL?

Реже, но метко: кто-то повесил ACL, режущий multicast 224.0.0.102 / протокол 112, или включил storm-control слишком агрессивно. Проверь недавние изменения.

После починки — убедись в ролях

show standby brief на обоих: один Active, второй Standby, счётчики state-change остановились. И запиши в тикет первопричину (trunk!), а не «пересобрал HSRP».

8. Плейбук №2: «переключение было, но связь падала на минуты»

Сколько ждали по таймерам?

Дефолт HSRP — 10 с hold. Для чувствительного сегмента это вечность. Тюнинг: standby 10 timers msec 250 msec 750 (согласованно на обоих!).

Свитчи переучились?

Если после failover часть хостов молчала минуты — MAC-таблицы свитчей не обновились (GARP потерялся/зарезан). Проверь, не фильтрует ли что-то GARP, и «пните» вручную: clear mac address-table dynamic vlan 10.

А не asymmetric ли всё стало?

Шлюз переехал на R2, а обратный трафик из ядра по-прежнему приходит на R1 (так решили маршруты выше). Само по себе не фатально, но в связке со stateful-фаерволом на пути — источник «односторонней» связи. Диагноз: трейс туда и обратно, сравнение путей.

Track настроен?

Если авария была «аплинк R1 упал, но Active он не отдал» — это не баг, это отсутствие tracking. Добавь track на аплинки (раздел 5) — и такой класс инцидентов исчезнет.

Вопрос с собеседования: почему при переключении HSRP хостам не нужно обновлять ARP-кэш?

Потому что и IP, и MAC шлюза — виртуальные и при failover переезжают на новый Active вместе. Запись «10.1.10.1 → 0000.0c07.ac0a» в кэше хоста остаётся верной. Обновиться должны только MAC-таблицы коммутаторов (порт виртуального MAC изменился) — для этого новый Active шлёт gratuitous ARP.

Вопрос с собеседования: чем HSRP отличается от VRRP? Назови три отличия.

1) HSRP — проприетарный Cisco, VRRP — открытый стандарт (работает и в keepalived/Linux). 2) Роли: Active/Standby vs Master/Backup; у VRRP preempt включён по умолчанию, у HSRP — нет. 3) Транспорт и MAC: HSRP — UDP 1985, MAC 0000.0c07.acXX; VRRP — IP-протокол 112, MAC 0000.5e00.01XX; таймеры VRRP по умолчанию быстрее (1 с против 3 с).

9. Мини-лаба

Найди FHRP в своей ARP-таблице (работа/учёба)

Открой arp -a в офисной/учебной сети и посмотри на MAC шлюза. Начинается с 00-00-0c-07-ac — здесь HSRP; 00-00-5e-00-01 — VRRP. Последний байт — номер группы. Ты только что «прочитал» дизайн сети из одного MAC-адреса.

Packet Tracer: собери пару за 15 минут

2 роутера + свитч + 2 ПК. Настрой HSRP по конфигам раздела 3, проверь show standby brief. Запусти непрерывный пинг с ПК на 8.8.8.8 (или loopback за роутерами) и выключи активный роутер. Посчитай потерянные пинги. Затем ужми таймеры (timers msec 250 msec 750) и повтори — почувствуй разницу.

Bonus для смелых: VRRP на Linux

Две виртуалки + apt install keepalived + конфиг из раздела 6. Убей MASTER — посмотри, как VIP переезжает (ip addr на BACKUP). Это ровно то, что делает пара балансировщиков в проде — ты уже умеешь.

10. Частые ошибки джунов

Ошибка	Последствие	Как правильно
VIP прописан как адрес интерфейса (HSRP)	конфликт адресов, группа не собирается	VIP — отдельный адрес; реальные IP роутеров — свои
Разные версии HSRP на паре (v1/v2)	не слышат друг друга → оба Active	`standby version 2` на обоих
Забыт preempt на «главном»	после ремонта основной не возвращает роль — сеть живёт «наоборот» месяцами незаметно	решай политику осознанно; обычно preempt на обоих
Нет track на аплинки	Active с мёртвым аплинком тянет трафик в дыру	track + decrement больше разницы priority
Таймеры ужаты только на одном роутере	флаппинг ролей	таймеры и аутентификация — зеркально на всей группе
Не смотрит на MAC 0000.0c07.ac… при диагностике	час ищет «чей это странный MAC»	выучи виртуальные OUI наизусть — это подпись FHRP

11. Словарик модуля

Термин	По-английски	Смысл в одну строку
FHRP	First Hop Redundancy Protocol	семейство протоколов резервирования шлюза (HSRP/VRRP/GLBP)
Виртуальный IP	VIP, virtual IP	адрес шлюза, которым владеет группа, а не конкретный роутер
Виртуальный MAC	virtual MAC	MAC группы (0000.0c07.acXX / 0000.5e00.01XX) — переезжает при failover
Active / Standby	—	роли HSRP: обслуживающий и подхватывающий
Master / Backup	—	те же роли в терминах VRRP
Priority / preempt	—	кто главнее / можно ли отобрать роль обратно
Hello / hold	—	пульс группы / сколько молчания = смерть
Tracking	object tracking	снижение priority при падении аплинка/маршрута/пинга
Split-brain	split brain	оба стали Active — симптом разрыва L2 между ними
keepalived	keepalived	VRRP-демон Linux — те же концепции в мире DevOps
Anycast-gateway	anycast gateway	«шлюз везде» в VXLAN/EVPN-фабриках — наследник FHRP в ДЦ

FHRP убирает единую точку отказа первого хопа: группа роутеров делит виртуальные IP и MAC, хосты не замечают аварию, потому что их настройки и ARP-кэш не меняются — переучиваются только MAC-таблицы свитчей (через gratuitous ARP нового Active). HSRP — Cisco (Active/Standby, hello 3/hold 10, preempt выключен), VRRP — стандарт (Master/Backup, быстрее, preempt включён, живёт и в keepalived). Обязательный прод-минимум: согласованные таймеры, preempt осознанно, track на аплинки. Оба Active = ищи разрыв L2, а не «баг HSRP».

12. Задачи — реши сам

Задача 1. В ARP-таблице офисного ПК шлюз 10.1.10.1 виден как 00-00-5e-00-01-0a. Что ты можешь сказать о сети, не заходя ни на одну железку?

OUI 0000.5e00.01 — это VRRP, последний байт 0a = группа 10. Значит шлюз зарезервирован минимум двумя устройствами (вероятно, не только Cisco — иначе чаще ставят HSRP), и при отказе одного из них ПК ничего не заметит.

Задача 2. R1: priority 110, preempt. R2: priority 100, preempt. R1 перезагрузился на 5 минут и вернулся. Кто Active через минуту после возвращения и почему? А если бы preempt не было ни у кого?

С preempt: R1 вернулся, увидел Active с priority 100 < 110 — отобрал роль, Active снова R1. Без preempt: роль остаётся у R2 навсегда (до его аварии) — сеть работает, но «наоборот», и однажды это удивит дежурного.

Задача 3. После failover пинги с хостов пошли через 40 секунд, хотя hold-таймер 10 с. Логи чистые. Куда смотреть?

На коммутаторы: роль переключилась за 10 с, но MAC-таблицы свитчей не переучились (GARP нового Active потерялся или отфильтрован) — кадры на виртуальный MAC летели в старый порт до истечения aging. Проверить прохождение GARP; при инциденте — clear mac address-table dynamic.

Задача 4. У R1 (Active) упал единственный аплинк в ядро. HSRP-группа в норме: R1 Active, R2 Standby. Пользователи без связи. Почему «в норме» — это и есть проблема, и что добавить в конфиг?

HSRP следит только за собой на этом интерфейсе, аплинк ему безразличен: R1 честно жив и держит роль, сливая трафик в никуда. Добавить object tracking: track 1 interface Gi0/1 line-protocol + standby 10 track 1 decrement 20 — при падении аплинка priority упадёт ниже R2, и роль уедет к нему.

Задача 5. На обоих роутерах show standby brief показывает State = Active. Перечисли три самые вероятные причины в порядке проверки.

1) Разрыв L2 между ними — VLAN не разрешён на trunk / порт down (проверяется пингом реальных адресов). 2) Несовпадение версии HSRP (v1 vs v2 — разные multicast-адреса) или номера группы/VIP/аутентификации. 3) ACL или storm-control, режущие hello-multicast. Это split-brain: чинится восстановлением связности, а не перезапуском HSRP.

Задача 6. DevOps-коллега говорит: «у нас два балансировщика с одним виртуальным IP на keepalived». Объясни ему в одном абзаце, что у него за технология и что будет при падении мастера.

Это VRRP — тот же протокол резервирования шлюза, только на Linux: мастер держит VIP на интерфейсе и шлёт advertisement каждую секунду. Умрёт мастер — backup за ~3 секунды объявит себя новым мастером, поднимет VIP у себя и разошлёт gratuitous ARP; клиенты продолжат ходить на тот же адрес, не заметив. Все грабли те же: split-brain при разрыве связности и необходимость согласованных приоритетов.

Мост дальше

Поздравляю — ты закрыл последний крупный блок ядра трека. Дальше два направления: закрепить всё методологией troubleshooting и packet capture (если прошёл модули не по порядку) и собрать первую серьёзную лабораторию — кампус с VLAN, OSPF и парой HSRP-шлюзов в Packet Tracer/containerlab. А на странице профессии «Инженер СПД» смотри следующую ступень — глубину и мост в NetDevOps.