Привет, Хабр! Меня зовут Никита Николайчук и в настоящее время я являюсь преподавателем курса «Сетевой инженер» в OTUS.

Я подготовил статью по FHRP, которая позволит структурировать знания в этой теме, обратить внимание на подводные камни и познакомиться с некоторыми особенностями реализации этой группы протоколов.

FHRP (First Hop Redundancy Protocol) — это название семейства протоколов, которое отвечает за резервирование шлюза по умолчанию (default gateway) и повышает отказоустойчивость сети. Другими словами, эта группа протоколов позволяет избежать больших потерь трафика в случае, если на шлюзе по умолчанию возникли проблемы.

Для того чтобы лучше разобраться в том, о чем далее пойдет речь, вспомним трехуровневую модель сети (см. рис. 1).

На данной схеме сверху находится ядро сети (Core), там расположены устройства, которые работают на L3 и осуществляют маршрутизацию. Ниже идет уровень агрегации или дистрибьюции (Aggregation/Distribution), там могут находиться устройства как L2, так и L3 уровня. И последний — уровень доступа (Access), там находятся L2-коммутаторы, к которым, как правило, подключаются клиентские устройства. От технологий L2, которые «процветают» на уровне доступа к L3 на уровне ядра должен быть выполнен переход, который обычно осуществляется на уровне Aggregation/Distribution. В общем случае тенденция такова, что чем более современный дизайн у сети, тем больший сегмент сети построен именно на L3 (есть решения типа L3 to access, в которых маршрутизацию можно увидеть даже на уровне доступа). В более старых сетях домен L3 минимальный и часто ограничивается только уровнем ядра сети.

Рассмотрим коммутатор доступа, который работает в L2 сети и к которому подключаются клиентские устройства (см. рис. 2).

Данный коммутатор подключается к маршрутизатору уровня Aggregation/Distribution, а тот в свою очередь подключен к ядру сети. В такой архитектуре подсеть пользователей, подключенных к коммутатору доступа, терминируется на маршрутизаторе уровня Aggregation/Distribution (R2). Отметим, что в общем случае на коммутаторе может быть настроено несколько VLAN и все они терминируются на маршрутизаторе R2.

Рассмотрим, ситуацию, когда на R2 произошла какая‑то проблема: это может быть как полный выход из строя данного маршрутизатора, так и выход из строя какого‑либо из его интерфейсов (в нашем случае, например, в сторону коммутатора доступа). При возникновении такой проблемы (см. рис. 3) все сети доступа, которые терминировались на R2, будут недоступны (отрезаны от ядра сети).

Отметим, что на уровне дистрибьюции выбираются более отказоустойчивые устройства, чем на уровне доступа: обычно, в таких маршрутизаторах несколько блоков питания и охлаждения, возможно также резервирование управляющего модуля (супервизора). Однако вероятность выхода из строя такого устройства все равно не равна нулю.

Поэтому было придумано целое семейство протоколов, которые позволяют это устройство (в нашей схеме это маршрутизатор R2) зарезервировать. Протоколы данного семейства позволяют устройствам, которые выполняют резервирование, взаимодействовать между собой и определять состояние друг друга (на рис. 4 это маршрутизаторы R2 и R3).

FHRP это не отдельно взятый протокол, а название семейства протоколов. В данное семейство включены следующие протоколы:

• HSRP (Hot Standby Router Protocol) — проприетарный, Cisco;

• VRRP (Virtual Router Redundancy Protocol) — стандартный, поддерживается большинством вендоров;

• GLBP (Gateway Load Balancing Protocol) — проприетарный, Cisco.

Отметим, что у различных вендоров сетевого оборудования могут использоваться и другие протоколы, которые работают по похожим принципам (обсудим это далее).

Протоколы HSRP и VRRP очень похожи по своей реализации. GLBP в значительной мере отличается по архитектуре и используется достаточно редко из‑за сложности процедур поиска неисправностей (в частности, этот протокол позволяет не просто резервировать шлюз, но и выполнять балансировку трафика между несколькими шлюзами одновременно). Изложение построим на работе протокола HSRP, а потом рассмотрим основные отличия между HSRP и VRRP.

На интерфейсах маршрутизаторов, которые смотрят в сторону пользователей (то есть по сути могут являться для них шлюзом по умолчанию) настраивается HSRP‑группа. После этого маршрутизаторы обнаруживают друг друга и устанавливают отношения соседства по протоколу HSRP (см. рис. 5). В результате одно устройство выбирается активным (роль Active), а второе резервным (роль Standby). Тот маршрутизатор, который был выбран Active, обрабатывает пользовательский трафик. Здесь стоит оговориться, что речь идёт именно о том пользовательском трафике, который выходит из сегмента в остальную часть сети. Для резервирования обратного трафика протоколы группы FHRP не требуются.

Постараемся понять, за счет чего достигается такое поведение сети. На интерфейсах маршрутизаторов есть MAC‑адреса, которые были настроены на заводе при производстве данного оборудования. Также на интерфейсах, которые смотрят в пользовательский сегмент (см. рис. 4) вы настроили IP‑адреса из одной подсети. Но кроме этого, при конфигурации протокола HSRP вы указываете виртуальный IP‑адрес (VIP). Именно активный маршрутизатор обрабатывает трафик, который отправляется на виртуальный IP‑адрес (VIP) и виртуальный MAC‑адрес (vMAC). По сути пара VIP и vMAC расположена на активном маршрутизаторе в дополнение к стандартным MAC‑адресу и IP‑адресу, которые вы настроили на интерфейсе. В случае отказа активного маршрутизатора конструкция {VIP+vMAC} переедет на Standby маршрутизатор, и он станет активным. При этом, как было отмечено ранее, при конфигурировании протокола HSRP вы указываете только VIP‑адрес. vMAC будет выбран автоматически из специально зарезервированного под этот протокол блока MAC‑адресов (во время настройки HSRP вы определяете номер HSRP‑группы и именно по этому номеру устройство и определяет, какой vMAC необходимо назначить).

Давайте постараемся понять, в чем логика работы конструкции VIP+vMAC. В клиентском сегменте единообразно настраивается маршрут по умолчанию (может быть настроен вручную или с помощью протокола DHCP). И в качестве шлюза по умолчанию на всех клиентах указан VIP‑адрес. Клиент по протоколу ARP пытается выяснить MAC‑адрес для VIP‑адреса: широковещательный ARP‑запрос получают все устройства, но отвечает на этот запрос только маршрутизатор с ролью Active и отправляет не MAC‑адрес своего физического интерфейса, а vMAC. Таким образом у клиента в ARP‑таблице формируется запись, которая связывает VIP и vMAC. Соответственно, если клиент захочет взаимодействовать с каким‑то устройством в другой сети (например, сервис, доступный через ядро сети), то он сформирует пакет с необходимым IP‑адресом получателя и инкапсулирует его во фрейм, указывая в качестве MAC‑адреса получателя vMAC. Коммутатор, когда к нему придет этот фрейм, просмотрит свою MAC‑таблицу и поймет, что vMAC доступен через интерфейс в сторону Active маршрутизатора (на рис. 4 это R2), поэтому отправит туда фрейм.

Если c Active маршрутизатором что‑то случилось и VIP+vMAC переехали на R3 (см. рис. 6), то R3 берет на себя роль Active и отправляет GARP (Gratuitous ARP), чтобы переобучить коммутаторы. Процедура переобучения: формируется фрейм, в котором в качестве MAC‑адреса отправителя указан vMAC, коммутатор понимает, что теперь vMAC доступен через интерфейс в сторону R3 и будет отправлять фреймы клиентов туда. Отметим, что для клиентов ничего не меняется: у них в качестве маршрута по умолчанию указан VIP и он все также доступен через vMAC. Таким образом, для клиента смена роли активного маршрутизатора происходит незаметно.

Итак, восходящий трафик (от клиентов в сторону ядра) обрабатывает маршрутизатор с ролью Active, а вот трафик, который возвращается из ядра в пользовательский сегмент, возвращается туда по маршрутизации и не использует HSRP (может возвращаться через любой из маршрутизаторов). Поэтому важно настроить протокол маршрутизации (например, OSPF) таким образом, чтобы при падении интерфейса от R2 или R3 к пользователям, трафик из ядра сети в сторону пользователей также переставал направляться на это устройство (см. рис 6).

Существуют различные механизмы (tracking), которые также позволяют решать и обратную задачу: если на активном маршрутизаторе «падает» интерфейс в сторону ядра сети/пропадает соединение с каким‑то сервисом, то он может изменить свой приоритет (а роли Active/Standby выбираются на основании приоритетов) таким образом, чтобы отдать роль Active другому маршрутизатору. Например, на рис. 7 при падении Uplink (Gi1/0) у R2 его приоритет уменьшится на 30 и станет меньше, чем на R3.

Механизм Preempt. При включении протокола HSRP между маршрутизаторами начинаются выборы, которые определяют распределение ролей (кто станет Active, а кто Standby). Как уже было отмечено ранее, распределение ролей основано на приоритете устройства (по умолчанию принимает значение 100, но можно перенастроить): «у кого выше приоритет, тот и главный». В случае если приоритет одинаковый, выборы выигрывает маршрутизатор с наибольшим IP‑адресом интерфейса, на котором настроен HSRP. А что делать, если роли уже распределены и в какой‑то момент появляется маршрутизатор с большим приоритетом? В этой ситуации все зависит от того, включена ли функция Preempt на этом «новом» маршрутизаторе (по умолчанию выключена в HSRP): если Preempt на новом устройстве включен, то оно может запустить процедуру перевыборов и «перехватить» роль Active. Если Preempt выключен, то перехват роли не случится. Для Preempt можно настроить задержку и новый маршрутизатор с большим приоритетом будет перехватывать роль Active не сразу, а через какое‑то время (время задержки). Это может потребоваться для того, чтобы на данном устройстве закончился процесс сходимости протокола динамической маршрутизации, используемого для связи с ядром сети (в примере выше это был OSPF). Если задержку не настроить, новое устройство может перехватить роль Active сразу после включения и трафик из пользовательского сегмента начнет на него поступать в тот момент, когда еще не готова таблица маршрутизации (устройство только что запустилось, OSPF еще не сошелся и префиксы из ядра еще не прилетели). В такой ситуации этот маршрутизатор в течение какого‑то времени будет просто отбрасывать трафик, так как на нем не будет информации об адресах назначения.

Отметим, что в случае, если у нас несколько VLAN (и, соответственно, несколько sub‑интерфейсов на R2 и R3 — Router‑on‑a-Stick) HSRP‑группа настраивается в рамках каждого VLAN (то есть для каждой пары sub‑интерфейсов) отдельно (независимо). Это позволяет в рамках одной HSRP‑группы (одного VLAN) сделать Active R2, а в рамках другой HSRP‑группы (другого VLAN) сделать Active R1. Таким образом можно выполнить ручную балансировку трафика (чтобы не было ситуации, когда весь трафик в сторону ядра идет через одно устройство).

Протокол VRRP и его логика работы очень похожи на HSRP. Рассмотрим кратко основные отличия протокола VRRP:

• Вместо ролей Active/Stanby введены роли Master/Backup;

• Preempt включен по умолчанию;

• В VRRP по умолчанию hello‑таймер равен 1 секунде, dead‑таймер равен 3 секундам (у HSRP 3 и 10 секунд соответственно);

• Виртуальный адрес может совпадать с адресом интерфейса (то есть можно использовать только два адреса для конфигурации данного решения), хотя обычно такое решение не рекомендуется.

Отметим также, что у некоторых вендоров есть похожие решения, в которых используется только VIP. MAC‑адреса остаются физические, при переезде роли Master с одного устройства на другое также отправляется GARP, правда теперь уже с целью изменить ARP‑записи пользователей (теперь VIP расположен за новым MAC‑адресом), а вот переобучать коммутаторы необходимости нет, так как коммутатор изучил оба физических MAC‑адреса и все зависит от того, что пользователь укажет в качестве MAC‑адреса назначения в отправляемом фрейме.

Напоследок хочется сказать, что в крупных корпоративных и кампусных сетях на уровне агрегации сегодня вы скорее всего встретите решения типа MLAG/vPC‑пары. Однако и при применении этих решений работа протоколов HSRP/VRRP остается актуальной, а с архитектурными особенностями такого дизайна вы можете ознакомиться в еще одной моей статье vPC/MLAG: сравнение Eltex с Cisco и Huawei. Благодарю за внимание!

+ пара слов после заключения

Если вы хотите поделиться своим опытом, у вас есть вопросы или примеры кейсов, которые хочется разобрать, пожалуйста, пишите в комментарии, я с удовольствием продолжу общение.

Спасибо

• Максиму Климанову (@foxnetwork) за ревью статьи

Если вам была интересна эта статья и вы хотите глубже разобраться в архитектуре сетей и протоколах, обеспечивающих отказоустойчивость, рекомендую заглянуть в календарь открытых уроков. Два из них, которые могут быть наиболее интересны:

1. Открытый вебинар «Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира» — 17 июня

2. Открытый вебинар «OSPF Deep Dive: Практикум по построению карты сети из базы данных маршрутизаторов» — 3 июля