Что происходит в сети с hsrp при выходе из строя active маршрутизатора

Обновлено: 06.07.2024

VRRP

Мы запустили новую услугу: резервирование маршрутизатора с использованием протокола VRRP (за рубежом она известна под названием failover IP. Насколько нам известно, в России до нас никто ничего подобного не делал. Услуга будет интересна в первую очередь тем, кто хотел бы обеспечить постоянную доступность бизнес-значимых интернет-ресурсов, но при этом не обладает для этого достаточными техническими возможности: не имеет ни собственной автономной системы, ни блока IP-адресов, ни подключений к провайдерам по протоколу BGP.
Об особенностях её технической реализации мы подробно расскажем в этой статье.

Выбираем схему резервирования

Если .78 — это адрес хоста, то .73 — адрес шлюза по умолчанию. Этот адрес — зона ответственности оператора, а если хост размещен в дата-центре — то зона ответственности дата-центра. Графически эту схему можно представить так:

vrrp-1

На конечном хосте прописывается адрес 12.34.56.78, на маршрутизаторе — .73, и между ними организуется единый L2-домен (как правило, это отдельный VLAN):

vrrp-2

Чтобы повысить уровень доступности конечного хоста, требуется резервирование сетевой инфраструктуры.
Для резервирования на уровне L2 в простейшем случае используется Virtual Chassis/Fabric/MC-LAG. Тогда конечный хост подключается сети дата-центра с использованием LAG (Etherchannel):

vrrp-3

Возможными точками отказа являются сам конечный хост и маршрутизатор.

Резервирование конечного хоста — это ответственность заказчика. Очень желательно, чтобы конечный и резервный хост были расположены в разных дата-центрах. Это позволит избежать многих проблем (с сетевой структурой, с доступностью конкретного физического сервера, с электропитанием и охлаждением на отдельно взятых площадках).
Организовать перенос IP-адреса между основным и резервным хостами можно разными способами.В пределах одного L2-сегмента это можно сделать с помощью протоколов CARP/HSRP/VRRP и их аналогов:

vrrp-4

О полноценном резервировании на уровне дата-центра можно вести речь только в случае, если все компоненты сервиса зарезервированы, и у них нет единой точки отказа.

Идеальную схему резервирования можно представить так:

vrrp-5

Конечный и резервный хосты заказчика находятся в разных дата-центрах. Маршрутизаторы, принадлежащие оператору, также расположены в разных дата-центрах. Дата-центры могут быть соединены несколькими каналами связи.
При возникновении неисправности в одном из дата-центров конечный хост все равно остаётся доступным. Описанный подход можно использовать для резервирования как по L2-, так и по L3-схемам.

Резервирование маршрутизаторов

Примером резервирования на уровне L3 может служить anycast-маршрутизация и использованием BGP с вышестоящим оператором. Каждый из хостов анонсирует на маршрутизаторы оператора связи сеть 12.34.56.72/29 с разным приоритетом. При этом каждый хост подключается к маршрутизаторам оператора связи отдельной подсетью, отдельным VLAN’ом:

vrrp-6

  • она широко используется в Интернете (BGP);
  • масштабирование осуществляется не на два, а на несколько дата-центров;
  • низкую скорость работы (по умолчанию скорость сходимости BGP — от 1.5 минут);
  • сложность настройки;
  • необходимость выделения отдельных подсетей для подключения в каждом дата-центре.

При использовании L2-схемы оператор организует единый L2-домен между основным и резервным хостами. Между маршрутизаторами организуется VXLAN или MPLS-туннель:

vrrp-7

VXLAN / MPLS помогают организовать резервирование с использованием нескольких каналов связи между маршрутизаторами провайдера.

Конечный и резервный хосты между собой используют VRRP или его аналоги. Таким образом IP-адрес 12.34.56.78 оказывается на активном в текущий момент хосте (если оба хоста активны — то на сконфигурированном master-хосте). Конечный хост получает IP-адрес из этой сети — 12.34.56.77, резервый хост получает адрес из той же сети — 12.34.56.76. Если на хостах установлена ОС Windows, то вместо VRRP можно использовать NLB-кластеризацию.

vrrp-8

Аналогичная схема строится и со стороны оператора. Оба маршрутизатора участвуют в одном VRRP-домене и разделяют между собой адрес шлюза по умолчанию —12.34.56.73/29. Маршрутизатор 1 является предварительно сконфигурированным мастером с физическим IP-адресом 12.34.56.73, а маршрутизатор 2 — резервным маршрутизатором с физическим адресом 12.34.56.74; адрес 12.34.56.73 для него является виртуальным и активным только в момент недоступности маршрутизатора 1.

vrrp-9

  • использование стандартных протоколов (VRRP);
  • простоту настройки, как со стороны заказчика, так и со стороны оператора;
  • высокую скорость работы;

Если случится неисправность: как это работает

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

Запросы из Интернета проходят через маршрутизатор 1 и попадают на основной конечный хост. На маршрутизаторах присутствует ARP-запись 12.34.56.78 с МАС-адресом 0000:5E00:01xx, указывающим в сторону основного хоста. Основной хост отвечает хостам в Интернете по роутингу через маршрутизатор 1 (для хостов указан default gateway 12.34.56.73). Для сокращения сетевой задержки основной маршрутизатор размещается в том же дата-центре, что и основной хост.

Что происходит, когда один из хостов недоступен? VRRP на резервном хосте определяет, что основной хост перестал отвечать на keep-alive запросы, и на резервном хосте устанавливается IP-адрес 12.34.56.78:

vrrp-11

апросы из интернета попадают на маршрутизатор 1; он в своей ARP-таблице видит МАС-адрес, соответствующий IP-адресу 12.34.56.78 со стороны маршрутизатора 2 и отправляет трафик на резервный хост. Резервный хост отправляет ответный трафик на шлюз по умолчанию 12.34.56.73, т.е. через маршрутизатор 1. При использовании этой схемы увеличивается сетевая задержка между хостами в Интернете и резервируемым хостом.
После устранения неисправностей IP-адрес 12.34.56.78 снова становится доступен на основном хосте, и схема работает в штатном режиме.

Аналогичным образом эта схема работает в случае неисправности сетевой инфраструктуры между маршрутизатором и конечным хостом:

vrrp-12

При выходе промежуточного коммутатора из строя основной хост по-прежнему остаётся носителем адреса 12.34.56.78, но у него нет сетевой связи с маршрутизатором и он не участвует в обработке запросов из Интернета. Резервный хост, потеряв связность с основным, становится ответственным за адрес 12.34.56.78.

Если становится недоступным маршрутизатор 1 или вообще весь дата-центр 1 целиком, то схема работает исключительно через маршрутизатор 2 и резервный хост:

vrrp-13

После восстановления инфраструктуры схема переходит в работу в штатном режиме. Практически никакие неисправности в дата-центре 2 не влияют на доступность конечного хоста.

Данное решение позволяет осуществлять инсталляцию и обслуживание высокодоступных ресурсов, полноценное их резервирование и разнесение в раздельные дата-центры.

Заключение

В этой статье мы рассмотрели технологии резервирования сетевых подключений с использованием протокола VRRP. Соответствующую услугу можно заказать в нашей панели управления.
Если у вас есть вопросы — добро пожаловать в комментарии. Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем к нам в блог.

Эффективным средством защиты от сбоев служит построение отказоустойчивых решений. Особенно это актуально там, где малейший простой может обернуться серьезными потерями. Чтобы такого не случилось, были разработаны специальные протоколы: всем известный STP, разнообразные протоколы агрегации каналов, протоколы, обеспечивающие отказоустойчивость шлюза по умолчанию. Однако, концентрируясь на этом свойстве, очень часто упускают из виду безопасность. Чем может обернуться отказоустойчивость шлюза по умолчанию? Давай разберемся!

featured_protokoli_otkaz

WARNING!

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

Как гласит определение, отказоустойчивость — это свойство технической системы сохранять свою работоспособность после отказа одного или нескольких составных компонентов. Представь ситуацию, когда из сети существует один-единственный выход во внешний мир и этот выход является шлюзом по умолчанию. Тогда в случае его падения уже ничто не поможет — неважно будет, насколько качественно спроектирована сеть, клиенты просто не смогут выйти за пределы своей подсети. Именно такие проблемы и призваны решать протоколы отказоустойчивости. Но у них есть свои нюансы, которые могут стать серьезной угрозой для безопасности системы. Поэтому в рамках данной статьи мы коротко коснемся основных видов отказоустойчивости и остановим свое пристальное внимание на безопасности протоколов HSRP и VRRP, призванных обеспечить безотказную работу шлюза по умолчанию. Поехали!

Рассматривать различные виды отказоустойчивости начнем с канального уровня модели OSI. На канальном уровне находится известнейший протокол Spanning Tree. STP просто предотвращает возникновение петель в сети. Если кадр канального уровня приходит на коммутатор, а у того нет в САМ-таблице МАС-адреса получателя, он отправляет фрейм на все свои порты в надежде, что хоть кто-то сможет на него ответить. В среде с одним свичем на этом все и заканчивается, а вот если свичей несколько, то могут быть нюансы. Этот кадр может уходить на все порты на каждом коммутаторе, и в случае наличия петли этот процесс может повторяться бесконечно. STP определяет так называемый root bridge (центр сети, куда сходится все дерево STP) и создает единый путь без петель между всеми коммутаторами. Стоимость пути определятся алгоритмом, основанным на количестве переходов и скорости порта, но может быть легко переназначена вручную. В итоге с единым путем к каждому мосту в сети кадры к неизвестным адресатам проходят каждый свитч один раз и затем отбрасываются, если хост-получатель оказался не в сети.

Казалось бы, при чем здесь отказоустойчивость? В случае отказа канала коммутатор обнаруживает проблему и поднимает резервный линк. На самом деле это не такой уж и простой процесс, но тема сегодняшнего разговора не STP, поэтому не будем сильно углубляться и двинемся дальше.

Также на канальном уровне обеспечивает отказоустойчивость EtherСhannel/LACP/PAgP. По сути, это взятие нескольких физических линков и агрегирование их в один логический.

Простейший вариант достижения отказоустойчивости на уровне одиночного порта и на уровне одиночного канала. EtherСhannel собирается ради надежности, увеличение скорости — это уже побочный эффект.

Достаточно распространено заблуждение, что с увеличением каналов увеличивается пропускная способность. Мол, берем четыре канала, 4 · 100 — получаем 400 Мбит/c. Но в реальности дела обстоят несколько иначе. Просто для каждого источника и назначения выбирается путь, условно говоря, трафик от хоста А до хоста Б будет идти по одному линку, а трафик от хоста А до С может идти по другому. В итоге если взять четыре линка, то для четырех одновременных соединений может быть доступно 100 Мбит/c.

Но возможны сценарии, когда скорость никак не поднимется, — например, два мощных сервера смотрят несколькими линками в коммутатор и передают в пределах одной TCP-сессии большой объем данных. В этом случае, независимо от количества каналов, использоваться будет только один линк и никакого увеличения скорости не будет.

NIC teaming, или агрегирование сетевых адаптеров, — это отказоустойчивость на аппаратном уровне для серверов. Обычно решается установкой дополнительных драйверов, созданием виртуального сетевого адаптера и затем добавлением физического сетевого адаптера для создания агрегации (team).

В большинстве случаев такая агрегация работает как пара активный/пассивный, и пассивный сетевой адаптер включается работу в случае потери канала активным. Но здесь могут быть и нюансы, когда поддерживается стандарт 802.3ad. Тогда уже может включаться балансировка, как и в случае EtherChannel.

Ну а на третьем уровне модели OSI обитают протоколы HSRP и VRRP. Они-то и обеспечивают отказоустойчивость на сетевом уровне. Если шлюз по умолчанию (в пределах одной подсети) уйдет в офлайн, тогда ни один хост в этой подсети не сможет получить доступ за пределами своего сегмента. Эти два протокола (HSRP и VRRP) призваны настроить дополнительный маршрутизатор (или L3-свитч), который выступит в роли резервного на случай падения основного. Если основной шлюз станет недоступен, то его сразу подменит резервный и клиенты даже не заметят, что что-то произошло.

Кроме отказоустойчивости, эти протоколы помогут решить задачи по обновлению железа и софта с минимальным влиянием на клиентов в обычное рабочее время. Самые известные протоколы, которые входят в эту группу, — HSRP, VRRP и GLBP. HSRP (Hot Standby Router Protocol) существует уже достаточно давно (c 1994 года) и является проприетарным решением от Cisco. VRRP (Virtual Router Redundancy Protocol) — это открытый протокол (появился в 1999-м), текущая его версия определена в RFC 5798. Несмотря на то что этот протокол позиционируется как открытый стандарт, компания Cisco говорит, что похожий протокол был запатентован и лицензирован. И хотя никаких патентных претензий не было, открытость VRRP остается под сомнением. Ну и GLBP (Gateway Load Balancing Protocol), относительно свежий протокол (создан Cisco для Cisco в 2005 году), как можно догадаться из названия, отличается от предыдущих тем, что кроме отказоустойчивости поддерживает и балансировку нагрузки.

Ну а сегодня мы подробно рассмотрим протокол HSRP, причем особое внимание уделим его безопасности.

HSRP может работать для двух и более маршрутизаторов (шлюзов), один из которых будет активный, один standby, а остальные будут просто ожидающими. Надо сказать, что протокол этот не особо масштабируемый. Сделано это и потому, что если активный маршрутизатор забросают пакетами с вопросом, живой ли он, то он наверняка упадет именно по этой причине. MAC-адрес активного генерируется автоматически, а виртуальный IP-адрес назначается вручную. В итоге тот, кто стал активным, отзывается на ARP-запросы про виртуальный IP, отправляя ARP-ответ с виртуальным маком.

Если standby-роутер не видит активный заданное время (в зависимости от настроек таймеров), то он объявляет себя активным и начинает отвечать. Для таких проверок используются hello- пакеты, отправляемые по мультикаст-адресу 224.0.0.2 . Стоит отметить также, что HSRP второй и первой версии технически несовместимы, так как трафик у них ходит по разным IP-адресам (см. врезку). На этом, пожалуй, закончим с теорией и перейдем к делу.

Виртуальная лаборатория

Для того чтобы опробовать все описанное в статье, вовсе не обязательно использовать настоящее оборудование. Для исследований вполне можно обойтись и эмулятором маршрутизаторов Cisco, например используя GNS3/Dynamips.

Сам GNS3 является, по сути, удобной графической оболочкой над непосредственно эмулятором Dynamips. Распространяются они бесплатно, под лицензией GPL, но, естественно, без прошивок роутеров Cisco — подразумевается, что пользователи будут их брать со своих железных роутеров.

Немного ознакомившись, что собой представляет HSRP-протокол, начнем собирать стенд для предстоящих испытаний. R1 будет основным HSRP-роутером, а R2 — резервным (см. рис. 1).

И сконфигурируем их следующим образом. На маршрутизаторе R1:

На маршрутизаторе R2:

После назначения IP-адреса на каждом из устройств нужно войти в группу HSRP standby с выбранным номером. Номер, естественно, должен быть одинаковый в пределах группы. Кроме того, от номера группы генерируется виртуальный МАС-адрес. После этого нужно вручную задать общий виртуальный IP-адрес. Оба этих действия выполняются одной командой: standby <номер группы> ip <виртуальный ip-адрес> .

Когда мы будем проверять статус HSRP на R1, будет видно, что HSRP содержит виртуальный MAC-адрес, отличающийся от реального физического и сгенерированный с учетом номера группы (0000:0с07:acXX, где номер группы 10 превращается в 0x0a и дописывается вместо XX).

Убедившись, что все работает (R1 числится как Active), можно начать исследование вопросов безопасности протокола HSRP.

Для начала давай проснифаем трафик на предмет интересных пакетов. Предположим, что мы находимся в пределах одного широковещательного домена. Результат такого сканирования представлен на рис. 2.

Рис. 2. Пакеты HSRP

Рис. 2. Пакеты HSRP

Как оказалось, вся информация передается чистым текстом, более того, несмотря на то что в настройках не устанавливался какой-либо пароль, он все-таки используется, и, как видно, по умолчанию (cisco). Теперь, когда мы знаем номер группы HSRP и ключевое слово, ничто не мешает нам провести атаку.

Для того чтобы провести атаку на протокол HSRP, можно как использовать специализированные утилиты вроде yersinia, так и действовать вручную, при помощи отличного инструмента под названием Scapy. Мы свой выбор остановим, конечно же, на втором варианте. Действовать будем прямо в интерактивном режиме, запускаем и начинаем назначать переменные:

Сразу создали переменные по протоколам IP и UDP, не забывая, что пакеты HSRP ходят по мультикасту. Перед тем как собрать HSRP, не помешает посмотреть, какие вообще есть в нем опции:

Видно, что большинство параметров (в том числе и пароль) уже заполнены разработчиками, нам остается заполнить только несколько:

В данном случае пакеты будут отправляться каждые три секунды, через интерфейс eth0, до тех пор пока это действие не будет прервано (например, escape-последовательностью ^C).

Как только пакеты начнут разлетаться на мультикаст-адрес, легитимные роутеры сразу же сменят свои статусы (см. рис. 3), а маршрутизатор атакующего станет активным и собственно главным. Что уже, безусловно, предоставит массу возможностей атакующему — фактически весь трафик начнет проходить через него. Теперь уже лишь бы хватило мощности и пропускной способности.

Рис. 3. Реакция маршрутизаторов

Рис. 3. Реакция маршрутизаторов

Даже если на обоих настоящих роутерах установить произвольный пароль командой standby 10 authentication text , то и это не особо поможет. Снифер все так же покажет ключевое слово, которое легко прописать в Scapy и получить такой же успешный результат.

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

Включить использование MD5-хеширования можно следующей командой:

Но можно пойти дальше и использовать не key-string, а key-chain. В итоге создается связка из нескольких ключей, которая затем привязывается к экземпляру HSRP и поочередно меняется. В таком случае защита серьезно усиливается, так как нужно знать все пароли в связке и расположить их в правильном порядке, потому что HSRP будет в цикле перебирать пароли по номеру и периодически их запрашивать.

Рис. 4. Пример HSRP с использованием MD5

Рис. 4. Пример HSRP с использованием MD5

К слову, не так давно появились изменения в модуле Scapy, и теперь он умеет разбирать пакеты HSRP, где используется MD5 (даже Wireshark в стандартном варианте этого не умеет).

Если бегло рассмотреть VRRP, то здесь все очень похоже. Вначале конфигурация, опять все очень просто. На R1:

Как можно заметить, основные отличия здесь в синтаксисе команд.

Рис. 5. Пакет VRRP

Рис. 5. Пакет VRRP

Затем опять включаем в работу снифер (см. рис. 5) — в пакете видно Virtual Rtr ID: 10 и Auth Type: No Authentication (0) .

И запускаем Scapy.

Осталось только заполнить нужные поля. Из основных отличий — мультикаст-адрес уже будет другой, вместо 224.0.0.2 теперь нужно использовать 224.0.0.18 . И вместо group=10 будет vrid=10 . Ну и естественно, UDP уже не нужен. В итоге получаем:

И проверяем результат.

Рис. 6. VRRP после атаки

Рис. 6. VRRP после атаки

Как видишь, тут тоже все прошло успешно.

HSRPv1 vs HSRPv2

Основные отличия между первой и второй версией протокола HSRP проявляются в следующем.

  • в HSRPv1 используется адрес 224.0.0.2;
  • в HSRPv2 используется адрес 224.0.0.102.
  • в HSRPv1 до 255 групп;
  • в HSRPv2 до 4096.

Виртуальный MAC-адрес (где x — номер группы HSRP):

  • в HSRPv1 0000:0C07:ACxx;
  • в HSRPv2 0000:0C9F:Fxxx.

Протоколы обеспечения отказоустойчивости, или, как их еще называют, FHRP (First Hop Redundancy Protocol), достаточно широко распространены и неплохо делают свою работу. Но при их использовании редко уделяют должное внимание вопросам безопасности. Как ты видел, настройка занимает буквально две-три команды, и все начинает работать. Но при этом остается большая дыра и широкий простор для злоумышленников. Надеюсь, после прочтения данной статьи, что бы ты ни делал, какое бы оборудование ни настраивал, ты всегда будешь оценивать производимые действия с точки зрения безопасности. Будь начеку!


На этой странице описывается настройка протокола HSRP на маршрутизаторах и коммутаторах Cisco.

HSRP настраивается одинаково на маршрутизаторах и коммутаторах 3го уровня, настройки выполняются на интерфейсах 3го уровня. На маршрутизаторе это могут быть физические интерфейсы или подынтерфейсы, а на коммутаторе 3го уровня интерфейсы переведенные в режим работы на 3 уровне или SVI-интерфейсы (interface vlan).

Содержание

HSRP.jpg

Создание групп и назначение виртуальных IP-адресов на маршрутизаторах (включение HSRP):

Если не указывать номер группы в команде standby ip, то будет использоваться номер 0.

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

Пример настройки двух групп для dyn1 и dyn3 (настройки одинаковые на обоих маршрутизаторах):

Хотя, для того чтобы HSRP работал достаточно указать виртуальный IP-адрес только на одном маршрутизаторе, Cisco рекомендует указывать адрес на всех маршрутизаторах.

По умолчанию используется версия 1.

Пример настройки имени для группы 1 на маршрутизаторе dyn1:

Имя группы имеет локальное значение.

Имя группы используется для связки HSRP с другими функциями маршрутизатора. Например, при использовании HSRP вместе с IPsec или NAT.

Настройка приоритета. Диапазон значений от 0 до 255 (по умолчанию значение 100):

Изменение приоритета по умолчанию для группы 1 на dyn1 (на dyn3 аналогично изменен приоритет для группы 3):

Режим preempt позволяет маршрутизатору с более высоким приоритетом перехватывать роль active маршрутизатора. По умолчанию режим preempt выключен.

  • delay -- позволяет указать задержку перехвата роли маршрутизатора. При включении у маршрутизатора ещё не заполнена таблица маршрутизации. Если он сразу перехватит роль active маршрутизатора, то, возможно, он не сможет передавать трафик некоторое время. Задержка позволяет маршрутизатору заполнить таблицу маршрутизации. По умолчанию значение параметра 0, то есть, маршрутизатор перехватывает роль немедленно.

Включение режима preempt:

  • interface-priority -- значение на которое приоритет маршрутизатора понизится, если интерфейс недоступен и повысится снова когда интерфейс поднимется. По умолчанию значение 10.

Пример настройки для маршрутизатора dyn1. Отслеживается состояние интерфейса fa1/0. Если интерфейс не работает, то все HSRP-группы на интерфейсе fa0/0 будут выключены.

Настройка выключения группы 1:

Если теперь выключить интерфейс fa1/0, то группы 1 и 3 на интерфейсе fa0/0 перейдут в состояние Init:

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

Изменение таймеров HSRP на интерфейсе:

  • hellotime -- по умолчанию 3 секунды. Значение в секундах, диапазон значений от 1 до 255;
  • holdtime -- по умолчанию 10 секунд. Значение в секундах, диапазон значений от 1 до 255.

Изменение таймеров для группы 1 на dyn1:

Так как dyn1 для группы 1 является active маршрутизатором, то аналогичные значения таймеров в этой группе будут и для dyn3.

Если, например, изменить таймеры на маршрутизаторе dyn1 для группы 3, в то время как он не является для неё active маршрутизатором, то реально использоваться будут таймеры пришедшие от active маршрутизатора (dyn3). Если dyn1 станет active в группе 3, то тогда будут использоваться настроенные таймеры.

Пример отображения информации о dyn1, когда для группы 3 он является standby и таймеры отличные от настроенных на active:

Пример настройки аутентификации для двух групп на маршрутизаторе dyn1:

Варианты команд просмотра настроек:

Просмотр краткой информации о группах:

Просмотр информации о всех включенных группах HSRP:

Просмотр информации группе 1 на интерфейсе fa0/0:

Просмотр информации о настроенных значениях задержки:

Просмотр информации о соседях:

Просмотр информации о настройках ICMP redirect:

Topology HSRP.jpg

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

На коммутаторах DSW1 и DSW2 порты Po1, Po2 и Po3 это агрегированные каналы (EtherChannel), которые переведены в режим 3го уровня и не описаны в настройках.

На рисунке отмечены VLAN:

  • VLAN 101 (зелёный)
  • VLAN 102 (красный)
  • VLAN 103 (синий)
  • VLAN 104 (оранжевый)

Принципы назначения адресов одинаковы для всех VLAN, меняется только третий октет в адресах. Адресация на примере VLAN 101:

  • Сеть 10.0.1.0/24
  • Адрес 10.0.1.1 используется как шлюз по умолчанию для хостов. Это виртуальный адрес HSRP группы
  • По DHCP хостам выдаются адреса 10.0.1.50-254 и шлюз 10.0.1.1. IP-адрес DHCP-сервера 10.0.100.100
  • Адреса 10.0.1.2 и 10.0.1.3 используются DSW1 и DSW2, соответственно

Топология построена таким образом, чтобы в ней не было петель на канальном уровне. Однако, на коммутаторах включен Rapid-PVST+ для защиты от случайных петель.

Использование HSRP вместе с трансляцией адресов описано на странице Cisco NAT.

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

In this Discussion

  • сентября 2017 DimkaSmith
  • марта 2016 eucariot
  • марта 2016 Константин
  • марта 2016 dmfigol
  • марта 2016 aleksei_boroda
  • марта 2016 kamasutr
  • марта 2016 EvgeniyHeine
  • октября 2017 Anumrak

Комментарии

Всё правильно вы описываете. Трекинг - это трекинг, preempt - это preempt. Если preempt отключен, то не Active роутер не вернёт себе Active роль, если уже есть Active. Другой вопрос, когда вы симулировали аварию, перешёл ли роутер в HSRP Disabled state, или он остался Active?

R1 перешел в Disabled state. R2 был стэндбай и стал эктив. После ремонта. R1 стал проходить по очереди все стадии - листен спикин и тд. И потом стал активом. А R2 стал тенд бай. И это при том что приеемп в дисейбл. На свитче spanning tree mode pvst+ и порты не portfast, да?


Свич из коробки

На нем натсроек 0. Только все заводское
Порты не портфаст

В принципе HSRP нормально работает только тогда, когда tracking включен, иначе приоритет падать не будет ни у кого.
Камасутр, ты должен понять:
Preemt для возвращения active и только.
Tracking - для возможности декрементировать приоритеты у active и у standby и инкрементировать(поднять) приоритет после восстановления наблюдаемого интерфейса.

Если отключить preemt, то никакого возвращения active не будет. То что ты пишешь не реализуемо в HSRP.
Если отключить tracking, то приоритеты не будут падать, потому что декрементировать нечем.

Спасибо за ваше пояснение. У меня вопрос совсем в другом. Я показиваю реальную работу реального оборудования. И у меня получается что - неважно написано дисэйбл или энейбл преемп - он работает так, как будто энебл всегда. Мой вопрос - почему так? Теперь вы поняли мой вопрос?

Всё правильно вы описываете. Трекинг - это трекинг, preempt - это preempt. Если preempt отключен, то не Active роутер не вернёт себе Active роль, если уже есть Active. Другой вопрос, когда вы симулировали аварию, перешёл ли роутер в HSRP Disabled state, или он остался Active?

R1 перешел в Disabled state. R2 был стэндбай и стал эктив. После ремонта. R1 стал проходить по очереди все стадии - листен спикин и тд. И потом стал активом. А R2 стал тенд бай. И это при том что приеемп в дисейбл. На свитче spanning tree mode pvst+ и порты не portfast, да?


Свич из коробки

На нем натсроек 0. Только все заводское
Порты не портфаст

Ну это и была подсказка Когда линк поднимается, он уже показывает up/up, мы начинаем слать HSRP Hello, но они не будут доходить 30 секунд, пока порт на свитче не перейдёт в Forwarding, поэтому мы становимся Active через 10.

Всё правильно вы описываете. Трекинг - это трекинг, preempt - это preempt. Если preempt отключен, то не Active роутер не вернёт себе Active роль, если уже есть Active. Другой вопрос, когда вы симулировали аварию, перешёл ли роутер в HSRP Disabled state, или он остался Active?

R1 перешел в Disabled state. R2 был стэндбай и стал эктив. После ремонта. R1 стал проходить по очереди все стадии - листен спикин и тд. И потом стал активом. А R2 стал тенд бай. И это при том что приеемп в дисейбл. На свитче spanning tree mode pvst+ и порты не portfast, да?


Свич из коробки

На нем натсроек 0. Только все заводское
Порты не портфаст

Ну это и была подсказка Когда линк поднимается, он уже показывает up/up, мы начинаем слать HSRP Hello, но они не будут доходить 30 секунд, пока порт на свитче не перейдёт в Forwarding, поэтому мы становимся Active через 10. А второй роутер находясь в эктиве сравнивает свой приоритет и приоритет первого, видит чтой свой меньше и потому переходит в стенд бай? Ша проверю

1) У вас свитч L2 или L3?
2) Какие интерфейсы, отвечающие за течение боевого трафика в интернет, следят за падением линка в интернет?

Чтобы сэкономить общее время, могу сказать, что на моем агрегационном L3 свитче абонентские интерфейсы объединены в standby группу и все они следят за одним outbound интерфейсом в интернет.

Мне кажется вы не правильно настроили HSRP. Потому что у него получаются два понятия: 1) Боевые интерфейсы ; 2) Интерфейсы, за которыми наблюдают.

Всё правильно вы описываете. Трекинг - это трекинг, preempt - это preempt. Если preempt отключен, то не Active роутер не вернёт себе Active роль, если уже есть Active. Другой вопрос, когда вы симулировали аварию, перешёл ли роутер в HSRP Disabled state, или он остался Active?

R1 перешел в Disabled state. R2 был стэндбай и стал эктив. После ремонта. R1 стал проходить по очереди все стадии - листен спикин и тд. И потом стал активом. А R2 стал тенд бай. И это при том что приеемп в дисейбл. На свитче spanning tree mode pvst+ и порты не portfast, да?


Свич из коробки

На нем натсроек 0. Только все заводское
Порты не портфаст

Ну это и была подсказка Когда линк поднимается, он уже показывает up/up, мы начинаем слать HSRP Hello, но они не будут доходить 30 секунд, пока порт на свитче не перейдёт в Forwarding, поэтому мы становимся Active через 10. А второй роутер находясь в эктиве сравнивает свой приоритет и приоритет первого, видит чтой свой меньше и потому переходит в стенд бай? Ша проверю

1) У вас свитч L2 или L3?
2) Какие интерфейсы, отвечающие за течение боевого трафика в интернет, следят за падением линка в интернет?

Чтобы сэкономить общее время, могу сказать, что на моем агрегационном L3 свитче абонентские интерфейсы объединены в standby группу и все они следят за одним outbound интерфейсом в интернет.

Мне кажется вы не правильно настроили HSRP. Потому что у него получаются два понятия: 1) Боевые интерфейсы ; 2) Интерфейсы, за которыми наблюдают.

Не. Все равно становится первый активом после востановления. Включил РСТП. Свич 3560 является Л3. Я писал. Не пойму вашего второго вопроса. У меня никто не закем не следит.

Установите внутренние интерфейсы роутеров в группу standby и их же поставьте трекать внешние интерфейсы, которые смотрят в интернет. Сам же интерфейс, который смотрит в интернет, вообще не конфигурируйте в standby группу.
Вот как выглядят мои "боевые" интерфейсы:
interface Vlan2
description Management
ip address 172.17.7.2 255.255.255.128
standby version 2
standby 1 ip 172.17.7.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan100
description ASW1&ASW2
ip address 10.37.0.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.0.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan101
description ASW1&ASW2
ip address 10.37.1.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.1.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan102
description ASW3&ASW4
ip address 10.37.2.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.2.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan103
description ASW3&ASW4
ip address 10.37.3.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.3.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1

А вот мой интерфейс, на который реагируют вышеописанные vlan интерфейсы:
interface GigabitEthernet0/1
description Uplink to GW
no switchport
ip address 172.17.7.249 255.255.255.252
ip summary-address eigrp 100 10.37.0.0 255.255.252.0 5
duplex auto
speed auto

Вообще не имеющий прямого отношения к группе standby.

Установите внутренние интерфейсы роутеров в группу standby и их же поставьте трекать внешние интерфейсы, которые смотрят в интернет. Сам же интерфейс, который смотрит в интернет, вообще не конфигурируйте в standby группу.
Вот как выглядят мои "боевые" интерфейсы:
interface Vlan2
description Management
ip address 172.17.7.2 255.255.255.128
standby version 2
standby 1 ip 172.17.7.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan100
description ASW1&ASW2
ip address 10.37.0.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.0.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan101
description ASW1&ASW2
ip address 10.37.1.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.1.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan102
description ASW3&ASW4
ip address 10.37.2.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.2.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1
!
interface Vlan103
description ASW3&ASW4
ip address 10.37.3.2 255.255.255.0
ip helper-address 172.17.7.129
standby version 2
standby 1 ip 10.37.3.1
standby 1 priority 101
standby 1 preempt
standby 1 track GigabitEthernet0/1

А вот мой интерфейс, на который реагируют вышеописанные vlan интерфейсы:
interface GigabitEthernet0/1
description Uplink to GW
no switchport
ip address 172.17.7.249 255.255.255.252
ip summary-address eigrp 100 10.37.0.0 255.255.252.0 5
duplex auto
speed auto

Читайте также: