FHRP

Последний наш модуль, связанный с коммутацией, это модуль, посвященный протоколам отказа устойчивости шлюза по умолчанию или FHRP, First Hop Redundancy Protocols. Задача, которая ставится перед этими протоколами, будет следующая. Мы с вами строим надежную коммутируемую сеть. То есть это хорошая, надежная сеть, в ней работает Spanning 3, в ней работает какая-то альтернативная Spanning 3, в ней, может быть, даже работает что-нибудь типа вендорская, типа WSS. Но как бы там ни было, коммутация в этой сети работает хорошо. И мы сделали так, что отказ любого узла внутри коммутируемой сети, ну кроме разве того access-свеча, к которому включается сам пользователь, не влияет на работоспособность сети. То есть мы сделали красивую схему, при которой у нас все надежное, все отказоустойчивое. Естественно, что есть возможность потерять сам порт, который смотрит на юзера, ну то есть от этого уже никуда не сбавишься. Но, тем не менее, и все остальное у нас защищено надежно.

В то же время, если у нас отказывает дальше протокол IP, то IP перестраивает свои маршруты в соответствии с тем, как мы скажем, чтобы он это делал. То есть у нас надежная маршрутируемая сеть еще работает, но она работает где-то в другом месте. То есть, например, вот здесь вот у нас слева работает Spanning 3 условный и делает защиту нашей сети. Справа у нас работает условный ОСПФ и делает защиту нашей сети. А вот на стыке находятся шлюзы. Шлюзы, которые стыкуют сеть Ethernet с какими-то другими частями сети. И там у нас происходит первая маршрутизация. Загвоздка заключается в том, что те кадры, которые отправляют наши пользователи, они должны отправляться на какой-то MAC-адрес, если мы говорим про Ethernet. И в этих кадрах будут лежать IP-пакеты. И в Ethernet у нас нет обратной связи. И мы не можем узнать, что те кадры, которые мы посылаем шлюзу, они до шлюза по факту не дошли. В других протоколах канального уровня, ну то, что мы называем канальным уровнем, да.

В других протоколах, поверх которых IP работает, у нас может быть обратная связь. То есть, например, у нас можно узнать, что развалилась PPP-сессия. Или можно узнать, что, например, там, не знаю, фрейм-рилей отвалился, потому что у нас перестала приходить сигнализация. Но в Ethernet обратной связи нету. Мы просто отправляем кадры, надеемся, что они дойдут до получателя. К слову, в провайдерских сценариях там немножко другая ситуация. Там вы можете узнать, что какой-то MAC-адрес перестал быть доступен путем разворачивания механизма, который называется OAM. Operations, Administration and Management. Но в сети предприятия это очень большая редкость. И, соответственно, там мы не можем на обычных узлах узнать о том, что какой-то MAC-адрес помер. И когда мы устанавливаем шлюз по умолчанию, мы, как правило, на конечных абонентов шлюз по умолчанию раздаем в виде IP-шника. Этот IP-шник по факту нигде не используется. То есть, на самом деле, от шлюза по умолчанию нам нужен только канальный адрес, чтобы на него мы отправили кадры, которые содержат IP-пакеты, которые не предназначены самому шлюзу.

И они дальше будут пересылаться уже в сеть назначения. Поэтому, по-хорошему, когда мы настраиваем в таблице маршрутизации указание, что куда мы посылаем такие пакеты, мы должны указывать MAC-адрес соседа. Но MAC-адрес указывать просто неудобно, поэтому мы указываем IP. Дальше ARP из этого IP-шника получает MAC. И дальше мы пользуемся на самом деле MAC-ом шлюза. Отправляя кадры на MAC-адрес шлюза и никоим образом не узнавая про то, что этот MAC больше недоступен. Единственное, что может произойти, когда у нас какой-то, допустим, наш шлюз по умолчанию выходит из строя, это то, что рано или поздно у нас сдохнет запись в кэш ARP. Мы заново постучимся на этот IP-шник, спросим, у кого из вас такой IP-шник, скажите свой MAC, и нам никто не ответит. В этот момент мы поймем, что у нас шлюз, в общем-то, недоступен и сможем предпринять какие-то действия. Но до тех пор мы продолжаем пользоваться MAC-ом шлюза, который мы однажды зарезолвили и больше ничего не предпринимаем. Как бы у вас коммутируемая сеть не была надежна, вы все равно прописываете один IP-шник, шлюза по умолчанию, который у вас будет использоваться.

Если вы пропишите два, то это будет означать, что если мы попробуем один, и он у нас в принципе не будет доступен, то есть он либо не будет резолваться в MAC-адрес, либо не будет в коннект от сети, либо что-то еще вот такого плана будет, только в этой ситуации мы будем прыгать на запасной. Ну вот как раз в ситуации, когда вы прописываете два IP-шника, например, в DHCP, там можно задать два IP-шника шлюза по умолчанию. По факту будет использоваться только один, а если он дохнет на уровне не резолвится в ARP, то только тогда начинает работать второй. Понятное дело, что эти механизмы, все, которые есть штатные в IPv4, как защитить шлюз по умолчанию, они очень медленно работают. То есть здесь написано, что таких механизмов нет, на самом деле они есть, но они реально медленные, то есть они работают долго. А если мы хотим их как-то ускорить, то мы можем это сделать, мы можем свести неработоспособность сети к, допустим, десяткам секунд, но при этом мы должны будем жестко закрутить гайки внутри сети и при этом мы увеличим количество бродкастов до каких-то совершенно неразумных значений.

Поэтому можно говорить, что в IPv4 механизмов нормальных рабочих отказов, стоящегося шлюза по умолчанию нет. Если у нас один шлюз дохнет, мы на другой перескочить штатно, ну, либо не можем, либо можем за очень большое время. Каким образом будут работать протоколы типа FHRP, First Hop Redudence Protocols? У нас есть несколько кандидатов на роль шлюза по умолчанию. Они между собой выбирают один, который будет forwarding traffic. И, соответственно, вот у нас получается такая выборная роль правильного кандидата на forwarding traffic, который занимается обслуживанием наших клиентов. У этого кандидата будет в распоряжении такой эстафетная палочка. Временный IP-шник, ну, не временный, нормальный IP-шник, да, но он у него будет находиться временно. Как эстафетная палочка у каждого бегуна находится временно, так же и здесь. Вот. И к этой эстафетной палочке привязан IP-шник, к этой эстафетной палочке привязан виртуальный MAC. И когда у нас идет forwarding боевого трафика, клиенты получают в качестве шлюза именно IP-шник виртуальный.

И MAC-адрес они, соответственно, будут резолвить тоже виртуальный. Они будут давать на всю сеть, у кого из вас такой виртуальный IP-шник, скажите свой MAC, и им будет возвращаться виртуальный MAC. Если у нас текущий обладатель эстафетной палочки дохнет, другой роутер, который другой кандидат на роль виртуального роутера, он берет, поднимает эту эстафетную палочку вместе с IP-шником, вместе с MAC-ом и начинает forwarding кадры на этот самый виртуальный MAC. Это общий принцип действия, ну, на самом деле, двух протоколов отказоустойчивости, FHRP протоколов, First Hope Redundancy Protocols, это HSRP и VRRP. Вот себя вот так вот будут вести. Есть другие протоколы, которые решают ту же самую задачу, но немножко иначе. Мы с вами разберем один из них, это GLBP. Но, в принципе, этих протоколов достаточно много. Вообще, в части, скажем, протоколов отказоустойчивости шлюза есть большой бардак. И бардак заключается в следующем. Есть протокол стандартный, RFC-шный. У него, соответственно, название VRRP, Virtual Router Redundancy Protocol.

Но у этого протокола есть фундаментальный недостаток. Он очень похож на другой протокол, который называется HSRP. Hot Standby Router Protocol. Этот протокол фирменный, цисковский. И циска его продает по лицензии. Поэтому, когда есть цисковский протокол, который она продает, и есть другой протокол, который как две капли воды на него похож, естественно, что циска в этот момент возникает и говорит, ну, ребят, ну как-то так нехорошо. Мы как бы это же за деньги продаем, да? А вы у нас как бы своровали всю идею и раздаете ее бесплатно. Так делать не стоит. Поэтому у VRRP есть определенные проблемы с патентами. А не то, чтобы вы прям не могли использовать этот протокол, если вам очень сильно хочется. Но циска в свое время очень серьезно как-то проявлял интерес к тому, чтобы начать брать деньги за использование VRRP и подавать в суд на тех, кто этот протокол у себя в железе имплементирует. Но по факту циска потом успокоилась и сказала,

ладно, делайте, что хотите. Все равно как-то у нас этот HSRP никто особо не покупает. Поэтому циска, да, выпустила заявление, сказала, что вы делаете это на свой страх и риск. Если вы хотите VRRP имплементировать, пожалуйста, используйте его. Но имейте в виду, что мы сейчас, прямо сейчас, не хотим подавать ни на кого в суд. Но, возможно, мы скоро захотим. Поэтому VRRP такой протокол, который должен стать стандартом, но по факту стандартом не стало именно за проблем с патентами. HSRP, как уже говорилось, протокол фирменный цисковский. Кроме циски его никто у себя не разрабатывал, поэтому встретить его можно только на цисках. GLBP – это еще один фирменный цисковский протокол. Он никоим образом не стандартный. HSRP стандартизирован в той части, что есть RFC, который его описывает. И теоретически, если вы захотите использовать HSRP у себя на железе, то вы можете взять и сделать это. Просто деньги циской заплатите и все. GLBP циска даже стандартизировать не стала. Она сказала, что это наш собственный внутренний протокол.

Мы не скажем, как он работает. То есть вы можете попытаться реверс-инженерить его, но это будет нарушение авторских прав. Ну и да, как следствие, нигде, кроме как на цисках, GLBP встретить нельзя. У других вендоров тоже есть свои специфические вендорские протоколы. Немножко черной магии. У Xtreme есть ESRP – Extreme Standby Router протокол. Ну тут тонкий намек, да, на то, что это очень похоже на циску. Но действительно он довольно сильно похож. Есть у Аваи свой фирменный протокол, который на самом деле закрывает вообще практически все, что связано с коммутацией. Он и про транкинг, он и про построение, как называется, Ether Channel, он еще и вот про отказоустойчивость шлюза. Есть и протоколы, которые пытались решить все эти проблемы, но получилось, как в комиксе XKCD, где есть 14 конкурирующих протоколов. Два человека смотрят на это и говорят, ой, какой ужас, 14 разных протоколов.

Надо сделать один, который будет решать все проблемы этих 14 протоколов. Следующая картинка – это два человека стоят, смотрят, говорят, 15 разных протоколов. Окей. Ну вот, да, CARP – это протокол, который появился как ответ на весь этот зоопарк. Но в тот момент, когда он появился, уже разгорелись вот эти патентные войны, уже был у каждого вендора свой вариант, как решать проблему отказоустойчивости шлюза. Поэтому протокол CARP, когда авторы пришли в ETF и сказали, ребят, давайте мы стандартизируем этот протокол, там сказали, ребят, у нас уже есть один протокол, который должен решить эту проблему. Это VRRP. И мы новый протокол уже предлагать в качестве стандарта не будем. Поэтому протокол есть, протокол не имеет патентных проблем, но он не стандартизирован просто because of acute that's why. Давайте вспомним, как работает HSRP. Мы на ICND2 это немножко смотрели. Вы можете запустить несколько маршрутизаторов в пределах одного широкопрещательного домена,

объединить их в одну группу, и один маршрутизатор в этой группе будет... Я сейчас использую слово выбран, но, пожалуйста, не воспринимайте это всерьез. То есть, когда я говорю выбран, на самом деле я не имею в виду, что там проходят какие-то выборы. Один из маршрутизаторов выбирается активным за всю эту группу, и он будет фарвардить трафик, то есть он будет обладать виртуальным MAC-ом, он будет обладать виртуальным IP-шником, и когда будут приходить ARP-запросы, у кого из вас такой IP-шник, скажите свой MAC, он будет отвечать ARP-ом на эти запросы, и плюс он будет оповещать всех остальных, что он действительно активен и что он нормально работает. Он будет отправлять Hello-пакеты, которые по умолчанию идут раз в 3 секунды. И все остальные узлы будут понимать, что активный роутер есть, с ним все хорошо, ну, то есть никаких действий не требуется. Да. Каким образом HSRP будет обеспечивать работоспособность активного роутера? То есть как все остальные роутеры будут перехватывать в случае проблем с активным роутером ту самую эстафетную палочку?

У нас будет один запасной роутер, который будет называться Standby. Он как раз будет слушать Hello-пакеты от основного, и если он в течение некоторого времени не услышит ни одного Hello-пакета от основного, он немедленно сам станет основным. Все остальные роутеры, они хотя и слушают Hello-пакеты от активного роутера, но они при этом ничего особо не делают. То есть они не реагируют на приход или отсутствие Hello-пакетов от активного роутера. На сообщения от активного роутера реагирует в основном только запасной. Зам запасной, он выбирается среди всех остальных роутеров. То есть смысл заключается в том, что выборы в HSRP проходят за роль запасного роутера, а не основного. Сам запасной при этом единственное, что делает, это слушает Hello-пакеты от основного. Если вдруг что случится, он, соответственно, захватывает роль этого основного по мере хотения своего. Ну и если вдруг сам запасной дохнет,

то надо будет провести перевыборы и сделать так, чтобы кто-то другой стал запасным. То есть у нас всегда есть активный роутер, который forward the traffic, есть всегда запасной, который на подхвате сидит и ждет, пока основной сдохнет. И есть и остальные, которые надеются и верят, что когда-нибудь запасной сдохнет или станет основным, и тогда его роль освободится, и можно будет провести перевыборы. Для того, чтобы все остальные знали, когда проводить перевыборы, запасной сам посылает Hello-пакеты. Тоже по умолчанию раз в три секунды. И тоже по умолчанию все остальные роутеры сидят и ждут сообщения от основного, чтобы понимать, работает он или нет. Если вдруг он перестает посылать сообщения в силу каких-то причин, у нас устраиваются перевыборы. Каким образом настраивается HSRP на оборудование CISCO? Нужно будет на интерфейсе, которым вы смотрите на абонентов. То есть если это роутер железный, то вы на физическом интерфейсе настраиваете или на субинтерфейсе. Если это коммутатор,

то вы настраиваете на SVI. Указываете интерфейс и в нем прописываете команду standby, дальше номер группы, IP и сам IP-шник. Номер группы на всех роутерах, естественно, должен совпадать. Вы можете иногда не указывать номер группы, тогда подразумевается номер группы 0. Ну, если захотите, можете сэкономить на одном символе и не печатать его. Надо даже на двух символах еще пробел. Вот. Ну, чаще всего указывается номер группы 1, потому что больше одной группы в широкомещении на менее, в принципе, держать особой нужды нет. Дополнительно, вы можете указать или не указывать IP-шник. Если вы хотите становиться хотя бы когда-то основным или запасным роутером, то вы должны будете указать IP-адрес, и тогда вы можете инициировать выборы запасного роутера сразу. Если вы вдруг не укажете IP-шник,

то есть вы укажете просто Standby 1 IP, то вы можете максимум услышать IP-шник в сообщениях от активного роутера. То есть, если у вас кто-то выберется запасным, потом перехватит роль основного активного, дальше он, кто-то этот, пришлет вам указание «Я hello, я активный роутер», вот он там укажет IP-шник. И тогда вы можете узнать этот IP-шник, если вы его не укажете, и задействовать при участии в HSRP самому. Но если вы не укажете это, то вы должны будете услышать hello-сообщение от кого-то еще. Если вы укажете Standby 1 IP, там 10.00.254, то вы сразу можете, как только у вас будет живой IP-шник, начать процедуру участия в выборах. Дальше. Вы можете указать, кто из вас должен быть активным. То есть, вы можете указать так называемый приоритет, и тогда, после того, как у вас начинаются выборы, сначала вы выбираете запасной роутер.

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

вы можете перехватывать роль у активного роутера в любой момент, если ваш приоритет строго больше, чем приоритет текущего основного. Но эта штука по умолчанию выключена, и вам следует ее включать. То есть это как раз хорошая рекомендация включать этот механизм. Он называется приемтинг. И в принципе, у него такое очень говорящее название, потому что слово приемт очень похоже на русское слово приемник. И приемник в последнее время, ну, не знаю, как сейчас, да, лет 8 назад, 8-10 назад, слово приемник означало вполне конкретную вещь. Это когда один человек взял и уступил трон другому чисто подержаться. Ну вот у одного человека есть право перехватить трон в любой момент, а у другого человека такого права нет. То есть один к другому может прийти и сказать, Димон, спасибо, что погрел кресло, тебе пора. А другой не может прийти и сказать, Вован, давай я теперь посижу. Ну вот один из них, да, приемник и сидит и ждет, надеется и верит,

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

Ну обычно, да, просто showstandby показывает все, и showstandby за интерфейс и потом номер группы указывает только конкретную группу, которая вас будет интересовать. Есть еще showstandbybrief, она покажет все в виде таблички. Это, пожалуй, самое удобное. Ну, showstandby дает достаточно много диагностической информации, можно ее использовать, и здесь у нас будет много разного полезного, видно. И вот здесь видно, что два свитча, которые друг на друга смотрят в первом Вилане, они выбрали один активный роутер, один запасной, активным будет свитч А, запасным будет свитч Б. И как мы это узнали? Мы видим, что у нас здесь в Вилане первом группа номер один свитч первый будет активный. А свитч второй будет запасной. В HSRP нет смысла в одной группе загонять больше двух устройств, больше двух роутеров, больше двух свитчей, просто потому, что один работает, второй сидит на подхвате, а все остальные

вообще ничего не делают. Они даже на подхвате не сидят. Поэтому деньги заплатили там за три роутера, а по факту работает только один. Это неудобно. Так, показывается здесь виртуальный IP-шник, виртуальные МАКи. На экзамене вы должны будете знать эти виртуальные МАКи как отчинаж. Соответственно, HSRP первой версии используют виртуальный МАК-адрес 00000C, 07AC, и дальше номер группы. То есть 00000C это хорошо известная цисковская ООИшка. Я ее много раз вам в течение курса выписывал. 07AC это хорошо известный суффикс HSRP первой версии. И 01 это вот номер группы, мы указываем, что у нас группа номер один в Вилане первого. Таймеры. По умолчанию HelloTimer 3 секунды, HoldTime, через сколько признаем соседу трупом, если он перестал присылать Hello пакеты, 10 секунд. Можно в HSRP настроить субсекундные таймеры и обнаруживать отказ соседа за время вплоть до 50 миллисекунд.

То есть у вас 50 миллисекунд это время, через которое вы обнаруживаете физический отказ Ethernet. Если у вас Ethernet перестал работать, то вы это определяете через 30-48 миллисекунд. Вот здесь вы можете настроить обнаружение соседа, отказа соседа с помощью HSRP за схожее время. Поэтому да, HSRP может обнаруживать отказ соседа очень быстро, быстрее, чем любой другой протокол, который вы можете использовать нативный VIP, то есть те же самые ARP, вы не можете отправлять там чаще, чем раз в секунду. Нельзя просто таймер, тайм-аут кэшарпа сделать там меньше секунды. А вот в HSRP можно, можно обнаруживать переключение соседа, в смысле, можно обнаруживать смерть соседа и переключение на другой роутер за время там порядка 50 миллисекунд. дальше. Дальше. Показывается в SHOW Standby, кто основной, кто запасной. Наверху показывается ActiveRouter is Local,

StandbyRouter и дальше IP-шник запасного. Внизу с точностью наоборот показывается, кто активный и StandbyRouter is Local. Любой роутер знает, кто активный, кто запасной, потому что они посылают Hello-пакеты, и эти Hello-пакеты идут на специальный мультикаст в адрес с HSRP. Иногда есть популярное заблуждение, что пакеты идут на, допустим, виртуальный MAC вот этого самого HSRP или там на что-то еще нет. Пакеты идут на виртуальный, на мультикаст вайпишник HSRP, на обычный MAC-адрес, соответствующий мультикастовому IP четвертому адресу, но на активном роутере они идут из-под виртуального MAC-а, вот этого самого 0000C077, от чего-то там. На запасном идут просто из-под обычного MAC-а, настоящего, который у него есть. Если вы настраиваете HSRP, то вы должны будете указывать,

кто у вас будет активный, кто будет запасной роутер, и вам следует это назначать сообразно тому, как у вас устроена внутренняя сеть. Для начала заметим, что не в любом дизайне вам HSRP вообще будет нужен. Если у вас используется, например, L3-access, то вам HSRP не нужен. Равно как любой FHRP протокол вам не сильно нужен. Если у вас используется, к примеру, так называемый L2-luped-access, то есть, ну, как раз вот то, что на рисунке нарисовано, где у вас есть кольца, если у вас есть Sparling 3, и вот Sparling 3 там какие-то кольца блокирует, вы в принципе можете обойтись без HSRP. Вы можете в принципе сказать, что у нас любой линк, который есть, он, ну, по большому счету защищен. Один линк отвалился, Sparling 3 перестроил топологию и направил трафик по другому линку. Но в принципе уже HSRP будет нужен, потому что трафик надо куда-то посылать. Если у вас используется

Loop Free Access, то есть сейчас давайте попробую порисовать, насколько мне это выйдет рисовалка. Вот эта штука у нас по определению соответственно L2 линк. Вот этот вот линк тоже может быть L2. Вот этот вот линк тоже может быть L2. А вот этот вот линк может быть L3. И у нас получается Loop Free Access, то есть нигде петель нету. В такой топологии нам Sparling 3 не сильно нужен, по большому счету. Но при условии, что у нас везде на всех свитчах используются локальные VLAN. Тут у нас просто физически петель не возникает. Но в этой ситуации получится, что у нас есть один Distribution Switch и другой Distribution Switch, которые должны будут прикидываться одним. И они будут по вот этому внутреннему VLAN каждому, который будет содержать пользователей, реплицировать свое состояние. Они будут не просто пользоваться, обслуживать через этот линк, они будут еще и свое состояние реплицировать. И вот там как раз HSA Pure уже будет очень сильно нужен.

И если у вас используется Spanning 3, то вы должны будете строить топологию HSRP, сообразную топологию Spanning 3. Фишка будет в том, что если у вас везде L2 линки, вот в таком сценарии будет L2 линк, у нас здесь получается петля. Соответственно, Spanning 3 что-то в этой петле заблокирует. сейчас попробую стереть. Что бы нам здесь могло заблокировать Spanning 3? Он, наверное, заблокирует один из линков, которые формируют петлю. Ну, например, вот этот. И, соответственно, у нас получится, что если у нас Spanning 3 заблокировал вот этот вот линк, то нет смысла активным роутером выбирать вот этот вот switch. Есть смысл активным роутером выбирать верхний, чтобы трафик шел до него напрямую и не шел по внутреннему линку между двумя дистрибьюшенами на соседний дистрибьюшен. Ну, то есть, чтобы он сразу выпрынулся наружу и отправил трафик во внешний мир. Поэтому есть такое общее правило, что кто у вас Spanning 3 тот должен быть и HSRP активным роутером.

Потому что до активного роута в любом случае все свечи будут строить кратчайший маршрут. Ну, соответственно, если у вас будут строить все свечи кратчайший маршрут до Spanning 3 то они же будут строить кратчайший маршрут и до HSRP активного роутера. При этом вы можете в разных виланах назначать разные Spanning 3 руты и как следствие вы можете в разных виланах назначать разные HSRP активные роутеры. Поэтому у вас по факту не просто внутренние линки будут балансироваться, но у вас еще и нагрузка на маршрутизацию на разных роутерах тоже будет балансироваться. У нас получается деньги заплатили за два роутера и работают по факту два роутера. Ну, два дистрибьюшен свеча, которые занимаются еще и маршрутизацией. При этом надо не забывать, что кроме того, что у нас есть внутренняя сеть, в которой мы делаем надежный IP-шник, который всегда, например, будет пингаться, есть еще дальше проблема с выходом во внешний мир. Что будет, если мы построим внутреннюю сеть,

которая надежная, а дальше во внешнем мире у нас внезапно обнаружится какой-то отказ, который не позволит активному роутеру выплевывать трафик наружу. То есть нам нужно будет здесь построить какой-нибудь например, OSPF. И в этом OSPF мы должны будем убеждаться, что у нас все хорошо, что мы нормальные маршруты видим, что мы можем отправлять трафик наружу. Если мы перестаем видеть какие-то маршруты, мы должны будем на это отреагировать и сказать, что все плохо, что мы перестаем быть активным роутером, мы искусственно себе занижаем приоритет и надеемся, что у запасного роутера включен приемкинг, чтобы он роль основного на себя забрал. Так, да, какие таймеры в HSRP мы будем использовать для того, чтобы реплицировать состояние двух роутеров. Вы указываете, во-первых, таймер, как часто отправлять в hello-пакеты. По умолчанию три секунды, но эти три секунды это, ну, прямо скажем, перебор.

Если вы внедряете у себя HSRP, то вам следует эти таймеры занизить, причем занизить довольно сильно. Учитывая, что на Аксессе у нас производительность интерфейсов обычно там в районе 100 мегабит тире гигабита, ну, больше вряд ли, меньше тоже вряд ли, мы смело можем поставить таймеры существенно меньше, чем три секунды. Как правило, HSRP позволяет работать с таймерами, ну, например, секундными, а если вы включаете HSRP второй версии, то даже и субсекундными. Вы можете указать таймер, который будет, например, 15 миллисекунд hello time, и тогда вы, если высказываете 15 миллисекундный таймер, то три подряд hello пакета пропущены, и будет означать, что вы признаете соседа трупом, и это означает, что hello time у вас должен быть в три раза меньше, чем hold time. Ну да, hold time 50 миллисекунд как раз намекает на то, что за это время мы сможем обнаружить соседа. вы можете даже пытаться

меньше таймера указать, но смысла в указании меньших таймеров нету, просто потому, что если у нас обнаружение отказа в эзернете происходит за 50 миллисекунд, то нет смысла в HSRP второй версии, даже если вы используете, определять мертвого соседа быстрее. Все равно у нас на уровне просто физики некоторые соседи не поймут, что у нас произошел какой-то отказ. Поэтому 50 миллисекунд это hold time такой минимально разумный. Даже если вы можете где-то поставить меньше, то не стоит этого делать, просто смысла нет. Ну и надо понимать, что чем чаще вы отправляете пакеты, тем больше вы их отправляете, тем большую нагрузку вы создаете. Если у вас прямо много виланов, в этих виланах много разных групп, и вы выставляете минимальные таймеры, и у вас при этом какой-то очень слабый, очень старый свитч используется, то это может создать на него довольно заметную нагрузку. Ну то есть, если вы указываете 15 миллисекунд hello time, то вы отправляете 600 пакетов в секунду. 600 ли? Нет, 60 пакетов в секунду.

60 пакетов в секунду, да. И у вас, представьте, если будет там, например, 500 виланов. Ну, соответственно, 60 умножить на 500, это сколько? 30 тысяч? Это много. 30 тысяч пакетов в секунду, это много. Вот. Да. Hello time указывает только на то, как часто вы посылаете hello пакеты, а hold time будет использоваться, во-первых, для определения того, когда сдох сосед, то есть вы, принимая hello сообщение, видите, какой hold time там указан. Так же, как в CDP, так же, как в EJRP, во всех цисковских протоколах используется одна и та же идея. мы отправляем hello сообщение, мы указываем в них hold time. И когда мы принимаем hello сообщение от соседа, и в нем написано, что через там 10 секунд считай меня коммунистом, вы, окей, говорите, я начинаю обратный отсчет. 10, 9, 8, 7, 6, 5, 5, дальше приходит новое сообщение, и мы заодно начинаем считать. Но если мы только что сами включились,

если мы не видим hello сообщение от соседа, например, потому что у нас нет ни активного, ни запасного роутера, и мы только должны сами провести перевыборы, то для выборов тоже будет использоваться таймер hold time. И вы будете для выборов использовать свой собственный таймер. Это на самом деле очень важно, потому что если у вас есть в сети несколько роутеров, и у них разные таймеры настроены, то вот в какой ситуации какой таймер будет использоваться, это не совсем очевидно. для проведения перевыборов вы используете свой собственный таймер. То есть, ну, например, как в Spanning 3, мы начинаем работать, мы начинаем работать, считая себя рутом, мы используем свои таймеры. А потом мы перековываемся, мы получаем информацию о каком-то другом руте, мы начинаем заимствовать его таймер. Вот здесь та же самая история. Мы начинаем работать со своим собственным таймером, объявляем перевыборы, и после того, как мы видим, что кто-то другой выбора выиграл, он начинает присылать hello пакеты, и мы начинаем заимствовать его таймер для работы, для того, чтобы определить, когда он сдохнет.

Так, дальше. HSRP начинает работу с того, что включается на интерфейсе. Если у нас есть HSRP роутер, он может на интерфейсе быть в одном из шести состояний. Соответственно, есть состояние init. В отличие от других протоколов, где init у нас означает, что есть хотя бы какая-то активность, нет. HSRP init означает, что этот интерфейс ждет инициализации, он не работоспособен. То есть, например, если у вас интерфейс выключен, в шатдауне находится, вот HSRP на нем не будет работоспособен, он будет состоять init. Learn — это вы ждете того, чтобы определить IP-адрес, с которым вы будете дальше работать. Это происходит, например, в ситуации, если вы запустили HSRP на интерфейсе команды standby1ip, не указав IP-шник. И вот вы пытаетесь залернить IP-шник, который у нас будет использоваться.

Если вы гвоздями прибиваете IP-адрес на интерфейсе, указываете standby1ip, там 10.0.254, то тогда эту стадию ваш роутер будет пропускать. Дальше. Когда вы принимаете участие, что… в смысле понимаете, что вы знаете IP-шник, вы начинаете принимать участие в работе HSRP. И, соответственно, когда вы понимаете, какой у вас IP-шник будет, за какой IP-шник, за какую группу вы будете работать, вы переходите в состояние listen. И вы ждете в течение некоторого времени, в течение hold-тайма более точно, вы ждете входящие пакеты. И это состояние называется listen именно потому, что вы сидите и слушаете. Вы ничего не делаете, вы слушаете, слушаете, слушаете. И, соответственно, слушаете hello-пакеты от активного и hello-пакеты от запасного. Зачем вы это делаете? Активный роутер вам, в принципе, ни зачем не нужен, потому что до тех пор, пока вы запасным не станете, активный роутер вам не интересен.

Активный роутер интересен только запасному. Но вот запасной вам очень сильно интересен. Вы ждете, чтобы на вас пришли сообщения от запасного. Если в течение hold-таймера вы не видите сообщения от запасного, то вы говорите, о, у нас перевыборы. У нас раньше запасного, соответственно, не было, а сейчас будет. И я первый кандидат. Вы начинаете рассказывать про то, какой вы будете запечатать на запасной, и вы себя переводите в фазу speak. То есть вы рассказываете про то, какой вы будете замечательный кандидат на роль запасного. Если вдруг у нас текущий запасной сдох, и несколько роутеров одновременно сидели в listen, они, соответственно, сидят, сидят, сидят, слушают сообщения от запасного, понимают, что в течение последнего hold-тайма сообщения от запасного не было, и надо проводить перевыборы. Вот, соответственно, фаза speak. Одновременно все роутеры переходят, начинают рассказывать друг другу про то, какие они замечательные. Но среди них будет один самый замечательный, который будет выбираться по каким-то общим критериям.

То есть у кого приоритет больше, и если приоритет одинаковый, у кого IP-шник больше. И рано или поздно запасной роутер у нас становится выбран, и час RP переходит в фазу standby. Это происходит, опять же, по окончанию таймера hold-time. Наконец, standby роутер получил, он сидит и ждет сообщений от активного. Но есть нюанс. Если активный уже есть, он присылает hello сообщение, час RP сидит на попе ровно, ничего не делает. Но если в течение последнего hold-тайма не было сообщения от активного роутера, мы в фазу standby только что перешли. Мы вообще-то только что были в фазе speak, и в этой фазе speak мы находились в течение hold-тайма. Так вот, если в фазе speak мы рассказывали про то, какой мы бы были запасной роутер замечательный, но мы при этом сидели и слушали сообщения от основного. И если мы сообщения от основного не слышали, то как только мы перешли в фазу standby, мы тут же немедленно говорили, вот мы сели на трон запасного,

но мы в течение последнего hold-тайма, пусть даже он был в фазе speak, не слышали сообщения от основного. Поэтому мы стул запасного немедленно освобождаем и немедленно пересаживаемся в стул активного, в стул основного роутера. Просто на том основании, что в течение последних 10 секунд мы не слышали от него никаких сообщений. Так что, когда у вас два роутера начинают работу, они начинают работу именно сначала в фазе listen, если вы прописываете IP-шники везде. После фазы listen они оба одновременно устраивают перевыборы, переходят в фазу speak. После фазы speak один из них выбирается standby, и он сразу же говорит, я немедленно перехожу в фазу активного роутера, потому что активного у нас нет. И, соответственно, роль standby освобождается, и второй роутер среди самого себя проводит перевыборы. Так. Как уже было сказано, есть у HSRP,

равно как и у всех на самом деле протоколов отказоустойчивости шлюза, фундаментальная проблема. Что сделать, если у нас перестает быть доступен выход во внешний мир? То есть то, что мы внутри сети реплицируем состояние, говорим, я буду активный роутер, нет, я буду активный роутер, окей, хорошо, роутеры договорились, роутеры сказали, что активным роутером будет вот он, мы от него получаем hello-сообщение, все правильно. Но что будет, если этот самый активный роутер перестает иметь доступ во внешний мир? Это, соответственно, означает, что он должен перестать быть основным роутером, перестать быть активным. Но а как это сделать? То есть он что-то должен сделать такое, чтобы все остальные поняли, что он перестал быть активным. И, соответственно, нам нужен будет какой-то активный логический элемент. И этот логический элемент будет называться так или иначе скриптинг. То есть мы должны будем написать какое-то условие, что если произойдет нечто снаружи неприятное для нас, то роутер должен перестать отсылать активные сообщения.

Штатной скоробки в HSRP этого нет. Но когда-то было что-то запрограммировано, но сейчас на все, что будет предлагать Cisco, мы фактически должны будем писать в явном виде, назовем это скрипты. Давайте расскажу поподробнее про это. Как вы помните, у нас есть такие штуки, как IPSLA, и у нас есть такие штуки, как объекты отслеживания. Самый простой вариант с IPSLA, который мы можем сделать, это сделать просто пинглку. То есть если у нас есть, назовем это пинглка, мы сделаем зонды, которые умеют пингить соседа, то мы можем сказать, покуда мы через switch, через роутер номер один можем пингать внешний какой-то узел, мы, соответственно, хотим быть активным роутером. Если мы перестаем пингать внешний узел, то мы перестаем хотеть быть активным роутером, мы, соответственно, должны будем потерять наш статус активного. И сделать это мы можем, например, с помощью декремента

по отношению к нашему приоритету. Приоритет штатный будет 100. Но если мы укажем, что у нас есть вот такая вот пинглка, которая пингает соседа, пока она в API, пока она пингает соседа, у нас все хорошо, мы работаем с дефолтным приоритетом. Если мы указываем, что у нас происходит какая-то авария, что у нас пинглка перестает пингать соседа, мы снижаем себе искусственно приоритет на заданную величину. Здесь на слайде вы можете видеть пример такой конфигурации. Мы сделали пинглку зонда номер 10, пинглка типа ICMP Echo, она раз в 5 секунд пингает соседа, и указываем ей расписание. Соответственно, IPSLA для 10 зонда. Запускаем расписание. Начни сейчас, никогда не останавливайся. Затем мы создаем объект отслеживания номер 100, трек 100 IPSLA 10. Запускаем 10 зонд, и, ну, да, объект отслеживания. И, наконец, в настройке интерфейса,

на котором у нас висит HSRP, пишем секретную команду. Standby 1, то есть Standby Новорогруппа 1, трек 100, то есть привязываем объект отслеживания сотой, и если этот объект уходит в даун, то проседаем по декременту. Декремент можно не писать, то есть можно записать просто Standby 1, трек 100, и тогда при проседании приоритета просядет на 10 копеек. Вот. На экзамене будут вопросы на дефолтные приоритеты, на дефолтные декременты. То есть что будет, если ничего не писать, что будет, если написать вот так, что будет, если написать вот это. То есть дефолтный приоритет 100, и если мы ничего не указываем, то декремент для объекта отслеживания будет 10. Если мы пишем в явном видео, то декремент будет такой, как написано. Дальше. Вы можете, даже сейчас вернусь к этому слайду, вы можете использовать другие объекты отслеживания, которые будут использовать нечто другое. Что я здесь имею в виду?

На слайде показан примен с пингалкой. И пингалка — это наиболее, наверное, простой вариант, чем можно отслеживать. Ну, пингается сосед хорошо, не пингается плохо. Но здесь у нас есть нюансы, заключающиеся в том, что то, что сосед не пингается, не означает, что у нас все пропало. То есть, если у нас есть стык маршрутизируемой и коммутируемой сети, более правильно было бы, на самом деле, отслеживать не пингание соседа, а, например, наличие определенного маршрута. И в команде track мы можем указывать, что нас интересуют не зонды, а, например, маршруты. Мы можем указать, пока у нас есть дефолтный маршрут, мы можем быть активным роутером. Если у нас дефолтного маршрута нет, мы перестаем быть активным роутером. Или можно сказать, что у нас есть, например, в таблице маршрутизации какой-нибудь маршрут до лубэка борда роутера. Если у нас есть маршрут до обоих борда роутеров, то мы, соответственно, декремент никакой не делаем. У нас приоритет нормальный штатный.

Если у нас по тому SPF один из бордеров перестает приходить, то мы говорим, окей, мы проседаем по приоритету, декремент у нас падает. Если у нас SPF вообще отваливается целиком, у нас перестают приходить вообще все маршруты, и мы декремент себе проседаем сильно. То есть вот этих вот команд stand-by-1-track чего-нибудь, их может быть несколько. И вы можете сделать два объекта отслеживания, один из которых отслеживает наличие маршрута до одного бордера, а другой — наличие маршрута до другого. Если у вас оба отваливаются, то вы можете, соответственно, сказать, я совсем плохо работаю, я не могу быть активным роутером. Если у вас отвалится только один бордер, то вы худо, бедно, но продолжить работать сможете. Можно отслеживать не IP маршруты, а можно отслеживать состояние интерфейсов. Можно отслеживать состояние IP поверх интерфейса. Например, если вы IP-шники, получаете динамическим образом. Вы, когда получаете адрес, у вас есть живой работающий IP на интерфейсе,

и вы можете сказать, у нас объект отслеживания будет в API. Если вы теряете IP-шник, например, потому что он у вас выключился, потом включился, и DHCP на нем адрес не получил, то вы говорите, у меня интерфейс, в общем, как бы в API, но IP-шника на нем, соответственно, нет. Вот такие вот вещи вы можете делать. И с помощью них вы можете достаточно гибкие правила указывать, кто у вас в сети должен быть активным роутером. Но в любом случае, да, кто-то один будет активный роутер, кто-то один будет forwarded traffic, и вы должны будете написать правила, в каком случае, насколько проседать у вас будут приоритеты, кто в какой ситуации, у кого будет приоритет перехватывать. Дальше. В старых iOS-ах до 15.00 у вас была возможность указать в HSRP команду отслеживания интерфейса напрямую в конфиге. Команда имела вид standby1, номер группы, трек, и дальше название интерфейса. И через пробел вы указывали декремент. То есть вот standby1, трек, gigabit, ethernet 01.20.

Эта команда позиционировалась как очень клевая вещь, которая в iOS позволяла в HSRP нативно привязывать интерфейсы. То есть если у вас падал живой интерфейс наружу, ну, например, uplink, то, соответственно, ваш switch терял возможность становиться активным роутером за эту топологию. Или вы могли сказать, что у вас есть два uplink. Вот один uplink теряем, мы чуть-чуть проседаем по приоритету, и мы проигрываем в этом случае выборы другому роутеру, который, например, оба uplink имеют живые. Но если у соседа при этом два uplink сдохнут, то один живой uplink у нас будет уже лучше, чем у него ноль живых uplink. Поэтому можно было вот там, опять же, достаточно гибко играть этим. В 15-ом iOS, в 15-нулевом, вы будете встречать то, что этой команды на самом деле больше нет. Вы можете ее ввести, но это будет макрос, который за вас будет в конфиг сразу создавать команду по созданию объекта отслеживания трекинга.

И, соответственно, вот здесь вот пример. Вы видите, на слайде показан, где мы создаем команду отслеживания в старом стиле. Standby 1 track gigabit Ethernet 0.1.20. То есть, типа, просядь на 20 по приоритету, если gigabit Ethernet 0.1 падает в down. А по факту в iOS 15-нулевом уже эта команда преобразовывалась в другое. На интерфейсе вешалась команда Standby 1 track, дальше номер объекта отслеживания, новый созданный, decrement 20. И создавался новый объект отслеживания. Track 1, интерфейс gigabit 0.1 line protocol. Эта команда, она создает объект отслеживания, который находится в API, когда у вас интерфейс находится в API, или переходит в down, когда интерфейс падает в down. В новых iOS вы даже эту команду просто ввести не можете. Standby 1 track interface. То есть, если вы попытаетесь в новом iOS выполнить такую команду, то система вам просто не даст это сделать. На экзамене у вас наверняка будет вопрос,

типа, что из перечисленного поддерживает отслеживание интерфейсов? Вы должны будете говорить, что HSRP штатно, нативно поддерживает отслеживание интерфейсов. Это его киллер фича. При этом, на самом деле, он этого не поддерживает. То есть, он это делает через костыль, через объекты отслеживания. А в новых iOS он даже этого не делает. То есть, там только объекты отслеживания, никак иначе. Вот. Но на экзамене, да, надо говорить по-старому. HSRP будет использовать следующую схему отправки пакетов. То есть, когда мы отправляем HSRP-шные пакеты, у нас два типа, два случая есть. Это hello-пакет основного и hello-пакет запасного. Все, что происходит в HSRP, все происходит с помощью hello-пакетов. И эти самые hello-пакеты, они отсылаются по таймеру, как уже говорилось. Таймер на каждом устройстве настраивается свой. И в каждом сообщении мы указываем hold time, через сколько нас признавать трубом. При этом, на самом деле, когда мы отправляем hello-пакеты от активного роутера,

мы тем самым влияем и на запасной тоже. Он должен отправлять hello-сообщение примерно с такой же частотой. Иначе получится некрасиво, что у нас один роутер будет использовать одни hello-пакеты, а другой другие. Поэтому в каждом сообщении каждый роутер прикладывает свои hello-time и hold time. Эти пакеты hello будут отправляться по UDP на хорошо известный порт 1985. Причем и source, и destination порт будет 1985. Это вот стандартные HSRP-пакеты. HSRP первой версии использует мультикастовый адрес все роутеры 224.002. То есть он предполагает, что если вы берете CISC и строите сеть на роутерах CISC, то все роутеры в этой сети, они все будут как бы CISC-овские, все они будут получать HSRP-шные сообщения. Потом у CISC пришла в голову идея, что, в общем, это не очень хорошо, что мы используем адрес все роутеры. И для HSRP второй версии она сделала отдельную мультикастовую группу 224.00102.

На экзамене надо будет опять же эти айпишники помнить. Дальше. На уровне Ethernet-а вот эти вот самые 224.002, 224.00102 айпишники мультикастовые превращаются в мультикастовые маки. То есть 0.1.005e и дальше хвост от айпишника. Либо 0.002, либо 0.00102. И адрес источников в кадрах будет либо, если мы активный роутер, виртуальный мак, тот самый 0.00000C, 0.7AC, номер группы, либо если это запасной роутер, он уже не отправляет сообщения из-под виртуального мака, он отправляет сообщения из-под своего собственного мака. То есть в этом заключается разница в хеллоу-сообщениях от основного и от запасного. Они идут из-под разных по типу маков. И здесь важно как раз то, что мак-адрес, вот этот вот самый в хсрп роутер, 0.00000C, 0.7AC, чего-то там, это мак юникастовый.

Он соответствует одному айпишнику. То есть он не соответствует на самом деле многим разным айпишникам. Мы по самому маку видим, что это мак начинается на 0.0. У него самый первый битик, передающийся по сети, самый младший бит первого адреса, четный. Поэтому это адрес юникастовый. И, соответственно, активный роутер использует именно его для отправки хеллоу-сообщений. Тот факт, что активный роутер рассылает по таймеру хеллоу-сообщения мультикастом, означает, что все узлы в принципе будут получать эти самые мультикастовые сообщения. Кроме того, это означает, что все-все-все свечи по дороге внутри топологии у вас получат эти самые кадры. И поэтому все-все-все свечи своими портами будут смотреть в сторону мультикастов адреса 0.0.0.0.0.0.0.0.0.0.7.0.0.1 в сторону физического интерфейса роутера, именно активного роутера. Если у вас произойдет переключение, если у вас другой роутер перехватит роль активного,

он начнет посылать сообщения, активный хеллоу от себя, ну то есть уже от своего порта, но опять же из-под виртуального мака HSRP 0.0.0.0.0.0.0.0.0.0.0.7.0.0.0.0.0.0.0.0.0.0.0.1. И все свечи, когда будут получать новые мультикастовые хеллоу-пакеты от другого роутера, они перестроят свои таблицы коммутации. То есть вам не нужно ничего делать для того, чтобы свечи перестроили таблицу коммутации. Сначала один отсылал пакет от виртуального мака, а теперь другой будет отсылать пакет от виртуального мака. И когда роутеры производят переключение с одного роутера на другой, свечам не нужно ничего делать, они сами перестроят свои таблицы. И причем сделают это очень-очень быстро. Так, далее. Что здесь еще заметить? Пам-па-па-па-пам. Здесь видно, соответственно, что у нас передается виртуальный IP-шник. То есть в хеллоу-сообщениях активного роутера передается указание, какой у нас виртуальный IP-шник используется.

Передается номер группы. Мало того, что он в маке закодирован, то есть вот это вот 0.1, это номер группы. Но на самом деле в самом сообщении номер группы тоже будет показываться. Показывается текущий приоритет активного роутера. Поэтому запасной, он всегда знает, какой приоритет у него и какой приоритет у активного. И если на запасном настроен приемптинг, то есть право отбирать у активного роутера трон в любой момент времени, то, соответственно, вот запасной роутер может принять решение о том, что он забирает роль у активного роутера прямо сейчас. Если настроен приемптинг и если приоритет запасного роутера строго больше, чем приоритет основного. Здесь же показываются таймеры. Здесь показывается, что это за хеллоу-сообщение. То есть состояние, что это hello-сообщение от активного роутера, там ставится флажок активный. Ну, у запасного ставится другой флажок. Вот. Ну, в общем-то, и все. Еще один забавный нюанс заключается в том, что все HSRP-сообщения всегда в обязательном порядке подписываются паролем.

И пароль по умолчанию Cisco, plaintext, вот маленькими буквами. То есть он прямо по сети передается. Вы можете HSRP настроить с каким-то другим паролем, но нельзя, вообще нельзя никогда ни при каких обстоятельствах сделать так, чтобы пароль не передавался. Он всегда есть. Так, по поводу, соответственно, пароли. Все пароли, все пакеты по умолчанию подписываются паролем, уже сказал. Если вы хотите, вы можете этот пароль поменять. Вы можете все сообщения подписывать каким-то другим паролем, не Cisco маленькими буквами, а каким-то другим. Но целесообразность этого действия вызывает вопросы, потому что любой желающий возьмет, включит в AirShark, и он будет получать мультикастовые кадры, соответственно, приходящие на все узлы, обладающие определенным IP-шником. И, соответственно, он будет перехватывать эти сообщения. Он может посмотреть на пароль в открытом виде, после чего, когда он увидит пароль в открытом виде, он, соответственно, сможет сделать какое-то нехорошее действие.

Ну, например, он может перехватить роль активного роутера, все пакеты, все узлы будут посылать в первую очередь к нему, а дальше он уже будет думать, что с этими пакетами делать. Идеальный вариант, как устроить атаку man in the middle. Поэтому, если вы хотите использовать CSRP с аутентификацией, использовать открытый пароль — это прям совсем плохая идея. И вам следует вместо использования открытого пароля использовать хэш от пакета плюс пароля. Опять же, здесь используются хэши MD5, и вы указываете... Здесь ошибка, конечно, напечатка на сайте. KeyString. Вот. Вы указываете пароль, и вы указываете, что не надо его по сети плейнтекстом гнать, надо пересылать MD5 хэши. MD5 хэш взламывается, но не настолько хорошо взламывается, чтобы на лету сообщение от нормального активного роутера, соответственно, подменить какими-то другими. Поэтому, в принципе, ничего плохого в использовании MD5 в этом случае нет. Так.

Дальше. Если мы хотим использовать HSRP первой версии, он нормальный, он хороший, то в HSRP первой версии мы можем создать до 256 групп в одном широковещательном домене. Столько, по факту, не надо. Более того, вы не сможете сделать 256 групп, если у вас всего два сервера, потому что на каждом сервере вы можете в одном вилане сделать до 16 групп. То есть вы можете 16 разных виртуальных айпишников держать в одном широковещательном домене. Но вот, соответственно, HSRP второй версии этот лимит решил убрать, и он позволяет создать до 4096 групп в канале, что, опять же, немножко неразумно, на мой взгляд, учитывая тот факт, что, опять же, ограничение на 16 групп никто не отменял. 4096 групп означает, что у вас под номер группы отводится 12 бит, и так же, как в HSRP первой версии, номер группы у вас закодирован в виртуальном МАКе. Поэтому старый МАК-адрес, который был 00000C, 07AC и дальше один байт номера группы,

пришлось изменить. Для HSRP второй версии используется МАК-адрес 00000C, 9FF, то есть 0000C это хорошо известный цисковский префикс, 9FF это хорошо известный HSRP 2 суффикс, и дальше 3 символа, 12 бит это номер группы. HSRP второй версии поддерживает IPv6, то есть если вы захотите, вы можете HSRP вторые сообщения посылать в IPv6, и они будут у вас реплицировать состояние IPv6 роутера. Ну, про мультикастовый IPv6 уже говорилось, что он другой, и UDP там тоже будет немножко другой. То есть HSRP вторые сообщения, они вместо 19.85 порта используют порт 2029. Как следствие, в принципе, не получится в одной сети, в одной группе взять и обеспечить легкий переход с HSRP первой версии на второй. То есть если у вас есть два роутера, которые оба работают в первой версии,

и вы хотите их перевести на вторую версию, как только вы на одном скажете версия 2, standby version 2 на интерфейсе, целиком на интерфейсе, она меняется не в группе, а на интерфейсе, то у вас один роутер начинает работать во второй версии, другой роутер все еще работает в первой версии. Каждый из них отдельный, независимо друг от друга существует. Первая и вторая версии несовместимы между собой. Они разные порты, разные мультикастовые маки используют. И, соответственно, они у вас разваливаются на две разные сущности, на две разные группы. Номер группы может быть одинаковый, но в одном случае это группа первой версии, а в другом случае группа второй версии. И у вас в каждой группе независимо выбираются активный роутер. И активный роутер начинает отправлять пакеты с своего виртуального мака и будет рассказывать про то, что у него есть виртуальный IP-шник. Как следствие, два активных роутера приведут к тому, что у вас в сети будет конфликт IP-адресов. Поэтому не надо так делать. Если вы хотите перевести HSRP первую версию во вторую,

то надо будет, соответственно, выключить сначала все роутеры, кроме активного в HSRP первой версии, потом на первой версии поменять вторую, а потом включать во вторую версию все остальные роутеры, просто подключаясь. Вот. HSRP второй версии, как уже говорилось, поддерживает субсекундные таймеры. То есть, если, опять же, вернуться немножко назад, здесь видно, что таймеры, которые используются в HSRP первой версии, они просто в секундах указывают время hold time и hello time. Но если мы используем HSRP второй версии, то там уже можно будет существенно более гранулярно эти таймеры поставить. переключение, да, уже говорил, да, на уровне всего интерфейса. То есть, без указания номера группы нельзя сделать так, чтобы часть групп у вас работала в одной версии, часть в другой. Есть нюанс, заключающийся в том, что на экзамене я своими глазами видел вопрос, на который правильным ответом была команда типа standby типа 1 в версии 2.

То есть, что можно отдельную группу перевести в режим второй версии. Это вранье, этого нельзя так сделать, вы можете это проверить на своем оборудовании. Но, да, если вдруг все остальные ответы будут еще более неправильные, то отвечайте так. Но, в принципе, да, в вторую версию переводится целиком интерфейс, а не отдельная группа. Так, далее. Еще один протокол фирменный, цисковский. Это протокол GLBP. Он будет очень похож на HSRP в том смысле, что он тоже решает ту же проблему, что и HSRP. Он внутри себя под капотом содержит протокол HSRP, второй версии причем. Он использует тот же самый IP-шник. Он использует ту же самую схему работы. То есть, там есть активный роутер, есть запасной роутер. Но у GLBP есть одна отличительная особенность, которая принципиально, скажем, его разнит с HSRP второй версии.

У HSRP второй версии один работает, все остальные отдыхают. Здесь четыре работают, остальные отдыхают. То есть, у нас есть четыре роли, те, кто forward the traffic. Активный роутер будет контролировать этих четырех. То есть, в HSRP у нас активный роутер выбирается, и он работает. А в GLBP активный роутер выбирается, и он назначает тех, кто работает. В этом разница в схеме HSRP и GLBB. У нас будет роутер, который называется активный роутер или Active Virtual Gateway. Это, несмотря на то, что он называется gateway, он не gateway на самом деле, это вот тот самый диспетчер. Он назначает роли Active Virtual Forwarder. Их четыре, ну или, скажем, до четырех. Он может назначать меньшее количество ролей, если посчитает нужным. Если у вас в сети всего два роутера, он назначит только две роли AVF. Но если у вас четыре роутера или больше, он назначит все четыре. Вот. Вот. AVG-шка Virtual Gateway, он же диспетчер, отвечает на запросы ARPA. Если вдруг приходят клиенты и говорят, у кого из вас какой IP-шник, скажите свой MAC.

Вот AVG-шка будет отвечать ARPA-ответами. И он будет отвечать виртуальными MAC-адресами ролей AVF. У них у каждого есть отдельная роль AVF1, AVF2, AVF3, AVF4. И у каждого из них есть свой собственный виртуальный MAC. И вот, соответственно, AVG-шка в разнобой отвечает разными MAC-ами в сторону разных AVF. Если у вас есть пользователи, они приходят на AVG-шку, говорят, скажи MAC IP-шника, например, 1001. И AVG-шка отвечает, на тебе IP-шник одного фарвардера. Потом приходит другой клиент, она говорит, на тебе IP-шник другого фарвардера. Приходит третий клиент, он говорит, на тебе IP-шник третьего фарвардера. И по факту разные клиенты, получая разные MAC-и фарвардеров, пользуются для отправки трафика во внешний мир именно разными MAC-адресами. В то же время, если у нас происходит какой-то отказ, например, AVF2 дохнет, то, соответственно, его роль просто переходит к какому-то другому роутеру, другому фарвардеру. И, соответственно, он начинает работать за себя и за того парня. Так.

Включается все очень похожим образом на HSRP. То есть мы на интерфейс заходим, говорим, там, где раньше была команда standby, здесь мы задаем команду glbp. glbp — номер группы, IP и дальше виртуальный IP-шник. То есть команда точно та же самая. Вы, в принципе, можете настроить приоритет, в принципе, можете настроить приемтинг, но смысла в этом особого нету, учитывая тот факт, что и приоритет, и приемтинг используются подкапотным HSRP V2 для роли того самого виртуального диспетчера. Поэтому вы можете сказать, что у вас приоритет миллион, и приемтинга аж целых два будет, но, соответственно, все равно вы просто тем самым указываете, что вы будете диспетчером. А по факту диспетчер — это роль очень ненапряжная. И если вы хотите, например, чтобы какой-то роутер фарвардил трафик с большей вероятностью, а какой-то роутер не фарвардил трафик вовсе, то вам следует играть не приоритетом в случае с glbp, а весами.

У каждого узла, который в glbp работает, есть еще такой параметр, как вес. По умолчанию он точно так же, как и приоритет, будет 100. Но этот самый вес можно уменьшать точно так же, как и в случае с приоритетом с помощью объектов отслеживания. Или вы можете назначать разные веса разным роутерам изначально. И, соответственно, если у вас есть какой-то более мощный роутер, вы можете ему вес побольше сделать. Если есть вес поменьше, в смысле, если роутер послабее, вы можете сделать ему вес поменьше. И тогда у вас будут выбираться наиболее мощные роутеры для фарвардинга трафика. И если вдруг у вас, у роутера, например, было два оплинка, стал один, то вы можете сказать, что раньше у нас было, соответственно, два оплинка, мы были мощный роутер, сейчас у нас один оплинк сдох, мы по производительности в два раза просели. И, например, мы вес в два раза тоже, соответственно, проседаем по весу. Вот. У GLBP точно так же команда есть, show GLBP.

Можно show GLBP brief, который покажет табличный вывод, кто в нашей группе есть, кто фарвардер, кто диспетчер. Ну и с того, что здесь будет интересно, показывается, кто мы. Вот это вот Active показывает, что мы AVG, Active Virtual Gateway или диспетчер. Показывается виртуальный IPшник, который мы используем, таймеры, которые по умолчанию 3 на 10. Это, опять же, видите, таймер из HSRP. Это его таймеры изначальные. Показывается, что приемтинг выключен, так же, как в HSRP, в GLBP по умолчанию приемтинга нет. Но приемтинг в GLBP и не нужен. В HSRP мы приемтинг включать должны, потому что иначе, если мы отдаем роль активного роутера в HSRP, кто-то другой должен ее забрать. Поэтому везде надо будет приемтинг в HSRP включать. А в GLBP приемтинг выключен. И, соответственно, его там можно не включать, он там не сильно нужен. Точно так же выбирается основной роутер-диспетчер.

Запасной роутер-диспетчер тоже выбирается. Здесь не совсем понимаю, почему он нов, но не суть важна. И показывается, кто у нас в группе есть. AVG знает про то, кто у нас в группе есть. Видит, соответственно, тех, кто пытается принимать участие в каких-либо выборах. И вот он видит IP-шники 10.001 и 10.002. Между этими двумя узлами разыгрываются две роли фарвардера. Фарвардер-1 и фарвардер-2. Вот. Соответственно, за роль фарвардера 1 мы сами стали активны. То есть у нас два роутера в сети, один из них диспетчер и оба они фарвардеры. Вот тот у нас совмещает и роль диспетчера, и роль фарвардера. Показывается виртуальный MAC-адрес. У GLBP виртуальный MAC-адреса следующий. 0.007B4. Дальше. Это префикс GLBP. Дальше.

0.001 номер группы. И 0.1 это номер фарвардера. У первого фарвардера будет такой MAC-адрес. У второго фарвардера будет MAC-адрес 0.007B4. Дальше. 0.001 номер группы. И 0.2 это номер фарвардера. Показывается, кто активный, какой вес имеет. За фарвардеры не выбирается запасной, потому что в GLBP нет процедуры выборов фарвардера. Фарвардеры назначаются. Назначаются диспетчером, поэтому нет смысла держать запасного. Вот за роль за диспетчером можно держать запасного. А за роль фарвардеров нет смысла держать запасного. Там они назначаются указки из Москвы. И поэтому им там нет смысла держать запасного. Что с GLBP будет принципиально проблемного?

GLBP поддерживается только если у вас дизайн без петли. То есть если у вас есть спанинг 3 в сети, то вам GLBP не нужен. Сами понимаете, что если у вас есть один роутер и второй роутер, и у вас есть пачка access свечей. Раз, два, три, четыре. Давайте другой цвет возьму для обозначения линков. Возьму какой-нибудь рыженький цвет и мы рисуем треугольники. Вот такие вот. Раз треугольник, два треугольник, три треугольник и четыре треугольник. Вот если у вас здесь спанинг 3 есть, а он здесь должен быть в такой сети, то спанинг 3 нам что-нибудь дозаблокирует. Так, опять же, сейчас я нарисую, что он нам заблокирует. Раньше планшет не рисовал, сейчас еще и мышка перестала показываться. Спанинг 3 скажет, вот этот вот порт у нас заблокирован, вот этот порт у нас заблокирован, этот порт у нас заблокирован, этот порт у нас заблокирован. Ну или как-то по-другому, что-то где-то заблокирует. И получается, что вот этот вот свеч, он, соответственно, находится в каком-то вилане ближе к всем свечам,

потому что он, например, root, буква R. А вот этот свитч у нас запасной рут, и трафик до него будет проходить по трассе через рута. Вот у нас поток трафика будет идти вот по такой трассе. В такой ситуации получается, что нет смысла включать фарвардинг и на одном свитче, и на другом, если все равно трафик до другого свитча пойдет через первый. Ну то есть все равно, в какую сторону выплевывать трафик на первом свитче. Лучше сразу же тогда отправить его в сеть назначения. И поэтому, если у вас используется такой дизайн, то вам имеет смысл использовать только HSRP. Но вот если вы используете LoopFree дизайн, то есть дизайн, в котором у вас... Сейчас попробую нарисовать. Дизайн, в котором у вас есть не треугольники, а вот так. У меня опять какая-то беда с мышкой. Так.

Вот такие вот сети у вас. И, соответственно, линк между двумя дистрибьюшн-свитчами, он уже L3. Вот. В этом смысле у вас GLBP будет полезен, потому что оба свитча одинаково равноударены от каждого узла, никто нигде не заблокирован, и, как следствие, оба свитча могут выполнять свою работу. Поэтому, если у вас есть дизайн с LoopFreeAccess, тогда вы можете использовать GLBP. Если у вас дизайн сети с Looped L2, то, соответственно, он вам там не нужен. Вторая проблема. Как правило, дистрибьюшн-свитчи выполняет маршрутизацию. Если говорить про свитчи, которые могут запускать GLBP, то это только 45-й и, соответственно, 65-й свитчи, ну или более новые модели 49-й и 68-й линейки. Вы не встретите GLBP на более младших свитчах. GLBP можно запускать на роутерах, но, опять же, в классическом сценарии сети предприятия роутеры на палке — это как-то вот прям совсем нехорошо.

А догонять трафик, например, до классического роутерного блока, который на Distribution Edge, а не на Distribution, а Enterprise Edge. То есть у нас, помните, да, там есть блок с Distribution, есть блок с Core, и где-то отдельно стоят серваки, которые смотрят во внешний мир со всякими ванами и прочими. Вот. Но догонять трафик до туда в виде отдельных виланов — это как-то совсем плохая идея. Поэтому в реальности GLBP в сети предприятия вы не встретите. Именно потому, что, во-первых, для него требуется очень специфический дизайн, а, во-вторых, даже если вы будете его использовать в сети со специфическим дизайном, вам придется использовать прям реально очень дорогие свитчи. А в предприятии, ну, такие дорогие свитчи обычно не очень любят. То есть бывают, конечно, компании, которые, ну, прям денег совсем не считают, но все-таки это скорее редкость. Плюс к тому, вся идея GLBP заключается в том, что вы деньги заплатили за два свитча и работают по факту тоже два. Сама вот эта вот идея красивая, но по факту вы не хотите держать стопроцентную нагрузку на каждом свитче.

Вы хотите, чтобы в случае отказа одного свитча у вас трафик шел через второй, и это не вызывало проблем в сети. Потому что бывают регламентные работы, бывают какие-то отказы, бывает оборудование дохнет. Поэтому если случается какая-то проблема в сети, например, отказывает один из дистрибьюшн свитчей или один из корс свитчей, вы не хотите, чтобы у вас сетка ложилась. Не просто сетка ложилась, а не хотите, чтобы у вас сервисы деградировали. Поэтому вы штатно закладываетесь под то, что у вас работает только один свитч. Вы не закладываетесь под то, что вы заплатили деньги за два свитча и хотите, чтобы оба свитча работали в 100% нагрузке. Потому что иначе, когда один из свитчей сдохнет, оставшийся получит 200% нагрузку, и он будет дропать трафик. У вас будет деградация сервисов. Поэтому вы рассчитываете сеть, исходя из схемы резервирования, в нашем случае N плюс 1. А это N плюс 1, это то же самое, что N плюс 1. Вы говорите, у нас может сдохнуть половина сети, и она останется рабочей. Из двух дистрибьюшн свитчей у нас один может отвалиться, и один продолжит работать без каких-либо проблем.

И поэтому нет смысла говорить, что вот мы деньги заплатили за два свитча, давайте размажем трафик по обоим. Даже один свитч может вытянуть весь трафик. Вот. Все вот эти вот проблемы приводят к тому, что GLBP по факту в сети предприятия не используется. А как следствие, он не используется вообще нигде. Количество развертываний GLBP экстремально маленькое. Проблема у него в том, что если мы говорим про свитчи, то, соответственно, его негде использовать. Если мы говорим про все эти предприятия, его негде использовать. Если мы говорим про провайдеров, там его еще негде использовать больше. Потому что провайдеры в принципе готовы заплатить деньги за то, чтобы там два роутера поставить. Оба они фарвардят трафик, вот, и как бы нагрузка 100% на каждом из них, ну, или там 90%. В случае одного отказа, ну, провайдер просто пожмет плечами и скажет, ну, извините, ну, вот да, да, у нас авария в сети, да, немножко деградация есть, ну, что же делать. Вы денег мало платите, потому что. Вот, ну, провайдеры могли бы его использовать, если бы не политика ЦИСКИ, что он поддерживается только на жирных железках.

Вот, опять же, да, 6-тонники, 4-тонники, все вот это вот, это довольно дорого. Поэтому провайдеры уходят в сторону более дешевого железа, и там GLBP просто тупо нету. Так, да, сценарий, где GLBP вы можете встретить, это GLBP на роутерах, то есть роутеры-роутеры, которые не свечи, которые в душе роутеры тоже мультилейер свеча, а именно вот полноценные железки, 39-е там всякие вот эти вот свечи, там можно встретить GLBP в чистом виде даже на младших лицензиях. Но в интерпрайзе экстремально редкая ситуация, что вы роутер на палке делаете, и два роутера на палке у вас фарварда трафик. Так, GLBP будет иметь по сути своей те же самые состояния, что и HSRP для AVG-шки. То есть в AVG-шке у нас есть состояние init на интерфейсе, когда у нас GLBP не понимает, что делать.

Так, здесь у меня кажется какая-то проблема, да. GLBP на интерфейсе не работоспособен, это disabled. GLBP ожидает определения виртуального апишника, это init, то есть здесь перепутаны местами два пункта. Listen, вы слушаете сообщения от текущего AVG и ждете, соответственно, возможности устроить выбор запасного. Speak то же самое, что и в HSRP, вы производите выбор запасного. Standby вы готовитесь захватить роль основного, и Active вы захватили роль основного. AVG-шка, когда захватывает власть, она распределяет роли AVF, роли фарвардеров. И у нас есть четыре роли фарвардеров, AVF1, AVF2, AVF3, AVF4. Гипотетически можно было бы наплодить их больше, но вот цисковская реализация позволяет сделать только четыре фарвардера. И каждый фарвардер может находиться в одном из четырех состояний. Disabled. Вы не знаете, какой MAC-адрес вам использовать.

То есть прям совсем не знаете, не знаете. Listen, вы ждете сообщений от основного роутера, от AVG-шки, который расскажет вам, что вы можете использовать роль фарвардера. И Active, значит, вы получили роль фарвардера, вы можете фарвардить трафик. То есть здесь, по сути, три состояния против пяти работоспособных состояний у роли AVG. Если у вас есть несколько фарвардеров, то они между собой могут балансировать трафик. Точнее, не они могут балансировать, а AVG может между ними балансировать трафик. Команда, которую мы должны будем ввести, должна будет работать фактически только на AVG-шки. Но, учитывая, что AVG-шка может быть кто угодно, то, соответственно, да. Вводить ее придется везде. Команда будет иметь вид GLBP, дальше номер группы, единичка, load balancing. И здесь мы можем выбрать один из трех вариантов. Раньше было, на самом деле, четыре. Первый вариант — это тот, который используется по умолчанию, round robin.

В новых EOS он именно так и работает. Мы говорим, к нам приходит первый клиент, мы выдаем один MAC-адрес, один фарвардер, MAC-адрес фарвардера. Приходит другой клиент, мы выдаем второго. Приходит третий клиент, мы выдаем третий. Приходит четвертый, мы выдаем четвертый. Приходит пятый, мы выдаем первый и так далее. То есть мы каруселькой раздаем MAC-е по порядку. Первый, второй, третий, четвертый. Первый, второй, третий, четвертый. Проблемы здесь особенной не будет. То есть у нас получится, что каждый клиент примерно получит одинаковое количество MAC-ов. Но иногда нам это нежелательно. Например, потому что у нас есть один роутер очень мощный, а второй роутер, который сидит на подхвате, и он типа слабенький такой, типа резервный. И мы хотим, чтобы они оба одновременно работали, но мощный роутер в основном фарвардил трафик, а маленький в резерве по чуть-чуть только обслуживал по мере возможности. Сценарий очень маловероятный, потому что, опять же, в сети предприятия, как вы понимаете, это ошибка дизайна, что у вас есть один роутер, который работает всегда, а другой роутер, который работает на подхвате, и вы хотите, чтобы они оба работали одновременно, и что если большой сдохнет, маленький останется каким-то живым и рабочим.

Я видел такой дизайн, на самом деле. Я до сих пор считаю, что это была ошибка. И там стояла одна большая, очень жирная циска, и рядом с ней стоял, ну, правда, микротик. Вот там у клиента как раз была идея, что жирная циска в случае смерти должна передать весь трафик маленькому-маленькому микротику. Он был 450-й, что ли, прям совсем крошка. Вот. И, ну, в общем, мы тогда клиента переубедили, но как бы на уровне дизайна, на уровне плана такой дизайн действительно был. Вот. Раундробин в большинстве ситуаций ведет себя хорошо, но если вы хотите, вы можете предположить, что у вас есть, ну, ладно, не микротик, на микротике GLBP не может быть, но, например, какая-нибудь 800-я циска, древняя, старенькая 800-я циска, и вы хотите, чтобы она тоже чуть-чуть разгружала трафик основного роутера. Вот в этом случае вы можете сказать, назначаем этим роутером разные веса и указываем вариант балансировки weighted. И тогда вы будете распространять MAC-адреса фарвардеров с AVG-шки.

Клиентам, когда клиенты приходят, они спрашивают по ARP, какой MAC-адрес использовать. Вы будете выдавать MAC-и, и будете выдавать MAC-и пропорционально весам. Например, если у вас веса соотносится как 2 к 1, на одном вес 200, на другом вес 100, то вы будете двум клиентам выдавать MAC-адрес первого фарвардера и одному клиенту выдавать второго, а потом снова двум первого, одному второго. Таким образом, вы получите распределение количества клиентов по роутерам примерно в пропорции веса. Это не означает, что по факту трафик будет идти пропорционально этому весу. Потому что может быть такое, что один клиент какой-то будет очень-очень жирный, который придет, один раз спросит, какой мне виртуальный MAC использовать. Ему выдадут MAC, допустим, фарвардера номер 2, и он начнет удалить гигабит. Никто от этого не застрахован. Но, по крайней мере, попытка это сделать вот такая вот есть, что вы исходите из того, что клиенты у вас все примерно одинаковые, что они все примерно по чуть-чуть потребляют ресурсов, и что под каждого пользователя мы выдадим чуть-чуть.

И в итоге у нас получается, что если мы распределяем запросы клиентов, точнее ответы на запросы клиентов пропорциональными весам, то и трафик на этих фарвардерах будет тоже пропорциональных весам распределяться. Проблема возникает и с этим режимом. Иногда следующее. Может быть такое, что у вас один клиент пришел, спросил, какой MAC-адрес мне использовать. Ему AVG вернула какой-то MAC. Он им попользовался, у него кэш протух, и он снова приходит на роутер, AVG, и снова спрашивает, какой MAC-адрес мне использовать. И, соответственно, AVG, что в режиме Round Robin, что в режиме Waited, не следит за тем, выдавала ли она конкретный MAC-адрес конкретному клиенту ранее. Может быть такое, что сейчас клиент пришел, попросил MAC-адрес, ему дали MAC-адрес первого фарвардера. Через пять минут тот же самый клиент пришел, попросил MAC-адрес, ему дали MAC-адрес второго фарвардера.

У некоторых клиентов это может вызывать проблемы. То есть они хотят, чтобы трафик всегда направлялся на один и тот же MAC. Если у вас в сети такая ситуация есть, вы можете использовать режим, который называется HostDependent. И, соответственно, этот режим будет считать хэш от MAC-адреса клиента. И в зависимости от этого хэша будет назначать фарвардер. То есть не в зависимости от веса, не в зависимости от того, какой мы предыдущий MAC выдали, а в зависимости от того, какой MAC пришел. Мы будем выдавать фарвардер каждому конкретному клиенту. Условно говоря, если у вас два фарвардера, и один из них первый, другой второй, вы можете получить MAC-клиента, который пришел к вам с вопросом, какой MAC мне использовать. Вы берете MAC-клиент и смотрите, он четный или нечетный. Если четный, вы даете первый фарвардер, если нечетный, вы даете второй фарвардер. То есть вот на основании такого механизма вы сделаете так, что всегда, когда приходит клиент, один и тот же, у него всегда MAC-адрес будет либо только четный, либо только нечетный, потому что он один и тот же.

И он всегда будет получать MAC одного и того же фарвардера. При этом, даже если вдруг переедет роль фарвардера на какой-то другой роутер, ну ничего страшного, клиент свою эту самую задачу сохранит. Но единственное, что если у нас роль гейтвея переедет, роль активного гейтвея, диспетчера, не факт, что другой диспетчер будет раздавать фарвардеров также. То есть может быть у него будет, соответственно, уже какой-то механизм другой. Ну и наконец, еще одна проблема будет, что может быть так, что у нас появится новый фарвардер. Было у нас два фарвардера, а потом пришел третий. Ну в этом случае, опять же, все поедет, что если у нас раньше выдавались два MAC-а, то сейчас надо выдавать три MAC-а. И да, механизм хеширования там будет испорчен. Ну не бывает 100% надежности в любой системе. К сожалению, да. И еще один режим был в старых EOS-ах. На экзамене его не будет, но вы можете встретить его в книгах.

Вы можете указать GLBP load balancing none. И в этом случае GLBP будет себя вести аналогично с HSRP. Он выдаст одну роль фарвардера себе самому. И в этом случае, да, AVG-шка будет фарвардить весь трафик. И фактически, да, у вас GLBP превратится в HSRP. На новых EOS-ах этой штуки нету. То есть вот как раз на скриншоте, да, GLBP 1 load balancing вопросик показан. Там вы просто такое ввести даже не можете. Но на старых EOS-ах можно будет встретить. Так же, как и в случае с HSRP, у GLBP та же самая проблема фундаментальная есть, что отслеживание интерфейсов, соответственно, нужно будет производить в нем для того, чтобы определять отсутствие доступа ко внешнему миру. У GLBP, в отличие от HSRP, нужно будет не просто сказать, я больше не хочу фарвардить трафик,

пусть кто-нибудь другой это делает. В GLBP можно так сделать. Но в GLBP есть несколько фарвардеров, и каждый роутер может фарвардить трафик. Причем теоретически, гипотетически, мы можем даже сказать, сколько именно этого трафика будет фарвардиться каждым конкретным роутером. Поэтому помимо того, что каждый фарвардер может сказать, я больше не хочу фарвардить трафик, пусть кто-то другой за меня его фарвардит, вы можете также понизить себе вес. И тем самым, если вдруг никто не хочет забирать у вас роль фарвардера, но вы в принципе еще можете фарвардить трафик, просто меньше, можно будет сделать так, что у вас был, например, вес 100, и вы фарвардили половину всего трафика, а сейчас вы назначили себе вес 50, и вы начинаете фарвардить только треть трафика, а другой роутер с весом 100 фарвардит, соответственно, все остальное. Вот можно так будет сделать. Для того, чтобы это сделать, нам нужно будет играть весом.

И этим весом мы будем играть так же, как мы играли приоритетом в HSRP. Создаем объект отслеживания, указываем, насколько мы хотим просесть относительно стандартного веса. Вес нужно будет назначить командой weighting на интерфейсе, glbp1, weighting100. и когда вы настраиваете веса, вы можете сказать, начиная с какого уровня вы отдаете роль фарвардера целиком. То есть, если вы хотите, вы можете сказать, у нас есть несколько объектов трекинга. Один объект трекинга, например, смотрит на то, можем ли мы обрабатывать трафик на одном интерфейсе. Другой объект трекинга смотрит на то, что мы можем обрабатывать трафик на другом интерфейсе. интерфейсе. Если у вас упал только один интерфейс, упал один объект отслеживания, то вы поседаете по весу, ну, например, на 50. Но если вы потеряли только один интерфейс, вы все еще можете фарвардить трафик.

А вот если у вас два интерфейса упало, вы телеком не хотите больше фарвардить трафик никак. По умолчанию все верхние и нижние границы будут, соответственно, совпадать с нулем. То есть, если у вас остался хотя бы какой-то вес, вы трафик фарвардите. Но вы можете сказать, что если у вас вес упал, например, ниже, к примеру, 30 или, к примеру, 70, то вы, соответственно, роль фарвардера отдаете. Кроме того, вы можете указать верхнюю границу. Когда вес уже упал ниже нижней границы, он начинает потихоньку, возможно, восстанавливаться. Если у вас много объектов отслеживания, он может восстановиться чуть-чуть. Не до конца, а чуть-чуть. И, соответственно, вы можете сказать, что если у нас случилась такая беда, что мы отдали роль фарвардера кому-то еще, мы сразу ее не забираем, если у нас приоритет чуть-чуть поднялся. То есть, может быть такое, что у нас там флаппинг какой-то происходит. Интерфейс то поднимется, то опустится. То поднимется, то опустится. Вот если у нас, допустим, нижняя граница настроена, к примеру, на 25, и мы просели по приоритету до 20,

а потом у нас приоритет стал 30, а потом снова 20, а потом снова 30, то мы не хотим то забирать роль АВФ, то опять ее отдавать. Мы скажем, что пусть у нас приоритет, не приоритет, вес поднимется хотя бы там до 50, до 40, до чего-то большего, чем у нас есть. В некоторых ситуациях это помогает избавиться от такого вот флаппинга. И, соответственно, если вы это настраиваете, то вы указываете вейтинг, дальше указываете дефолтный вес, стартовый, от которого дальше начинается пляска, он может только проседать, соответственно. И вы указываете две границы, lower и upper. Lower — это ниже, который мы отдаем роль фарвардера, upper — это, начиная с которой, мы забираем роль фарвардера, если вдруг у нас будет такая необходимость. Вот. Трекинги создаются точно так же. То есть точно так же мы указываем вейтинг track 100, стартовый, декремент, соответственно, указываем декремент 50.

Track 100 — это номер объекта, естественно. Так. GLBP будет использовать под капотом HSRP второй версии, как уже говорилось. У него будет относительно GLBP второй версии еще другой порт. Порты запоминать не обязательно. IP-шники обязательно. 224.0.0.102. Надо будет знать, как у чинаж. А вот UDP-шные вот эти вот порты, 19.85, 20.29, 32.22 — это запоминать не обязательно. У GLBP есть, соответственно, свой собственный формат, который Cisco не раскрывает. Но в Airshark, например, GLBP-шные сообщения читать умеет, хотя и не всегда он их читает как бы правильно. Поэтому в некоторых случаях мы видим, что некоторые поля расшифровываются с вопросиками. Например, первое поле имеет название version и дальше вопросик. Это связано именно с тем, что нигде никогда Cisco формат этих сообщений не публиковала.

Да, реверс инженерия нас спасет, но тем не менее, да. Мы предполагаем, что это, скорее всего, поле версии. Вот. И в каждом сообщении, которое отсылается в GLBP, а все роутеры отсылают сообщения, не только активный и запасной, а вообще все и всегда, соответственно, у нас показываются, кто мы и что мы делаем. Есть TLV-шка, которая называется Hello. Hello-TLV-шки отсылаются именно ролью AVG. То есть, если мы сами себе поняли, что мы должны быть диспетчером, то мы говорим, мы диспетчер. Если мы будем фарвардером, то мы посылаем сообщение, что мы не против стать фарвардером. Будет сообщение request и будет сообщение response. то есть AVG-шка, когда говорит, да, я не против, чтобы ты стал диспетчером, вот она говорит, я буду сообщать, кто будет диспетчером. Дальше. Будет указываться виртуальный MAC.

Соответственно, виртуальный MAC 00.07.B4. И дальше номер группы. Соответственно, номер группы вот такой вот. Начинается на 0 всегда. И последний байт – это номер фарварда. Я вам уже показывал. Вот. Так же, как и в случае с HSRP, сообщение, которое отправляются, будет отправляться держателями виртуального MAC. AVF – это держатель виртуального MAC, поэтому AVF-ки отсылают свои сообщения из-под этих самых виртуальных MAC. И они идут на мультикастовый IPшник. IPV4. 0.1.0.0.5… 224.0.0.102. Это 0.1.0.0.5e. 0.0.0.0.066. 66 – это 16-ричное, соответственно, 102 – десятичное. Вот. В общем-то, здесь, наверное, все, что хотелось рассказать.

Все рассказал. Google показывается у нас… Да, показывается, что все роутеры, которые имеют какую-то роль, они все отправляют свои сообщения. Дальше. В GLBP у нас таймеры те же самые, что и в HSRP первой версии. Вы можете указать таймеры 3 на 10 дефолтные, либо вы можете переопределить таймеры, сказав команду GLBP, timers, чего-то там. Обычно это настраивается на группе, но в нашем случае GLBP 1, timers 1.3. Как в HSRP второй версии, вы можете назначить субсекундные таймеры, тогда вместо просто циферок вы должны будете написать слово msec. Ну, та же самая история, что и в HSRP второй версии. То есть GLBP 1, timers, msec, чего-то, msec, чего-то. Таймеры меньше, чем 15.50.

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

допустим, той же самой таблице маршрутизации полностью наполнится перед тем, как фарвардить трафик. И вы указываете это командой preempt delay. Вот. Вы указываете там минимальные задержки и там 10 секунд. Так же, как и HSRP, GLBP, учитывая, что это на самом деле развитие HSRP второй версии, поддерживает защиту сообщений с помощью пароля. Можно будет указывать, что вы защищаете пакеты просто паролем. Здесь, опять же, кейстринг, а не кейстринг, должно быть. Так, что-то у меня... Желтая указка не видна совсем, кейстринг. Вот. Ну, смысл, да, тот же самый, что вы вкладываете в каждое сообщение хэш от содержимого пакета и текстового ключа. Команда будет GLBP authentication, и дальше вы указываете md5-кейстринг. Либо, если вы хотите, вы можете использовать ключевые цепочки.

Соответственно, создаете ключевую цепочку и указываете GLBP authentication, md5, но не кейстринг, а кейчейн. И указываете название ключевой цепочки. Эта штука позволит вам при настроенных минимальных таймерах произвести схему... смену ключа с минимальными последствиями для вашей сети. То есть, вы, опять же, можете сказать, что вы отправляете сообщение только с одним ключом, а принимаете с разными ключами одновременно. Вот. В HSRP ключевые комплекты использовать нельзя, а в GLBP можно, поскольку там немножко другой формат. Там у нас можно будет использовать номера ключей. Итак, у нас есть наши роутеры. На этих роутерах сейчас нету никаких IP-адресов. А нам они понадобятся для того, чтобы поучаствовать в работе сети. Ну, соответственно, я предлагаю сделать следующую вещь. У нас есть наши свитчи, у нас есть наши роутеры, и свитчи связаны между собой

в сеть типа «Звезда». Я предлагаю сделать так, чтобы наш роутер выполнял роль клиента. То есть это, хотя и роутер, но просто же машинка, на которой мы можем повесить IP-шник, сказать, вот мы в качестве шлюза в внешний мир используем определенный узел. Вот мы сделаем так, чтобы у нас на всех наших свитчах передавался трафик определенных виланов, чтобы у нас все наши роутеры использовали доступ ко внешнему миру через виртуальный IP-шник, который будет разделяться между всеми нашими свитчами, а свитчи будут, в свою очередь, смотреть на центральный свитч, на котором будет некий секретный IP-адрес. Давайте сделаем следующую вещь. Создадим на всех наших свитчах два вилана. Ну, у нас уже есть первый вилан, давайте сделаем еще один вилан номер 100. Соответственно, я сейчас его сделаю на центральном свитче. Сначала давайте вилан 100

exit. Вы тоже у себя, пожалуйста, на ваших свитчах сделайте сотый вилан. И, помимо того, что у нас будет сотый вилан, надо будет на свитче поднять транк до центрального свитча. Интерфейс Ethernet 1. Switchport Trunk encapsulation .1Q switchport 0.1Q тоже у тебя это делаете. То есть, интерфейс Ethernet 0.1 на нашем свитче смотрят в сторону центрального свитча. Там у нас будут бегать и сотый вилан, и первый вилан, который всегда в базе есть, и ничего для него делать не нужно. Помимо того, что мы сделали сотый вилан, мы сейчас должны будем настроить два SVI, virtual switch, virtual interface. Один из них будет смотреть в первый вилан,

и, соответственно, это будет тот самый интерфейс, на котором мы будем смотреть, типа, на наших пользователей. И другой интерфейс у нас будет в сотый вилан смотреть, и это будет интерфейс, через который мы будем общаться с центральным свитчем. поэтому поднимаем интерфейс вилан 1. Интерфейс у нас поднимается в выключенном состоянии, его нужно включить no shutdown. Ждем, пока он включается, и вешаем на него IP-адрес. IP-адрес я предлагаю сделать 10.0.0. номер вашего комплекта, ну, то есть IP-адрес 10.0.0. 8.2 access в моем случае у меня 8-мый комплект 255, 255, 255, 0. У себя тоже, пожалуйста, вилан-первый включаете, вешается на него IP-шник 10.0.0 номер комплекта. Плюс к тому нужен будет интерфейс, который смотрит в сторону центрального свитча,

и то же самое делаем абсолютно аналогично, интерфейс вилан-100 no shutdown поднимается в выключенном состоянии, сейчас будет включаться, и на него вешаем ip-шник IP-адрес 10.0.100 номер вашего комплекта. Это будет интерфейс, которым мы смотрим на центральный свитч по IP. У нас получается 10.0.0 сетка смотрит на клиентов, 10.0.100 сетка смотрит на центральный свитч. На центральном свитче сейчас ответные действия предпринимаю. Enable, ConfT. Я нагло пользуюсь тем, что у нас работает протокол DTP, благодаря чему на центральном свитче транки все поднимаются автоматически. Do, show, interface, tranq. Вот я вижу, что поднялся интерфейс Ethernet-01, Ethernet-02, Ethernet-1.3. Все в автосогласовании находятся. На всех согласовался 802.1Q.

Поднимаю VLAN 100 и поднимаю интерфейс VLAN 100. No shutdown. IP-адрес 10.0.100.100. Сейчас у нас на всех свитчах должен работать IP-уровень. То есть мы должны со всех наших свитчей видеть IP-шник 10.0.100.100. Кроме того, мы на всех свитчах должны видеть друг друга. То есть наши IP-шники 10.0.0 чего-то там должны тоже пингаться. Давайте проверим, что это действительно так. Я попробую 10.0.0.1 попингать. А вы можете 10.0.0.8 попингать. 10.0.2 пингается. 10.0.0.3 пингается. 10.0.1 пингается. 10.0.1 пингается.

Таким образом у нас сейчас наш свитч выполняет роль маршрутизатора. По большому счету это не совсем типичная роль для него. То есть если бы мы делали это на совсем какой-то маленькой железке, мы должны были бы сказать, что типа IP-раутинг. Здесь это просто команда по умолчанию есть. Но вообще по-хорошему, конечно, ее надо было ввести. И получается, да, что если у нас сейчас будет роутер пытаться достучаться до IP-шника 10.0.100.100, то нужно будет, чтобы этот роутер... чтобы этот роутер мог принимать пакеты от центрального свитча. Центральный свитч мог принимать пакеты от роутера. Давайте делать настройку на роутере. То есть мы настроили наши свитчи, подняли на них IP-шники, подняли транки, подняли VLAN. Ну, в общем, это дело уровня ICND2. На роутере подготовительные действия тоже делаем. enable.

...энтрофейс Ethernet 0.0. No shutdown. IP-адрес 10.0.0.0. Давайте 100 плюс номер комплекта. 255.255.255. Вот сейчас гипотетически наши роутеры должны иметь возможность пингать друг друга. То есть у нас есть IP-шники 10.0.0. Номер комплекта. 10.0.0.100 плюс номер комплекта. 10.0.0.8. Это IP-шник моего свитча. Он должен пингаться. И плюс 10.0.0.2. IP-шник свитча второго комплекта должен пингаться. 10.0.0.102. IP-шник роутера второго комплекта пока еще не пингается. Так, ну, может быть, 103 комплект готов. 103 пингается.

Но сейчас не будет пингаться. 10.0.100.100. Он не будет пингаться, потому что этот IP-адрес отсутствует в таблице маршрутизации. Для того, чтобы этот IP-шник у нас пингался, нам нужно настроить маршруты. И маршрут, если мы будем настраивать, то мы должны будем настраивать на какой-то адрес. И мы хотим сейчас, чтобы у нас вот этот вот адрес не зависел от конкретного роутера. И мы говорим, давайте настроим все наши роутеры на то, чтобы они работали в группе. И группа у нас была бы такая, которая бы объединяла в себе несколько роутеров. Мы можем сделать вид, что наши все роутеры сидят в одном вилане. Они действительно сидят в одном вилане. И они разделяют друг с другом возможность стать центральным роутером за определенный вилан. Активным роутером за определенный вилан. И я предлагаю сделать соответственно IP-шник 10.0.0.100.

Это будет IP-шник, который будет нашими свечами разделяться. И они будут за этот IP-шник драться. 10.0.0.100 это... Или у нас уже есть такой IP-шник? Нет? У нас нет такого IP-шника. На центральном свече 10.0.100. Просто на наших свечах 10.0.0. Да, у нас на свечах все правильно. Короче говоря, мы сейчас сделаем так, чтобы наши свечи на интерфейсе вилана первого, интерфейс вилан 1, имели бы виртуальный IP-шник с некоторой вероятностью. Они бы подрались. Кроме того, что там есть IP-шник 10.0.0.8. На этом интерфейсе будет еще с некоторой вероятностью IP-шник 10.0.0.100. Соответственно, указываем стендбай. Дальше указываем номер группы. Давайте используем группы 1 в соответствии с номером вилана. И указываем IP-10.0.0.100.

Сейчас у нас пройдут перевыборы. Соответственно, первые 10 секунд роутер, ну, свитч, да, свитч сидит, ничего не делает. Он слушает пакеты. Он находится в стадии listen. Потом он переходит в стадию speak и начинает устраивать перевыбор. Рассказывает про то, какой он будет замечательный. Наконец, он переходит в стадию stand-by. Говорит, я тут самый красивый запасной среди всех. И, наконец, переходит в стадию active, когда он говорит, я среди всех роутеров единственный, кто готов стать основным. Основного нету. Соответственно, роль захватывается. При этом, по-хорошему, надо еще рядышком прописать приемтинг, чтобы если вдруг мы будем проседать по приоритету, чтобы, точнее, не мы будем проседать, а чтобы, если кто-то другой, кто был бы активным роутером, проседал бы по приоритету, чтобы мы могли у него эту роль забрать. Stand-by-preempt указывает на то, как вы будете себя вести, если вы запасной, а текущий основной хуже, чем вы. У него приоритет строго меньше, чем у вас. Поэтому указываем stand-by 1-preempt.

Вы у себя тоже аналогичные вещи делаете. Абсолютно такой же IP-шник, абсолютно такой же настройку приемтика, приемтинга. Вот. И, соответственно, сейчас мы должны будем настроить на вот этот вот виртуальный IP-шник наши роутеры, чтобы они отправляли пакеты во все остальные сети через этот виртуальный адрес 10.0.0.100. Идем на наш роутер и прописываем. IP-роутер 10.0.0.100. Гипотетически мы сейчас должны бурно радоваться. Мы должны радоваться тому, что у нас есть вот этот вот виртуальный IP-шник 10.0.0.100. Я предполагаю, что он сейчас даже должен пингаться и что активный роутер должен фарвардить трафик во все остальные сети. Как у нас это будет происходить? Show IP-роутер.

Вот он, дефолт. Он есть. Соответственно, он добавился. Можем проверить, что этот IP-шник пингается. Ping 10.0.0.100. Он действительно пингается. Можем show IP-ARP посмотреть. Вот он есть. Вот наш MAC-адрес 0.0.0.0.0.7. 0.7.AC. И дальше номер группы 0.1. То есть все хорошо, все честно. Можем даже посмотреть, за каким портом на нашем свече этот MAC-адрес. Но этот MAC-адрес, понятно, на самом свече будет. Вы у себя на ваших свечах можете выполнить команду show MAC-адрес. Вот. И здесь вот 0.0.0.0.0.0.0.0.0.0.0.7. А.C. 0.1. Показано, за каким портом он будет сидеть. Ну, понятно, что у вас он будет смотреть в сторону транка Ethernet-0.1. На центральном свече он смотрит на Ethernet-1.3.

В сторону самого активного роутера. Ну, то есть вот так вот можно отследить, кто из вас активный. Плюс к тому на свече в нашем случае можно будет посмотреть show stand-by. Вот. Показывается, что я активный роутер. Показывается, что у нас есть приемтинг. Что у нас таймеры вот такие вот. Показывается, кто запасной. Опять же, запасной среди всех остальных выбрался. У нас запасных кандидатов был 10.002 и 10.003. У нас приоритеты у всех одинаковые. Поэтому при выборах запасного роутера 10.003 победил. 10.002 сидит в состоянии listen и ждет, чтобы запасной роутер перестал присылать hello-пакеты. Вот. Ну и если сейчас гипотетически мы с роутера попытаемся попингать центральный API-шник. Так. Так. Не 0.001.00, а 10.001.00. У нас должно быть все хорошо, правильно?

Должно же быть хорошо. Ну, должно же, да? Должно же, правда? Но нет. Проблема будет очевиднейшая связана с тем, что у нас нету обратного маршрута. До центрального свеча, до 10.001.00. То пакеты наши доходят. Они не доходят обратно. Вот если вы сейчас попытаетесь попингать, соответственно, этот IP-шник, эти пакеты дойдут до 8-го свеча, до активного роутера. Но дальше он попытается их отправить в сторону самого центрального свеча. И здесь мы увидим дебаг IP ICMP. Это приходит из-под адреса, которого нет в таблице маршрутизации. Show IP. Это вот промахнулся. Вот. В таблице маршрутизации есть 10.0.100 чего-то. И у нас задача есть еще вернуть обратный трафик. То есть сейчас дебаг IP ICMP включен. Если я буду пингать, я увижу эти пакеты.

Я сказал, я увижу эти пакеты. Так, интересно, а почему я не вижу эти пакеты? Ну-ка, может быть, вот так. Никогда так не делайте. Так, я что-то не понимаю. А, во-во-во, да. Проблема была в цехе. Короче, этот цех глючный. Цех на наших эмуляторах. Никогда не выключаете их на продакшн-железках. Но вот на наших эмуляторах, да, выключение цеха помогло. Мы видим сообщение, которое приходит от узла 10.0.0.103. То есть это третий роутер. И мы видим, что мы не знаем, как до них добраться.

То есть на центральном свече нет возможности отправить пакет до 10.0.0.3. Соответственно, так, нам нужно прописать каким-то образом маршрут. И прописывать маршрут, сразу возникает задача, куда прописывать маршрут. Возможны варианты. Либо вы можете сказать, а давайте мы, например, сообразим какой-нибудь протокол маршрутизации дистанц-векторный. И будем в качестве NextHop отдавать виртуальный IPшник, который мы, опять же, тоже виртуально соберем на вышестоящих интерфейсах в сторону внешнего мира. Но в реальности у нас, скорее всего, в такой ситуации будет просто на каждом свече, дистрибьюшном свече, L3-линк до всего остального мира. У нас будет там какой-нибудь USPF работать. Так, давайте я выключу это. Вот. И, соответственно, на этом USPF у нас будет просто приходить маршрут от каждого конкретного дистрибьюшн свеча до всей остальной топологии в сети,

что сетка, в которой сидят пользователи, у нас доступна через два роутера. Давайте мы тоже это сделаем. Мы сейчас поднимем USPF. Конфт. Роутер USPF 1. Network 10.0.0.0. 0.255.255.255. Area 0. Самый простой USPF. Так. Да. На свече тоже поднимаем USPF. Роутер USPF 1. Network. Я сейчас лентяю. Никогда так не делайте, но... 10.0.0.0. 0.255. أي 2.55. Area 0. Мы поднимаем USPF. На наших свечах у нас происходит дружба в сотом vlaner с центральным роутером. И дальше мы с этим будем сейчас как-то жить. И теперь, после того, как соседские отношения установились, центральный роутер, в нашем случае центральный свитч, знает про внутреннюю сетку.

То есть к нему от нескольких соседей приходит указание, где можно достать внутреннюю сетку. И, соответственно, там мы сейчас увидим show ip route. Вот внутренняя сетка у нас доступна, ну, как минимум через 10.0.100.8. То есть не всегда у нас по OSPF эта сетка будет приходить на активный роутер. То есть может быть такое, что у нас будет работать equal cost multipath, и трафик возвратный будет приходить не на тот же роутер, который будет активным. Может быть такое, что трафик туда будет ходить через активный роутер, а трафик обратно будет возвращаться через какой-то другой. Это вполне такое может быть. Так, а я вот не пойму, сейчас у нас 10.0.102, 10.0.108. Как минимум я вижу двух соседей, но почему-то OSPF... Да, OSPF не хочет балансировать трафик. У нас по идее должна быть балансировка. Так, ну-ка, show ip OSPF neighbors.

У нас есть 10.0.108 BDR и 10.0.102 DR other. Show ip OSPF... Не нравится мне что-то ваш вождь. Давайте попробуем CERV включить. Conf T... IP CERV... Посмотрим, чему это приведет. Да не, он все равно только один маршрут показывает. Show ip OSPF... Не, собака страшная. Пробуем, что у нас получилось. Может сейчас балансировка будет. Вот, сейчас есть балансировка. То есть здесь второй комплект почему-то не присылает сетку 0.10.0.0.0.

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

и тогда роутер перестанет быть активным. Но в OSPF он все равно будет анонсировать эту сетку. Связано это с тем, что исторически, когда-то давным-давно, когда у нас был Ethernet, если у нас отваливался интерфейс во внешний мир, то он отваливался прям совсем целиком. И все остальные узлы, которые находились в этом же линке, они либо, соответственно, либо они тоже не могли работать, если у нас разваливался прям линк, либо у вас просто отваливался именно ваш доступ к общей среде, если отваливался просто именно, например, ваш интерфейс. Был коаксиальный провод, там, условно говоря, либо провод порвался пополам, и тогда все не могут работать в коаксиальном проводе, либо у вас, соответственно, просто отвалился один узел, и тогда этот узел понимает, что он не может работать, а все остальные работать могут. Но у вас не могла сеть развалиться на две части, каждый из которых автономна. Сегодня в Ethernet такое произойти может. Если у нас есть два свеча, которые друг к другу соединены, может между ними линк разорваться, у вас на каждом свече останутся живые пользователи.

Исторически этого не предполагалось. Поэтому, когда все это дело закладывалось, предполагалось, что у вас роутер анонсирует ту сетку, которая у него есть. Если у него есть сетка 10.0.0, там, допустим, 0, то, значит, она у него есть вся. Конкретно в нашем случае такой образцово-показательный пример хренового дизайна, потому что сеть как бы не дизайнилась изначально под то, во что она в итоге превратилась, и, соответственно, у нас есть большой Вилан, который растянут на несколько виртуальных коммутаторов. И вот этот вот виртуальный широковещательный домен, он потому и виртуальный, что он виртуализируется. И может такое случиться, что у нас линк между двумя коммутаторами, которые составляют физически этот домен, развалится, и у нас получится, что он распадется на две автономные части, каждая из которых будет абсолютно нормально. У нас будет одна половинка сети 10.0.0.0 и вторая половинка 10.0.0.0. И каждый роутер, который будет анонсировать свой кусочек сети, он будет анонсировать всю сеть целиком.

Когда вы планируете вашу сеть, когда вы дизайните вашу сеть, дизайните линки между свечами, дизайните, соответственно, адресную структуру вашей сети, вы должны будете такие штуки отлавливать, вы должны будете убедиться, что никогда ваша сеть не должна разваливаться на несколько разных частей, причем каждая из которых остается работоспособной. Никогда не надо будет делать всякие нехорошие вещи, типа давайте мы свяжем два роутера с помощью Ethernet over IP. Любимая фича микротиководов. Протокол, который позволяет инкапсулировать в ГРЕ кадры Ethernet и таким образом сделать псевдопровод, который протягивается между городами, странами. Что здесь может пойти не так? Да все здесь может пойти не так. После того, как вы начнете включать маршрутизацию, чтобы сделать все правильно, внезапно выяснится, что у вас есть широковещательный домен, который протягивается между странами. Ethernet over IP link лег. Здравствуйте, вы анонсируете два куска вашей сети из двух разных мест. То есть в этом смысле Ethernet over IP настолько же плохая идея,

как и делать линк между двумя свечами и, соответственно, на этих двух свечах пытаться анонсировать одну и ту же сетку одновременно. Рано или поздно этот линк у вас сломается и, соответственно, вы начнете анонсировать сетку 10.0.0.0. Вот как мы сейчас это делаем. Но при этом, да, может случиться такое, что по факту, по факту связи между вот этим узлом и вот этим узлом не будет. И, соответственно, каждый из них будет анонсировать всю сетку целиком 10.0.0.0. И трафик до какого-то узла будет приходить, до, например, вот этого IP-шника, а он не будет знать, куда его девать, потому что он будет смотреть, что в его кусочке сети 10.0.0.0, в его осколке сети такого узла, в который направляется нужный пакет, не будет. Поэтому сейчас вот у нас есть проблема, связанная с бэт-дизайном, которую решить никак нельзя. Я вам ее показывал, что, соответственно, да, что трафик до вот этой сетки 10.0.0.0.0.0.0.0.0.0.0., будет приходить на оба узла одновременно. И мне будет зависимости от самого какого-то узла одновременно.

И совершенно не факт, что в случае какой-то аварии, когда у нас большая сетка 10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.,0.0.0.0.0.0.0.0.0.0 Кажется именно в нужном кусочке. Поэтому чем меньше ваши виланы будут, тем лучше. Чем меньше ваши виланы будут, тем меньше у них вероятность развалиться на несколько разных кусочков. Лучше всего делать вообще изолированные виланы, когда у вас все пользователи одного вилана сидят только на одном свече. Если вдруг этот свеч сломается, да, у нас, естественно, все пользователи потеряют доступ к сети. Но, соответственно, не может быть такого, что мы одну и ту же IP-сеть анонсируем из какого-то места, в котором по факту доступа к какому-то другой части этой сети уже не будет. То есть, чем меньше ваши виланы, тем лучше. Больше виланы – хуже. Строить сети с использованием изернет-овер чего-нибудь без острой необходимости – это совсем плохо.

Так, ну, в итоге у нас сейчас наши роутеры должны пингать центральный узел. Проверяем. Пинг 10.0.100.100. Пингается. Если у нас сейчас вдруг отвалится внутренний линк, например, на свече 0.8, у меня он активный за роль. Я сейчас возьму его и погашу. Shutdown. Соответственно, у вас сейчас должны через некоторое время ваши роутеры, ваши свечи, точнее, определить, что активный роутер за группой HSRP отвалился. Должны будут перестроить, кто обладатель виртуального IP-шника во внутренней сети, и трафик дальше во весь остальной мир будет направляться уже через него. Я, по идее, сейчас тоже на своем маленьком роутере должен это буду отследить.

Трафик сейчас уже не ходит через мой Switch 8. Он ходит через кого-то еще. Enable. Show IP. Почему комп тета? Show IP. Почему show IP? Не надо show IP. Show MAC address table. Вот. Теперь этот MAC смотрит в сторону третьего комплекта. В общем, опять же, неудивительно, потому что запасным роутером был роутер номер 3, и когда он, соответственно, увидел, что основной роутер сдох, он стал основным, а роутер второго комплекта захватил роль запасного. Если я сейчас включусь на восьмом роутере, я заберу себе роль запасного обратно, и после того, как я стану запасным, я определю, стоит ли мне захватывать роль основного или нет.

Кстати, я не буду захватывать роль основного, если я вдруг стану запасным. Несмотря на то, что у меня включен приемтинг, приемтинг перехватывает роль основного только тогда, когда приоритет строго больше. Вот. Вот. Мы с вами настроили базово HSRP. Теперь пришла пора немножко поиграться. Что еще мы можем сделать? Мы можем настроить наши роутеры на то, чтобы отслеживать события. И, соответственно, просидать порт по приоритету в случае необходимости это сделать. Давайте я на своем свече включу обратно. Я должен забрать интерфейс. Я сейчас должен забрать роль активного, не активного, а запасного роутера. Активным я не стану, а запасным стану. Вот. И после того, как сейчас я заведусь, я, соответственно, хочу сказать, я собираюсь вообще обслуживать трафик или не собираюсь.

Например, типичный сценарий. Мы хотим отслеживать состояние оплинка. То есть на оплинку у нас приходит какой-то маршрут, и вот мы хотим по этому маршруту работать. Мы можем отслеживать либо состояние прямо маршрута-маршрута, либо состояние интерфейса. Ну, вот простенький сценарий, когда мы указываем, что нас интересует просто состояние интерфейса. Давайте сделаем сейчас. А когда будем делать лабу на GLBP, сделаем уже то же самое, но с маршрутами. Указываем, что у нас на интерфейсе VLAN 1, который вовнутрь смотрит, мы отслеживаем состояние физического интерфейса. Я, честно говоря, не знаю, наши вот эти вот свечи будут ли поддерживать команду track-interface, поэтому давайте сделаем прямо вот по-честному, как это на самом деле в конфиге будет выглядеть. Но я просто сейчас для себя, сугубо для себя, попробую выполнить команду standby1ip...

...по-честному, как это на самом деле в том, что мы можем сделать, чтобы мы не можем сделать это. Track позволяет создать только трекинг объекта, но не трекинг интерфейса. Давайте сделаем объект отслеживания и привяжем его к нашему HSRP. Укажем, что объект отслеживания у нас будет иметь номер 1 потом, когда мы его создадим. И укажем, соответственно, декремент, что если у нас будет падать объект отслеживания 1, мы просядем по приоритету на, не знаю, на 50. И теперь создадим сам объект отслеживания. Track 1 interface. Track 1 interface. И, соответственно, укажем, какой интерфейс нас интересует. На нашем свече у нас есть интерфейс, который смотрит во внешний мир Ethernet 0.1.

Не интерфейс 0.1, а интерфейс VLAN 100. Вот если он гаснет, то, соответственно, выхода во внешний мир у нас нет. И мы указываем, на каком уровне мы отслеживаем состояние этого интерфейса. Можно указать, что нас интересует, чтобы был живой уровень IP. Ну, то есть, например, когда у нас есть хотя бы один живой IP-шник. Либо line protocol — это что интерфейс находится в API. Ну, давайте line protocol. Простенький вариант. Указываем, что у нас есть объект отслеживания номер 1, который отслеживает состояние интерфейса VLAN 100. Если он в API, то и tracking в API. Если интерфейс в дауне, то и tracking интерфейс тоже в дауне. Show standby. Можно brief. Покажет, что у нас есть HSRP-шная группа. Сидит на интерфейсе VLAN 1. Группа номер 1. Текущий приоритет 100. Приемтинг, соответственно, включен. По умолчанию он не включен, но мы его включили отдельно.

Текущее состояние меня в этой группе standby. Показывается, кто активный, кто standby. И показывается виртуальный IP-шник, который у нас известен. Если сейчас я выключу интерфейс VLAN 100, на VLAN 1 это вообще никак не скажется. Но приоритет у меня просядет, потому что я сказал, что в первом VLAN HCR-пишная группа проседает по приоритету, если падает интерфейс VLAN 100. Conf T. Интерфейс VLAN 100. Shutdown. Объект отслеживания сдох. Как следствие, да, у нас отваливается связь со внешним миром. И мы проседаем по приоритету. Мы указываем, что мы теперь больше не будем хорошим запасным роутером. Мы не будем хорошим активным роутером. Мы не будем хорошим запасным роутером. Мы отдаем приоритеты. Соответственно, отдаем право стать запасным роутером кому-нибудь еще. И, соответственно, сейчас Show Standby Brief покажет нам, что приоритет действительно просел.

Вот, полтинничек. Ну и текущая моя роль – это роль Listen. Текущий активный роутер третий. Текущий запасной роутер второй. Вот. Вы должны будете в реальной сети обязательно настраивать трекинг. То есть вы обязательно должны будете настроить трекинг для того, чтобы два роутера, которые находятся в одном в Вилане, они, соответственно, разделяли бы IP-шник внутри сети только если они оба имеют доступ во внешний мир. Если кто-то перестает иметь доступ во внешний мир, то, соответственно, он теряет право захватывать внутренний IP-шник в Вилане с пользователями. Ну и плюс к тому, вы должны будете на уровне самой сети сделать так, чтобы ваши оба роутера анонсировали только сетку, которой они действительно имеют доступ. Очень тяжело в сети задизайнить HSRP или VRRP, неважно что, таким образом, чтобы трафик не возвращался на неправильный роутер.

То есть если ваша сеть большая, плоская сетка, то HSRP, равно как VRRP, будет возвращать трафик куда попало. Вы не можете средствами самого HSRP сделать так, чтобы у вас трафик возвращался только на роутер, который будет активен. Можно будет это с помощью жутких костылей сделать, то есть это действительно жуткие костыли, но насколько это вообще будет разумно, я, честно говоря, не знаю. То есть HSRP, при том, что он кажется протокол клевый, прикольный, когда мы на ICND 2 про него рассказываем, мы говорим, это очень хороший механизм, с помощью которого можно защититься от отказа одного роутера. Сейчас вы работаете уже, соответственно, на профессиональном уровне, вот вы сталкиваетесь с проблемой. И проблема эта заключается в том, что если у нас есть два роутера, которые из коммутируемой сети переходят в маршрутизируемую, то там возникает вопрос, куда будет возвращаться трафик. Этот вопрос вообще не поднимается на ICND 2, но в реальности он, конечно же, всегда стоит. И да, возвращаться он будет куда попало.

Вот так. Это что касалось, соответственно, настроек HSRP первой версии. Если вы включаете HSRP второй версии, то на интерфейсе добавляется команда standby version 2. И, соответственно, мы говорили уже, что это плохая идея на живую менять номер версии. Особенно, если вы начинаете это делать на каком-то роутере, не выключив все остальные роутеры. То есть надо сначала выключить все остальные, ну или выключить соответствующие VLAN интерфейсы, или снять настройки HSRP с них, потом перевести HSRP на активном роутере в вторую версию, и потом уже запустить все остальное. Иначе вы получите конфликт IP-адресов. Если мы настраиваем GLBP, то настройки все те же самые будут, только слово standby меняется на GLBP. Сейчас у нас конфигурация нашего HSRP будет иметь следующий вид.

Show, run, interface, VLAN. То есть у нас есть указание, какой IP-шник мы используем, есть ли приемтинг, есть ли какие-то трекинги. То есть фактически это скрипты, которые указывают, что если то иначе. И мы можем указать также таймеры, мы можем указать также вот нотификацию. Ну все это, понятное дело, что вы должны будете сделать самостоятельно, чтобы команда у вас на кончиках пальцев отложились. Если мы работаем с GLBP, то команды будут те же самые, только приемтинг указывать не нужно, только вы можете назначить веса. Конфт. Давайте убираем HSRP. No standby 1. IP. А, пардон. Интерфейс, VLAN 1. No standby 1.

IP. 10, 0, 0, 8. А, 100. No standby 1. Preempt. No standby 1. Track. 1, decrement. 50. Я, соответственно, выключил конфигурацию HSRP с интерфейса VLAN 1. И я хочу включить GLBP. GLBP включается точно так же, как включался standby. То есть, GLBP. 1. IP. 10. 0. 0. 100. включаются. дальше выбирают точнее запасной перехватывает роль активного роутера он назначает фарвардеры и все

роутеры которые у нас есть топология в нашем случае три роутера они получат роль фарварда вот я сейчас стал за основным диспетчером по той же логике что вы часа пьесно с начала основным то есть учитывая что меня самый большой айпишника учитывая что приоритет у нас всех одинаковая да действительно я становлюсь активный активным диспетчером но фарвардеры получат каждый из нас роль шоу и lbp три фарвардера один из них это я сейчас проходят процедуру утверждения самих фарвардеров нам посчастливилось увидеть стоит ли сен то есть ситуация когда я как бы заявил что я уже готов стать фарвардером номер один но я еще не получил эту роль и соответственно шел джелл про всех трех можно в курсе за роль фарвардера 2 я сам себя назначил активным ok 3 фарвардер есть один из них активный на моем роутере 2 соответственно других это вот вы виртуальные маки у нас опять же хорошо

известный 0 0 0 7 b 4 дальше нолик хорошо известный дальше 0 0 1 номер группы 0 1 номер фарвардера ну 0 2 и 0 3 показывают какие маки у нас есть я так сильно подозреваю что вот этот вот маг 2 роутера это мак 8 роутера то есть моего это мак 3 роутера ну и после того как мы видим каждый из этих роутеров мы можем понять что у нас трафик по факту будут обслуживать все трое если у нас наш маленький роутер сейчас возьмет и покричит на всю сетку у кого из вас такое пишет скажите свой маг и r p p p а свом кэш арпа что так нельзя я же нигде не ошибся 10 0 0 100 10 0 0 100 и делаю шоу и пи рп шоу айпи рп 10 0 0 100 нету пинга 10 0 0 100

айпи рп вот мне а в гашка выдала какой-то мак адрес где 10 0 0 100 соответствует фарвардер номер один если сейчас я сброшу кэш арпа и снова запрошу запрошу запрошу в смысле type-ишник 10 0 0 100 зарезал ведь в мак адрес а соответственно мне выдадут уже другой фарвардер вот 10 0 100 далее фарвардер 2 таким образом получается что а в гашка каруселькой раздает маки своих трех фарвардеров сейчас я запросил первый форм дали 1 фарвардер через немножко попросил дали 2 фарвардер через немножко запрошу дадут следующий третий фарвардер вы тоже можете позапрашивать соответственно резолвинг а и пишника виртуального роутера в мак и каждый раз а в гашка

будет выдавать разные мак адреса за счет этого как раз получается балансировка если у нас будут разные клиенты ходить на разные фарвардеры то получится да деньги заплатили за три роутера по факту работают все три роутера так это вот что касалось раздача слонов по поводу веса мы можем сказать что у нас разные роутеры имеют разные веса можем сказать что у нас разный дефолтный вес и этот вес может немножко проседать делается это с помощью команды waiting опять же в настройке интерфейса мы идем и если лан один g lbp 1 rating и дальше здесь два параметра первый параметр мы можем указать какие именно веса у нас будут то есть например штатный дефолтный вес это 100 но если мы хотим сказать что у нас наш роутер простите более приоритетный роутер с большей вероятностью должен стать фарвардером то мы

укажем вес больше фарвардерами становятся те роутер у которых вес как раз больше и мы указываем штатный вес ну например не знаю 90 у нас все три фарвардера есть поэтому вес на это никак не скажется и мы можем сказать просто что вес 90 или мы можем сказать что мы перестаем быть фарвардером если наш вес проседает до какой-то неразумной границы снизу то есть lower это нижняя граница начиная с которой и ниже мы теряем роль фарвардера и а пер граница это после того как мы потеряли роль фарвардера насколько нам нужно поднять приоритет чтобы мы снова могли получить роль фарвардера и вот сейчас у меня вес 90 допустим я могу сказать что если у меня вес сядет ниже 80 over 80 а то я теряю роль фарвардера ну соответственно а пер границу я не задаю но предполагается что она такая же как lower и ду шоу джи лбп видно что у нас есть одна строчка за обладателя виртуального и пишника это на самом деле роль в

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

я могу настроить tracking и сделать тем самым указание что мой вес будет понижаться в случае если будут обнаружены какие-то проблемы в сети но опять же джек ведь им как простите указываем какой объект мы отслеживаем ну у нас уже можем указать опять же декремент по умолчанию 10 декремент если мой объект отслеживания 1 дохнет то и мой вес на интерфейсе соответственно падает до 70 и и он становится меньше чем нижняя граница и как следствие он вот здесь вот был 90 станет например 70 и он станет ниже чем lower 80 так я хотел показать до конвт

так у меня кто-то а потому что вот как раз весь просел потому что трекинг объект ушел в даун я видимо как раз не включал интерфейс который смотрит наружу и у меня объект трекинга ушел в даун у меня вес просел на 20 стал 70 и соответственно нижняя граница 80 указывает до что я теряю роль фарвардера сейчас у нас как раз будет ситуация когда я в gilbp вроде как бы есть я могу посылать hello пакеты с указанием я живой я все со мной все в порядке но при этом я не хочу исполнять никакую роль я не хочу быть а в фом и я по-прежнему а в грешка я по-прежнему работаю в диспетчером потому что диспетчер не не напряжная работа но фарвардить трафик я больше не хочу так и вот соответственно шоу

ну вот давайте шоу gilbp сейчас посмотрим а ну вот да собственно он уже выполнен то есть сейчас фарвардер один я лисан показывается кто текущий обладатель роли первого фарвардера это 1002 текущий обладатель моей роли 2 фарвардера 1003 и текущий обладатель роли 3 фарвардера тоже 1003 при этом для 1003 нормальный фарвардер это как раз 3 вот он показывается праймере 1003 держит также роль 2 фарвардера но он ее готов отдать при желании кому-нибудь еще то есть если у нас появится какой-то кандидат на то чтобы стать фарвардером новый которого раньше не было то соответственно 1003 с радостью отдаст ему не свойственную ему задачу ну или если я например вернусь я тоже как бы формально

стану новым фарвардером и после этого я получу от 1003 свой обратно свой в f2 вот но это как раз происходит до тех пор пока мой вес не просядет до какого-то точнее не восстановится до какого-то значения трекинга сейчас должен завестись он завелся дальше у меня диагетически сейчас должен отработать вес нужный вот у меня завелся успев у меня заведется вес и у меня сейчас должна будет отобраться обратно роль а в 2 ждем кстати мы не настроили таймер задержки но по-хорошему да как раз вот нужно будет задержку на отбор роли фарвардера делать как раз именно для того чтобы успели установиться все вот эти вот

фарвардер все вот эти вот маршруты у нас успев маленький он быстренько устанавливает соседство но если у вас там будет какой не знаю биджи пи или рип то то что интерфейс у вас поднялся не означает по факту что мы сможем действительно пользоваться выходящим интерфейсом и поэтому если мы отслеживаем только интерфейс это нужно давать задержку для того чтобы вышестоящий протокол маршрутизируемый маршрутизирующий протокол успел насосать все маршруты в таблицу маршрутизации вот здесь у нас все хорошо маршруты установились роль фарвардера я отобрал то есть в вилан 1 группа 1 фарвардер 2 я отобрал обратно свой фарвардер что я да сам себе отдал роль в ф2 мой вес сейчас 90 и соответственно никакие декременты у нас не работают сейчас вот такая вот штука если вдруг вы будете работать с коммутируемыми сетями в которых

требуются подобные вещи gelbp вам ну в общем до противопоказан но тем не менее работать он тоже может так чего нас дальше по плану вера в пиропе протокол очень похож на и час арпи имеет некие патентные проблемы к уже говорилось работает по той же схеме что и час арпи то есть выбирает один роутер который будет главный который будет фарварде трафик также как и час арпи но отличие от час арпи будет заключаться в том что нет запасного то есть есть только один основной он же мастер и есть все остальные которые слушают hello сообщение от мастера и как только перестанут приходить hello сообщение от мастера они устраивают перевыборы и выбирают себе новый роутер за счет того что нету запасного случае отказа основного процедура перевыборов занимает некоторое время и поэтому вера рпи медленнее чем и час арпи но соответственно если у нас вера пи будет работать с теми же таймерами что и и час арпи то у нас получится что

надо сначала определить что основной сдох например 10 секунд а потом провести перевыбор еще 10 секунд то есть у вас 20 секунд сетка будет лежать недоступности естественно это очень много и авторы протокола предположили что такое до такого доводить нельзя поэтому стандартные таймеры в и час арпи здесь вранье написано не раз три секунды раз в одну секунду у в ррп и hello таймер одна секунда а холл тайм три с половиной секунды то есть он за 7 секунд будет выбирать запасной роутер по умолчанию с коробки можно будет настроить таймеры которые будут поменьше ну то есть прям совсем маленькие настроить не получится но по крайней мере да что если вдруг вы захотите вера пида можно застроить на таймеры достаточно маленькие и перескакивание с одного роутера другой будет происходить весьма быстро не перескакивает перескакивай

так gbp или вообще что gbp вот вера пи включается вера пи тем же самыми командами на циске как и и час арпи только слова стендбай заменяется на вера пи циска специально и сознательно когда имплементировал у себя вера пи для нее это был вопрос принципа она специально делала все таким образом чтобы было понятно что это тот же самый час арпи только в другой упаковке что ни у кого-нибудь не возникло бы впечатление что это совершенно другой протокол поэтому везде где у нас вы час арпи было слово стендбай в вера пи мы просто меняем на слово вера пи и все остальное остается то же самое соответственно нас есть вера пи один айпи дальше и пишник точно так же как и в и час арпи здесь вот слова стендбай осталось но вера пи надо его заменить точно так же как в час арпи в вера пи можно управлять

тем кто будет главным то есть вы можете указывать приоритет и вы можете включить или выключить прием тинг в отличие от и час арпи прием тинг вера пи штатно работает прием тинг за говорит что если вдруг вы чувствуете что вы более достойный кандидат на справа стать мастером то вы немедленно перехватываете роль мастера ну то есть так же как в и час арпи на самом деле за роль запасного происходили выборы и также как в час арпи за роль запасного любой желающий может немедленно взять и провести перевыборы то есть фактически за роль запасного прием тинг там особо не нужен в час арпи ну вот в рапе он как бы есть но он работает по умолчанию вот еще одним заметным даже знаковым отличием вера пи от час арпи является то что вы можете в edge с арпи использовать виртуальный айпишник только отличающиеся от физических айпишников которого свет на интерфейсах висят то есть вот нас в лабе мы сейчас поднимали 10 001 10 002 10 03 10 08 и виртуальный

пишет у нас был 10 00 100 он отличался от всех айпишников в виропе вы можете на роутере нам на на одном из роутеров сказать что этот роутер будет своим айпишником делиться со всеми остальными при этом естественно что если у него есть этот айпишник и он нормально работает то соответственно вот он должен будет сам всегда быть мастером за этот айпишник то есть вы можете в случае с использованием вера рпи использовать виртуальный айпишник совпадающий с физическим айпишником на одном из роутеров если вы это делаете то при любых выборах обладатель физического айпишника должен такие выборы выигрывать специально для этого случая есть приоритет 255 вот если у вас виртуальный айпишник равен физическому то приоритет у вас будет 255 вы его не можете изменить а если вы не обладаете айпишником совпадающим

вот виртуальный совпадающий с вашим физическим то вы можете регулировать приоритетом ваш приоритет но только в диапазоне от единицы до двухсот пятидесят четырех то есть 255 если ваш айпишник не совпадает с виртуальным вы поставить не можете как следствие если вы захотите вы можете сделать так что у вас есть железный роутер например большой толстый у которого сейчас прописан айпишник и вы хотите в к существующему роутеру без потери связи без переконфигурирования айпи адресов подставить еще один другой и вы можете в этой ситуации сказать а давайте мы вот возьмем подоткнем второй роутер назначим ему какой-нибудь там левый айпишник и скажем ты будешь на подхвате ты будешь по vrp работать в связке с вот каким-то там вот роутером у него будет какой-то железный айпишник прописан и если вдруг он сдохнет ты его железный айпишник заберешь по vrp такую вещь делать можно хорошая ли эта идея нельзя сказать однозначно потому что во первых это как бы хотя и позволяет в определенных

ситуациях без смены айпишников на клиентах без смены айпишника на железном роутере добавить небольшую схему со сказоустойчивостью но проблема будет в том что вы в такой ситуации не сможете понизить приоритет на железном роутере у которого физический айпишник совпадает с виртуальным то есть приоритет если у вас физический айпишник совпадает виртуальным вас всегда будет 255 и играть им не получится поэтому иногда может быть это и полезно но если вы используете и чесар пи протоколы то вы ну должны будете отслеживать состояние внешнего мира и проседать по приоритету в случае необходимости вы этого не можете сделать если у вас приоритет прибит гвоздями жестко так далее show vrp та же самая команда что была в шоу стендбай то же самое показывает виртуальный а пишет виртуальный mac виртуальный mac опять же хорошо заметный хорошо известный если мы говорим

про стандартные протоколы которые управляются и и т.ф. то есть это те протоколы на которые есть рфс и там зачем-то нужны mac адреса вот например в ipv4 у нас нужны mac адреса для мультикаста у нас для мультикаста вайпи 4 есть хорошо известный оу и если у нас есть вера рпи тоже хорошо известный протокол который описывается и и т.ф. н.м. рфс то там тоже есть mac адреса они тоже хорошо известны и тоже пользуются тем же самым хорошо известным и это с кем и и и это я вы 0 0 0 0 5 я вот из него например придумывается мультикастовый mac 0 0 0 1 0 0 5 я чего-то там ну и соответственно 0 0 0 1 это суффикс вера пи 0 1 это номер группы на экзамене возможно вас спросят какой мультикастовый какой mac просите у вера пи будет и вот 0 0 0 0 5 я надо будет запомнить дальше показывается кто активный роутер ну то есть активные

в терминологии вера пи называется мастер и показывается почему он мастер то есть какой у него приоритет мастера 2 тазминт это как часто халлоу сообщения посылаются и мастер down интервал это холл тайм показывается через сколько вы признаете его трупом таймеры настраиваются немножко неожиданно то есть не слово таймер там будет указываться а слово адвертайз если вы хотите указать миллисекундные таймеры то вы должны будете указать msec но также как и в еще серпит то есть указываем там таймер и вместо цифры указываем msec и цифра по умолчанию троим таймеры 1 секунда advertising таймер и мастер таймер высчитывается автоматически он высчитывается по хитрой формуле но там умножить на 3 плюс немножко вот три с половиной секунды это как раз таймер через сколько признаемся сент трупом если вы указываете миллисекундный таймер то вы указываете например msec 50 то есть раз в 50 миллисекунд посылаем сообщение и тогда

примерно через 100 200 миллисекунд сосед будет признан трупом если он вам ничего не пришли в отличие от и чсрп вы настраиваете только один таймер за счет того что в европе в общем-то существенно проще по сравнению с и чсрп там нету процедуры вот этого двухэтапного сначала выбираем 1 потом он захватывает другое потом там что-то еще за счет того что в веро пи вы всегда знаете айпишник в котором вы работаете у вас нету состояния состояние лерн в котором и чсрп мог находиться когда он знал что ему надо работать в и чсрп но он не знал с каким виртуальным айпиш никому он слышал чужие hello сообщения что по нему рассказали какой адрес надо использовать у виропе вы всегда знаете какой и пишет вы должны будете использовать поэтому состояние learn нету нету состояния отдельного как бы специального состояния как называется нет отдельного состояния ли сон то есть фактически если у вас есть если у вас есть

да вот возможность стать мастером то есть вы знаете свой айпишник то вы просто сидите и ждете что от мастера приходит hello пакет если нет то вы говорите давайте я захватываю роль мастера и ну вас никто не претендует то я тогда буду мастером если вдруг два роутера одновременно захотят стать мастером но один пришли от hello сообщение другому и второе сразу немедленно успокоиться то есть здесь нету каких-то вот этих промежуточных схем вида давайте подождем давайте пусть он расскажет о себе расскажет о себе здесь все просто и нет в ррп нету backup мы сидим и слушаем сообщение от мастера и актив это мы сейчас сами мастер также как и hsrp в ррп нужно будет играть с приоритетами нужно будет отслеживать объекты в виропе никогда штатно нельзя было отслеживать интерфейсы только через отслеживание объектов поэтому если на экзамене вас будут спрашивать вопросы типа какой из протоколов

штатно умеет отслеживать интерфейсы нужно будет говорить что это час арпи умеет хотя он на самом деле не умеет если вдруг будут спрашивать чем и час арпи отличается от веропи то нету приемтинга нету штатного отслеживания интерфейсов в веропи дальше нету выборов за роль активного в и час арпи то что выбора в час арпи идут за роль запасного несколько больше времени требуется на перестроение топологии когда у нас вера пи забирает один роутер роль другого ну вот да такие вот таком вот аспекте так настройка трекинга происходит точно также документ точно такой же то есть здесь никаких сюрпризов нету вера пи будет использовать вложение я в ethernet кадры использует он маг уже говорилось какой 0 0 0 0 0 5 и 0 0 0 1 дальше номер группы для не для айпи в 4 используется хорошо известный

мультикаст в адрес 224 0 0 18 уверов и будет использоваться очень хитрое сообщение там него ттл будет 255 делается это для того чтобы защититься от каких-то левых вера пишных кадров которые будут приходить непонятно от кого вот вы отправляете вера пишные пакеты вы указываете ттл 255 и вы принимаете только пакеты в которых ттл прописан 255 то есть если такие пакеты вдруг пройдут через роутер то ну вы их не примите и вкладывается он напрямую в айпи код вложения 112 то есть там не и депи не ничего то там как вот было у и чесар питом помните номера портов 1985 и так далее здесь прям сразу 112 вложения показывается по по скриншоту что у нас здесь передается обратите внимание на следующий момент вы отправляете пакеты из-под своего физического адреса и вы указываете внутри сообщений много и виртуальных айпи адресов которые у вас будут то есть адрес каунт на это указывать то есть вы можете

в одном hello сообщение вера пиш нам отправить указание что вы будете мастером сразу за несколько виртуальных айпишников это забавная особенность увер от и есть до что в и час арки вы можете только один айпишник виртуально использовать для группы а виропе много на экзамене про это вопросов не будет но в реальности вы можете встретить другие имплементации нет cisco вские вера пи там прям будет это хорошо заметно тот же микротик к примеру да там поднимается сущность которая похожа на виртуальный интерфейс и вот вы к этому виртуальном интерфейс и вы вешаете уже и пи адреса их можно много повесить да это нормально то есть это не то как вы час арпимы одна группа это один айпишник здесь одна группа это много айпишников дальше то же самое есть приоритет дефолтный приоритет 100 это штатный приоритет он же рекомендуемый приоритет для запасного роутера вера если вы захотите использовать аутентификацию в вера пи вас здесь поджидает сюрприз

сюрприз заключается в следующем изначально вера пи когда создавался он создавался с аутентификацией старые версии протокола они использовали аутентификацию поинтекстовую в стандарте циска для того чтобы соблюсти указание на то что вирпи это в общем то же самое что час арпи только верх ногами поддерживает аутентификацию до сих пор и это plain текстовая аутентификация она в общем никому особо не нужна но она нужна вот циска для того чтобы просто показать что она она есть в актуальных версиях стандарты аутентификации нету вовсе потому что предполагается что если вдруг злоумышленник может взять и отправить какой-то левый кадр содержащий вера пишные вложения у вас есть системные проблемы с вашей сетью то есть злоумышленник может устроить атаку например на арп и это куда страшнее чем атака на вера пи поэтому если вы используете в вашей сети вера пи вам нет смысла

защищать его потому что вся его все что он делает фактически это создает отвечал q арпом с виртуальным мак адресом ну и если у вас есть злоумышленник который может отправлять произвольные кадры все эти он скорее всего просто завернет весь трафик на себя и будет рад и делать это с помощью атаки на арп будет ему намного проще чем атаку на вера пи производить поэтому в актуальных версиях россии аутентификации нету предполагается что вы должны будете защищать свою коммутируемую сеть как-то еще как то еще как понятно это access листы то есть на недоверенных портах у вас просто не должно пропускаться вложение 112 так далее если у вас ситуация такая может быть что мало айпишников в сети такой бывает например у вас есть внутренняя сеть и в ней двести пятьдесят три железной машины и вам

нужно сделать один айпишник виртуального роутера но вам нужно два железных роутера поставить у вас не льду то есть не хватает адресов для того чтобы виртуальный айпишник и физические айпишники назначить на все хосты в этом случае что сверрп что сейчас рп вы можете сделать схему при которой вы физически айпишники на железке назначите не из той же сетки что у вас и юзеры будут иметь то есть у вас есть юзеры 1001 1002 1003 и так далее и вот у вас с первого по 253 айпишники все разданы юзером и вы хотите сказать что у вас есть виртуальная пишник 100254 но вы не можете назначить из 1001 1002 все это пишники за занята уже и вы не можете назначить эти айпишники на ваши роутеры в такой ситуации вы можете назначить айпишники с какой-то другой сетки 10 но это не 10000 а 100 2 168 011 12 168 02 дальше вы должны будете указать виртуальный айпишник из той же сети которая у вас железная

1002 168 0254 но для того чтобы юзеры получили адрес из-за своей сетки вот вы указываете что у вас есть секондри адрес 10 0 0 254 то есть это позволит вам сделать так чтобы у вас два роутера прикидывались одним виртуальным роутером и задействовали только один адрес из той сетки которую они раздают то есть при такой при таком сценарии у вас до пользователи вообще не смогут даже догадаться что есть какие-то другие вот айпишники которые можно например подключиться опять же на экзамене этого вряд ли будут вас спрашивать но в реальности такая задача иногда встречается когда уже есть один айпишник и надо каким-то образом не меняю адресацию не затрагивать другие адреса сделать из этого и пишника 2 для того чтобы двум разным роутером их раздать и желательно вообще не два даже три чтобы еще виртуальный айпишник получился какой-то треть если мы говорим про чсрпи вот в такой схеме можно будет взять и настроить два виртуальных айпишника из

другой сети сделать виртуальный айпишник из той же сети и еще один виртуальный айпишник из той сети которая будет вам нужно в чсрпи и в соответственно в вверх и у нас привязываются айпишники группам мы становимся мастером за группу номер один или активным роутерам за группа номер один и получается что мы становимся обладателями всех виртуальных айпишников и вот этот виртуальный айпишник И вот этот виртуальный IP у нас на каком-то роутере объявляются. И, соответственно, весь трафик начинает идти на него. Если у нас есть IPv6, в отличие от IPv4, в IPv6 есть штатные механизмы отказоустойчивости. Там роутеры периодически отсылают рашки. И в этих рашках указывается время в секундах, какое время этот роутер согласен быть шлюзом по умолчанию. То есть, если у вас есть два роутера, они оба могут присылать рашки, что они будут шлюзами. И дальше, если вы хотите, вы можете IPшники назначать по слуаку или получать по DHCPv6.

Не суть важна, где роутеры возьмут свои адреса. Они будут настраивать шлюзы по умолчанию на тех, кто присылает им RA. Роутер адвертайзмент. Если у нас есть два роутера, и мы хотим, чтобы один становился более важным, другой менее важным, мы можем играть приоритетами. То есть, там есть разные варианты приоритета в самих рашках, с какой вероятностью конкретно этот роутер должен становиться шлюзом. Но этот механизм не обеспечит вам субосекундное переключение с одного роутера на другой. То есть, даже если вы роутер lifetime указываете какой-то совсем маленький, рашки вы будете посылать раз в секунду. И, соответственно, переключение между одним и другим роутером у вас будет происходить, например, за 3-4 секунды. Иногда это вполне нормально, иногда хочется обеспечить более быстрое переключение, и в этой ситуации нам, опять же, может пригодиться протокол FHRP. HSRP поддерживает IPv6, начиная со второй версии. Ну, то есть, их всего две. Одна не поддерживает, вторая поддерживает. И если вы хотите указать, что у вас есть IPv6 адрес, вы привязываете к группе указание standby, дальше номер группы, IPv6, и вы можете сказать, какие адреса вы хотите использовать.

Как правило, вы хотите использовать такие адреса в качестве виртуальных, которые можно назначить в качестве шлюза. И в качестве шлюза назначаются обычно link-local адреса. Если мы говорим про link-local адрес для IPv6, то это будет, как правило, хорошо известный link-local. Ну, в смысле, хорошо известный. Он будет получен из хорошо известного Mac. То есть, как правило, он будет FE80, дальше куча нулей. 0, 0, 0, 0. Так, сейчас, пардон. Сейчас, я чуть затупил. Да. 0, 0, 0, 0. Вот это вот сейчас надо расписать. 0, 0, 0, 5. 7, 3. Да, 0, 0, 0, 5, 7, 3. Дальше, FF, FF, E. Это, понятное дело, суффикс EUE64. Дальше, A0, 0.

Это суффикс, опять же, HSRP. И XXX, вот это вот, это номер группы. Если мы говорим про HSRP для IPv6, у HSRP для IPv6 будут использоваться свои MAC-адреса. Вот он, этот MAC-адрес. 0, 0, 0, 0, 5, 7, 3. Дальше, A0, 0, суффикс. И номер группы XXX. Как уже говорилось, UDP-шный порт 2029. Ну и мультикастовый адрес, в общем, такой же, как был в HSRP для IPv4, только совсем другой. Заканчивается на 102 или 66 в 16-ти речном виде. Вы не можете смешивать в одной группе HSRP v2 и IPv4 и IPv6 адреса. То есть, если вы хотите использовать HSRP v2 для IPv4 и для IPv6, вам следует сделать две разные группы. Вот. Дальше.

Что еще тут можно сделать? Вы можете, в принципе, сказать, что у вас будет какой-то маршрутизируемый адрес. Но если вы делаете это для цели отказоустойчивости шлюза, вам, скорее всего, пригодится либо заданный ручками link local адрес, либо вы можете сказать как раз автоконфиг, и у вас сделается вот это вот... Ой, как его расколбасило. И у вас сделается вот такой вот виртуальный... Из виртуального мака вот такой вот link local адрес. Так. Дальше. Если мы хотим работать с VRRP для IPv6, возможность такая у нас, конечно же, есть. Нужен VRRP третьей версии. И здесь есть, опять же, нюанс, заключающийся в том, что VRRP штатно из коробки работает второй версии. И если мы хотим переключить VRRP в третью версию, то для этого надо сделать немножко плясок с бубном. И пляски с бубном будут следующие. Во-первых, надо глобально на уровне всей системы выполнить команду fhrp version vrp и дальше v3.

Абсолютно неочевидная команда. Она делается не в настройке интерфейса, а в настройке всей системы целиком. Вот. И вы указываете, соответственно, что в каком режиме VRRP вы хотите работать. Это не в настройке интерфейса делается. Это абсолютно неочевидно. И когда вы переключаете VRRP в третью версию, у него настройка будет другая. Не такая же, как в HSRP. То есть в настройке интерфейса надо будет выполнить команду vrp, дальше номер группы, адрес family и тот адрес, который вы хотите вешать. Вы переходите в субконтекст настройки VRRP третьей версии. И там даете IPшники, там даете приоритеты, там даете таймеры, там даете все, что необходимо для работы VRRP. Вот. И если вдруг вы где-то на одном интерфейсе хотите работать по VRRP третьей версии, а на другом интерфейсе, или даже не на другом, а на том же самом интерфейсе, хотите работать в VRRP второй версии, то вы можете для, например, работы по IPv4 запустить эмуляцию VRRP второй версии.

Вот эта команда VRRP v2 внутри контекста адрес family IPv4 даст вам возможность отправлять на этом интерфейсе VRRP вторые пакеты. То есть если у вас есть, например, циска, которая настроена просто на работу VRRP без каких-либо изощрений, она работает в VRRP второй версии. Рядом другая циска, на которой вы включили изощрение. Вот там надо будет вот этот вот костыль включить, чтобы у вас на интерфейсе, который смотрит на лего с циску, работал VRRP v2, хотя на всей системе работает VRRP v3. JLP штатный из коробки поддерживает IPv6, но не на всех платформах. Вот. Опять же, так же, как в HsRP, надо разносить IPv4 и IPv6 по разным группам. Все остальное, в общем, аналогично. На этом я предлагаю считать наш курс завершенным. Так же, как и во всех остальных случаях, я напоминаю про то, что, да, когда вы пойдете сдавать экзамен, я очень вас сильно прошу,

после того, как вы экзамен запланируете, связаться со мной и сказать, что вот вы на экзамен идете. А после того, как вы экзамен сдадите, написать мне, как все прошло. Если вы экзамен сдадите хорошо, я за вас порадуюсь. Если вы экзамен вдруг сдадите не очень хорошо, ну, по крайней мере, вы расскажете, где что не получилось, и я вам где-то подскажу советом, добрым словом, может быть, какой-то полезной ссылкой. Так же, как и в случае с всеми остальными курсами, прошу, по-хорошему, да, прошу заполнить вас форму с обратной связью, потому что мне, на самом деле, очень важно знать, как курс прошел. Если вам все понравилось, расскажите про это. Если что-то не понравилось, ну, расскажите, что именно не понравилось. И если вдруг у вас будет такое острое желание, заполните какой-нибудь отзыв на какой-нибудь социальной платформе. Можно заполнить на Facebook, можно на Вконтакте, можно где-то еще. А на сегодня все. Спасибо за внимание. Пока-пока. Пока.