Cisco с нуля 13. HSRP: резервирование шлюза по умолчанию

В статьях первой части шлюзом для всех VLAN был один маршрутизатор R1. Пока он работает, всё хорошо. Но стоит R1 перезагрузиться, потерять питание или лишиться канала к провайдеру, как весь офис остаётся без выхода наружу и даже без связи между VLAN. В этой статье мы поставим рядом второй маршрутизатор R3 и объединим их протоколом HSRP (Hot Standby Router Protocol): клиенты по-прежнему будут ходить на адрес .1, но за этим адресом окажутся два устройства, и при отказе одного второе подхватит работу.

В итоге у вас будет:

• общий виртуальный шлюз .1 в VLAN 10, 20 и 99 на двух маршрутизаторах;
• распределение нагрузки: R1 обслуживает VLAN 10 и 99, R3 — гостевой VLAN 20;
• автоматическое переключение, если у активного маршрутизатора пропал WAN-канал;
• понимание, что при этом происходит с NAT и клиентскими сессиями, и способ вернуть всё обратно.

Что понадобится

• Обязательно: статья 05 (router-on-a-stick).
• Желательно: 04 (VLAN и trunk).
• Для блоков NAT и списка GUEST-IN на R3: 07 и 08. Если вы их не читали, пропустите соответствующие строки.
• Необязательно: 02 (базовая настройка и SSH), 10 (защита коммутатора) и 12 (резервные копии и TFTP/SCP).
• Состояние сети на старте: R1 является шлюзом .1 в VLAN 10, 20 и 99 на подинтерфейсах GigabitEthernet0/0/1.10, .20, .99, а SW1 связан с ним trunk-портом GigabitEthernet1/0/24 (VLAN 10, 20, 99 разрешены, native 999); управляющий интерфейс Vlan99 коммутатора имеет адрес 192.168.99.2 (мы перенесём его на .4). Если у вас NAT и DHCP из статьи 07, они продолжат работать, как описано ниже; без них можно обойтись, просто пропустите соответствующие строки.
• Второй маршрутизатор R3 с базовой настройкой (имя, пароли, SSH, как в статье 02), подключённый к SW1 так: порт GigabitEthernet0/0/1 маршрутизатора R3 — порт GigabitEthernet1/0/23 коммутатора SW1. Порт GigabitEthernet0/0/0 смотрит ко второму провайдеру: стык 198.51.100.4/30, адрес R3 — 198.51.100.6, шлюз провайдера — 198.51.100.5.
• Доступ к консоли R1, R3 и SW1. Мы будем менять адреса шлюза, и по SSH вы можете потерять управление.
• Компьютер в VLAN 10 для проверки пингом.
• Перед началом сохраните рабочую конфигурацию на R1, R3 и SW1 (copy running-config startup-config) и сделайте копию во flash (команда в разделе «Что изменится в сети»). Таймер reload in, который мы используем ниже, возвращает устройство именно к startup-config: если вы не сохраняли результаты предыдущих статей, они при срабатывании таймера пропадут.

Проблема: единая точка отказа

У клиента один адрес шлюза по умолчанию. Он получает его по DHCP или вводит вручную и не умеет сам «переключиться» на другой маршрутизатор. Если поставить второй маршрутизатор с другим адресом, клиенты об этом не узнают. Нужен механизм, при котором у двух маршрутизаторов есть общий адрес и они сами договариваются, кто им сейчас отвечает.

Такие механизмы называют FHRP (First Hop Redundancy Protocols, протоколы резервирования первого перехода):

Протокол	Кто придумал	Особенность
HSRP	Cisco	Один маршрутизатор active, второй standby. Самый распространённый в сетях Cisco, ему посвящена эта статья
VRRP	открытый стандарт IETF (RFC)	Та же идея, работает и с оборудованием других производителей. Короткий пример ниже
GLBP	Cisco	Умеет делить нагрузку внутри одного VLAN: клиентам выдаются разные виртуальные MAC-адреса одного шлюза

HSRP предназначен для сетей Ethernet, где есть несколько узлов-соседей (многодоступные сети). Он не заменяет динамическую маршрутизацию: это протокол только про шлюз по умолчанию для клиентов.

Как работает HSRP

Виртуальный IP и виртуальный MAC

Оба маршрутизатора получают собственные «реальные» адреса (у нас .2 и .3), а у группы HSRP появляется общий виртуальный IP (VIP) — это и есть прежний шлюз .1. У группы также есть виртуальный MAC-адрес. Клиенты узнают его обычным ARP-запросом про .1 и дальше шлют кадры именно на него. Когда роль переходит к другому маршрутизатору, он начинает отвечать на тот же VIP и тот же виртуальный MAC, поэтому клиентам ничего перенастраивать не нужно.

Active и standby

В группе один маршрутизатор active: он владеет VIP и пересылает трафик клиентов. Второй — standby: он следит за активным и готов его заменить. Active выбирается по приоритету (по умолчанию 100; чем больше, тем лучше), а при равенстве приоритетов в выборе участвует IP-адрес интерфейса (больший адрес имеет преимущество). Исход при равных приоритетах лучше не использовать как гарантию: документация Cisco описывает его по-разному, см. раздел про тест отказа. Поэтому приоритеты мы всегда задаём разными.

До выбора роли группа проходит состояния Init (HSRP на интерфейсе ещё не готов работать), Learn, Listen и Speak (их можно увидеть в show standby). Что делать, если группа в одном из них «застряла», описано в разделе «Как проверить».

Hello, hold и preempt

Маршрутизаторы обмениваются сообщениями hello: по умолчанию каждые 3 секунды. Если standby не слышит active в течение hold time (по умолчанию 10 секунд), он занимает роль active. Эти таймеры можно менять командой standby timers, но мы оставляем значения по умолчанию: на разных платформах ограничения различаются (например, в руководстве по Catalyst 9300 сказано, что миллисекундные таймеры HSRP там не поддерживаются).

Preempt («вытеснение») отвечает на вопрос: что делать, когда маршрутизатор с более высоким приоритетом вернулся в строй. По умолчанию preempt выключен, и такой маршрутизатор не отнимет роль active у текущего, даже если его приоритет выше. С standby preempt он заберёт роль обратно. Для нашей схемы preempt нужен на обоих маршрутизаторах. На R1 — чтобы после перезагрузки он снова стал основным. На R3 — чтобы при потере R1 WAN-канала он перехватил роль у ещё живого R1, о чём ниже.

У preempt есть параметр delay minimum <секунды>: маршрутизатор откладывает вытеснение на указанное число секунд. Это нужно, потому что только что загрузившийся (или только что поднявший интерфейс) маршрутизатор ещё может не иметь полной таблицы маршрутов, и, захватив роль сразу, он начнёт терять трафик. Мы используем 30 секунд (такое значение встречается в примерах документации Cisco). Практический вывод: задержка добавляется там, где роль переходит через preempt (возврат роли после загрузки, вытеснение при срабатывании track), поэтому пауза до 30 секунд после события нормальна. Когда же active просто замолчал (выключился или оборвался LAN-интерфейс), standby занимает роль по истечении hold time. Ориентируйтесь на show standby brief, а не на часы. Если вам важнее скорость переключения, уменьшите задержку или не задавайте её на R3; цена этого решения — риск захватить роль раньше, чем маршрутизатор «прогреется».

Версии HSRP 1 и 2

На интерфейсе работает только одна версия HSRP, и версии между собой не совместимы.

	HSRP версии 1 (по умолчанию)	HSRP версии 2
Номера групп	0–255	0–4095
Multicast-адрес hello	224.0.0.2	224.0.0.102
Виртуальный MAC	0000.0C07.ACxy (xy — номер группы в hex)	0000.0C9F.F000–0000.0C9F.FFFF (последние три hex-цифры — группа)
UDP-порт	1985	1985

Мы берём версию 2: она допускает группы до 4095, поэтому номер группы можно приравнивать к номеру любого VLAN. В нашей топологии (VLAN 10, 20, 99) это не обязательно, поскольку эти номера укладываются и в диапазон версии 1, но удобно и оставляет запас на будущее. Кроме того, у версии 2 свой multicast-адрес 224.0.0.102. Для группы 10 виртуальный MAC в версии 2 — 0000.0c9f.f00a. Версию задают на интерфейсе командой standby version 2 (без номера группы), и делать это нужно до создания групп: при смене версии все группы переинициализируются, потому что у них меняется виртуальный MAC.

Что изменится в сети из статей 05–12

• Адреса. Шлюз .1 становится виртуальным адресом HSRP. Реальные адреса интерфейсов: у R1 — .2, у R3 — .3 (в каждом из VLAN 10, 20, 99).
• Клиенты и DHCP. Клиентам ничего менять не нужно: default-router в пулах DHCP остаётся .1 (статья 07). Но DHCP-сервер по-прежнему только на R1: если он выключится, новые адреса выдавать станет некому, а уже выданные продолжат работать до конца аренды (у нас 1 день для OFFICE и 4 часа для GUEST). Запасной DHCP-сервер на R3 (с непересекающимся пулом) можно сделать по статье 07, здесь мы его не разбираем. Исключённый диапазон .1–.20 из статьи 07 уже покрывает адреса .2 и .3.
• Управление.
  • SSH на маршрутизаторы идёт на реальные адреса: 192.168.99.2 для R1 и 192.168.99.3 для R3. Адрес 192.168.99.1 ведёт на то устройство, которое сейчас active.
  • Конфликт адресов: по статьям 02 и 04 адрес 192.168.99.2 занят управляющим интерфейсом Vlan99 коммутатора SW1. Поэтому SW1 переносится на свободный 192.168.99.4 (шаг «Подготовка SW1» ниже). Его ip default-gateway 192.168.99.1 остаётся прежним.
  • Если адрес .2 для SW1 прописан у вас в мониторинге, правилах доступа или закладках, замените его на .4.
  • В статьях 20–24 SW1 имеет адрес .2: после этой статьи подставляйте там 192.168.99.4, а .2 считайте адресом R1.
• NAT. NAT настраивается на каждом маршрутизаторе отдельно: R1 транслирует в свой WAN-адрес 203.0.113.2, R3 — в 198.51.100.6. Состояние трансляций между устройствами не передаётся. Поэтому при переключении существующие соединения клиентов (загрузки, сеансы, видеозвонки) обрываются, а новые устанавливаются через второго провайдера. Из-за разных провайдеров у клиента сменится и внешний адрес. Входящие сервисы, опубликованные на 203.0.113.2, через R3 доступны не будут.
• ACL. Всё, что в статьях 02 и 08 настроено только на R1, на R3 отсутствует: список GUEST-IN на гостевом подинтерфейсе, ограничение доступа к линиям vty (access-class), правила на WAN. Поскольку по нашей схеме гостевым VLAN 20 в норме занимается R3, без переноса этих правил гости пойдут мимо изоляции. Перенос списка гостевой сети показан в разделе про R3. Кроме того, входящие списки на подинтерфейсах не должны блокировать HSRP (см. раздел про ACL ниже).
• Маршруты. На R3 есть только маршрут по умолчанию. Всё, что R1 знает дополнительно (например, сеть 192.168.50.0/24 за R2 из статей 06 и 11), R3 не знает. После переключения на R3 интернет будет работать, а филиальная сеть может стать недоступной. Что с этим делать, сказано в разделе про R3.
• Остальное из серии. Всё, что настроено только на R1 в других статьях (QoS, AAA, SNMP и syslog, туннели к филиалу (GRE, IPsec), межсетевой экран на маршрутизаторе — ZBFW, BGP), на R3 отсутствует; при необходимости повторите это на R3 по соответствующей статье. Если на R1 включён ZBFW, трафик HSRP придётся явно разрешить: это наш вывод, а не прямое указание документации. HSRP здесь настроен только для IPv4. Стенд с двумя провайдерами на одном R1 (статьи 15 и 16, а также шаг 4 со статическим плавающим маршрутом в статье 21) с этим стендом не совмещается: там второй провайдер подключён к R1, а не к R3. Исключение — вариант для HSRP в той же статье 21: он как раз рассчитан на стенд этой статьи (см. предупреждение про IP SLA ниже).

Откат описан в конце статьи. Отдельно про классическую IOS 15.x: группа команд standby там та же, но порты называются иначе (например, GigabitEthernet0/1.10), а поддержку HSRP версии 2 в вашем образе проверьте справкой ? после standby. В любом случае перед работой сделайте резервную копию конфигурации на R1, R3 и SW1 (способы — в статье про резервные копии). Самый короткий вариант, пока вы ничего не сохраняли после правок:

enable
copy running-config flash:pre-hsrp.cfg

Файл остаётся во flash-памяти устройства; имя pre-hsrp.cfg произвольное. Если у вас есть TFTP/SCP-сервер из статьи 12, скопируйте конфигурацию и туда.

Подготовка SW1: управляющий адрес и trunk к R3

Освобождаем адрес 192.168.99.2

В VLAN 99 у R1 будет адрес 192.168.99.2, поэтому управляющий интерфейс SW1 переносим на свободный 192.168.99.4 (в VLAN 99 DHCP не используется, так что клиентам адрес не выдадут):

enable
configure terminal
interface vlan 99
 ip address 192.168.99.4 255.255.255.0
end

Как проверить: show ip interface brief на SW1 покажет Vlan99 с адресом 192.168.99.4, а show running-config | include default-gateway — ip default-gateway 192.168.99.1. Пока R1 ещё шлюз .1 по схеме из статьи 05, ping 192.168.99.1 с коммутатора по-прежнему отвечает.

Trunk к R3

Порт Gi1/0/23 в статье 04 мы закрыли как запасной: перевели в VLAN 999 и выключили. Теперь он нужен как trunk к R3, с теми же параметрами, что у порта к R1.

Порт к R3 можно настраивать без таймера перезагрузки, но держите консоль SW1 под рукой: ошибка в списке VLAN может отрезать R3, а при потере сетевого доступа к самому SW1 возвращаться придётся через консоль. По желанию запустите на SW1 reload in 30 (отмена и правила те же, что для R1 ниже).

enable
configure terminal
interface GigabitEthernet1/0/23
 description UPLINK to R3 Gi0/0/1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99
 switchport nonegotiate
 no shutdown
end

На старых L3-коммутаторах 3560/3750 перед switchport mode trunk нужна строка switchport trunk encapsulation dot1q (подробнее в статье 04).

Как проверить: show interfaces trunk должна показать Gi1/0/23 в состоянии trunking, native VLAN 999 и разрешённые VLAN 10, 20, 99. Если VLAN не разрешены на этом порту, R3 до сети не достанет (см. «Типичные ошибки»).

Настройка R1: шлюз становится виртуальным

enable
reload in 30

Если устройство сразу после reload in 30 спросит про сохранение конфигурации (System configuration has been modified. Save?), ответьте no, а запрос подтверждения перезагрузки (Proceed with reload? [confirm]) подтвердите клавишей Enter. То же касается reload in 30 на SW1 и R3. Если после настройки вы потеряли доступ, через 30 минут R1 перезагрузится с последней сохранённой конфигурацией, то есть без правок. Если вопрос о сохранении появится при самой перезагрузке, ответьте no и там. Весь путь может занять больше получаса, поэтому перед каждым новым этапом продлевайте таймер (reload cancel, затем снова reload in 30) на тех устройствах, где правки ещё не сохранены. Если таймер сработал посреди работы, R1 и SW1 вернутся к схеме из статьи 05, а настройку R3 придётся повторить. После успешной проверки отмените перезагрузку командой reload cancel.

Теперь сама настройка. Сначала создаётся объект отслеживания track 10: он считает «поднятым» состояние линии GigabitEthernet0/0/0, то есть WAN. Затем на каждом подинтерфейсе меняется адрес и создаётся группа HSRP.

enable
configure terminal
track 10 interface GigabitEthernet0/0/0 line-protocol
 exit
interface GigabitEthernet0/0/1.10
 ip address 192.168.10.2 255.255.255.0
 standby version 2
 standby 10 priority 110
 standby 10 preempt delay minimum 30
 standby 10 track 10 decrement 20
 standby 10 name HSRP-OFFICE
 standby 10 ip 192.168.10.1
interface GigabitEthernet0/0/1.20
 ip address 192.168.20.2 255.255.255.0
 standby version 2
 standby 20 priority 100
 standby 20 preempt delay minimum 30
 standby 20 track 10 decrement 20
 standby 20 name HSRP-GUEST
 standby 20 ip 192.168.20.1
interface GigabitEthernet0/0/1.99
 ip address 192.168.99.2 255.255.255.0
 standby version 2
 standby 99 priority 110
 standby 99 preempt delay minimum 30
 standby 99 track 10 decrement 20
 standby 99 name HSRP-MGMT
 standby 99 ip 192.168.99.1
end

Разберём команды:

• standby version 2 — версия протокола для этого (под)интерфейса. Выполняется до создания групп.
• standby 10 priority 110 — приоритет в группе 10 (по умолчанию 100). Номер группы мы взяли равным номеру VLAN, так проще читать вывод.
• standby 10 preempt delay minimum 30 — разрешить вытеснение с задержкой не менее 30 секунд (подробности и оговорки — в разделе про preempt выше).
• standby 10 track 10 decrement 20 — если объект track 10 перешёл в down, уменьшить приоритет этой группы на 20. Номер объекта (10) не связан с номером группы: мы просто выбрали 10, чтобы он не пересекался с объектами track из других статей серии (например, в статьях про два провайдера и IP SLA используются другие номера).
• standby 10 name HSRP-OFFICE — имя группы (по справочнику команд HSRP, до 25 символов и уникальное в пределах маршрутизатора). Для работы протокола оно не обязательно, но облегчает чтение конфигурации и нужно некоторым функциям, например привязке NAT к группе HSRP.
• standby 10 ip 192.168.10.1 — виртуальный IP. Эта команда включает HSRP в группе, поэтому её пишут последней: Cisco рекомендует сначала задать все атрибуты и только потом включать группу, иначе возможны лишние смены состояний.

Адрес подинтерфейса и VIP должны быть в одной подсети. Все standby-команды выполняются в режиме настройки интерфейса, в том числе на подинтерфейсах.

После этого R1 окажется единственным устройством в группах и через несколько десятков секунд станет active (точное время зависит от платформы и версии; следите за show standby brief). Клиенты на это время теряют шлюз.

Как проверить: show standby brief на R1 покажет состояние Active для групп 10, 20 и 99, пока R3 ещё не настроен (в Init, Listen или Speak группа может побыть некоторое время; если она не выходит из Init, смотрите расшифровку в разделе «Как проверить» ниже). Клиентский пинг на .1 проверяйте после того, как группы стали Active.

Настройка R3

R3 получает такую же схему, только с другими реальными адресами, приоритетами, собственным WAN, маршрутом по умолчанию и NAT. Если вы не настраивали NAT на R1, пропустите строки с nat и access-list 1. Здесь предполагается, что на R3 есть только базовая настройка и порт Gi0/0/0 пока без адреса.

Гостевой VLAN 20 в норме обслуживает именно R3, поэтому список GUEST-IN (логика статьи 08) создаётся в этом же блоке до подинтерфейсов и применяется сразу, чтобы у гостей не было окна без изоляции. Он запрещает не внешний адрес R1, а собственный WAN-адрес R3 (198.51.100.6). Строк про DHCP здесь нет: они нужны только там, где работает DHCP-сервер, а на R3 его нет, поэтому DHCP-запросы гостей по-прежнему обрабатывает R1 в том же VLAN. Если вы не делали статью 08, список можно не создавать, но тогда гости получат доступ в офисные сети и к управлению (см. следующий раздел). Если вы позже подключите филиал по статьям 17 и 18, обновите этот список на R3 так же, как на R1: в нём нужно закрыть гостям сеть филиала 192.168.60.0/24 и сети туннелей 10.0.100.0/30 и 10.0.101.0/30 строками deny выше permit.

enable
configure terminal
access-list 10 permit 192.168.99.0 0.0.0.255
no ip http server
no ip http secure-server
line vty 0 15
 access-class 10 in
 transport input ssh
 exit
ip access-list extended GUEST-IN
 deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
 deny ip 192.168.20.0 0.0.0.255 192.168.99.0 0.0.0.255
 deny ip 192.168.20.0 0.0.0.255 192.168.50.0 0.0.0.255
 deny ip 192.168.20.0 0.0.0.255 10.0.12.0 0.0.0.3
 deny ip 192.168.20.0 0.0.0.255 host 198.51.100.6
 permit ip 192.168.20.0 0.0.0.255 any
 deny ip any any
 exit
interface GigabitEthernet0/0/0
 description WAN to ISP2
 ip address 198.51.100.6 255.255.255.252
 ip nat outside
 no shutdown
 exit
ip route 0.0.0.0 0.0.0.0 198.51.100.5
access-list 1 permit 192.168.10.0 0.0.0.255
access-list 1 permit 192.168.20.0 0.0.0.255
access-list 1 permit 192.168.99.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/0/0 overload
track 10 interface GigabitEthernet0/0/0 line-protocol
 exit
interface GigabitEthernet0/0/1
 description LAN trunk to SW1
 no ip address
 no shutdown
interface GigabitEthernet0/0/1.10
 description OFFICE
 encapsulation dot1Q 10
 ip address 192.168.10.3 255.255.255.0
 ip nat inside
 standby version 2
 standby 10 priority 100
 standby 10 preempt delay minimum 30
 standby 10 track 10 decrement 20
 standby 10 name HSRP-OFFICE
 standby 10 ip 192.168.10.1
interface GigabitEthernet0/0/1.20
 description GUEST
 encapsulation dot1Q 20
 ip address 192.168.20.3 255.255.255.0
 ip access-group GUEST-IN in
 ip nat inside
 standby version 2
 standby 20 priority 110
 standby 20 preempt delay minimum 30
 standby 20 track 10 decrement 20
 standby 20 name HSRP-GUEST
 standby 20 ip 192.168.20.1
interface GigabitEthernet0/0/1.99
 description MGMT
 encapsulation dot1Q 99
 ip address 192.168.99.3 255.255.255.0
 ip nat inside
 standby version 2
 standby 99 priority 100
 standby 99 preempt delay minimum 30
 standby 99 track 10 decrement 20
 standby 99 name HSRP-MGMT
 standby 99 ip 192.168.99.1
end

Как проверить: show standby brief на R3 должен показать Active для группы 20 и Standby для групп 10 и 99. Если группа 20 ещё не Active, подождите окончания preempt delay (до 30 секунд) и повторите команду. Подробный вывод и расшифровка состояний — в разделе «Как проверить» ниже.

Обратите внимание на распределение приоритетов:

Группа (VLAN)	Приоритет R1	Приоритет R3	Кто active в норме
10 OFFICE	110	100	R1
20 GUEST	100	110	R3
99 MGMT	110	100	R1

Так работает распределение нагрузки между VLAN: у каждой группы свой active, и в нашем случае гости выходят в интернет через второго провайдера, а офис — через первого. Это не балансировка внутри одного VLAN: все клиенты одного VLAN используют один шлюз. Если вам нужно, чтобы всё шло через R1, поставьте на R3 приоритет 100 во всех группах, а на R1 110 во всех.

Ограничения и маршруты на R3

Как проверить: show access-lists GUEST-IN на R3 и пробный доступ с гостевого компьютера в офис и к 192.168.99.1 (должен быть закрыт, пока active именно R3). Проверьте ограничение vty: show running-config | section line vty должно показать access-class 10 in.

Теперь маршруты. Если за R1 есть сеть 192.168.50.0/24 за R2, то R3 о ней не знает: после переключения клиенты потеряют её, хотя интернет будет работать. Простой вариант для статической схемы — направить трафик к ней через реальный адрес R1 в том же VLAN:

enable
configure terminal
ip route 192.168.50.0 255.255.255.0 192.168.10.2
end

У этого варианта есть ограничения: он работает, пока R1 жив (если отказал сам R1, маршрут тоже ничего не даст), а ответный трафик пойдёт мимо R3 напрямую через R1. Кроме того, пакеты к 192.168.50.0/24 вернутся из R3 в тот же VLAN, к R1: это работает, но неэффективно (лишняя нагрузка на порт и подинтерфейс, возможны ICMP-редиректы), поэтому как постоянное решение это не годится. Если вы используете OSPF (статья 11), полноценное решение — включить R3 в ту же схему маршрутизации, но это выходит за рамки статьи. Если филиальная сеть при работе через R3 вам не нужна, так и оставьте и знайте об этом ограничении.

Сохраните конфигурацию R3 только после проверки (copy running-config startup-config). На случай ошибки на R3 держите под рукой его консоль: при необходимости reload in 30 можно запустить и на нём, как на R1.

Как проверить

Начните с краткой таблицы на R1:

enable
show standby brief

Пример вывода (выравнивание зависит от версии):

R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi0/0/1.10  10   110 P Active  local           192.168.10.3    192.168.10.1
Gi0/0/1.20  20   100 P Standby 192.168.20.3    local           192.168.20.1
Gi0/0/1.99  99   110 P Active  local           192.168.99.3    192.168.99.1

Что должно получиться: для VLAN 10 и 99 на R1 состояние Active, для VLAN 20 — Standby, в столбце P стоит признак preempt, а виртуальные IP — те самые .1. На R3 вывод зеркальный. Если состояние не меняется со временем, различайте два случая. Init означает, что HSRP на этом интерфейсе ещё не работает: проверьте, что подинтерфейс в состоянии up/up, у него есть encapsulation dot1Q и адрес, VIP входит в ту же подсеть, а на SW1 нужный VLAN разрешён на trunk. Speak, не переходящий в Active/Standby (или два Active сразу), означает, что hello от соседа не доходят: проверьте версию HSRP, ACL, trunk и ключ аутентификации (см. «Типичные ошибки»).

Подробности по одной группе:

enable
show standby GigabitEthernet0/0/1.10

Пример вывода (формат строки Track зависит от версии: на другой платформе она может выглядеть как Track object 10 state Up decrement 20):

R1#show standby GigabitEthernet0/0/1.10
GigabitEthernet0/0/1.10 - Group 10 (version 2)
  State is Active
    2 state changes, last state change 00:12:41
  Virtual IP address is 192.168.10.1
  Active virtual MAC address is 0000.0c9f.f00a
    Local virtual MAC address is 0000.0c9f.f00a (v2 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.744 secs
  Preemption enabled, delay min 30 secs
  Active router is local
  Standby router is 192.168.10.3, priority 100 (expires in 8.816 sec)
  Priority 110 (configured 110)
  Track 10 state Up decrement 20
  Group name is "HSRP-OFFICE" (cfgd)

Здесь важны: version 2, виртуальный MAC в диапазоне 0000.0c9f.f..., таймеры 3 и 10 секунд, Preemption enabled, адрес standby-соседа и состояние объекта отслеживания Track 10. Состояние самого объекта можно посмотреть командой show track: интерфейс GigabitEthernet0/0/0 должен быть в состоянии Up. Команда show standby без параметров выводит все группы, а show standby brief — только сводку. Отдельной команды show standby vlan в документации мы не нашли и не используем её.

Затем проверьте клиента. С компьютера в VLAN 10 выполните ping 192.168.10.1 (в Windows с ключом -t для непрерывного пинга) и убедитесь, что адрес отвечает. После этого проверьте выход наружу, например ping 192.0.2.53. Если всё в порядке, отмените таймеры reload in командой reload cancel на каждом устройстве, где вы их запускали (R1, при желании R3 и SW1), и сохраните конфигурацию на обоих маршрутизаторах и на SW1. SSH на SW1 теперь идёт на 192.168.99.4.

Тест отказа

Проведите его в окно обслуживания, потому что клиенты на время потеряют сеть.

Отказ маршрутизатора или LAN-интерфейса. Запустите на компьютере VLAN 10 непрерывный ping 192.168.10.1 -t. С консоли R1 выключите подинтерфейс:

enable
configure terminal
interface GigabitEthernet0/0/1.10
 shutdown
end

Ждите несколько секунд. Пинг на VIP должен восстановиться: теперь на него отвечает R3. Проверьте show standby brief на R3: группа 10 должна стать Active. Верните интерфейс командой no shutdown. R1 вернёт себе роль active сразу или после паузы до 30 секунд (см. preempt delay выше); ориентируйтесь на show standby brief. Обратное переключение тоже может дать короткий разрыв, поэтому делайте тест в окно обслуживания. Потери при переключении возможны в пределах hold time (по умолчанию 10 секунд), точное время зависит от платформы и версии.

Отказ WAN-канала. Выключите на R1 порт к провайдеру:

enable
configure terminal
interface GigabitEthernet0/0/0
 shutdown
end

Объект track 10 перейдёт в down, приоритеты R1 во всех группах упадут на 20 (VLAN 10 и 99: 110 → 90; VLAN 20: 100 → 80). Поскольку на R3 включён preempt и его приоритет в группах 10 и 99 равен 100, R3 станет active везде. Здесь R1 жив и сам рассылает hello со сниженным приоритетом, так что hold time не ждут: переключение идёт через preempt на R3. Из-за preempt delay minimum 30 оно может занять до 30 секунд плюс интервал до очередного hello (до 3 секунд), а не несколько секунд: не пугайтесь паузы в пинге. Для быстрого теста можно временно уменьшить задержку на R3 (например, standby 10 preempt delay minimum 5 на подинтерфейсе), а потом вернуть 30. Проверка на R1:

enable
show standby GigabitEthernet0/0/1.10

Пример вывода (фрагмент):

  State is Standby
  Active router is 192.168.10.3, priority 100 (expires in 7.392 sec)
  Standby router is local
  Priority 90 (configured 110)
  Track 10 state Down decrement 20

Клиенты VLAN 10 теперь выходят наружу через R3 и второго провайдера. Верните порт командой no shutdown: после восстановления линии приоритет R1 вырастет обратно, и он вернёт себе роль active сразу или после паузы до 30 секунд: следите за show standby brief.

Правило подбора decrement: значение должно быть больше разницы приоритетов, иначе после снижения приоритет R1 не окажется строго ниже, чем у R3. У нас разница 10, а decrement 20. Значение по умолчанию (10) дало бы равные приоритеты (100 и 100). Исход при равных приоритетах не стоит принимать за гарантию: руководство по настройке HSRP говорит, что standby с равным приоритетом, но большим IP-адресом не вытесняет active, а справочник команд пишет, что при равенстве выигрывает больший IP-адрес (у R3 адрес как раз больше). Поэтому задавайте decrement строго больше разницы приоритетов (у нас 20 против 10) и проверяйте тестом отказа.

Аутентификация HSRP (необязательный шаг)

Раздел можно пропустить и вернуться к нему позже: схема работает и без аутентификации. Без аутентификации любое устройство в VLAN, пославшее HSRP-сообщения с высоким приоритетом и включённым preempt, может перехватить роль шлюза. Для двух маршрутизаторов в доверенной сети это скорее профилактика (гостевой VLAN 20 доверенным не назовёшь), но настроить её недорого. Поддерживается текстовая аутентификация (пароль идёт открытым текстом, защиты почти никакой) и MD5. Текст и MD5 в одной группе одновременно использовать нельзя.

Синтаксис MD5: standby <группа> authentication md5 key-string <ключ> или со ссылкой на цепочку ключей standby <группа> authentication md5 key-chain <имя>. Длина ключа ограничена, а источники расходятся (справочник команд называет 64 символа, руководство по настройке MD5 — 80), поэтому берите 16–32 символа. Мы используем цепочку ключей (key chain): ключ хранится отдельно от настроек интерфейсов, и его можно сменить, не трогая настройки подинтерфейсов. Учтите, что key-string в конфигурации виден администраторам и попадает в резервные копии (без дополнительных средств шифрования хранится открытым текстом; service password-encryption лишь маскирует его обратимым type 7, а о хранении общих ключей на устройстве см. также статью 20), поэтому храните копии конфигураций как секретные, а ключ делайте уникальным и не короче 16 символов.

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

enable
configure terminal
key chain HSRP-KEYS
 key 1
  key-string <КЛЮЧ_HSRP>
 exit
 exit
end

Затем включите аутентификацию сразу во всех трёх группах: сначала на R3, потом на R1. Блок один и тот же на обоих маршрутизаторах:

enable
configure terminal
interface GigabitEthernet0/0/1.10
 standby 10 authentication md5 key-chain HSRP-KEYS
interface GigabitEthernet0/0/1.20
 standby 20 authentication md5 key-chain HSRP-KEYS
interface GigabitEthernet0/0/1.99
 standby 99 authentication md5 key-chain HSRP-KEYS
end

Как проверить: show standby GigabitEthernet0/0/1.10 покажет строку об аутентификации, а состояния в show standby brief останутся Active/Standby. Если вместо этого оба маршрутизатора стали Active, ключи (key-string) или режим аутентификации (text или MD5) не совпадают, либо аутентификация включена пока только на одном из них; проверьте show key chain и show standby. Отладка: debug standby errors покажет сообщения вида Auth failed for Hello pkt. Не забудьте выключить отладку командой undebug all.

ACL и HSRP

Если на подинтерфейсе стоит входящий список доступа, он применяется и к hello-пакетам соседа. Правило общее: если список не пропускает UDP-порт 1985 на адрес 224.0.0.102 (для версии 1 адрес 224.0.0.2), hello блокируются, и маршрутизаторы перестают видеть друг друга.

Для GUEST-IN из статьи 08 (и для его копии на R3) ничего добавлять не нужно: hello идёт с реального адреса соседа (192.168.20.2 или .3), и этот пакет уже попадает под строку permit ip 192.168.20.0 0.0.0.255 any. Продление аренды DHCP юникастом на 192.168.20.2 проходит по той же строке, отдельных правил не требуется.

Правило нужно там, где список разрешает из своей подсети не всё подряд, а только избранное, например, пропускает только DNS и веб. Тогда добавьте разрешение выше запрещающих строк. Пример для такого списка с именем VLAN-IN на подинтерфейсе с версией 2 (имя условное):

enable
configure terminal
ip access-list extended VLAN-IN
 5 permit udp 192.168.20.0 0.0.0.255 host 224.0.0.102 eq 1985
end

Номер 5 нужен, чтобы строка встала выше существующих (у них номера 10, 20 и далее). Как проверить: в show access-lists VLAN-IN счётчик этой строки растёт.

L3-коммутаторы: HSRP на SVI

На L3-коммутаторах (Catalyst 9300 и подобных) HSRP настраивается так же, но не на подинтерфейсах, а на SVI (Switch Virtual Interface, виртуальный интерфейс VLAN на коммутаторе). Для каждого VLAN создаётся interface vlan N, и в нём задаются standby version 2, standby N ip <VIP>, standby N priority и standby N preempt. Пара L3-коммутаторов заменяет пару маршрутизаторов, а общий механизм остаётся тем же. Минимальный пример для VLAN 10 на первом коммутаторе пары (адрес .2, на втором .3 и приоритет 100):

enable
configure terminal
interface vlan 10
 ip address 192.168.10.2 255.255.255.0
 standby version 2
 standby 10 priority 110
 standby 10 preempt
 standby 10 ip 192.168.10.1
end

Отличия платформ сверяйте с руководством: например, для Catalyst 9300 описана только текстовая аутентификация, а слежение в разных руководствах для Catalyst 9000 описано по-разному (с интерфейсом напрямую или с номером объекта track), поэтому сверяйтесь с руководством своей модели и версии и со справкой standby <группа> track ?. Если на коммутаторе пока не включена маршрутизация, не забудьте ip routing (статья 05).

Альтернатива: VRRPv3

Если нужен открытый стандарт, на маршрутизаторах IOS XE есть VRRPv3. Включается он глобальной командой fhrp version vrrp v3, после чего версия VRRPv2 недоступна. Настройка группы идёт через address-family. Пример для VLAN 10 на R1. Это альтернатива HSRP, а не дополнение к нему: если HSRP на подинтерфейсе уже настроен, сначала уберите его (см. раздел об откате).

enable
configure terminal
fhrp version vrrp v3
interface GigabitEthernet0/0/1.10
 ip address 192.168.10.2 255.255.255.0
 vrrp 10 address-family ipv4
  address 192.168.10.1 primary
  priority 110
  preempt delay minimum 30
end

Здесь приоритет по умолчанию тоже 100, а preempt включён по умолчанию. Виртуальный MAC имеет вид 0000.5E00.01xx, где xx — номер группы в hex, hello идёт на multicast 224.0.0.18. Аутентификация в VRRPv3 не поддерживается, а слежение за каналом в этом блоке мы не показываем: в прочитанных нами разделах документации оно не подтверждено. Состояние смотрите командой show vrrp detail.

Откат к одному шлюзу

Чтобы вернуться к схеме из статьи 05, сначала отключите R3 от LAN, чтобы он не владел VIP, пока адреса на R1 меняются:

enable
configure terminal
interface GigabitEthernet0/0/1
 shutdown
end

Выполните это на R3. Затем на R1 (с консоли) верните прежние адреса:

enable
configure terminal
interface GigabitEthernet0/0/1.10
 no standby 10 ip
 ip address 192.168.10.1 255.255.255.0
interface GigabitEthernet0/0/1.20
 no standby 20 ip
 ip address 192.168.20.1 255.255.255.0
interface GigabitEthernet0/0/1.99
 no standby 99 ip
 ip address 192.168.99.1 255.255.255.0
end

Команда standby ... ip включает HSRP на интерфейсе, поэтому после её удаления остальные standby-строки (приоритет, preempt, track) ничего не делают. Их можно убрать командами с no по одной или оставить для будущего. Если вы ещё не сохраняли конфигурацию, самый простой откат — выполнить reload на R1 без сохранения, чтобы он загрузился с прежним startup-config; для этого мы и запускали reload in 30. После copy running-config startup-config такой откат уже не вернёт прежнюю схему: используйте команды выше или восстановите конфигурацию из копии, сделанной до начала. Для точного восстановления берите configure replace, а не copy flash:pre-hsrp.cfg running-config: последняя команда лишь сливает файл с текущей конфигурацией, и строки HSRP останутся. С консоли R1 (и так же на R3, если вы делали копию и на нём):

enable
configure replace flash:pre-hsrp.cfg list

Ключевое слово list покажет, какие строки будут добавлены и удалены; после ответа Y устройство применит разницу. Ограничения команды описаны в статье 12 и в статье про резервные копии. На SW1 порт Gi1/0/23 можно вернуть в запасное состояние (VLAN 999, shutdown) по статье 04, а управляющему интерфейсу вернуть прежний адрес (после того как R1 освободил .2, то есть после смены адресов на R1; делайте это с консоли SW1):

enable
configure terminal
interface vlan 99
 ip address 192.168.99.2 255.255.255.0
end

Типичные ошибки

• Разные версии HSRP на двух устройствах. На одном standby version 2, на другом версия по умолчанию (1): hello идут на разные multicast-адреса, маршрутизаторы не видят друг друга, и оба становятся active. Версия задаётся на интерфейсе, а не в группе. Сравните show standby на обоих: должно быть (version 2).
• Разные виртуальные IP или номера групп. Если у R1 standby 10 ip 192.168.10.1, а у R3 другой адрес или номер группы, это две независимые группы, и в сети два «шлюза». Проверьте show standby brief на обоих.
• Нет preempt. Без него R3 не перехватит роль у живого R1 при падении WAN, а R1 не вернёт её после восстановления. На R3 preempt нужен так же, как на R1.
• ACL блокирует HSRP. Входящий список на подинтерфейсе без разрешения UDP 1985 на 224.0.0.102 (или 224.0.0.2 в версии 1) отрезает hello. Признак: оба маршрутизатора в состоянии Active либо один застрял в Speak. Наш GUEST-IN из статьи 08 это не затрагивает (hello с реальных адресов проходит строкой permit ip ... any), но более строгие списки затронуть могут.
• VLAN не пропущен на trunk к R3. Если на Gi1/0/23 не разрешён нужный VLAN (особенно после команды switchport trunk allowed vlan без add) или R3 подключён в access-порт, R3 не получает hello от R1. Смотрите show interfaces trunk на SW1.
• Слишком маленький decrement. Если decrement меньше разницы приоритетов или равен ей, отказ WAN может не привести к переключению: нужно, чтобы приоритет R1 стал строго ниже, чем у R3 (исход при равенстве приоритетов не гарантирован). Проверяйте тестом отказа, а не по конфигурации.

Что дальше

• Следите не только за состоянием порта, но и за реальной доступностью интернета: Cisco с нуля 21. Мониторинг: SNMPv3, syslog, NTP, IP SLA.
• О двух провайдерах на одном маршрутизаторе, резервном маршруте и NAT рассказано в статье про два провайдера.
• Если нужно подключаться к провайдерам по BGP, переходите к Cisco с нуля 15. BGP: подключение к провайдеру.
• Подробности про подинтерфейсы и маршрутизацию между VLAN: Cisco с нуля 05. Маршрутизация между VLAN: router-on-a-stick и SVI.