HSRP

Итак, HSRP в Cisco, естественно, поскольку фирменный Cisco протокол, мы его рассматриваем на примере Cisco, никакого стандартного поведения и отдельно от него Cisco-специфичного поведения у HSRP нет. Протокол HSRP, Hot Standby Redundancy Protocol, у нас работает следующим образом. Вы можете в пределах одного широковещательного домена Ethernet, например, в пределах VLAN, сказать, что у вас есть несколько роутеров, которые должны быть кандидатами на роль шлюза по умолчанию. Эти роутеры должны сговориться между собой и выбрать один роутер, который будет по факту обслуживать клиентов. Один роутер, который будет по факту работать с клиентами, он будет называться активным роутером или Active. Он будет делать три основные задачи. Первое — это на запросы ARP, у кого из вас IP-шник, будет отвечать виртуальным MAC. А второе — он будет слушать этот самый виртуальный MAC и форвардить те IP-пакеты, которые на него приходят. То есть заниматься форвардингом трафика.

И ещё он будет отправлять Hello-пакеты. По умолчанию раз в три секунды, но можно настроить, как часто это стоит делать. И в этих Hello-пакетах он говорит, я активный и я живой. Из остальных роутеров, которые у вас не являются активным, выбирается ещё один роутер, который будет называться запасным или Standby. Он ничего специального не делает. Единственное, для чего он нужен, — это сидеть и ждать, пока активный не сдохнет. Как только активный сдохнет, запасной становится немедленно основным. Он сам при этом слушает Hello-пакеты от активного роутера. Если он перестаёт их слышать, он говорит, о, пришла моя очередь. И он сам отправляет Hello-пакеты тоже по умолчанию раз в три секунды. Все остальные роутеры вообще ничего не делают. Они просто сидят и ждут, пока перестанут приходить пакеты от запасного роутера. Важный момент. Активный роутер отправляет Hello-пакеты на мультикаст, в специальный адрес. Их слышат вообще все, но по факту они интересны только запасному.

Все остальные роутеры, покуда приходят пакеты от активного, им это всё неинтересно. Они говорят, мы не сможем сразу стать активным роутером. Мы максимум, что можем сделать, — это стать запасным. Если запасной перестанет присылать Hello-пакеты, мы подерёмся за право стать этим самым запасным. А единственный вариант попасть на роль активного роутера — это сначала стать запасным, а потом уже перехватить власть у активного. Либо потому, что активный сдохнет, либо потому, что запасной в какой-то момент скажет, баста карапузики, я принял решение становиться активным прямо сейчас. По факту выборы, если вдруг какие-то будут проходить, они проходят только за роль запасного. За роль основного выборов как таковых нет. Есть только право захвата власти запасным у основного активного. Включается HSRP в настройках интерфейса, маршрутизируемого, естественно. В настройках интерфейса вы указываете команду standby, дальше цифра — номер группы, если не указано, то имеется в виду группа номер 0,

и потом IP и дальше IP-шник. Например, у нас есть свитчи, на них есть некоторое количество VLAN, между этими VLAN происходит маршрутизация, и на интерфейсе VLAN 1 мы указываем, что у нас есть IP-адрес 10.0.1 с маской 255.255.255.0. Просто обычный IP-шник. И рядышком указываем standby, один — номер группы, IP 10.0.0.254. Рядышком тут будет, наверное, другой свитч, свитч B, и у него будет то же самое, интерфейс VLAN 1, и IP-адрес какой-то другой уже будет, 10.0.0.2. И та же самая команда standby, standby 1 IP 10.0.0.254. IP-шник назначается на них одинаково. У них физические адреса будут разные, 10.0.0.1 у одного, 10.0.0.2 у другого. Но виртуальный IP-шник они будут разделять одинаковый.

И MAC-адрес из этого виртуального IP-шника у HSRP тоже всегда будет одинаковый. 0000.0C07.AC01, если мы говорим про номер группы 1. Вы можете указать, кто из этих двух товарищей, свитч A или свитч B, должен стать активным роутером без каких-то дополнительных вводных. Если для вас это важно, то вы можете назначить так называемый приоритет. Это чем больше, тем лучше, некоторое число однобайтовое. И активным — точнее, запасным сначала станет тот, у кого приоритет больше. А потом, если запасной посчитает нужным, он может перехватить власть у текущего активного. Или если текущего активного просто нет, он может им сам стать. Есть нюанс. Будет ли запасной роутер перехватывать власть у основного, если посчитает это необходимым делать прямо пока ещё активный роутер живой.

Эта штука будет называться preempting. По умолчанию в HSRP он выключен. Вы, как правило, хотите его включить. В чём смысл этого самого preempting? Если у вас есть активный роутер и запасной роутер, и у активного роутера приоритет, например, 100, и у запасного приоритет 100, то в этом случае запасной не сможет захватить власть в любом случае. У запасного приоритет такой же, как у основного, дефолтный 100. Он не строго больше. Поэтому будет некрасиво, если standby-роутер будет перехватывать власть у основного, становиться основным, а потом активный сделает то же самое. Они будут постоянно драться между собой, будет непонятно, кто у кого власть перехватывает. Поэтому, если вы включаете preempting, то перехватить власть немедленно, пока ещё активный живой, можно только если ваш приоритет строго больше. Тогда, если у вас будет, например, 101 приоритет у запасного и 100 у основного, тогда standby может сказать, у меня приоритет строго больше, у меня preempting включён,

следовательно, я становлюсь немедленно основным, а текущий основной, если он хочет, он может попытаться стать запасным. В любом случае, приоритет по умолчанию 100, preempting выключен. Если вы хотите, вы можете назначить себе приоритет какой-нибудь другой: standby, дальше номер группы, priority и тот приоритет, который вам больше нравится. И standby, номер группы, preempt — включает preempting. Если вы хотите посмотреть, как работает ваш HSRP, для этого есть команда show standby, если вы хотите, вы можете просто show standby сделать, она покажет вообще все группы. Но если у вас много VLAN, и между ними выполняется маршрутизация, и в каждом VLAN у вас есть отдельный виртуальный IP-шник, то вывод может быть очень большой. Поэтому вы можете указать show standby с ограничением по интерфейсам и с ограничением по номеру группы в пределах интерфейса. Вас никто не останавливает в том, чтобы одну и ту же группу использовать на нескольких разных интерфейсах. Поэтому, скорее всего, вы будете использовать везде группу 1,

просто потому что это удобно. Здесь показывается, что show standby vlan 1 group 1, у нас switch A, и показывает, что известно про HSRP на этом интерфейсе, в этой группе. Показывается, что состояние на этом интерфейсе у этого роутера — активный, то есть он активный, он форвардит трафик, он отвечает своими ARP на виртуальный IP-шник. Показывается, какой этот самый виртуальный IP-шник, поскольку он у нас в явном виде в конфиге, то угадывать здесь особо не приходится. 10.0.0.254. Показывается, какой MAC-адрес у нас используется. 0000.0C07.AC01. Я не думаю, что вас на экзамене будут это спрашивать, но на курсах по свитчингу наверняка спросят. Этот самый MAC-адрес, 0000.0C — это OUI Cisco. Её надо будет просто знать наизусть. 0000.0C.

07.AC — это хорошо известный суффикс для HSRP первой версии. 07.AC — это HSRP первой версии. И дальше 01 — это номер группы. У нас номер группы 1, и здесь 01. Поэтому 0000.0C07.AC01 — это хорошо известный MAC-адрес, который по умолчанию назначается на виртуальный интерфейс, виртуальный IP-адрес, соответствующий HSRP первой группе. Понятно, что номер группы — это значение однобайтовое, но по факту вы не можете на свитче создать больше чем 16 групп в одном VLAN. Если вы хотите HSRP запускать с множеством разных групп, вы можете 16 групп в одном широковещательном домене запустить, а 17-ю уже не получится. Таймеры, которые по умолчанию

в HSRP используются: hello-таймер 3 секунды, это как часто посылаются hello-пакеты. Hello у нас посылает и основной, и запасной. Основной посылает hello-пакет для того, чтобы запасной понимал: во-первых, кто основной, во-вторых, какой у него приоритет, и в-третьих, не пора ли его уже смещать с должности. Hold time 10 секунд. Сколько времени мы ждём перед тем, как принимать решение, что с отправителем hello-пакета что-то случилось. Если он нам не присылает 10 секунд ничего, то мы понимаем, что пришла пора захватывать власть как запасному. Preempting включён. Если мы его действительно включили, то мы его включили. Есть смысл preempting включать на всех роутерах в топологии. Либо вы везде включаете, либо вы его не включаете, везде не трогаете вообще. Чаще всего лучше включать. Показывается, кто активный и кто запасной. Активный в нашем случае — это мы сами. Запасной — 10.0.0.2. И показывается, какой приоритет у текущего запасного. 110.

110 означает, что у него приоритет неплохой. Лучше, чем приоритет по умолчанию, который 100. Но он совершенно справедливо стал запасным, потому что приоритет у нас 120. Поэтому, да, его приоритет меньше. Он не может, даже если у него был бы включён preempting, захватить у нас власть, потому что наш приоритет строго больше, чем у него. Далее. На другом роутере, свитч B, мы видим, что состояние текущее — standby, виртуальный IP-шник 10.0.0.254, MAC-адрес сгенерировался точно так же, как мы и сделали это на основном свитче, на основном роутере, но только учитывая, что это роутер запасной, он пока этот MAC-адрес никоим образом не использует. 0000.0C07.AC01. Таймеры. Запасной роутер тоже рассылает Hello-сообщения, поэтому 3 секунды и 10 секунд — это дефолтные таймеры, следующее Hello-сообщение будет отправлено через 2,5 секунды.

Здесь показано, что на запасном роутере выключен preempting, и это не совсем правильно, учитывая, что на основном роутере preempting у нас включён. По идее есть смысл включать preempting везде, иначе вы рискуете словить разные забавные, смешные эффекты. Preempting разрешает запасному роутеру при живом основном, если приоритет запасного строго больше, перехватить власть у основного. И показывается, кто активный — 10.0.0.1, и у него приоритет 120, показывается, кто запасной — это мы, показывается наш приоритет 110, мы понимаем, что нам со 110 приоритетом против 120 соваться бесполезно, даже если preempting был бы включён. Вот так оно и работает. После того как два роутера договорились, кто из них использует виртуальный IP-шник, кто из них использует виртуальный MAC, дальше мы направляем трафик как клиенты на этот виртуальный IP-шник,

точнее, сначала мы резолвим виртуальный IP-шник в MAC, мы кричим запрос ARP, кто из вас, 10.0.0.1, скажите свой MAC, нам возвращает текущий активный роутер MAC-адрес 0000.0C07.AC01, мы направляем трафик на этот виртуальный MAC. Именно активный роутер этот трафик форвардит в сеть назначения. Если вдруг происходит какой-то отказ, активный роутер дохнет, он перестаёт присылать hello-пакеты, через hold time, через 10 секунд запасной роутер это понимает, перехватывает власть и начинает сам обслуживать трафик, который идёт на этот виртуальный MAC. Важный момент. Для клиента ничего не меняется. Клиент после того, как произошёл отказ, после того, как запасной роутер перехватил власть, вообще никоим образом от этого не зависит. Он как посылал пакеты свои на виртуальный MAC 0000.0C07.AC01, он продолжает посылать на этот MAC. Для клиента вообще ничего не изменилось. Свитчи, которые в цепочке будут между клиентом

и обладателем самого виртуального MAC, они перестроят свою таблицу коммутации на основании hello-пакетов, которые посылает активный роутер. Hello-пакеты активный роутер посылает именно из-под виртуального MAC. Поэтому в таблицах коммутации клиентский трафик будет доставляться до обладателя роли активного роутера без каких-либо проблем. Покуда у вас активным был роутер, например, вот этот, он посылал hello-пакеты, эти пакеты шли мультикастом, они разбрасывались по всей сети, и все свитчи в топологии знали, как добраться до этого виртуального MAC. И они отправлялись раз в три секунды, гарантированно у всех свитчей информация была актуальная. Они отправлялись на мультикастовый MAC, соответствующий определённому мультикастовому IP в четвёртом адресе, и они шли из-под этого самого MAC-а 0000.0C07.AC01. Как только у нас активный роутер дох,

запасной роутер становился активным и начинал рассылать сам такие мультикастовые пакеты. Поэтому все свитчи говорили, раньше мы знали, что он вот там сидит, теперь мы знаем, что он вот тут сидит. Это просто обычные кадры, которые меняют направление, в котором свитч знает, где сидит конкретный адрес источника. Этот адрес не мультикастовый, 00000C, как вы видите, первый байт там 00. Поэтому этот адрес обычный unicast-овый. Да, он придуман. Он придуман, правда, не на заводе, но по хитрой схеме он придуман самой Cisco. Cisco немножко некорректно, но всё-таки сделала виртуальный MAC-адрес. Однако он unicast-овый. Он принадлежит ровно одному устройству в каждый момент времени. Если вы используете HSRP и вы делаете это в сети, в которой у вас работает Spanning Tree, с очень большой вероятностью на Cisco у вас Spanning Tree работает в режиме PVRST, ну или PVST. Следовательно, у вас есть много VLAN-ов.

В каждом VLAN-е у вас работает экземпляр Spanning Tree, строит отдельное дерево. И в каждом VLAN-е у вас есть HSRP-группа, в которой есть активный и запасной роутер. Скорее всего, вы будете на distribution-свитчах выполнять функцию маршрутизации, которая у вас будет фактически терминировать этот широковещательный домен. Смотрите, вот это access-свитчи. Это у нас distribution-свитчи. Дальше в ядро. Обычно в сети предприятия очень мало кто закладывает прохождение Ethernet-трафика. Как правило, в реальных сетях, которые у нас встречаются на курсе ICND1 и ICND2, количество свитчей не такое большое, чтобы делать ещё какие-то специальные свитчи ядра. Как правило, в таких сетях, про которые мы говорим, есть только два distribution-а и пачка access-свитчей, которые с этими distribution-ами связываются. Вот такая схема позволяет обслужить практически любую сеть небольшого размера.

И в этой ситуации у нас есть два distribution-свитча, которые выполняют межвиланную маршрутизацию и которые являются шлюзами по умолчанию для пользовательского трафика в разных VLAN-ах. Если у нас есть и Spanning Tree, и HSRP, мы должны будем делать так, чтобы HSRP-шный активный роутер в каждом VLAN-е совпадал бы со Spanning Tree root-ом. В чём фишка? Представим себе, что у нас есть первый VLAN. В этом первом VLAN-е у нас есть, например, пользователь. Если у нас не будут совпадать HSRP-шный активный роутер и Spanning Tree-шный root, например, у нас Spanning Tree-шный root, STP root, будет верхний свитч, а активный роутер HSRP active будет нижний свитч. Что в этом случае произойдёт? На уровне Spanning Tree у нас каждый коммутатор посчитает, как можно добраться до этого самого root-а.

Он скажет, что вот это у нас root-порт, а вот это у нас alternate-порт. Поэтому этот порт будет заблокирован на access-свитче. Именно access-свитч со своей стороны заблокирует uplink-порт. Потому что два distribution-а, скорее всего, находятся ближе к root-у. Здесь, скорее всего, быстрый интерфейс. И в этой ситуации чаще всего блокируется uplink-порт. Один uplink живой, другой uplink заблокирован. Это классическое поведение Spanning Tree. И получается, что для того, чтобы пользовательский трафик дошёл до шлюза по умолчанию, надо пустить трафик сначала до интерфейса на пользовательском свитче. Потом пользовательский свитч через единственный живой uplink должен пустить его на distribution. А потом distribution через свой между-distribution-ский линк должен пустить трафик до HSRP-активного роутера. Если бы мы HSRP-активный роутер держали бы на том же свитче, на котором у нас был бы Spanning Tree root, то это действие было бы не нужно.

Трафик по между-коммутаторному линку между distribution-ами пускать было бы не нужно. И у нас он бы сразу вышел на улицу, сразу бы во внешнем мире уже работал с протоколом IP. Поэтому, если вы сочетаете роль Spanning Tree root с активным роутером, то у вас не происходит лишней передачи трафика по этому линку. Так, давайте попробуем это дело сконфигурировать. Поскольку у нас наша лабораторная сеть прямо сейчас довольно компактная, прямо скажем, она исключительно компактная, у нас в сети есть два узла, которые могут выполнять лабу на HSRP, плюс ещё центральный узел, центральный Core Switch, особенно здесь мы не разгуляемся, конечно. Но мы попробуем что-нибудь придумать. Итак, у нас есть наши свитчики. В моём случае это свитч 0.8, у вас это там свитч 0.1, 0.2. И мы сейчас на них будем включать маршрутизацию.

Точнее, не маршрутизацию, на них мы будем делать так, чтобы на этих свитчах появились IP-адреса. Нам нужен будет тот самый VLAN 1, который нужно будет включить. Интерфейсы SVI, Switch Virtual Interface, они поднимаются в выключенном состоянии. Мы их только что вроде бы создали, только создали этот интерфейс, но у него в конфигурации сразу прописан shutdown. Поэтому нужно его поднимать, выполнить no shutdown, для того чтобы он включился. И затем на него можно повесить IP-адрес. Я предлагаю повесить IP-адрес 10.0.0. Номер комплекта. В моём случае комплект 8, у вас будет там первый, второй. IP-адрес 10.0.0. 10.0.8. 255.255.255.0. И после того, как этот IP-адрес мы повесили,

мы можем взять и посмотреть, что в итоге у нас получилось. У нас, по идее, должна быть связь между двумя узлами, которые у нас сейчас в лабораторных сценариях есть. Я ещё сейчас на центральном свитче пропишу enable, conf t, interface VLAN 1, no shut, IP-адрес 10.0.0.100 255.255.255.0. И сейчас у нас, по идее, всё должно пинговаться. Ping 10.0.0.8. Так, что-то не пингуется. Что-то где-то поломалось. Я знаю, где поломалось. Поломалось вот здесь. Switchport access VLAN 1.

Убираем то, что я там показывал, то, что там было switchport VLAN 20. И сейчас оно должно работать. Тоже что-то не очень интересно. Так, а что может быть? Может быть, Spanning Tree у нас козлит? Show Spanning Tree VLAN 1. Вроде всё в forwarding. Да, Spanning Tree козлил. Вот. Соответственно, сейчас 10.0.0.8 и 10.0.0. Что у нас там? 254. Или 10.0.0. Что там? 10.0.0.100. Пингуются между собой. И мы можем приступать к лабе на HSRP. Дальше. После того, как у нас есть связь

между нашими свитчами по протоколу IP, мы хотим сделать так, чтобы наши два маленьких свитча прикидывались бы одним большим роутером, у которого был бы один большой IP-шник. И для этого мы делаем вот что. На интерфейсе VLAN 1 мы указываем standby. Дальше. Номер группы. Я предлагаю номер группы 1. IP. И IP-шник, который мы будем использовать. Если у нас 10.0.0.1, 10.0.0.2, 10.0.0.8, 10.0.0.100 заняты, давайте 10.0.0.254 будем использовать. Это тот самый виртуальный IP-шник, который у нас будет использоваться в качестве шлюза по умолчанию для клиентов. И клиенты, когда они будут у себя прописывать IP-адреса, они пропишут там 10.0.0.200 IP-адрес, и шлюз по умолчанию 10.0.0.254. После того, как мы прописали это, после того, как у нас виртуальный IP-шник 10.0.0.254 появился,

дальше проходят выборы за право стать запасным. У нас никогда не проходят никакие другие выборы, кроме как за право стать запасным. Сначала в течение hold time после включения роутер, в нашем случае свитч, пытается понять, вообще есть ли живые какие-то собеседники в канале. После того, как он в течение 10 секунд не понимает, что есть живые собеседники, он пытается сам устроить перевыборы, которые длятся ещё 10 секунд. И спустя 20 секунд он понимает, что он право стать запасным таки выиграл. А в тот момент, когда он понимает, что он текущий запасной, и он понимает, что последние 10 секунд он сообщения от основного не слышал, он становится сам основным. Поэтому у меня показывается, что на первом VLAN группа номер один перешла из фазы standby в active, из запасного в активный. Теперь, если вдруг клиенты будут пытаться резолвить виртуальный IP-шник 10.0.0.254 в MAC-адрес,

я сейчас возьму, ping 10.0.0.254 сделаю с центрального свитча, вот он пингуется, show ip arp 10.0.0.254 нам покажет виртуальный MAC-адрес. 0000.0C07.AC01. Core Switch покричал на всю сеть, у кого из вас IP-шник 10.0.0.254, активный роутер ему ответил, этот IP-шник соответствует MAC-адресу вот такому. Как я узнаю, за каким именно портом этот MAC-адрес виден? Я пользуюсь тем, что на этом свитче у меня есть show mac address-table, и дальше я указываю этот MAC. Так. Как там? Адрес надо указывать? Да, адрес. Вот. И я вижу, что он находится за портом Port-Channel 8. Действительно, за Port-Channel, который смотрит в восьмую группу,

этот MAC-адрес обнаружен. Это соответствует вполне той картине мира, которую я наблюдаю, что мой восьмой свитч перешёл в роль активного роутера за эту группу. Давайте теперь мы позволим нашим роутерам перехватывать власть в случае, если текущий активный роутер не кажется достаточно достойным. Если у нас не включен preempting, неважно какой активный роутер, хороший, плохой, запасной роутер не перехватывает власть. Он дожидается, пока тот вздохнёт, и только после этого захватывает роль активного. Но если у нас включен preempting, то мы захватываем роль у основного ровно тогда, когда посчитаем это нужным. Когда мы видим, что текущий основной имеет недостаточный приоритет, который строго меньше, чем наш, мы отправляем сообщение, что теперь мы будем основным. Если мы запасной при этом. Указываем: standby 1 preempt.

Эта команда разрешает захватывать власть. Давайте я сейчас сделаю приоритет строго меньше, чем у текущего запасного. У него приоритет, скорее всего, 100, а я сделаю приоритет 90. И в предположении, что у текущего запасного, то есть у того единственного моего соседа, который есть в канале, приоритет будет больше, и включен preempting, я потеряю роль основного, я попытаюсь установить, кто я буду, я объявлю перевыборы, и через 10 секунд я стану запасным. А он станет основным немедленно. Standby 1 priority 90. Мой приоритет стал строго меньше, чем у запасного. Я активный роутер, мой приоритет стал меньше, чем у запасного. Запасной немедленно захватил власть. Сам стал активным. Я перестал быть активным, поэтому из состояния active

перешёл в фазу «а кто я вообще такой». Я объявил перевыборы, и через 10 секунд я легитимно выиграл выборы из одного кандидата. Здесь видно, что потерял роль активного я в 49 секунд, и в 59 секунд фаза выборов закончилась, и я стал запасным. Теперь, если я буду отправлять пакеты на MAC-адрес 0000.0C07.AC01, трафик будет идти в порт PortChannel1, потому что именно оттуда приходят кадры из-под MAC-адреса 0000.0C07.AC01. Давайте я вам покажу, как выглядят в Wireshark такие кадры, чтобы вы примерно понимали, о чём идёт речь. Давайте попробуем вот этот порт. Я, честно говоря, не знаю, на каком порту оно бегает,

но я надеюсь, что это тот самый порт. Вот он, HSRP. Да, я угадал. Соответственно, 10.0.0.8... А, это мои как запасного кадры. Давайте с основного начнём. HSRP. Standby. Standby. Standby. Я, кажется, с портом не угадал. Тогда вот так. Вот HSRP. State: Active. Это то, что посылает роутер 10.0.0.1, и указывает на то, что он активный. Кадры, которые идут, они идут в обычном Ethernet-формате. Внутри лежит IP-вложение. MAC-адрес отправителя — тот самый 0000.0C07.AC01. И MAC-адрес получателя — IPv4 MAC-адрес,

соответствующий IPv4 мультикастовому IP-адресу 224.0.0.2. Из мультикастового IPv4-адреса мультикастовые MAC-адреса получаются приклеиванием OUI 00:01:00:00:5E и ещё одного нулевого бита к последним 23 битам IPv4-адреса. Если мы хотим отправить пакет на мультикастовый адрес 224.0.0.2, то получится 01:00:5E:00:00:02. Дальше внутри лежит IP-вложение. Внутри IP лежит UDP, внутри UDP идут пакеты с порта 1985 на порт 1985. Такой характерный HSRP-порт. И там HSRP-вложение. Hello Packet идёт с указанием того, что он активный, и виртуальный IP — 10.0.0.254. Тут указывается тот самый Hello Time, тут указывается тот самый Hold Time, и тут указывается приоритет 100.

Если я буду как запасной отправлять какие-то пакеты — это будет уже на другом порту, давайте я это закрою и покажу HSRP-пакеты на другом порту. Я думаю, нам хватит. Вот они. Здесь запасной роутер посылает пакеты на такой же MAC-адрес, на такой же IP, но уже из-под своего настоящего MAC-адреса. Активный роутер посылает пакеты из-под виртуального MAC-адреса, а запасной — из-под своего реального. Но внутри точно так же IPv4. Внутри IPv4 точно так же лежит UDP. Внутри UDP точно так же 1985 порт. И внутри 1985-го UDP-заголовка указание на то, кто мы — мы запасной. Указание на то, какой виртуальный IP — 10.0.0.254, какая группа и какой приоритет. Действительно, приоритет у меня 90. Так что всё честно.

Действительно, ровно такие пакеты там передаются. Ничего хитрого. И поведение, которое мы видим в результате взаимодействия этих пакетов, такое, какое и должно быть. Роутеры прикидываются одним — 10.0.0.254, обладателем виртуального IP. Если какой-то из роутеров отказывает, то через некоторое время запасной принимает на себя его функции. Отказывает — это значит либо просто выходит из строя и перестаёт присылать Hello-пакеты, либо он продолжает присылать Hello-пакеты, но с маленьким приоритетом, и при условии, что на запасном включен preempting, он немедленно становится активным. Это очень удобная штука тогда, когда у вас есть два роутера, которые могут обеспечить выход во внешний мир. Они указывают IP виртуального роутера, как мы сейчас указали — 10.0.0.254. Клиенты на этот виртуальный IP ставят свой адрес шлюза по умолчанию, резолвят таким образом виртуальный MAC-адрес и трафик направляют на этот виртуальный MAC-адрес.

Кто его сможет обслужить, тот и молодец. Для корректной работы HSRP, любого на самом деле FHRP-протокола — это не только HSRP, но и VRRP, и GLBP — мало настроить взаимодействие внутри сети. Надо ещё обеспечить корректную работу этого протокола в случае, если роутер теряет возможность форвардить трафик наружу. Если у него внутренний интерфейс живой, Hello-пакеты посылать может, но у него упал внешний интерфейс, или упали маршруты, которые смотрят во внешний мир, в этом случае роутер должен добровольно понизить себе приоритет. В рамках нашего курса мы не рассматриваем, как это делать, но это очень важный элемент, и если вы настраиваете HSRP, или VRRP, или GLBP, вы обязательно должны это сделать перед тем, как пускать протокол в продакшн. Ещё раз подчеркну, в рамках нашего курса мы не указываем, как это делать, это рассматривается на курсе по свитчингу, поэтому если вы захотите после курса понастраивать HSRP, подумайте, потому что по факту

сейчас вы не узнали самого главного — как это делать. Но тем не менее вы видите, что в конфигурации у нас получается. Show run interface VLAN1. Промахнулся. Show run interface VLAN1. Вот эти команды, которые начинаются со слова standby, они отвечают за настройку протокола HSRP, и примерно их назначение вам уже должно быть понятно. Если вы видите команды, которые начинаются со standby, это про HSRP. На этом HSRP мы прошли. Давайте посмотрим на другой протокол, который похож на него как брат-близнец. Это протокол VRRP. А хотя, есть ли он у нас вообще в нашем курсе? По-моему, нет. Секундочку, я выясню это. Да, я посмотрел программу, прошу прощения, VRRP нету в курсе.

Он там раньше был, теперь его нету. Но если вкратце, VRRP настраивается точно так же, как и HSRP. Вместо слова standby вы пишете VRRP. И всё. Всё то же самое. VRRP 1, IP 10.0.0.254. VRRP 1, priority 90. VRRP 1, preempt. Те же самые команды, ровно те же самые команды, которые мы с вами прошли. И даже диагностика точно такая же. Кстати, диагностику мы с вами не сделали. Show standby. И show VRRP на самом деле — то же самое всё будет. Здесь показывается, кто мы, какие у нас настройки, про что мы знаем, какой у нас приоритет. Всё то же самое. Ещё одна штука, которая здесь интересна. Show standby brief. Она показывает в табличном виде список всех групп, которые у вас есть на устройстве. Показывается интерфейс, номер группы, текущий приоритет, есть ли preempting. Вот это P означает, что есть. Текущая роль — кто активный,

кто запасной, и виртуальный IP. В VRRP единственная разница: preempting по умолчанию включён, нет роли запасного, то есть выборы сразу проходят за роль основного. Немножко другие таймеры, и есть возможность сделать так, чтобы виртуальный IP соответствовал физическому IP одного из устройств. Но в остальном всё то же самое абсолютно. Hello-сообщения отправляются, но только не активным и запасным, а только одним единственным обладателем роли активного роутера, он там называется master. И таймеры там 1 на 3, по-моему. Hello Time — 1 секунда, Hold Time — 3 секунды. А в остальном всё то же самое. Насколько хорошая идея использовать один и тот же адрес? Скорее всего, это плохая идея. За редкими исключениями, которые связаны с миграцией с одного единственного роутера

на какой-то другой. Если вы хотите к существующему роутеру на подхвате ещё один сделать, тогда использовать физический IP может быть неплохой идеей. А если вы новую сеть разворачиваете, то в VRRP Не надо использовать возможность назначать виртуальным адресом физический IP-шник одного из хостов. Давайте перейдем тогда к GLBP. Спасибо.