Настройка IEEE 802-совместимой коммутации: часть 2

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

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

Она может быть достаточно странной, но чаще всего, если мы говорим про провайдерские сети, дизайн таких сетей устроен таким образом, что там есть кольца. И, соответственно, эти кольца, они там штатно на этапе планирования, на этапе дизайна были добавлены. Кольцо — это очень удобная штука, потому что у нас, если вдруг оно в каком-то одном месте разорвется, то, соответственно, трафик может пойти по другой стороне. Гонять там спанинг-3 внутри этого кольца — не очень хорошая идея, потому что спанинг-3 — а, штука медленная, и б, в определенной ситуации, если у вас рут за топологию находится вне кольца, у вас, как уже было сказано, спанинг-3 подвержен проблеме подсчета до бесконечности. Он в определенных ситуациях может там до 40 секунд сидеть и курить бамбук, пока у вас идет перестроение топологии. Вот. Даже несмотря на то, что спанинг-3 у вас может быть сколько угодно быстро, и даже несмотря на то, что спанинг-3 у вас может быть со всеми возможными ухищрениями, ускорениями настроен, все равно проблема подсчета до бесконечности в определенном случае остается.

Для того, чтобы защититься в именно провайдерском сценарии от колец, которые у вас формируют проблемы штатного Ethernet, если ничего дополнительного не предпринимать, провайдеры любят использовать не спанинг-3, а другие протоколы. В частности, у CISC есть Resilient Ethernet протокол. Это протокол, когда мы указываем, в каких портах у нас сформируется кольцо, и, соответственно, там коммутаторы заранее выбирают, какой порт будет блокироваться. То есть, фактически, вы указываете на всех коммутаторах, которые формируют кольцо, какие порты входят в это кольцо, указываете на каждом коммутаторе левую петлю, и левую часть кольца, и правую часть кольца – два интерфейса, которые смотрят налево-направо. На соседних свечах левый порт должен смотреть на правый порт соседа, и правый порт наш должен смотреть на левый порт соседа. Так что вот они получаются друг на друга, как за ручки держат. И, как правило, на одном из коммутаторов, на одном из бриджей, более правильно сказать, ну, коммутаторов, мы указываем в явном виде,

что покуда все живы, вот именно этот порт должен будет гаснуть. Соответственно, если вдруг у нас коммутатор какой-то один выходит из строя, остальные, соответственно, просто продолжают работать, как ни в чем не бывало, но какой-то вот этот вот заблокированный порт, он, соответственно, разблокируется. Равным образом, если у нас вдруг есть какой-то интерфейс, линк между двумя коммутаторами, которые тоже выходят из строя, то связь между двумя свечами в кольце пропадает, то, соответственно, заблокированный порт, он разблокируется. Как настраиваются подобные протоколы? Если мы посмотрим на примере CISC. У CISC протокол REP есть, он как бы живой, рабочий, поддерживается на метроизорных свечах, на наших свечах его, к сожалению, нету. Ну и выглядит он примерно следующим образом. Мы заходим на интерфейс и указываем, что определенный интерфейс входит в определенное кольцо. С точки зрения REPа кольцо будет у нас называться сегмент. В принципе, гипотетически мы можем взять и сказать, что у нас REP будет работать не только в кольце. Он, в принципе, может работать еще и на именно сегменте.

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

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

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

Мы говорим, вот этот порт у нас штатно заблокированный, этот порт штатно основной разблокированный. Это primary, а вот этот вот, соответственно, secondary. Но secondary порт никак не помечается, он просто помечается как edge. Это минималистичная конфигурация. В реальности вы захотите REP настраивать существенно более изощренно. На экзамене вопросов про настройку REPа не будет, но вопросы могут быть про то, как вообще он в принципе работает. Как работает REP, как работает ERPS. Это в любом случае, в любом проведере встретить вживую можно будет довольно часто. Поэтому как бы команды, которые штатно имеют отношение к REPу, вот они выглядят так как REP-сегмент на интерфейсе. А дальше там можно кучу дополнительных настроек задать. То есть как часто отправлять пакеты REPа, какие виланы к какому кольцу привязывать. То есть можно будет по-разному указывать, как ходит трафик самого REPа, как коммутация от поведения определенных колец будет разрешаться, не разрешаться. Но в любом случае, да, ключевые слова REP

там будут каким-то образом фигурировать в настройке интерфейса. Для того, чтобы REP включить на интерфейсе, этот интерфейс должен быть в режиме trunk, а switchport mode trunk должен быть в режиме NNE. Если мы говорим про метро Ethernet свечи, там можно будет port type задать. Вот здесь вот как раз это будет важно. То есть вы не можете это на абонентском порту включить. Это, в принципе, логично. Если вы строите провайдерскую сеть, если у вас где-то в провайдерской сети есть кольцо, то, естественно, никаким образом пользовательский интерфейс в этом кольце оказаться не сможет. Если вы включаете REP на порту, выключается Spanning 3. Ну и если вдруг вы хотите использовать связь между двумя коммутаторами, и там у вас уже два линка проложены в Ether Channel, то вот этот вот линк в Ether Channel REP рассматривается как один линк в сегменте. То есть так же, как и Spanning 3, REP не замечает, что на самом деле там два физических провода.

Он воспринимает это как один логический канал. Ну и настройка REP-сегмент задается в этом случае на порт-ченнеле. Аналогично не должно быть никаких настроек FlexLink. То есть если вы используете FlexLink, вы в этом случае кольцо рассрываете более простым образом. У вас есть Access Switch, есть два Distribution Switch, и, соответственно, вот они там между собой как-то вот так вот выглядят. Это Distribution 1, это Distribution 2, и это, соответственно, Access Switch. Ну вот он в этом случае говорит, это основной порт, а это бэкапный порт к нему. Если основной порт работает, то бэкапный выключается за счет логики самого FlexLink. Если у нас основной порт дохнет, на нем лампочка гаснет, соответственно, перескакивает взаимодействие на второй порт, и отправляются там специальные дамми кадры. Ну, у REPа, в принципе, по большому счету, примерно так же все работает, но только с использованием дополнительных пакетов, дополнительных ПДУшек, дополнительного взаимодействия между свечами. FlexLink предполагает, что у вас взаимодействия между свечами нет.

Если мы говорим про агрегацию, то на ЦИСКе, соответственно, как вы помните, агрегация будет называться специфическим словом Ether Channel. То есть Ether Channel — это технология, которая позволяет агрегировать несколько разных портов в один логический канал. Ether Channel будет называться технология, которая объединяет сами порты, плюс балансировщик, алгоритм балансировки, который у ЦИСКе всегда, трафик одного и того же потока приложения, будет отправлять в один и тот же канал. При этом каналы могут загружаться неравномерно. Для того, чтобы настроить агрегацию на свечах ЦИСКе, мы будем использовать команду Channel Group, дальше номер группы, Mode, и дальше тип агрегации, который мы будем использовать. Точнее, тип агрегации, он всегда одинаковый, просто берем и агрегируем. Но контроль агрегации, который можно осуществлять либо с помощью LATS, либо с помощью PANG, либо не осуществлять вовсе, вот здесь будет указываться качество ключевого слова после слова Mode. Номер группы по сети не передается,

он локально значимый, и эти самые номера не обязаны совпадать на соседних железках. То есть если мы берем, допустим, вот этот свитч, и на нем указываем, что вот эта группа будет иметь номер один, никто нам не мешает, вот на этом свитче номер группы сделает два. То есть они не передаются по сети, и они могут не совпадать, имеют полное моральное право на это. Если мы создаем группу, то у нас включается виртуальный интерфейс, который будет называться Port Channel плюс номер группы. То есть группа номер один, значит Port Channel будет тоже номер один. И если мы хотим давать какие-то настройки на логическом канале до соседнего свитча, то мы даем их именно на этом самом Port Channel. Все настройки транков, Switchport Mode Trunk, Switchport Mode Access, Switchport Access VLAN, Switchport Trunk Native VLAN, Switchport Trunk Allout VLAN, вот это все задается на Port Channel интерфейсе. Автоматически все настройки копируются на физические интерфейсы, и тем самым вы в одном месте указываете, что у вас, допустим,

Switchport Translation.1Q на вот этом самом Port Channel интерфейсе, автоматически у вас все настройки копируются на физические интерфейсы, в нашем случае Gigabit 001. То есть не надо на физических интерфейсах прописывать какие-то настройки, это повлечет за собой неприятный и неожидаемый результат. Надо прописывать их на именно логическом интерфейсе. Нюанс заключается в том, что вы, когда прописываете какие-то настройки на физическом интерфейсе, система проверяет, может ли этот интерфейс вообще войти в пачку, вообще быть агрегирован. Если настройка физического интерфейса отличается от настройки логического интерфейса Port Channel, то интерфейс вываливается из пачки. Это не LATS проверяет, что можно ли там на этом интерфейсе работать, а именно сама логика Azure Channel говорит. Этот интерфейс настроен не так же, как все остальные, не так же, как логический интерфейс, поэтому мы его выбрасываем из пачки. Любые настройки,

которые вы хотите дать на физические интерфейсы, вместо этого следует давать на интерфейсах Port Channel. Далее. Что еще интересного можно было бы сделать? Если вы используете, безусловно, агрегацию, то вы сами берете на себя ответственность за любые проблемы, которые могут появиться в результате ваших действий. То есть вы тем самым грубо вмешиваете в логику коммутации, и вы берете на себя ответственность за свои действия. Система не проверяет, насколько вы корректно собрали Port Channel, смотрит ли все ваши порты на одну и ту же железку, согласна ли железка с другой стороны, что все эти порты должны быть в одной группе. То есть все вот такие вот вещи она пропускает мимо ушей. Как следствие, если вдруг вы неправильно соберете Port Channel, у вас может быть такое, что система будет работать некорректно. Если вы хотите использовать агрегацию портов с контролем правильности,

то вам следует использовать LATS. Альтернативный вариант, как уже было сказано, ПАГБ, фирменный цисковский протокол, Port Aggregation Control Protocol, не имеет никаких преимуществ по сравнению с LATS. То есть вам всегда, если вы хотите собирать порт агрегаты, следует использовать контроль сборки, и следует использовать именно протокол LATS. У ПАГБа есть преимущества следующего характера. Оно полезное в сети предприятия. Если вы берете и собираете две коробки 65-х каталистов, ну или 68-е тоже, вы их собираете в единую группу, которая называется Virtual Switch System VSS, и, соответственно, они у вас связываются через так называемый Virtual Switch Link. И дальше вы берете Access Switch и соединяете его двумя проводами с двумя вот этими самыми 65-ми коробками. И тоже объединяете в Port Channel, потому что так делать можно. Если у вас два 65-х свеча соединяются в единое VSS, то как бы и LATS, и ПАГБ, и все на свете протоколы контроля, они говорят,

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

говорит, я тоже буду мастером. И в этом случае она говорит, я буду сама отвечать за то, какие кадры у меня куда будут фарвардиться. И в этом случае она у вас тоже фактически начинает работать по своей ноге вот этого самого Port Channel. Если вы используете Pugb, и точнее говоря, E-Pugb, Enhanced Pugb, вот такой вот продвинутый Pugb, если у вас шеститонники стоят с одной стороны Port Channel, если у вас с другой стороны девятитысячные свечи или 38-50-е цисковские фирменные свечи стоят на Аксессе, то в этом случае Pugb, Pugb, VSS, может передавать указание, и что я мастер. И в этом случае, если вы по двум ногам Port Channel получаете указание, я мастер, вы понимаете, случился развал вашей системы VSS. В этом случае Port Channel гасится. Это единственное преимущество Pugb

по сравнению с LATP. Все остальные особенности Pugb, они настолько незначительны, что можно будет ими пренебречь. Понятное дело, что в провайдерском сценарии у вас крайне редко шеститонники собираются в VSS, а на Аксессе стоят вот эти вот жирные свечи, которые поддерживают EPUG. Поэтому в реальных сценариях EPUGb не нужен. Он не нужен ни в сетях предприятия, если у вас только не используется вот это вот оборудование, и вы не строите сети именно с помощью Port Channel, которые собираются в Multishassist лаге. Ну и, соответственно, если вы используете на сети какое-то другое оборудование, то, как вы понимаете, разницы Pugb и LATP для вас вообще никакой не будет. Итак, по этой причине мы всегда используем LATP, мы не используем Pugb. Мы указываем настройки интерфейса Channel Group 1 Mode, и вместо ON, который указывает, что мы не используем контроль, мы указываем Mode Active или Mode Passive. Разница между Active и Passive

заключается в том, что в пассивном режиме LATP первую свою ПДУшку отправит только в ответ на ПДУшку от соседа. То есть, если у вас с одной стороны будет узел, который Active, а с другой стороны узел, который Passive, то, соответственно, сначала Active отправит свою ПДУшку, а потом пассивный узел в ответ отправит свою. Если у вас два узла будут пассивные, они друг на друга будут смотреть и будут ждать до тех пор, пока сосед отправит ПДУшку, в LATP-ПДУ, и, естественно, что ни один из них первый не решит показать, что он активен. В реальной сети вы должны будете хотя бы с одной стороны указать Channel Group 1 Mode Active, ну, или Channel Group, не знаю, 2, 3, 10. Можно Active и Active между собой связывать, то есть это не проблема. Можно связывать Active и Passive. Вот нельзя Passive и Passive. Они будут на друг на друга смотреть, как баран на новые ворота каждый. В остальном настройка идентична обычному Port Channel, то есть все, что касалось

настройки Port Channel в целом, все здесь же будет актуально. Если мы хотим настроить агрегацию на роутерах, то вы можете это сделать с использованием похожих, в принципе, настроек. Для iOS обычного некоторых его редакций и iOS XE это выглядит примерно следующим образом. Мы, опять же, настроим на интерфейсах физических команду Channel Group, дальше номер группы, Mode и Active. На iOS XE, по крайней мере, вы не можете задать Channel Group 1 Mode On, потому что от вас требуется в обязательном порядке использование LATSP. То есть вы не можете включить просто обычную агрегацию без контроля. Если говорить про iOS XR, то настройка выглядит чуть-чуть отличным образом. То есть, в принципе, логика та же самая. То есть мы заходим на физический интерфейс и указываем, что они входят в определенную пачку и указываем,

что они требуют контроля правильности сборки перед тем, как они войдут в пачку. Но вместо Channel Group мы указываем Bundle ID и дальше номер группы. Если говорить про iOS и обычные iOS XE, то там групп, по-моему, 64 штуки можно создать. В iOS XR групп можно сделать сильно больше. Но опять же, учитывая, что XR роутеры могут иметь безумное количество интерфейсов, вспоминаем те же самые системы CRS, на которых 1152 линейные карты может быть и в каждой там по 48 портов. И в принципе, в некоторые из них можно вставить расширение, в некоторые роутеры на основе XR. То есть у вас получится совершенно немыслимое количество портов. Ну, поэтому да. Поэтому групп у вас может быть достаточно много. и поэтому номера у вас превосходят 64, которые есть в обычном iOS. И у вас создается интерфейс, который называется Bundle Ether. То есть система здесь уже не называется Ether Channel, она уже называется просто Ethernet Bundling. Ну, в принципе, да.

Так же, как и на многих других роутерах. Далее. Что еще тут можно будет сказать? Зачем на роутере нужно использовать агрегацию? На самом деле, очень простой механизм. У вас есть какая-то коммутируемая сеть, свечи, два свеча, и вы хотите сделать на роутере надежный канал, который будет смотреть на один свеч или даже на два свеча, которые, возможно, объединены в единую систему того же самого VSS. Вот. И вы хотите все это дело сделать порт-ченнелом. Но в этом случае вот вы на роутере делаете это не для того, чтобы какой-то транзитный фарвардинг этих кадров делать, а для того, чтобы на этом интерфейсе просто терминировать IP-пакеты, которые приходят именно на ваш собственный MACAD. В этом случае вы вместо того, чтобы у вас делать четыре отдельных интерфейса, смотрящие в одну и ту же среду, на них там четыре разных IP-шника делать, вы говорите, окей, мы собираем все эти четыре интерфейса в единую пачку,

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

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

И тут возникает вопрос. Если у нас есть пользователь, который хочет отправить какой-то пакет в сеть назначения, нам нужно будет использовать, соответственно, протокол FHRP для того, чтобы два роутера, которые у нас в сети есть, договорились бы, кто именно из них обрабатывает трафик. Если вдруг один из роутеров выходит из строя, чтобы второй роутер стал подхватывать задачу фарвардингом пользовательского трафика через себя. Для этого у нас есть протоколы типа FHRP, First-Hall-Predonancy Protocols, и у нас, соответственно, там протоколы HSRP, VRRP и GLBP будут присутствовать. Если мы говорим про реальную настройку этих протоколов, то мы, конечно, можем сделать что угодно для того, чтобы наши роутеры договорились, кто из них будет основным, кто будет запасным, то есть кто из них будет мастер-бэкап в терминологии VRRP, кто из них будет ActiveStandby в терминологии HSRP, кто из них будет фарвардерами в терминологии GLBP. Но если вдруг у роутера нету больше связи со внешним миром,

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

можно будет отдать, можно себе будет понизить приоритет, если у кого-то другого приоритет будет выше. Но там не приоритет, там веса. Вот, если у кого-то другого вес будет выше, то мы, соответственно, отдаем добровольно роль фарвардера к кому-нибудь еще. Для того, чтобы это сделать, нам нужно будет использовать механизм, который называется отслеживание объектов. У нас наши системы, что EOS обычные, что EOS XE, что EOS XR, позволяют использовать так называемые объекты отслеживания, которые могут чего-нибудь отслеживать. И если они отслеживают чего-то, им все нравится, они говорят, мы в API. Если у нас происходит какое-то отслеживание объекта, и мы перестаем иметь доступ ко внешнему миру, объект отслеживания по какому-то заданному критерию, по заданному алгоритму переходит в состояние DAO, и мы можем на основании DAO что-нибудь, какое-нибудь действие предпринять. Можем, например, понизить приоритет на FHRP протоколе. Настройка будет примерно похожая что на EOS обычном, что на EOS XE,

что на EOS XR. Вы должны будете создать объект отслеживания. Оно создается везде с помощью команды track. То есть, в EOS обычном мы указываем track, указываем номер объекта отслеживания, ну, допустим, track 3, 2, 1, и указываем, что именно мы отслеживаем. То есть, на основании чего объект трекинга будет переходить в состояние up-down. Вот если мы используем самый простой механизм, то мы можем сказать, давайте попингаем соседа, и если у нас сосед пингается, то мы в up. Если сосед не пингается, то мы в down. Для того, чтобы это сделать, нам нужна какая-то сущность, которая будет пингать соседа и запоминать результаты. В EOS, в обычном EOS XE эта штука называется зонды IPSLA, и, соответственно, мы указываем, что нас будут интересовать зонды 1, 2, 3. Ну, и предварительно надо, конечно, зонд создать и запустить, чтобы он начал пингить соседа. Мы из глобального конфига указываем IPSLA 1, 2, 3. Мы создаем зонды номер 1, 2, 3. Переходим в контекст IPSLA, это создание нового зонда.

Мы еще в этот момент не указали, что это будет за зонд и как он будет работать. Ну, указываем, что этот зонд будет типа ICMP echo и указываем IP-шник. Это указание, что мы будем пингать определенного соседа. Если сосед в API, сосед пингается, то, значит, и зонд в API. Если сосед перестает пингаться, то, значит, зонд будет down. Надо будет указать, как часто пингать соседа, потому что, если вдруг у нас сосед быстренько, допустим, пропал из сети, а потом вернулся, это не должно быть основанием для того, чтобы у нас зонд плохо себя чувствовал. То есть отдельные проседания по пингам не должно вызывать моргание зонда. И мы указываем frequency 5, значит, раз в 5 секунд будем пингать соседа. И нужно будет, здесь неправильно написано, 1, 2, 3, вот, нужно будет этот самый зонд запустить. Мы указываем, вообще, это команда глобального конфига, IPSLA, schedule, дальше, номер зонда, live forever, start time now. Ну, я обычно заду наперед, делаю start time now, live forever. Типа начни сейчас,

никогда не останавливайся. Этот очень простой конфиг заставляет циску создать зонд номер 1, 2, 3, который будет пингать соседа раз в 5 секунд. Если пинг не проходит, сосед выключился из сети, значит, у нас зонд падает в down, значит, у нас объект трекинга 3, 2, 1 тоже упадает в down. Если пинги появляются, зонд переходит в up, объект трекинга тоже переходит в up. Та же самая история и в UXR. Мы создаем в контексте IPSLA зонд, указываем, что у нас номер зонда будет 1, 2, 3, указываем его тип, что мы будем просто пингать соседа, указываем, с какого адреса, какой адрес будем пингать, как часто, допустим, раз в 60 секунд. Дальше указываем частоту, не частоту, а когда, как это, расписание работы зонда, то же самое, как было IPSLA, schedule 1, 2, 3, live forever, start time now. Здесь то же самое,

schedule operation 1, 2, 3, start time now, live forever. Начни сейчас, никогда не останавливайся. После того, как зонд запущен, можно его использовать в объекте трекинга, указываем, что у нас есть объект трекинга, ну, допустим, назовем его T1, можно имена давать. Эти имена, на самом деле, могут быть какие-то вполне интересные, вполне говорящие, то есть вы можете сказать, что у вас есть объект зонда, который отслеживает интернет, и этот зонд, не зонд, а объект трекинга интернет будет проверять, что у вас, допустим, пингается шлюз, и дополнительно к этому работает DNS, и дополнительно через этот шлюз можно там взять из сайта www.google.com скачать какую-то веб-страничку. Ну, это, к примеру, обычно такие штуки настраиваются именно, вот как я рассказываю, про в сетях предприятия. Если говорить про провайдерские сети, то там, конечно, никто друг друга особо не пингует, там настраиваются более защищенные зонды, которые будут, например,

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

будет допустим для того, чтобы зонд оставался в апе. То есть, если вы там указываете, что мы отправляем пять пингов и расхождение во времени между ними в тотель, не в тотель, а именно во времени туда-сюда а он trip time небольшое, то у вас зонд будет в апе. В реальности лучше, конечно, использовать такие типы зондов, чем просто обычный пинг соседа. Вот. Ну, да, в XR у нас указываем ICMP echo, кто кого, как часто, запускаем, и объект отслеживания tracking T1 указываем, что будет ссылаться на операцию 1.2.3 IPSLA, и если результат операции 1.2.3 будет, что сосед доступен в речабилити, то, соответственно, мы говорим, у нас tracking T1 тоже будет в апе. Дальше ссылаться уже можно на tracking T1. Еще раз подчеркну, что в реальности это все выглядит немножко иначе. Здесь показаны просто самые коротко

настраиваемые зонды, самые компактно настраиваемые зонды. Реальность такова, что там, как правило, настраивается достаточно сложная конструкция, когда у вас один объект отслеживания ссылается на несколько других объектов отслеживания, говорит, что у нас для работы интернета в сети предприятия нужно, чтобы работал DNS, чтобы работал HTTP, чтобы с Яндекса скачивались странички, чтобы HTTP получил адрес, чтобы маршруты прибегали. То есть вы можете действительно настроить там весьма глобальные правила, если захотите. Но настройка IPSLA сильно выходит за пределы нашего курса. Так. Далее. После того, как вы настроили трекинг, вы дальше должны будете указать, что с этим трекингом делать. Если мы говорим про использование трекинга в протоколах FHRP, то мы создаем сначала группу, мы указываем, как мы в этой группе работаем, а потом указываем, соответственно, что делать, если у нас теряется связь со внешним миром. Вот пример.

У нас есть HSRP. Все настройки, которые HSRP на интерфейсе даются, я думаю, что вы все сильно помните, они имеют слово standby. Ключевое слово standby в настройке интерфейса на EOS обычном. Указываем в настройке Gigabit 001 или в настройке VLAN или в настройке субинтерфейса, вот где у нас IP-шник висит. Указываем standby, дальше номер группы, IP и IP-адрес. Этот IP-адрес будет соответствовать виртуальному IP-шнику, который будут разделять все роутеры между собой. Если вы хотите, вы можете на одном узле задать этот виртуальный IP-шник, а на остальных узлах его не задавать. То есть, как только у вас появляется первый активный роутер, который знает, какой IP-шник он будет работать, все остальные узлы будут тоже знать, какой виртуальный IP-шник соответствует их группе. То есть, в принципе, достаточно на одном роутере сказать IP 10.0.254, а на всех остальных просто сказать standby один IP. Как только обладатель виртуального IP-шника станет активным,

он начнет рассылать с лоб-пакеты, все остальные тоже узнают, что виртуальный IP-шник тоже 10.0.254. Равным образом MAC-адрес тоже можно поменять. По факту, естественно, что абоненты будут использовать вот этот вот IP-шник в качестве шлюза по умолчанию. Мы для этого и заводим этот самый IP-шник, чтобы его раздавать в качестве шлюза по умолчанию. Но по факту абоненты никогда не будут посылать пакеты на этот адрес на 10.0.254. IP-пакеты никогда не будут иметь этот адрес в качестве адресного значения. адреса есть эта возможность его разрешить в MAC-адрес. То есть у нас есть абоненты. Мы на абонентах прописываем этот IP-10.0.254 как шлюз по умолчанию. Абонент, когда просыпается, когда хочет какой-то отправить пакет в сеть по маршруту по умолчанию, он орет нам всю сеть. У кого из вас IP-шник 10.0.254, скажите свой MAC. Нам возвращается виртуальный MAC-адрес, который в HSRP первой версии будет иметь вид 0.0.0.0.0.C.

0.0.0.0.0.0.0.C. 0.0.0.1. Для первой группы. Нужно будет хорошо знать этот MAC-адрес. Может быть, не сейчас, может быть, на курсе по свитчингу. 0.0.0.0.0.0.C. Хорошо известная O.U.I. Сиски. 0.0.7. А.C. Хорошо известный суффикс HSRP первой версии. И 0.1. Это номер группы. Вот такой вот MAC-адрес соответствует виртуальному IP-шнику первой группы HSRP первой версии. Ну, соответственно, если вы хотите, вы можете поменять этот MAC-адрес, сказать, что вы желаете обслуживать виртуальный IP-шник другим виртуальным MAC-ам, он точно так же будет разъезжаться по сети. Дальше указываем приоритет. Чем больше приоритет, тем лучше роутер станет с точки зрения выборов запасного роутера. Как уже было сказано, в HSRP все выборы проходят только за роль запасного, то есть за роль основного выборов и бывает. Основным роутером можно стать только одним-единственным образом, это стать запасным и захватить роль

основного. Для того, чтобы захватить роль текущего основного, если основной уже есть, он себя нормально чувствует, он рассылает хотя бы какие-то hello-пакеты, может быть, не очень выгодные, но тем не менее рассылает, в том случае HSRP штатно ничего не перехватывает, никакую роль. Но вы можете указать команду standby, дальше номер группы preempt, и это заставит ваш роутер standby, если он увидит, что приоритет текущего активного роутера в явном виде меньше приоритета запасного, то запасной в этом случае захватывает власть. Он говорит, я теперь буду запасным, а ты, текущий основной роутер до настоящего момента, будешь просто обычный роутер, никто. Но он в этом случае, если у него приоритет будет достаточный, может за освободившуюся вакантную роль standby подраться, потому что standby же освободился, значит, можно объявить перевыборы. Ну и вы должны будете сказать, что да, ваш приоритет сейчас может быть 105, если вы активный роутер, потому что вы только что

захватили власть у кого-нибудь, у вас есть приемник, вы захватили власть со своим приоритетом 105, строго большим, чем приоритет кого-то другого активного в канале. Но дальше вы понимаете, что у вас, например, сосед, который является шлюзом во внешний мир, перестал пингаться, у вас есть объект трекинга 1, 2, 3, и вы говорите, понижаем приоритет, у нас сейчас приоритет 105, мы приоритет, в случае, если у нас объект трекинга 1, 2, 3 переходит в даун, понижаем его на 20. Можно не писать декремент 20, можно просто сказать трек 1, 2, 3. В этом случае штатный приоритет проседает на десятку. То есть на экзамене на этом могут быть вопросы, по идее, мало вероятно, но могут быть. Вот штатный декремент 10. Если вы указываете в явном виде, то проседает вот настолько, насколько вы сказали. Дальше, в предположении, что у текущего запасного роутера приоритет строго больше, чем тот, который у вас получился. Например, у вас приоритет сейчас 105, после того, как сосед перестал пинуться, он стал prototype 75.

Вот в предположении, что у текущего запасного роутера приоритет строго больше, он в этом случае власть захватывает. Приоритета обязан быть строго больше при захвате власти. Дело в том, что если вы захватываете власть, и ваш приоритет хотя бы такой же, то получается, что два узла будут одновременно друг у друга эту самую власть перехватывать, что нехорошо. Но если вот у вас ситуация, когда от текущего активного роутера приходит HelloPacket, и в нем написано, что у него приоритет какой-то один, а у вас у стендбая приоритет какой-то выше, прямо строго выше, например, у него 100, а у вас 101, то в этом случае вы сможете захватить власть. На этапе выборов, когда просто идут обычные выборы стендбая, выигрывают тоже роутеры, у которых приоритет больше, а если таких роутеров несколько, то выигрывает выборы стендбая, роутер, у которого больше IP-шник, то есть пара IP-адрес плюс приоритет. Далее, далее, далее, далее. Есть команда show standby brief, которая покажет в табличном виде,

какие интерфейсы у вас, в каких группах будут какие виртуальные IP-шники разыгрывать. Показывается, что у нас вот есть приоритет, интерфейс Gigabit 001, который в первой группе пытается подраться за адрес 10.00254. Ну и стоит, показывается, что ему удалось-таки действительно подраться за этот виртуальный IP-шник, он стал активным. Справочно показывается, кто активный, кто запасной. В HSRP все узлы знают, кто активный, кто запасной, потому что каждый из них посылает хеллоу-пакеты. Каждый из активного и запасного. То есть обычный роутер и никто, они просто сидят на пуперон, ничего не делают. Они начинают показывать голос только тогда, когда идут перевыборы заранее запасного. Вот тогда, когда просто идет нормальная работа, активный роутер посылает хеллоу-пакеты. Из-под виртуального мака, напомню, что это важный момент, что из-под виртуального мака он посылает пакеты, тем самым свитчи всегда имеют актуальную таблицу коммутации. В сторону этого виртуального мака они смотрят, откуда приходят кадры.

Ну и запасной роутер посылает хеллоу-пакеты от своего собственного мака. Используют они 224.002 для HSRP первой версии, 224.00102 для HSRP второй версии. Так, ну и показывается приоритет, текущий активный, текущий приоритет с учетом декринентов. И показывается, есть ли приемтинг. То есть это как раз вот флажочек показывает очень важную вещь. У вас в сети, скорее всего, приемтинг должен быть везде, но по умолчанию он и назначается. То есть его надо ручками назначать. В EOS XR настройка чуть-чуть отличается. То есть если все предыдущее, что мы смотрели в EOS обычном EOS XR, было похоже, то здесь настройка такая, другая немножко. У нас сначала нужно запустить контекст роутера HSRP. То есть как будто бы мы запускали, там, не знаю, OSPF, BGP и прочее. В EOS обычном, например, если мы запускаем BGP,

то все настройки BGP фактически относятся к BGP, и они хранятся в контексте роутера BGP. Это удобно, потому что если у нас есть обычный EOS, и у нас есть конфигурация, мы смотрим там show run, он показывает сначала там настройку интерфейса, настройку другого интерфейса, третьего интерфейса, потом блок настройка OSPF и блок настройка BGP. И мы можем сказать show run section router BGP. Покажи нам типа все, что относится к BGP. Ну вот в случае с HSRP, например, если мы хотим посмотреть все, что относится к HSRP, мы должны заказывать отображение конфига на всех-всех-всех интерфейсах. Потому что чуть-чуть настройка HSRP в EOS обычно есть на одном интерфейсе, на другом интерфейсе, на третьем интерфейсе. Нет какого-то центрального места в конфиге, которое бы отвечало только за настройку HSRP, в котором бы не было ничего лишнего. В EOS XR эту логику изменили. Соответственно, все, что касается HSRP, вынесено в отдельный блок конфигурации. И, соответственно, вот роутер HSRP как раз этот блок конфигурации и задает.

Вот. Дальше, после того, как мы запустили сам контекст HSRP, мы должны будем указать, на каких интерфейсах мы работаем. То есть интерфейс там такой, интерфейс такой. И HSRP, если мы говорим про HSRP первой версии, может работать только с IPv4. HSRP второй версии может работать с IPv6. Можно переключить на интерфейсе версию HSRP. Ну, здесь я не помню точно, но я предполагаю, что прямо в настройке вот здесь, в настройке интерфейса, можно указать версию 2. Гипотеза у меня такая есть. Далее. Указываем после того, как мы переключили HSRP на интерфейсе в первую или вторую версию, по умолчанию первая, мы указываем адресные семейства, адрес фэмили, допустим, IPv4, и попадаем внутрь контекста адрес фэмили IPv4. То есть приглашение к ководу здесь, смотрите, сначала конфига HSRP, потом конфига HSRP if, потом по-хорошему должно было быть конфига HSRP if IPv4,

но здесь уже просто решили сократить все дело. Приглашение к ководу сокращенное. И когда мы указываем, что у нас есть HSRP с номером группы 1, по-хорошему приглашение должно было быть конфига HSRP if IPv4 группа 1, но оно сокращается до просто конфига HSRP. GP — это номер группы, в смысле группа. И в настройке группы мы даем уже все те же самые настройки, которые у нас были для ИОСа обычного. Указываем адрес, приоритет, преемптинг, трекинг. Ну, трекинг настраивается не просто трек 1, 2, 3, декремент чего-то, а трек-объект. Дальше название объекта отслеживания и просто циферку декремента. Опять же, если не писать, будет декремент 10. Уже нет в явном виде команды standby, то есть для того, чтобы работать с HSRP в ИОС-XR, нужно будет везде писать именно HSRP. И команда show.hsrp показывает то же самое, что show.standby.brief в обычном ИОСе.

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

То есть можно, но не нужно. Сама логика VRRP, она не предполагает, что вы внезапно можете просесть по приоритету, но при этом не отказываться от роли мастера. Как уже было сказано, VRRP позволяет использовать виртуальный IPшник, равный физическому IPшнику мастера. То есть если виртуальный IPшник соответствует физическому IPшнику какой-нибудь ноды, то эта нода автоматом получает приоритет 255. Вы ручками физически выставить 255 приоритет не можете никаким образом. То есть это единственный способ получить такой приоритет, это иметь такой же IPшник, как виртуальный IPшник в группе. Ну и, соответственно, у вас показывается show-vrp-brief, какой интерфейс, какая группа, какой виртуальный IPшник, кто мастер, кто мы, кто мастер, включен ли приемтинг, вот это вот, это вот то, что там раньше была буквка P, здесь при.

Какой приоритет у нас? И вот загадочная вот эта штука, oven. Oven – это значит, что у нас приоритет 255, что мы обладатели этого IPшника. Так, далее. Если мы хотим настроить vrp в iOS XR, то делается это, опять же, похожим образом на HSRP. Запускаем контекст роутер vrp, указываем, что vrp у нас будет работать на интерфейсе gigabit 001, указываем, что мы работаем с адресным семейством, там, IPv4, и указываем, что мы запускаем группу vrp1 на интерфейсе 001 для IPv4, и указываем, что у нас тут какие-то настройки даются. Опять же, адрес можно задать, приоритет можно задать, объект отслеживания можно задать. Все то же самое, как для HSRP. Один в один. Приглашение к вводу здесь уже более изощренное, то есть config.vrp запускаем, сам vrp, config.vrp интерфейс.

Переходим в адресное семейство. Config.vrp адрес family. Это мы находимся внутри настройки, адресного семейства IPv4 на интерфейсе, Gigabit 001 настройки vrp, и дальше запускаем группу vrp1. И у нас vrp – это фактически виртуальный роутер получается. Поэтому здесь уже показывается не то, что у нас группа HSRP, а config.vrp virtual router. Тот самый virtual router, который соответствует группе номер один, который соответствует адресному семейству IPv4 в настройке интерфейса 001 на нашей железке. Вы можете встретить в настройке других вендоров, когда вы с vrp работаете, как то, что у вас vrp фактически настраивается как отдельный интерфейс. Иногда так и бывает, что у вас, типа, есть роутер, у него есть физический интерфейс такой, сякой, пятый, десятый, и еще есть отдельный интерфейс, который как бы выглядит как физический, ну, как виртуальный интерфейс vrp. Вот. И вот на этот vrp можете повесить IPшник, например. Но в сути это не меняет.

То есть, да, в CISC этого не происходит, у нас не порождается новый интерфейс. Но если мы говорим про оборудование некоторых других вендоров, то вы включаете vrp, вы указываете, что на каком-то интерфейсе у нас он будет работать с определенным приоритетом, с определенным виртуальным адресом. Простите, виртуальный адрес вы не назначаете. У вас появляется новый виртуальный интерфейс, вы на этот интерфейс назначаете IPшник. То есть, допустим, у вас есть там интерфейс здесь вот, не знаю, гигабит 0.1, и вы указываете, что у вас есть vrp, виртуальный интерфейс, который работает на гигабите 0.1, и вы на него вешаете какой-нибудь IPшник. Но обычно, если мы говорим про IPv4, у вас на вот этом интерфейсе висит адрес, не знаю, 10.0.0.1.24, а вот сюда вы вешаете там 10.0.0.254.32. Как-то вот так. Так. В циске вот этого всего нету. Так что это я вам так чисто ради смеха рассказал.

Да. Showvrp на XR показывает, в общем, все то же самое. Интерфейс, на котором мы деремся, за что деремся, кто мы, кто мастер, есть ли приемтинг у нас, обладаем ли мы настоящим этим IPшником, какой у нас приоритет и виртуальный router ID. GLBP на XR не поддерживается, поэтому настраивается он только на EOS, обычном и EOS XE. И, соответственно, для включения GLBP нужно будет задать, во-первых, группу и виртуальный IPшник, во-вторых, приоритет и приемтинг. Они, в принципе, не обязательны их задавать, потому что они используются только при выборах AVG-шки, а AVG-шка-то, в общем-то, ни на что не влияет. То есть, ну, вы, наверное, захотите, чтобы у вас AVG-шкой был роутер, который наиболее стабильный, наиболее, скажем, дольше живет, самый долгоживущий роутер в сети. Поэтому приемтинг там вам не сильно будет нужен.

Но гипотетически его можно будет включить. И дальше вы должны будете назначить веса. Именно весом будет регулироваться то, кто будет получать ролик фарвардеров, потому что у нас есть одна роль это AVG, это тот, кто будет отвечать ARP-ами на запросы пользователей и будет раздавать роли AVF-ок. И будет вот четыре или менее ролей фарвардеров, AVF-1, AVF-2, AVF-3 и AVF-4. Если какой-то роутер теряет связь со внешним миром или теряет часть связанности со внешним миром, он должен будет просесть не по приоритету, для того, чтобы добровольно отдать роль диспетчера, что в общем решено смысла. А он должен будет просесть именно по весу, а не по приоритету. И настройки на интерфейсе будут, опять же, похожие на HSRP. Это будет не случайно, учитывая, что GLBP основан на HSRP второй версии. Вы указываете все то же самое, как в HSRP указывали standby, только GLBP. GLBP-1, IP чего-то. GLBP-1, проверить чего-то. GLBP-1 приемт. Вот это вот можно не указывать,

оно не влияет на результат. И дальше указываете GLBP-1, weighting, то есть размечаем веса, штатный вес. Чем больше вес, тем больше трафик обслуживает виртуальный роутер, если мы раздаем клиентам MAC-адреса AVF на AVG-шке с учетом этих самых весов. Вы можете это сделать, это по умолчанию не происходит, но это можно сделать. То есть если вы знаете, что у вас есть один, допустим, жирный роутер и два мелких, вы можете сделать так, чтобы трафик на эти роутеры приходил бы в определенной пропорции. Но трафик сам, вот вы гарантировать не можете, но вы, по крайней мере, можете гарантировать, что количество клиентов, которые будут пользоваться разными роутерами, оно будет плюс-минус километр распределяться в определенной пропорции. То есть к вам приходит это роутер 1, это роутер 2, это роутер 3. Вы указываете вес, например, одному роутеру 200, другому 100, третьему тоже 100. И когда приходит первый компьютер абонента, он спрашивает у кого из вас вертуальный IP-шник какой-то,

ему выдают IP-адрес, не IP-адрес, в ответ на IP-адрес ему выдают MAC-адрес роутера номер 1. Приходит другой клиент, он говорит, я клиент номер 2, какой IP-шник виртуального роутера, точнее IP-шник, то он знает, какой MAC-адрес виртуального роутера с определенным IP-шником. Ему снова возвращают MAC-адрес первого фарвардера. Приходит третий клиент, ему говорят, а вот тебе второй MAC-адрес. Приходит четвертый клиент, и ему там третий MAC-адрес. Они все задавали один и тот же запрос по протоколу ARP, но AVG-шка раздает MAC-адреса AVF клиентам в соответствии с пропорциями с весами. Если у одного роутера вес 200, то он получит в два раза больше ответов клиентов, чем два других с весами 100. И вот waiting 100 как раз указывает, что стартовый вес, начиная с которого идет работа, это вес будет 100. Ну а дальше может этот вес проседать. Проседать вес может за счет приоритетов. Если вы хотите, вы можете отказаться от роли виртуального фарвардера,

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

если ваш приоритет обратно повышается до определенного значения. Вот upper 50 указывает, что до тех пор, пока ваш вес ниже 50, вы роль AVF-а своего обратно не забираете. Так. Можно указать, соответственно, за счет чего у вас вес будет проседать. Опять же, команда GLBP, номер группы waiting. Дальше указываем, чего отслеживаем и насколько падаем по декременту. GLBP фактически будет указывать, что у нас есть много разных ролей. И когда мы заказываем showGLBP brief, показывается, что у нас есть роль AVG. Это кто будет диспетчером. И показывается за роль AVG, что мы на интерфейсе F00 подрались. Как я узнал, что это именно роль AVG? Потому что разыгрывается виртуальный IP-шник, от которого по факту используется только ARPA. Поэтому, да, вот первая строчка — это AVG. Группа у нас номер один. Приоритет при выборах AVG у нас используется.

И тот роутер, у которого приоритет был самый большой, он, соответственно, стал активным роутером. В нашем случае мы активный роутер за роль virtual gateway. То есть AVG. Активный роутер мы, запасной роутер 1002. Активный роутер 1002. Дальше у нас есть роли AVF первого, AVF второго. AVF 1 и AVF 2. Вот, соответственно, за роль первого фарвардера мы подрались, но проиграли эту битву. Мы в состоянии листом сидим и ждем, пока AVF 1 сдохнет. Обладатель роли AVF 1 — это IP-шник 1002. Он располагает адресом 0007B4 000101. Опять же, виртуальные маки GLBP хорошо бы знать. 0007B4 — это OU-ишка, соответствующая цисковскому GLBP. Дальше 0001 — это у нас номер группы.

И 01 — это номер фарвардера. То есть вот это групп, а вот это virtual forwarder. А это OU-и циска. Так, пардон. Так. Соответственно, за роль второго фарвардера мы выиграли выборы. Мы активный роутер. Располагаем вот этим вот виртуальным маком. Активный роутер мы. Стэндбай роутера за роли фарвардеров нету. То есть есть только активный роутер, который получил роль фарвардера. И в случае, если он перестанет выполнять свою функцию, то AVG будет назначать, кому переходит его роль. То есть у нас за роль диспетчера выбирается запасной роутер. Если текущий диспетчер дохнет, запасной немедленно захватывает у него власть. А в случае вот с фарвардерами, там у нас идет именно переназначение власти со стороны управляющего центра.

Что касается HSRP. В HSRP, в принципе, есть штатный механизм повышения отхазоустойчивости шлюза. То есть если вдруг мы в IPv6 используем автоматическое назначение IP-адресов, мы используем слаг на хостах, то два узла, которые будут раздавать один и тот же attach-in-prefix, они будут тем самым указывать на то, соответственно, что узлы должны... от тех узлов, которые присылают роутер анонсмент, они должны будут добавить, соответственно, link-log к адресу отправителя в качестве шлюза по умолчанию. Для этого в отправляемых роутер анонсментах сообщениях есть поле роутера lifetime. Если оно выставлено в ноль, то роутер не рекомендует добавлять его в качестве шлюза по умолчанию. А если вы роутер lifetime выставляете в определенное значение, то вот на такое количество секунд

роутер будет добавлен в качестве шлюза на конечных абонентах. Предположение, что следующий роутер анонсмент придет скорее, чем это поле роутер lifetime закончится. Но, соответственно, если у вас есть два роутера, то они оба могут быть... могут порождать маршрут в таблице маршрутизации. Вы в этом случае можете указать приоритет, какой именно из двух роутеров будет использоваться в качестве основного шлюза по умолчанию, а какой нет. Можно будет использовать более хитрый механизм, когда вы можете на уровне... на уровне хостов назначать IP-адрес шлюза вручную. И вы не обязаны делать это через link-local-адреса. Чаще всего, если мы настраиваем маршрутизацию на конечных абонентах, мы видим, что link-local-адрес будет в качестве шлюза по умолчанию прописываться. Но мы не обязаны использовать маршрут по умолчанию обязательно на link-local-адреса. Мы можем использовать указание, что шлюзом будет некий маршрутизируемый IP-шник.

И, формально говоря, мы можем использовать для этой цели anycast-овый IP-шник все роутеры в пределах канала. То есть это такой адрес, у которого network ID будет... Ну, да, network ID будет такой же, как у всех остальных узлов. Левая часть, собственно говоря, совпадать будет с адресом сети. А правая часть интерфейса ID будет все нули. То есть вот такой вот адрес, который состоит фактически из всех таких же битов, как адрес самой сети, будет называться anycast all routers в пределах канала. И, соответственно, если вдруг вы отправляете запросы, у кого такой IP-шник, скажите, в Mac, то вам будет вращаться MAC-адрес живого роутера. Дальше. Если вы используете IPv6, в штатном IPv6 есть механизм отслеживания состояния конечных узлов. То есть если вы даже используете Ethernet, но вы используете поверх Ethernet IPv6, если вы ведете взаимодействие с каким-то узлом, с каким-то роутером, например, пересылая ему пакеты дальше в сеть назначения, и вы отправляете данные соседу,

а сосед ничего вам не присылает, сам IPv6 стэк может что-то заподозрить. То есть, еще раз подчеркну, это не Ethernet вам вернет указание, что такой-то MAC-адрес будет недоступен. Это в IPv6, если вы понимаете, что вы отправляете данные шлюзу по умолчанию, а от шлюза никакие данные не приходят, вы можете Neighbor Discovery отправить этому шлюзу вручную. Ну, как вручную, автоматически. Этот механизм будет называться Dead Per Detection. Сейчас. Не перепутал я чего-нибудь. Ну, в общем, да, смысл там будет именно такой, что вы отправляете Neighbor Discovery сообщение соседу, и если сосед вам не возвращает Neighbor announcement в ответ, то, значит, сосед сдох. И вы в этом случае не используете его в качестве шлюза по умолчанию, вы пытаетесь перескочить на другой шлюз. Все это как бы в IPv6 есть. Все оно работает, но оно обеспечивает очень медленное переключение между двумя роутерами. Поэтому, если мы хотим обеспечить переключение за срок там меньше секунды,

то мы должны будем использовать протоколы FHRP так же, как мы это делали с IPv4. То есть штатные механизмы переключения между роутерами в IPv6, они работают медленно, они работают там за десятки секунд, что в современных сетях это, ну, недопустимо. Особенно, если вы провайдер, и вы, да, вы, может быть, испытываете какую-то аварию, но, тем не менее, да, все равно у вас роутер. Один, который становится недоступен, он по-прежнему числится в качестве шлюза на некоторых узлах. Если мы хотим использовать HSRP, то время переключения будет такое же, как на IPv4, то есть это субсекундные переключения будут, как правило. Для того, чтобы субсекундные переключения достичь, нужно будет настраивать таймеры, но, тем не менее, да, мы указываем на каждом протоколе два таймера. Как часто отправлять хэллоу-пакеты и через сколько признавать соседа трупом, если он перестает просилать эти самые хэллоу-пакеты. Штатные таймеры для HSRP — 3 на 10. Штатные таймеры для VRRP — 1 секунда хэллоу-таймер, 3,5 секунды дэт таймер.

Если мы должны будем использовать HSRP для IPv6, то в этом случае мы должны будем использовать HSRP только второй версии. Первая версия не умеет работать с IPv6, то есть вторая версия умеет работать и с IPv4, и с IPv6, но у нее другой формат пакета и у нее другие MAC-адреса. Если в IPv4, в HSRP первой версии я вам рассказывал, что MAC-адреса будут 0, 0, 0, 0, 0, 0, c, 0, 7, a, c, 0, там, x, где x — это номер группы, то в, ну, вообще, срок говоря, да, x, x — последние два 16-речных символа, это один байт, это номер группы, то в случае с HSRP второй версии это будет, я, конечно, боюсь ошибиться, но 0, 0, 0, 0, 0, c, 9, f, по-моему, и дальше три символа номер группы. То есть три символа — это 12 бит, в HSRP второй версии группы у нас 12-битовая.

Вот насчет вот этой части я… Как-то у меня сомнения есть. Давайте-ка я проверю. Нет, не ошибся. Все правильно. Такой MAC-адрес, который я написал, вот он и есть. Надо же. Вот. И, соответственно, естественно, что если у вас есть два узла в одной сети, один будет работать с HSRP первой версии, HSRP в версии 1, а другой узел будет навстречу ему посылать сообщение HSRP в 2, они никак между собой не подружатся. То есть это два разных протокола, они используют разные MAC-адреса, они используют все разное. И они не смогут вести взаимодействие между собой, они не смогут дружить между собой, поэтому если у вас с одной стороны HSRP в первой версии, а с другой стороны HSRP в второй версии, каждый из них будет считать, что он в группе только один. И у вас по факту будут две разные группы. Даже если у этих групп будут одинаковые номера, то есть если вы скажете, что у вас HSRP первой версии первая группа,

и HSRP второй версии тоже первая группа, это все равно будут две разные группы. Две разные группы с номером один, которые не совместимы между собой. В каждой группе у вас будет выбран активный роутер, который будет обслуживать свой IP-шник. Для того, чтобы HSRP для IPv6 у вас работал, скорее всего у вас в этом же канале работает и IPv4, потому что скорее всего у вас на абонентов будет смотреть DualStack. И в этом случае скорее всего у вас будет на интерфейсе указываться стендбай дальше какой-то номер группы, IPv4 адрес и IPv6 адрес. То есть все те же самые настройки, которые мы делали для IPv4, они все становятся точно так же актуальны, но мы должны будем использовать HSRP второй версии, переключаем интерфейс команды standby version 2, не группу переключаем во второй режим, а целиком интерфейс. И мы используем отдельную группу для работы с IPv6. То есть указываем, допустим, standby 1 IP такой-то, standby 2 IPv6 такой-то.

Мы можем указывать, что у нас HSRP будет работать либо с IPv6 link-local адресом. В этом случае вы в явном виде указываете, какой link-local адрес вы хотите использовать. Либо вы указываете автоконфиг, и тогда у вас адрес автоматически будет назначен. Или вы можете использовать IPv6 префикс. То есть сказать, у нас есть адрес, который нужно будет в явном виде задать на интерфейсе, и этот адрес будет маршрутизируемый. В случае с link-local адресом, естественно, адрес должен начинаться на FE8. Вот пример. У нас есть, соответственно, два роутера. Они между собой связываются по прямому проводу. Ну, не по прямому проводу. Здесь коммутатор есть, и в этом коммутаторе там абонент сидит. К примеру, да? И, соответственно, они договариваются между собой, что они будут использовать link-local адрес FE80.2.1. И на абонентах, у нас на конечных абонентах,

именно этот link-local адрес будет использоваться в качестве шлюзопомолчания. Далее. Далее, далее, далее. Если мы хотим настроить то же самое на роутере EOS XR, то настраивается все, в общем, очень похоже на IPv4. Единственное, что вот адрес фэмили у нас будет не IPv4, а IPv6. Если вы заказываете адрес фэмили IPv6, это автоматом означает, что на интерфейсе у вас работает это XRP второй версии. То есть здесь адрес фэмили IPv6 не позволяет вам использовать XRP первой версии, а интерфейс автоматически проключается в версию 2. Дальше мы указываем HsRP номер группы. То есть здесь вот у нас 2 — это номер группы. Не номер версии, а номер группы. И здесь то же самое 2 — это номер группы. Можем указать адрес linklocal.autoconfig. Можно указать адрес global, какой-то конкретный IPшник. То есть в обоих случаях мы можем получить, в общем-то, такой же эффект, как и в случае с EOS обычно.

Ну, адрес linklocal.autoconfig удобен тогда, когда у вас работает Slack. У вас два роутера придумывают одинаковые linklocal-адреса, и тот роутер, который будет активным, он будет рассказывать про то, какой у него виртуальный IPшник будет использоваться. Далее, далее, далее, далее. Если вы хотите использовать маршрутизируемый адрес, ну, адрес global, как понятно. То есть все те же самые действия можно будет прописать. Точно так же прописываются объекты трекинга. Никуда от этого не приходится уходить. Точно так же прописывается приемтинг. Точно так же прописывается приоритет. То есть эта группа — совершенно самостоятельная группа. В ней точно такие же все настройки нужно делать, как и для IPv4. Если вы работаете с VRRP, то в IOS, в обычном IOS, это делается нетривиально. По умолчанию IOS работает с VRRP второй версии. Если вам нужно переключить роутер в VRRP третьей версии, то у вас это не просто какая-то одна команда, которая заставляет VRRP работать иначе, как сейчас RP.

Зашли на интерфейс и сказали, а ну-ка поработай во второй версии. Вот в VRRP это не так. VRRP вы указываете в глобальном конфиге команду fhrp version vrp v3. После чего у вас на интерфейсах становится другой режим конфигурации VRRP. То есть вы заходите на интерфейс, на котором вы хотите включить VRRP, и указываете команду VRRP, номер группы, адрес family, и указываете адресное семейство, с которым вы хотите работать. VRRP третьей версии поддерживает IPv6, так что если вы хотите включить VRRP третьей версии, то, вероятно, это делается именно для того, чтобы IPv6 у вас работал. Указываете адрес family IPv6, указываете, что вы хотите, например, виртуальный IP-шник получить, FE82.2001, указываете приоритеты, таймеры, трек, ну все то же самое указываете, но в контексте конфиг if VRRP. То есть обратите внимание на то, что здесь конфигурация становится похожа на XR.

Мы заходим в контекст настройки VRRP, и дальше в этом субконтексте начинаем работать уже с группой, заточенной под конкретное адресное семейство. Вот. Синтакс из каждой отдельной команды остался примерно таким же, но вот по большому счету, если вы понимаете, как устроено здесь все, то и на XR вы тоже можете перепрыгнуть без каких-либо проблем. Если вы хотите, вы можете в настройке интерфейса сказать, что следует работать и с IPv4, и с IPv6. То есть если вы настраиваете IPv6, то вы используете VRRP третью версию. Если вы хотите в VRRP третьей версии использовать и группу IPv4, и группу IPv6, никаких проблем у вас такая возможность есть. Вы можете отдельно запустить группу одну для IPv4, группу другую для IPv6. Но если вы работаете с группой IPv4,

вы можете сказать рядышком VRRP v2. И тогда для работы по IPv4 у вас будут отправляться пакеты двух разных протоколов. И VRRP второй версии, и VRRP третьей версии. Иногда это бывает нужно. Ну, редко, конечно, но гипотетически. Например, в ситуации, если у вас для работы по IPv4 надо использовать VRRP v2, а для работы по IPv6 надо использовать VRRP v3. Ну, то есть мало ли вдруг. На XR делается все предсказуемо. Роутер VRRP. Заходим в интерфейс, заходим в адресное семейство, заходим в номер группы, и дальше все конфиги делаем те же самые, которые у нас были. Так же, как и в случае с HSRP, адрес link-local, автоконфиг. Адрес global, какой-то там может юзерим адрес. Вот. Что касается GLBP. GLBP. И XR, как уже говорилось, для GLBP не работает. То есть, наоборот, GLBP для XR не работает. Он только на EOS, EOS XE обычных,

и только на жирных платформах. В GLBP проблемы имеют как раз именно то, что непонятно для кого позиционируется, поэтому для старших жирных роутеров провайдерских просто решили его не делать. Незачем. Не пригодился. Ну и, соответственно, GLBP для IPv6 тоже, как следствие, есть только на EOS обычных. Причем вы должны будете знать, что даже для EOS обычных именно GLBP, именно для IPv6 есть тоже не везде. То есть, может быть такое, что у вас есть GLBP для IPv4, а вот GLBP для IPv6 просто нет. Настройка тоже самая, как HSRP, VRRP и прочее. То есть, мы указываем ключевое слово, номер группы, IPv6, и дальше указываем адрес. Та же самая история. Либо указываем в явном виде link-local адрес, который хотим получить, либо указываем автоконфиг. GLBP не позволяет использовать маршрутизируемые адреса. Такая его особенность небольшая. Ну, он может придумать себе адрес автоматически. Так же, как и в случае с HSRP,

мы должны будем разносить IPv4 и IPv6 по разным группам. То есть, у нас должна быть одна группа для IPv4, другая группа для IPv6. Давайте попробуем это все дело поконфигурякать. У нас сейчас наши железки сброшены в состоянии по умолчанию, поэтому нужно будет их сейчас перенастроить. Что нам потребуется? Во-первых, ну-ка, действительно ли они сброшены? Может быть, они не до конца сброшены? Show run. Да, они как-то не до конца сброшены. То есть, часть конфигурации сохранилась, часть сбросилась. Давайте сбросим все целиком, благо как раз есть возможность потренироваться, посбрасывать конфигу. Для того, чтобы сбросить конфиг на iOS XR, нужно будет зайти в конфигурацию, сказать configuration, просто configuration terminal, conf.t, или просто conf, и сказать commit replace. То есть, у нас сейчас все, что есть в буфере команд,

который потенциально должен дополнить наш конфиг, он сейчас пустой. И вот commit replace делает именно замену текущей активной конфигурации на то, что есть в буфере команд. Система предупреждает, что как бы штука опасная. Да, мы соглашаемся с тем, что опасная, но у нас конфигурация сброшена целиком. На iOS XE, если у вас конфигурация такая же, как у меня, пустая, а у меня она пустая, то есть вот на интерфейсе Gigabit 0.1, ну, Gigabit просто 1, ничего нет. Можно, в принципе, ничего не делать, а можно сбросить конфигурацию тоже. Erase, nvram, что у меня случилось, nvram, startup config, нет, ну, можно просто erase nvram. И перезагрузиться. Но перезагрузиться, понятное дело, штука такая,

она длительная, поэтому перезагружаться на наших железках мы сейчас не будем. Я все-таки думаю, что у вас, скорее всего, конфигурация пустая на XE, так что давайте мы предположим, что она у всех пустая, одинаковая, и в крайнем случае мы просто переконфигурируем те настройки, которые сейчас есть, на те, которые у нас должны будут получиться. Что нам потребуется? Нам нужно будет, чтобы наши роутеры XE и XR смотрели друг на друга. Они смотрят друг на друга следующим образом. На роутере XE у нас будет conft, interface gigabit 1, просто gigabit 1, без ничего, никакие ни субинтерфейсы, ничего не делаем. Дальше указываем no shutdown, потому что все интерфейсы на роутерах поднимаются и выключены. и указываем, что на интерфейсе у нас будет какой-нибудь IP-шник. IP-адрес, так, у нас IP-адрес 10, 0, 0, не знаю,

пусть будет 1, 255, 255, 255, 0. С другой стороны на XR вешаем, соответственно, какой-нибудь IP-шник из этой же сети. Интерфейс gigabit 0, 0, 0, 0, 0, 0, no shutdown, IP-адрес, 10, 0, 0, 0, 0, 2. Немножко лайфхак. iOS XR поддерживает вот такую конструкцию. То есть уже не обязательно писать 255, 255, 255, 0. Ну и, соответственно, commit. Проверяем, что у нас должны пингаться два узла. То есть на одном роутере мы включили один IP-шник, на другом роутере другой IP-шник. Ну, в общем-то, связь должна быть. Ну, пинг 10, 0, 0, 1. Так, что-то как-то у меня не получилось, видимо, с прошлого занятия решить проблему с XE-шкой. Что-то, наверное, плохо у нас работает.

Давайте на iOS тогда обычным будем делать. Так, iOS обычный. Покажись. enable conft interface gigabit 0, drop 0, no shutdown, IP-адрес 10, 0, 0, пусть будет 3. Это все интерфейсы, которые смотрят друг на друга на одни и те же самые, как называется, на одну и ту же среду. То есть фактически они смотрят на один и тот же маленький свитч, который вы не видите, но они действительно связаны между собой. Вот я сейчас на iOS обычном сделаю. В принципе, синтаксис на iOS обычном и на iOS XE идентичный, поэтому вы разницы даже не заметите. 10, 0, 0, 3, 255, 255, 255, 0. Do ping 10, 0, 0, 2.

Вот. XR и iOS обычные друг друга пингают. И теперь мы можем настроить связь между этими двумя роутерами с помощью с помощью CSRP. То есть, если мы хотим сделать так, чтобы наши два роутера действительно прикидывались бы одним, ну, гипотетически может быть такое, что у нас стоят два роутера. Один XR, другой iOS обычный или iOS XE. Ну, указываем standby. Дальше указываем номер группы. Например, один. Группы могут пересекаться в разных широкопечательных доменах на разных интерфейсах. То есть, можно везде введя группу номер один, это проблем не будет вызывать. Standby 1. Можно, кстати, вообще не писать номер группы. Тогда будет группа номер 0. Но я обычно пишу 1. Standby 1, IP 10, 0, 0, не знаю, 254. С другой стороны, на XR делаем ответные действия. То есть, делаем так, чтобы XR роутер тоже участвовал в этой группе.

Но я предлагаю немножко подождать. Я предлагаю дождаться того, чтобы у нас наш текущий роутер получил бы виртуальный IP 10, 0, 154. Иус обычный применяет изменения немедленно, никаких коммитов не нужно. Штаймеры по умолчанию 3 на 10, то есть, раз в 3 секунды отправляются Hello пакеты и 10 секунд требуется на определение того, что что-то идет не по плану. Соответственно, когда роутер просыпается, вот мы только-только включили Standby 1, IP 10, 0, 0,254, первые 10 секунд роутер просто вообще пытается понять, что в жизни такое творится. Он в течение 10 секунд пытается услышать Hello пакеты от запасного. Как только он в течение 10 секунд слышит, что пакетов от запасного нету, он переходит в состояние давайте-ка я попытаюсь стать запасным сам. То есть, начинается все с состояния Listen, когда роутер просто сидит и ничего не делает. Вот это вот состояние Listen, оно как бы просто пассивное ожидание. ожидание смерти запасного. А потом идет фаза Speak. В фазе Speak роутер пытается

стать запасным, и она тоже длится 10 секунд. Вот спустя 20 секунд роутер таки становится запасным, но он в этот момент понимает, что за последние 10 секунд, пока там фаза Speak шла, он еще и пакетов от основного не видел Hello, от активного роутера. Поэтому он, только став запасным, немедленно становится и основным. И вот это вот сообщение «Я стал основным роутером», «Я стал активным», пробегает у нас в конфиге. Do show standby. Есть show standby brief, который у нас на слайдах была. Вот оно нам покажет, что мы знаем про HSRP. Какой роутер, какой интерфейс, какая группа, какой приоритет по умолчанию 100, включен ли приемтинг, не включен, кто мы, активный роутер, кто активный, это мы, кто запасной, нет у запасного, Hello пакет от запасного не приходит, и виртуальный IP-шник. Если мы хотим на XR включить,

соответственно, HSRP тоже, то мы должны будем сделать следующее действие. Указываем на… уже не на уровне интерфейса, а роутер HSRP. Дальше указываем, что нас интересует интерфейс гигабит 0, 0, 0, 0, 0, 0. Здесь мы указываем адрес family IPv4, и здесь мы указываем номер группы HSRP 1. И в настройках группы в адресном семействе IPv4 на интерфейсе гигабит 0, 0, 0, в настройке роутера HSRP мы указываем адрес 10, 0, 0, 254. Commit. Сейчас XR тоже посидит немножко. В течение 10 секунд он ждет, ждет, ждет, ждет, ждет пакетов от запасного,

не дожидается их, переходит в фазу speak, в фазе speak проводит новые 10 секунд, дожидается того, чтобы он стал запасным, и дальше он на этом успокаивается, потому что приемтинга у него нет, по умолчанию он выключен, как следствие, когда мы понимаем, что мы с запасной роутер и от основного роутера какие-то пакеты приходят, значит, хорошо, жизнь удалась, мы можем ничего не делать, сидеть на попировано. Так, там пробежало сообщение, что у нас commit произошел, и произошел он 22.48.02 по UTC. Я так сильно подозреваю, что время-то у него какое-то кривое показывало, но тем не менее, я думаю, что 20 секунд уже прошло. Do show HSRP. И мы видим здесь, что у нас на интерфейсе гигабит 0000 в группе номер 1 в приоритете 100 без приемтинга мы стали запасным роутером. Активный роутер 10.003, запасной – это мы. Подрались мы за 10.00254.

Но возникает вопрос, а вот как бы нам сделать так, чтобы мы стали при этом основным? До тех пор, пока iOS живой, XR не станет основным, потому что у него приемтинга нет. Для того, чтобы отобрать роль основного, нужно будет обладать, во-первых, строго большим приоритетом, во-вторых, приемтингом. Если сейчас просто включу приемтинг, он автоматом основным не станет. Прием мопат коммит. Вот ничего не произойдет. Show HSRP. Вот ничего не происходит. Мы как были в стендбай, так и остаемся. Hello пакет от основного приходит регулярно, роутер на них не обращает внимания. Он говорит, ладно, хоть какой, хоть кривенький, косенький. То есть его приоритет не строго меньше, чем наш, поэтому мы продолжаем считать его легитимным основным роутером, легитимным активным. Если мы должны будем

забрать роль текущего основного у того, у кого приоритет строго меньше, чем у нас, то у нас должен быть включен приемтинг. Поэтому no preem. Я сейчас выключу его и покажу, что мало иметь больше приоритет. Нужно помимо большего приоритета еще и priority 110. Нужно еще и вот этот самый флаг приемтинга иметь. Commit. Show душевый Hsrp. Вот он. У нас приоритет 110. Мы запасной, активный вот этот вот. Оно вот так, да? Да. То есть показывается, что мы совершенно точно знаем, кто активный. У него 10.003, у него приоритет 100. У нас приоритет 110. Где 110 написано. Вот приоритет 110. Но мы сидим на

поперов и ничего не делаем, потому что у нас нет приемтинга. И для того, чтобы отобрать приемт роль активного роутера, нам достаточно буквально одну секунду. Вот. Я буквально сразу ввел эту команду show chsrp detail. И у нас появилось новое событие, которого раньше не было. lower priority active received. Мы получаем hello пакет от текущего активного роутера, у которого приоритет меньше, чем у нас, и у нас включен приемтинг. Раньше вот этой штуки не было, а у нас сейчас она появилась. Поэтому как только мы увидели такой пакет, мы от активного роутера с меньшим приоритетом, чем у нас, и у нас был включен приемтинг, мы роль активного роутера немедленно забрали. А текущий активный роутер стали мы, текущий запасной роутер получился никто, потому что выборы за роль запасного роутера на тот момент, когда я выполнял эту команду, еще не прошли.

Поэтому я сейчас снова делаю эту команду show chsrp detail, и показывается, что после того, как я отобрал роль активного роутера, запасной роль освободил, я роль запасного освободил, и тот, который был активным, он через некоторое время эту роль забрал на себя. Но не забрал, он по-честному выиграл выборы из одного кандидата. Показывается наша виртуальная маки 00000C 07AC 01, то есть номер группы 1, 07AC хорошо известный суффикс chsrp, 00000C хорошо известный цисковского увуишка. Если мы хотим попингать этот айпишник, то нам нужен, наверное, кто-то еще один. Давайте свитча попробую это сделать. Так, свитчик, подключайся. Так, подключиться. enable,

conct, интерфейс vlan1, no shutdown, и что нам еще нужно будет сделать здесь? Нам нужно будет айпишник повесить, айпи адрес 10 00 4. Так, и пинг 10 00 254. Вот мы пытаемся пингать виртуальный айпишник, он у нас даже пингается, show айпи арп, показывает, в какой стороне сидит этот виртуальный айпишник. Он у нас известен в первом вилане за мак адресом 00000C 07 AC 01. То есть тот самый виртуальный айпишник, который у нас, виртуальный мак, простите, который у нас и ожидался. Активный роутер на запрос арпа, у кого такой айпишник, скажите, свой мак, ответил виртуальным маком. После чего трафик идет именно на этот виртуальный мак, и даже если вдруг у нас текущий роутер активно меняется, все равно трафик идет на тот роутер,

который в данный момент будет активен. Давайте я покажу пинг 10 0 0 254 repeat. Не повторяйте за мной, а то если у вас что-то пойдет не по плану, то потом это будет тяжело прервать. По идее, Ctrl-Shift 6 должно работать, но мало ли что. Вот пинги пошли. Дальше я указываю, что у меня текущий активный роутер priority 90, а на веусе указываем прием... А, стендбайден приемт. Вот. И у нас сейчас должно перескочить с одного роутера на другой, но вы видите, что никаких пакетов не теряется. То есть все пакеты, которые отправляются, они доходят до текущего активного роутера. При этом в какой-то момент времени там произошло уже переключение. То есть,

да, у нас... Давайте прерву. Нигде, вы видите, нет ни одного пакета потерянного. Все пакеты, которые есть, они дошли. При этом... Так, а что у нас не забрал он роль активного? Шелстенбайбриф. Интересно. А, я коммит забыл сделать. Простите. О, потеря случилась. В момент переключения один пакетик потерялся. Но один пакетик — это одна секунда. То есть, мы отправили пакет, не дождались в течение одной секунды результата, и все остальные пакеты уже нормально прошли. То есть, вот, переключение происходит весьма быстро. Если бы я настроил таймеры не по умолчанию,

оно бы перескакивало бы еще быстрее. То есть, если бы я отправил таймеры в самый низ, который только можно там... Самый низ — это 10 миллисекунд hello time, а 30 миллисекунд dead time, то этого бы заведомо бы не произошло. То есть, у нас вот этот вот пакетик бы не потерялся вовсе. Так. Давайте попробуем пошчупать для IPv6 все то же самое. То есть, если у нас есть роутер на основе операционной системы EOS обычный или EOS XE, то мы должны будем сделать следующие настройки. IPv6 адрес. И мы должны будем сказать, какой у нас виртуальный IP-шник будет использоваться. не виртуальный, физический IP-шник. Давайте сделаем fd002.1. Вот такой вот красивый адрес по 64-й маске. Указываем standby version 2.

Здесь у нас сейчас будет конфликт, потому что сначала у нас будет со стороны EOS IPv4 группа 1 отправляться в версии номер 2, а со стороны XR та же самая первая группа останется в версии номер 1. Поэтому у нас будет фактически конфликт IP-адресов. Даже система будет про это ругаться. Но ничего страшного, поругается, поругается. Потом поменяем. Так. Вот у нас, собственно, конфликт прошел. У текущего обладателя в первой версии есть MAC-адрес 0000C 07AC01. У нас MAC-адрес 100254 будет 0000C 9FF 001. Ну вот мы указываем, что у нас рядышком есть standby группа номер 2. Так. IPv6. И что нам там? IPv6 адрес. конфиг.

И смотрим, что у нас получилось. Show standby brief. Так. Вот мы видим виртуальный IP-шник Linklokal. Он придумал какой-то случайный. И мы видим, что что-то как-то у него пока сложности есть с процедурой назначения адреса, потому что сначала идет состояние init, и что-то он как-то из этого состояния не хочет выходить. Есть гипотеза, что ему не хватает IPv6 unicast router routing. routing. Да. Ему не хватало именно этого. Перешел в фазу listen. В течение 10 секунд ждет сообщений от соседей. Не находит это, переходит в фазу speak. Еще 10 секунд выбирает самого себя любимого. Наконец, спустя 10 секунд назначает себя запасным, немедленно становится основным. Сейчас.

Вот запасной и ну и где? Кто будет запасным становиться? Так, вот он стал активным роутером и показывается, что у нас виртуальный IPшник вот такой вот получился. Со стороны iOS XR надо будет сделать ответное действие. Выходим exit. Указываем, что мы сейчас находимся в адресном смесье IPv4. Это, конечно, здорово. Но нам нужно будет на этом же интерфейсе перейти в адрес family IPv6. Family IPv6. Указываем, что у нас есть HSRP2, группа номер 2, адрес autoconfig. Так, не угадал. Link local autoconfig. commit.

И смотрим на то, что получилось. Do show HSRP. Так, вижу, что группу он завел. Состояние init намекает на то, что не мешало бы IPv6 вообще включить интерфейс хотя бы. Интерфейс гигабит 0, 0, 0, 0, 0, IPv6, интерфейс, ой, адрес fd 002, 2, 2, по 64-й маске. Так, exit, exit. Здесь произошел казус небольшой. Я находился в режиме настройки группы, и когда я указал интерфейс, система нашла ближайший подходящий мне субконтекст и определила, что это не настройка глобальной интерфейса, а настройка субконтекста интерфейса контекста HSRP.

Ну, окей. Назначили IPv6 адрес. смотрим на то, что у нас получилось. Commit. HSRP все еще висит в unknown. Вот, перешел в fuzzle listen, speak. Так, и у нас как-то криво назначился виртуальный адрес, я так вижу. виртуальный адрес у нас один, а виртуальный адрес у него другой. Надо это дело пресечь. Роутер HSRP адрес family а, интерфейс интерфейс гигабит 0,0, 0,0 адрес family IPv6 HSRP 2 ну, адрес

link local after config так, и адрес link local надо в явном виде указать, какой он у нас будет. Так, вот так вот у нас будет. помид. помид. Do show HSRP. Так, так, так, так. Standby. Ну, собственно, да, standby, все, все, как и ожидалось. То есть у нас прошли перевыборы. Текущий обладатель роли, вот, обладатель вот этого вот IPшника у нас некий вот этот вот товарищ.

Это link local адрес роутера на основе операционной системы CSKA. Запасной роутер это мы. Вот. Можно взять этот IPшник попингать. Опять же, со стороны обычного свеча указываем conft interface vlan1 ipv6 enable ping так ping процент vlan1 вот он пингается. Так, show ipv6 neighbors вот показано, что наш виртуальный IPшник, за который мы дрались, он соответствует вот такому вот виртуальному маку. HSRP для IPv6 используют другие маки, то есть 000573 это OOI дальше A00 это суффикс HSRP V2 002

это номер группы. Вот он пингается, все нормально идет. Если вдруг опять же у нас переходит переключение, так, давайте попробуем сделать это, проэмулировать переключение. Нам нужно везде включить приемтинг. Так, он в Т, интерфейс гигабит 00, standby 2, приемтинг. Что это он ругается? Та зрительная та. так. Так. А, на XR надо в явном виде переключать группу в режим HSRP первой версии, второй версии. Забыл. Так, адрес family план, потом сделаю. превент, превент, адрес family

IPV4, HSRP1, так, версия, HSRP1 версия. вот, здесь вот задаются группы немножко по-дурацки. Версия 2. На CISC нельзя сделать так, чтобы у нас на одном интерфейсе работали некоторые группы в одной версии, некоторые в другой. Здесь можно. Commit. Так, и у нас текущий обладатель роли активного роутера за виртуальный IPv6 адрес это IELTS. Соответственно, текущий наш ping и пит нормально pingается. Если на IOS я сейчас искусственно понижаю приоритет, priority не знаю, 90 ставлю, то мы увидим,

а мы не увидели, мы даже не увидели потерю, потому что она немедленно перескочила, роутер отдал роль быстро и без потерь. вот он перешел, мы не видим никаких потерь. Так, если мы хотим искусственно понижать приоритет, делается это через tracking. Давайте сделаем это. Сделаем так, чтобы у нас был объект отслеживания, который можно было бы пронаблюдать, что он действительно поднимается, падает, поднимается, падает. Сотворим мы такой объект отслеживания, который будет не пингать соседа, потому что это было бы скучно. Там на слайдах уже все пингалки посмотрели. А мы будем отслеживать наличие маршрута. То есть мы сделаем такой объект отслеживания, который будет говорить «да», если у нас в таблице маршрутизации есть определенный маршрут. И выглядеть это будет примерно следующим образом. А что у нас постоянно ругается? Он же не должен ругаться. «Коммит»

сделал HSRP 1 версии 2 2 шоуран. Так. Ага. То есть у него отдельная HSRP первая группа, отдельная HSRP первая группа второй версии. Ну ладно, пусть ругается. трек. Указываем, что мы хотим создать объект отслеживания. Делаем этому объекту отслеживания некий номер. Например, номер 1. Указываем, что нас будет интересовать объект, связанный с IP. Дальше. Из двух вариантов выбираем не зонда IPSLA, а именно маршрут. И указываем, что если у нас в таблице маршрутизации есть маршрут 0, 0, 0, 0, 0, 0, то, соответственно, вот у нас все хорошо. Можно проверять, что маршрут есть вообще, и тогда мы указываем просто речабилити, что маршрут в таблице маршрутизации

присутствует, хоть какой-нибудь, хоть рыбкой, хоть киской, хоть зайкой. А можно указать метрик, и тогда, если в таблице маршрутизации есть маршрут с определенной метрикой, или лучше, то, соответственно, мы говорим, да, у нас объект трекинга в API. Если нет, то, значит, объект падает. Ну, речабилити нас спасет. Здесь можно задать дополнительные свойства, ну, обычно можно задать. Можно указать, что если у нас маршрут теряется, то можно срабатывать только с некоторой задержкой. Можно переходить в другое состояние, не сразу, а через чуть-чуть. Сделано это для того, чтобы сбежать флаппинга. Если у нас маршрут прибежал, а потом сразу убежал, то, ну, или наоборот, убежал, а потом сразу прибежал, чтобы объект трекинга не терялся. Так, мне, честно говоря, подбешивает немножко Hsrp, const, так, интерфейс gigabit 0, drop 0, ну, stand by 1.

Решим вопрос таким образом. Так, и если мы хотим отслеживать объект маршрута, то нам нужно будет создать IP road 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, 0, 0, 0, 0, 0, show track 1. Так. Здесь я, конечно, немножко облажался, потому что маршрут должен быть нестатический. Можно ли это как-то победить, интересно?

Наверное, нет. Track 1. OSPF быстро сляпать. Ну, давайте OSPF быстро сляпаем, да. Просто для демонстрации. ConfT, роутер, OSPF1. Так. Так, нет, это не дистрибут, а... Сейчас. Default information, господи. Default information originate always. Так. Интерфейс gigabit 0, drop 0, IP OSPF 1, area 0. Что не так?

А, это же switch. Интерфейс VLAN 1, IP OSPF 1, area 0. Так. И на iOS роутере. Интерфейс gigabit 0, 0, IP OSPF 1, area 0. Так. И маршрут статический, естественно, надо из таблички убрать. А то он нам сейчас картинку всю испортит. Так. Show IP road. Пока нету. Show IP protocols. Так. OSPF вроде работает. Show IP OSPF interfaces. Brief. Так.

Фаза wait. Надо немножко подождать. Show IP OSPF interface brief. Так. Вот. У нас установилось соседские взаимоотношения буквально на глазах. Смотрим на iOS. Show IP road. Root. Root. Так. Вот у нас FPF-овский маршрут. И буквально на глазах поднялся объект трекинга. Вот он. Да. Объект трекинга у нас завелся. И если мы захотим в HSRP сказать, что вот на основе вот этого маршрута мы хотим говорить, что мы имеем доступ во внешний мир, то мы идем в conf.t. Интерфейс gigabit 0.0. И указываем здесь stand by. Ну, я stand by 1 не буду делать, stand by 2. Предположим, что у нас маршрут IPv6 отслеживается. Дефолт. Track.

Указываем, что у нас есть объект отслеживания номер 1. Если мы хотим просто проседать на десятку, то мы можем просто enter нажать. Если мы хотим декремент, не знаю, 1000 сделать. Так нельзя. 100. Там однобайтовое значение, поэтому 1000 — это перебор. Вот то в случае с падением объекта трекинга 1 во второй группе у нас приоритет понизится на 100. Если он default-набил 100, значит станет 0. Show stand by brief. Давайте не brief, просто show stand by. Там как раз будет видно. Приоритет 90 сейчас прямо есть, потому что 90 настроенный. Если объект трекинга упадет, он просядет на сотку, ну, станет минус 10. Никогда не пробовал так сделать, чтобы приоритет стал отрицательный. Conf.t. А, давайте не так сделаем. Давайте вот так вот сделаем.

На роутере скажем. Conf.t. Роутер. OSPF1. Shutdown. Соседство падает. И ждем, чтобы оно упало и на роутере тоже. Show IP OSPF neighbors. Sob. Пальцы заплетаются. OSPF. Сосед у нас в плохом каком-то состоянии. Через 20 секунд. Вот он упал. И упал у нас маршрут. И видно, да, что, соответственно, здесь у нас объект трекинга пропал. Show track 1. Он в состоянии down. Show stand by brief. Покажет, какой у нас приоритет прямо сейчас. Приоритет у нас 0. И 0 у нас именно потому, что... Show stand by...

Вот. Что у нас настроенный приоритет стартовый 90. Но из-за того, что объект трекинга 1 ушел в down, приоритет просил на сотку. Как следствие, результат стал 0. Вы обязаны фактически всегда, когда вы настраиваете любой FHRP протокол, настраивать его с трекингом. То есть мало просто сказать, что у нас 2 роутера или 3 роутера или 10 роутеров будут сидеть в одной группе и подхватывать IP-шники. Если один сдохнет, второй подхватит. Нужно, чтобы они друг другу отдавали этот IP-шник добровольно в случае, если у них что-то теряется связь со внешним миром. Контролировать дефолт – это один из самых простых способов, как можно в случае с провайдерской сетью добровольно отдавать маршрут другому HSP роутеру. На этом, пожалуй, тему закроем. VRRP и GLBP настраиваются абсолютно идентично. То, что их можно включить, и вы это знаете с CCNA, то, что можно объект отслеживания делать с CCNA,

вы, может быть, и не знали, но сейчас узнали. Настройки роутеров XE и XR, в общем-то, однотипны для всех протоколов практически. Единственная разница есть в VRRP третьей версии, но его в курсе нету, в экзамене точно нету, поэтому даже если вдруг вы с ним когда-то будете работать, ну, разберетесь как-нибудь. На всякий случай давайте быстренько пробегусь по командам. conft fhrp. Здесь вот мы указываем version VRRP v3, по-моему, да, v3. И, соответственно, после того, как мы это сделаем, в настройке интерфейса gigabit 0.0 у нас появляется VRRP 1. Вот уже немножко изменяется синтаксис. Раньше на... давайте на use покажу на таком вот. Интерфейс VLAN 1. VRRP 1. Здесь вот... Что, он такой не умеет?

А, интерфейс VLAN 1. Это мы в лупбеке. VRRP 1. Вот у нормального iOS по умолчанию используется VRRP второй версии, и синтаксис здесь вот в настройке VRRP номер группы, дальше мы даем все необходимые настройки. После переключения в VRRP третьей версии мы указываем VRRP номер группы, дальше адрес family, IPv чего-нибудь, не знаю, IPv4, и уже в настройке этой группы делаем все настройки, там адрес, приемтинг, priority, tracking и все остальное. Если хотим для IPv4 рядышком включить и VRRP второй версии, например, если нам нужно одновременно дружить по IPv4 в VRRP 2, по IPv6, VRRP 3, то указываем VRRP V2. Рядышком будут бегать еще и пакеты VRRP V2. Так, ну, в общем-то все. Здесь больше ничего нету такого, что стоило бы рассматривать. Там есть ряд хитрых нюансов,

как настраиваются HSRP, VRRP, GLBP в предприятиях, поэтому на курсе по свитчингу, например, там, где мы рассматриваем эти протоколы, там у нас есть тонкие крутилки, то есть как настраиваются таймеры, как настраиваются всякие задержки, чтобы можно было, там, допустим, сказать, не сразу поднимай участие в группе, а только через некоторое время после того, как ты проснулся, чтобы дать время тому же самому SPF насосаться маршрутами, BGP насосаться маршрутами. Вот. Но здесь у нас в курсе как бы стартовый просто обзор, поэтому здесь ничего этого делать не будем. Пожалуй, все. Следующая тема у нас будет про что-то совсем другое. Спасибо. Спасибо. Спасибо.