Теория: Отказоустойчивый шлюз: VRRP
Как два роутера делят один адрес шлюза так, что хост ничего не замечает: виртуальный MAC, приоритеты и выборы, preempt, таймеры переключения, отслеживание аплинка и балансировка двумя группами. Прочитайте материал, а затем пройдите тест — следующий пункт курса откроется после верных ответов.
Шлюз — самая обидная точка отказа
Соберите сколь угодно отказоустойчивую сеть: два аплинка, кольцо, динамическая маршрутизация, резерв на каждом плече. А потом посмотрите на настройки обычного компьютера в этой сети — там будет один адрес шлюза. Один. И если устройство с этим адресом выключится, вся отказоустойчивость окажется бесполезной: хост просто не знает, куда ещё отправлять пакеты наружу.
Обидно тут то, что резервный роутер рядом и полностью исправен. Он видит сеть, знает маршруты, готов работать — но у него другой адрес, и хосты о нём не подозревают.
Первое, что приходит в голову, — раздавать хостам два шлюза. Так нельзя: поле «шлюз по умолчанию» одно и в DHCP, и в настройках интерфейса. Второе — поднять на хостах маршрутизацию. Тоже мимо: держать протокол на каждом ноутбуке никто не станет.
Рабочее решение противоположное по логике: не хост должен узнать про второй роутер, а второй роутер должен научиться отзываться на адрес первого.
Обидно тут то, что резервный роутер рядом и полностью исправен. Он видит сеть, знает маршруты, готов работать — но у него другой адрес, и хосты о нём не подозревают.
Первое, что приходит в голову, — раздавать хостам два шлюза. Так нельзя: поле «шлюз по умолчанию» одно и в DHCP, и в настройках интерфейса. Второе — поднять на хостах маршрутизацию. Тоже мимо: держать протокол на каждом ноутбуке никто не станет.
Рабочее решение противоположное по логике: не хост должен узнать про второй роутер, а второй роутер должен научиться отзываться на адрес первого.
Адрес, который переезжает
Два роутера договариваются между собой и заводят виртуальный адрес — третий, не принадлежащий никому из них лично. Именно его получают хосты как шлюз по умолчанию.
В каждый момент времени адресом владеет ровно один роутер — мастер. Он отвечает на ARP-запросы за виртуальный адрес и маршрутизирует трафик хостов. Второй — резерв — молча слушает объявления мастера и ничего не делает.
Пропали объявления — резерв объявляет себя новым мастером и начинает отвечать за тот же адрес. С точки зрения хоста не изменилось ничего: адрес шлюза тот же, настройки те же, перенастраивать нечего.
Роутеры в такой паре образуют группу со своим номером — VRID, от 1 до 255. Номер должен совпадать у всех участников: он попадает в объявления и в виртуальный MAC, а роутеры с разными номерами друг друга просто не замечают.
В каждый момент времени адресом владеет ровно один роутер — мастер. Он отвечает на ARP-запросы за виртуальный адрес и маршрутизирует трафик хостов. Второй — резерв — молча слушает объявления мастера и ничего не делает.
Пропали объявления — резерв объявляет себя новым мастером и начинает отвечать за тот же адрес. С точки зрения хоста не изменилось ничего: адрес шлюза тот же, настройки те же, перенастраивать нечего.
Роутеры в такой паре образуют группу со своим номером — VRID, от 1 до 255. Номер должен совпадать у всех участников: он попадает в объявления и в виртуальный MAC, а роутеры с разными номерами друг друга просто не замечают.
Почему одного адреса мало: виртуальный MAC
Кажется, что достаточно переносить IP-адрес. Но хост, отправляя пакет шлюзу, кладёт в кадр MAC-адрес, взятый из своей ARP-таблицы. Записи в ней живут минутами. Если бы при переключении менялся MAC, каждому хосту пришлось бы дождаться устаревания записи — и всё это время его трафик уходил бы на мёртвый роутер.
Поэтому вместе с адресом переезжает и виртуальный MAC, построенный по фиксированному правилу:
Для хоста при переключении не меняется ни адрес, ни MAC. Меняется только порт коммутатора, за которым этот MAC находится, — и об этом коммутатор узнаёт из gratuitous ARP, который новый мастер рассылает сразу после захвата роли. Именно эта рассылка и делает переключение почти мгновенным.
Поэтому вместе с адресом переезжает и виртуальный MAC, построенный по фиксированному правилу:
00:00:5e:00:01:VRID для IPv4 00:00:5e:00:02:VRID для IPv6Группа номер 1 всегда получает MAC
00:00:5e:00:01:01, и он же будет у любой другой первой группы в любой другой сети — это не уникальный идентификатор устройства, а метка роли.Для хоста при переключении не меняется ни адрес, ни MAC. Меняется только порт коммутатора, за которым этот MAC находится, — и об этом коммутатор узнаёт из gratuitous ARP, который новый мастер рассылает сразу после захвата роли. Именно эта рассылка и делает переключение почти мгновенным.
Смотрите на нижнюю строку: у хоста не меняется ничего — ни адрес
шлюза, ни MAC в его таблице. Меняется только то, за каким портом коммутатора этот MAC
находится. В этом весь смысл виртуального MAC: без него каждому хосту пришлось бы ждать,
пока устареет его собственная запись, и всё это время слать трафик мёртвому роутеру.
Кто станет мастером: приоритет и выборы
У каждого участника группы есть приоритет от 1 до 254, по умолчанию 100. Мастером становится тот, у кого он выше; при равенстве выигрывает больший IP-адрес интерфейса.
Значение 255 зарезервировано и означает особый случай: роутер, у которого виртуальный адрес совпадает с его собственным реальным адресом (владелец адреса). Такой участник забирает роль всегда.
Мастер раз в интервал рассылает объявления на групповой адрес
Отдельно стоит запомнить: VRRP не проверяет, что участники группы настроены одинаково. Опечатка в виртуальном адресе на резерве не помешает ничему — роли распределятся, объявления пойдут, состояние будет выглядеть здоровым. Проблема вылезет ровно в момент отказа мастера, то есть в худший из возможных.
Значение 255 зарезервировано и означает особый случай: роутер, у которого виртуальный адрес совпадает с его собственным реальным адресом (владелец адреса). Такой участник забирает роль всегда.
Мастер раз в интервал рассылает объявления на групповой адрес
224.0.0.18 (для IPv6 — ff02::12), протокол 112. Пока объявления слышны, резерв не делает ничего.Отдельно стоит запомнить: VRRP не проверяет, что участники группы настроены одинаково. Опечатка в виртуальном адресе на резерве не помешает ничему — роли распределятся, объявления пойдут, состояние будет выглядеть здоровым. Проблема вылезет ровно в момент отказа мастера, то есть в худший из возможных.
Preempt: забирать роль обратно или нет
Мастер отказал, резерв подхватил, инженер починил основной роутер. Что должно произойти дальше — вопрос настройки.
• Preempt включён (по умолчанию): вернувшийся роутер с более высоким приоритетом сразу забирает роль обратно. Хорошо, когда основной шлюз действительно лучше — например, у него толще канал наружу.
• Preempt выключен: роль остаётся у того, кто её держит, пока он жив. Хорошо, когда плечи равноценны: лишнее переключение — это лишний обрыв сессий, даже если он длится доли секунды.
Практическое правило: каждое переключение чего-то стоит. Если разницы между роутерами нет, возвращать роль незачем. А вот если основной роутер флапает — включённый preempt превратит это в постоянную чехарду ролей, и лечится это не выключением preempt, а починкой роутера.
• Preempt включён (по умолчанию): вернувшийся роутер с более высоким приоритетом сразу забирает роль обратно. Хорошо, когда основной шлюз действительно лучше — например, у него толще канал наружу.
• Preempt выключен: роль остаётся у того, кто её держит, пока он жив. Хорошо, когда плечи равноценны: лишнее переключение — это лишний обрыв сессий, даже если он длится доли секунды.
Практическое правило: каждое переключение чего-то стоит. Если разницы между роутерами нет, возвращать роль незачем. А вот если основной роутер флапает — включённый preempt превратит это в постоянную чехарду ролей, и лечится это не выключением preempt, а починкой роутера.
Как быстро замечают отказ
Резерв признаёт мастера мёртвым не сразу. Время ожидания считается так:
Поправка на приоритет (skew) нужна на случай, когда резервов несколько: чем выше приоритет, тем короче ожидание, и роль первым заберёт самый приоритетный, а не самый быстрый.
Интервал уменьшают — до сотен миллисекунд — и переключение становится почти незаметным. Плата за это чувствительность к потерям: три пропавших подряд объявления при интервале 300 мс — это меньше секунды неудачи на канале, и роль уедет туда-обратно на ровном месте. Ставить агрессивные таймеры имеет смысл там, где потери — это авария, а не будни.
Master Down Interval = 3 × интервал объявлений + skew skew = (256 − приоритет) × интервал / 256При стандартном интервале в одну секунду и приоритете 100 это чуть больше трёх секунд. Три секунды — это уже заметный обрыв: разговор оборвётся, сессии переустановятся, пользователь заметит.
Поправка на приоритет (skew) нужна на случай, когда резервов несколько: чем выше приоритет, тем короче ожидание, и роль первым заберёт самый приоритетный, а не самый быстрый.
Интервал уменьшают — до сотен миллисекунд — и переключение становится почти незаметным. Плата за это чувствительность к потерям: три пропавших подряд объявления при интервале 300 мс — это меньше секунды неудачи на канале, и роль уедет туда-обратно на ровном месте. Ставить агрессивные таймеры имеет смысл там, где потери — это авария, а не будни.
Отслеживание аплинка: мастер жив, а выхода нет
Классическая ловушка. Основной роутер работает, объявления рассылает, роль держит — а его канал наружу оборвался. Хосты исправно шлют трафик мастеру, мастер исправно принимает его и не может доставить никуда. Резерв при этом полностью исправен и с рабочим каналом.
Само по себе VRRP такой случай не различает: оно следит только за тем, слышны ли объявления, а слышны они прекрасно.
Лечится это отслеживанием (tracking): роутер привязывает свой приоритет к состоянию аплинка. Упал внешний интерфейс — приоритет автоматически падает, скажем, на 50, резерв оказывается приоритетнее и забирает роль. На оборудовании Cisco это
Важная оговорка для практики: отслеживания нет в самом стандарте VRRP — это вендорское расширение. В частности, здесь его нет, и приоритетом там управляют вручную или снаружи. Проектируя отказоустойчивость на конкретном железе, этот пункт проверяют первым.
Само по себе VRRP такой случай не различает: оно следит только за тем, слышны ли объявления, а слышны они прекрасно.
Лечится это отслеживанием (tracking): роутер привязывает свой приоритет к состоянию аплинка. Упал внешний интерфейс — приоритет автоматически падает, скажем, на 50, резерв оказывается приоритетнее и забирает роль. На оборудовании Cisco это
vrrp 1 track interface, на других вендорах — свои варианты.Важная оговорка для практики: отслеживания нет в самом стандарте VRRP — это вендорское расширение. В частности, здесь его нет, и приоритетом там управляют вручную или снаружи. Проектируя отказоустойчивость на конкретном железе, этот пункт проверяют первым.
Балансировка: две группы навстречу друг другу
Резервный роутер простаивает: он полностью исправен, но весь трафик идёт через мастера. Половина мощности стоит без дела.
Приём, который это исправляет, простой — две группы вместо одной:
• группа 1: виртуальный адрес
• группа 2: виртуальный адрес
Половине хостов раздают в качестве шлюза первый адрес, половине — второй. В обычном режиме работают оба роутера, при отказе любого из них оставшийся забирает обе роли и тянет всё один.
Делить хостов удобно через DHCP: два пула, два разных шлюза. И сразу оговорка о честности: это балансировка «по половине хостов», а не по нагрузке. Если все тяжёлые клиенты окажутся в одной половине, перекос останется. Настоящую балансировку между шлюзами умеет GLBP — но он проприетарный, и встречается редко.
Приём, который это исправляет, простой — две группы вместо одной:
• группа 1: виртуальный адрес
…50.1, мастер r1, резерв r2;• группа 2: виртуальный адрес
…50.2, мастер r2, резерв r1.Половине хостов раздают в качестве шлюза первый адрес, половине — второй. В обычном режиме работают оба роутера, при отказе любого из них оставшийся забирает обе роли и тянет всё один.
Делить хостов удобно через DHCP: два пула, два разных шлюза. И сразу оговорка о честности: это балансировка «по половине хостов», а не по нагрузке. Если все тяжёлые клиенты окажутся в одной половине, перекос останется. Настоящую балансировку между шлюзами умеет GLBP — но он проприетарный, и встречается редко.
VRRP, HSRP и родственники
VRRP — открытый стандарт (RFC 3768 для второй версии, RFC 5798 для третьей, где появился IPv6). Работает на оборудовании любых вендоров и в Linux, поэтому в смешанной сети выбирают его.
HSRP — то же самое, но проприетарное, от Cisco. Отличается деталями: свой групповой адрес, свой диапазон виртуальных MAC (
GLBP — тоже Cisco, но с настоящей балансировкой: один виртуальный адрес, а в ответ на ARP разным хостам выдаются MAC-адреса разных роутеров.
И то, чем VRRP не является: это не резервирование канала и не резервирование маршрутов. VRRP решает ровно одну задачу — подменить шлюз, о котором знает хост. Каналы резервируются агрегацией, маршруты — динамической маршрутизацией, а всё вместе они работают, только если настроены все три.
HSRP — то же самое, но проприетарное, от Cisco. Отличается деталями: свой групповой адрес, свой диапазон виртуальных MAC (
00:00:0c:07:ac:XX), понятия active и standby вместо мастера и резерва. Смысл тот же.GLBP — тоже Cisco, но с настоящей балансировкой: один виртуальный адрес, а в ответ на ARP разным хостам выдаются MAC-адреса разных роутеров.
И то, чем VRRP не является: это не резервирование канала и не резервирование маршрутов. VRRP решает ровно одну задачу — подменить шлюз, о котором знает хост. Каналы резервируются агрегацией, маршруты — динамической маршрутизацией, а всё вместе они работают, только если настроены все три.
Что здесь ломается
Разные VRID у участников. Роутеры не видят друг друга и оба становятся мастерами. В сети два устройства с одним адресом, трафик рвётся через раз.
Опечатка в виртуальном адресе на резерве. Всё выглядит исправным, роли распределены. Сеть встанет в момент отказа мастера — именно тогда, когда резерв и был нужен.
Резерв административно выключен. Мониторинг зелёный, пользователи довольны, резервирования нет. Самая тихая из аварий: обнаруживается либо проверкой, либо настоящим отказом.
Приоритеты выставлены наоборот. Мастером стал роутер с тонким или дорогим каналом. Работает, но не так, как задумано, и заметно это обычно по счёту от провайдера.
Нет отслеживания аплинка. Мастер жив, канал наружу мёртв, переключения не происходит. Классика.
Слишком агрессивные таймеры. Роль скачет от каждой потери пакета, сессии рвутся чаще, чем при полном отсутствии резерва.
Забыли, что нужен ещё и обратный путь. Хосты ходят через виртуальный адрес, а вышестоящая сеть должна уметь вернуть ответы через любого из двух роутеров. Если маршрут наверх прописан только на одного — переключение сломает связность в обратную сторону.
Опечатка в виртуальном адресе на резерве. Всё выглядит исправным, роли распределены. Сеть встанет в момент отказа мастера — именно тогда, когда резерв и был нужен.
Резерв административно выключен. Мониторинг зелёный, пользователи довольны, резервирования нет. Самая тихая из аварий: обнаруживается либо проверкой, либо настоящим отказом.
Приоритеты выставлены наоборот. Мастером стал роутер с тонким или дорогим каналом. Работает, но не так, как задумано, и заметно это обычно по счёту от провайдера.
Нет отслеживания аплинка. Мастер жив, канал наружу мёртв, переключения не происходит. Классика.
Слишком агрессивные таймеры. Роль скачет от каждой потери пакета, сессии рвутся чаще, чем при полном отсутствии резерва.
Забыли, что нужен ещё и обратный путь. Хосты ходят через виртуальный адрес, а вышестоящая сеть должна уметь вернуть ответы через любого из двух роутеров. Если маршрут наверх прописан только на одного — переключение сломает связность в обратную сторону.
Как проверять
show vrrp — главная команда. В выводе сразу видно всё нужное: номер группы, роль (Master / Backup / Initialize), приоритет, виртуальный MAC, список виртуальных адресов и интервал объявлений. Начинать разбор всегда отсюда, и обязательно на обоих роутерах: половина проблем видна только при сравнении.show vrrp 1 — та же карточка с счётчиками: сколько объявлений отправлено и получено, сколько было смен состояния. Ноль в «получено» у резерва означает, что мастера он не слышит вовсе — и дело не в VRRP, а в сегменте.ip neigh show <виртуальный адрес> на хосте — какой MAC отвечает за шлюз. Там должен стоять виртуальный 00:00:5e:00:01:XX, а не настоящий адрес роутера. Настоящий означает, что виртуальный MAC не поднялся и переключение будет заметным.И приём, который стоит завести привычкой: проверять резерв, а не мастера. Мастер работает — это видно и так. Смысл проверки в том, чтобы убедиться, что подхватит второй.
Команды — шпаргалка
# базовая группа: адрес и приоритет
interface eth1
vrrp 1 ip 192.168.50.1 # 1 — номер группы (VRID), одинаковый у обоих
# роутеров. Дальше виртуальный адрес, который
# хосты видят как шлюз
vrrp 1 priority 200 # приоритет в группе: по умолчанию 100,
# больше — важнее, кто важнее, тот и главный
# таймеры и режим
vrrp 1 advertisement-interval 300 # как часто главный подаёт голос,
# в миллисекундах
no vrrp 1 preempt # no снимает поведение по умолчанию:
# вернувшийся роутер НЕ заберёт роль обратно
vrrp 1 version 3 # версия протокола, третья и так по умолчанию
# вторая группа для балансировки
vrrp 2 ip 192.168.50.2 # другой VRID и другой виртуальный адрес:
# половину хостов направляют на него
vrrp 2 priority 100
# вывести из работы, не удаляя настройку
vrrp 1 shutdown # номер группы, которую выводим из работы
# в Linux виртуальный MAC живёт на отдельном подинтерфейсе
ip link add vrrp4-1 link eth1 addr 00:00:5e:00:01:01 type macvlan mode bridge
# vrrp4-1 — имя нового интерфейса;
# link eth1 — поверх какого он создаётся;
# addr — виртуальный MAC, последний байт
# равен номеру группы; type macvlan — «свой
# MAC на общем порту»
ip addr add 192.168.50.1/24 dev vrrp4-1
ip link set vrrp4-1 up
sysctl -w net.ipv4.conf.all.arp_ignore=1
# -w — записать значение. Без него на ARP-запрос
# про виртуальный адрес ответит обычный порт,
# и хосты выучат не тот MAC
# проверка
show vrrp # все группы: кто главный, кто запасной
show vrrp 1 # номер сужает вывод до одной группы
ip neigh show 192.168.50.1 # на хосте: чей MAC он видит за шлюзомКонтрольные вопросы
Дальше — лабораторная работа «VRRP: выдерни мастер»
Для неё нужен аккаунт: стенд поднимается персонально под вас — свои роутеры, свои конфиги, никто в них не мешает. Регистрация — почта и пароль.
Теория прочитана. Дальше — руками.
Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.
Начать бесплатно →
бета открыта, доступ бесплатный