STP Toolkit

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

топологии вы еще и max h timer просчитываете и этот max h timer может быть до 20 секунд и как следствие соответственно вот 20 секунд плюс 30 секунд дважды формателый таймер получается там уже 50 секунд у 49 более того может быть такое что у вас события смена топологии возникает в одном конце сети и дальше она начинает разбегаться в сторону всех остальных свечей и где-то в течение forward delay таймера информация о том что топологии вас начинает перестраиваться добегает до каких-то других свечей в топологии поэтому может быть такое что у вас начало как бы развития критической ситуации у вас дохнет труд но дохнет непрямым образом его сосед определяет что руд сдох и через 20 секунд говорит у нас сменилась топология дальше начинает рассылать эту информацию в сторону всех остальных свечей и все остальные свечи получают эту информацию с 15 секундной задержкой и дальше они начинают

заблокировать свои порты и через 30 секунд только разблокируют эти свои порты поэтому форма родилы таймер вас может посчитаться аж трижды помимо того что он трижды просчитается еще будет max h timer 19 секунд получается в итоге на 100 5 секунд спаринг 3 медленный может вам сетку заблокировать если у него что-то нехорошее случится кроме того спаринг 3 на любой чих будет очень нервно реагировать то есть у него вот эти вот четыре события вида когда надо начинать перестраивать топологии они на самом деле в классическом спаринг 3 случались довольно часто в девяностом году когда его проектировали рассчитывали под то что у нас все линки будут шарид линк то есть конкурентная среда типа толстого желтого как села а по факту индустрия шагнул в совершенно другую сторону и все линки стали расти как point to point на каждого абонента нашел отдельный провод с отдельным портом у вас включился новый компьютер в сеть и вся сеть легла легла на 30 секунд у вас включился другой компьютер у вас снова вся сеть легла на 30 секунд

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

абонентских портах дальше у нас есть механизмы root guard loop guard you deal de bridge assurance и немножко спонинг 3 диспут это соответственно механизмы которые предполагают защиту спонинг 3 на связях между коммутаторами и древние технологии оплинг фазбок бонфаст аплинг фаст и бакбонфаст да это все уже мертвые но тем не менее она все еще как бы в курсе может присутствовать поэтому мы про него расскажем и за чанал guard которым на самом деле уже с вами проходили давайте разбираться по пунктам что у нас тут есть самое первое порт fast технология разработанная компания циска потом она вошла в стандарт 802 1 дабы но не совсем она как бы не напрямую вошла идея которая заложены были в механизме порт фаст вошли в 802 1w рабочую группу в которой естественно представители циска тоже были и затем стандарт 802 1 d 2004 года смысл порт фаста заключается в том что если у вас есть абонентский компьютер и этот компьютер

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

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

соседнего сервера то есть например у вас как раз так гипервизор висит на этом гипервизоре виртуальные машины которые смотреть должны в много разных виланов вот в этой ситуации вы можете сказать спонинг 3 порт fast на тот порт который смотрит на такой сервер даже если он будет в транке но вообще по идее вы должны будете включать это на абонентских портах на портах которые access вы есть несколько команд как можно это сделать несколько способов точнее как можно это сделать и есть несколько синтаксисов команд которыми это можно делать раньше на старых свечах на старых и усах команда была на интерфейсе спаринг 3 порт fast просто без ничего тогда когда циска придумала этот механизм вот она говорила это у нас фирменная цисковская технология которая ускоряет работу спаринг 3 и называется эта штука порт fast потом когда все это дело вошло в стандарт 802 1w и в 802 1d 2004 года в 802 1w эта штука называется edge порты то есть по смыслу все то же самое только называется по-другому поэтому циска переименовала команду

команда стала называться спонинг 3 порт fast edge вот и вы можете сказать спонинг 3 порт fast edge или если этот ранковый порт спонинг 3 порт fast edge ранг если вы хотите вы можете заставить вашу циску включить автоматический порт fast на всех аксессовых интерфейсах команда спонинг 3 порт fast edge default если вы знаете точно что у вас на вашем абонентском свече точно сидят только обычные абоненты если вы знаете что везде прописан switchport mode access то вы можете эту команду внести и она ускорит и очень сильно ускорит работу спаринг 3 за счет того что она быстро переведет все порты в порт fast и у вас включение абонента на свече не будет вызывать смены топологии у вас абонент начнет работать сразу да если у вас пропадало питание свечи только начинает грузиться у него появляются какие-то новые оплинки вот на оплинках он 30 секунд конечно там может блокировать коммутацию даже если он там не обнаружит репет спонинг 3 но если обнаружит он нам быстро все разблокирует но тем не менее на обычных абонентских портах появление нового

порта сразу будет переводить это порт в 10 на этот форматинг очень удобная команда спарник 3 порт fast edge default в глобальном конфиге если вы точно знаете что это у вас свеч доступа то пожалуй эта команда рекомендуется к использованию в противном случае вы должны будете на отдельном порту на каждом из отдельных портов писать спонинг 3 порт вас также опять же так как также как и в случае со старыми иосами на интерфейсе спонинг 3 порт fast было раньше команда вот эта вот команда спонинг 3 порт вас default она тоже раньше не имела слова edge она раньше на старых иосах было просто спонинг 3 порт вас default но на новых иосах циска все-таки пошла на поводу у стандартного протокола 800 21 до 2004 года и называют эти порты порт fast edge с набегом на то что это в принципе стандартная фича 800 21 ну 800 21w когда вы как администратор прописываете команду спонинг 3 порт fast edge это факт фактически рекомендация

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

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

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

начинаем проходить десигнает дискардиный десинге плёрнет ну в общем что там полагается да там уже будут работать обычные правила спаринг 3 равным образом мы можем включить только bpdo guard без порт фаста и тогда порт начинает включаться мы на этом порту начинаем отправлять бопадушки в течение первых 15 секунд мы отправляем бопадушки и говорим ну ты это самое мы же ничего не делаем ты пожалуйста ответь нам своим агриментом на наш пропозал то что мы на посылаем пропозал и ждем агрименты но нам никто не отвечает потом соответственно мы еще 15 секунд 10 до этот learning тоже продолжаем отсылать бы подушки тоже говорим что но нам бы это самое перевести бы порт десигнает фарвардинг но поскольку порт фаста на порту нету значит он не переводится сразу в десигнает фарвардинг и только спустя 30 секунд спустя дважды форвардилай таймер порт на котором нет порт фаста но есть бы подугвард переводится в фарвардинг и тут внезапно какая-то залетная попадушка приходит и соответственно порт гасится нет особенного смысла

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

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

интерфейса можно включить автоматически на всех интерфейсах где есть порт fast да если мы включаем bp2 guard на отдельном интерфейсе то эта команда спанник 3 bp2 guard enable если мы хотим мы можем отменить действия команды спаринг 3 bp2 guard enable предсказуемой командой ноу спанник 3 bp2 guard enable или мы можем еще дополнительно сделать штуку команда спанник 3 bp2 guard disable как ни странно это две разные команды бисей был говорит что на этом порту никогда не должен порт fast работать а но спанник 3 bp2 guard enable говорит что на этом порту bp2 guard может работать по каким-то общим правилам и общее правило будет как раз следующая команда в глобальном конфиге спанник 3 порт fast edge bp2 guard бп2 guard default она включает автоматически порт бп2 guard на всех порт фастовых интерфейсах так же как и в предыдущем случае вот этот порт fast edge это раньше у нас порты назывались просто порт fast и команда мило вид спорт спанник 3 порт fast bp2 guard default но с появлением быстрого спанник 3 в

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

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

вы как администраторы говорите что на этом порту я обещаю что петли никогда не будет но если в случае с бы подруг гвардом у говорите я не обещаю что на порту никогда не будет петли но если вдруг приходят бапу душка расстрелять такой порт чтобы туда фильтр это вы обещаете что на этом порту никогда не будет петли и ничего не надо делать, если приходит BPD-ушка. Более того, никогда не реагируем на приходящие BPD-ушки с той стороны. И, соответственно, вы можете сказать на порту Spanning3 BPD-Filter Enable, вы не реагируете на приходящие BPD-ушки. То есть, что бы с той стороны не прошло, вы просто выкидываете эти BPD-ушки, вы их игнорируете. Вы в этот порт не отправляете свои BPD-ушки, и на этом порту порт всегда получает состояние Designated Forwarding. То есть, этот порт фактически выключается из топологии Spanning3. И рекомендуется эту штуку использовать на тех интерфейсах, где вы хотите практически выключить Spanning3.

То есть, на интерфейсах в сторону чужих железок, чужих автономных систем, например, с провайдера. У вас есть провод от провайдера, вы его втыкаете в свой свитч, вы не хотите, чтобы Spanning3 провайдера влиял на вашу топологию. Поэтому вы говорите, что соседский свитч провайдерский может присылать какие угодно Spanning3-шные BPD-ушки, мы их игнорируем, мы не можем с использованием провайдера устроить петлю никаким образом. У нас никогда не организуется внезапно второй провод в сторону сети провайдера. Поэтому, да, вот на таком интерфейсе, который смотрит на провайдерский, широковещательный домен на провайдерскую коммунируемую среду, вы указываете Spanning3 BPD-Filter Enable. Ну или тоже можно Spanning3 BPD-Filter Disable в явном виде сказать, что на всех портах BPD-Filter у нас будет работать, а на этом нет никогда. Ну и есть, опять же, автоматическая команда по включению автоматически этой штуки на всех портфаст-интерфейсах. Фактически вы выключаете Spanning3 для обычных абонентов. Вы оставляете Spanning3 на тех линках, которые у вас до соседних свитчей.

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

есть нюанс. И нюанс заключается вот в чем. Если вы провайдер, и у вас есть как раз вот такой вот свитч, который вы взяли, развернули на каком-то там шкафчике доступа. Ну, например, там, не знаю, вы предоставляете доступ по Ethernet в многоквартирном доме. У вас до каждой квартиры тянется отдельный провод. Вы где-то там, либо на чердаке, либо в подвале, либо где-то еще ставите свитчек. Дальше вы от каждой квартиры дотягиваете провод и включаете в этот свитч. И вдруг случайно ваш монтажник взял и замкнул два порта коммутатора. Вот для того, чтобы не уложить в петлю этот свитч, автоматически включаемый BPDU-фильтр на интерфейсах не доверяют по умолчанию тому, что делает администратор. Если у нас был какой-то порт, который переходит в app, то в течение 10 hello-таймов мы отправляем BPDU-шки. То есть мы отправляем 10 BPDU-шек в этот порт по обычному нашему нормальному таймеру. Если в течение этого таймера обратно приходит хоть одна BPDU-шка,

то порт fast на этом порту не включается. Поэтому будьте, пожалуйста, очень осторожны с использованием вот этой вот команды. Она на самом деле, хотя и кажется, что BPDU-фильтр включает, на самом деле она совершенно не факт, что его будет включать. Если у вас есть абонент, который в вашу сторону будет смотреть спалинг-тричным портом, он со своей стороны BPDU-шки не зафильтровал, а у вас свитч, например, перезагружается, то, соответственно, у вас свитч включается. Он смотрит, что есть какой-то порт, которым вы смотрите на абонента. На этом абонентском порту у нас прописано, что порт будет действительно порт-фастовый. Дальше мы говорим, не надо ли включить на нем BPDU-фильтр. У нас есть вот эта вот команда Spalning-3, порт-фаст-эдж, BPDU-фильтр-дефолт. Вроде как надо, но мы отправляем 10 BPDU-шек, и с той стороны к нам начинают приходить ответные BPDU-шки от соседа. И сосед говорит, я не просто соседний свитч, я еще и знаю, как добраться до рута. Очень крутого рута с приоритетом 0. И, соответственно, у вас вся топология вашей сети начинает переколбашиваться.

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

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

который вам начинает присылать BPDU-ушки, но, соответственно, у вас в любом случае что-то упадет. И выбор на самом деле богатый. Либо у вас упадет отдельный порт на клиента, либо у вас упадет вообще вся сеть. Я однозначно предпочитаю, чтобы упала не вся сеть, а только порт клиента. Поэтому, если использовать BPDU-фильтр, то в сочетании с BPDU-гвардом. Вот, да. Если вы сеть предприятия, то вы должны будете BPDU-фильтр вешать на линке в сторону провайдеров. Если вы их включаете не в маршрутизаторы, а именно в свечи. Это, на самом деле, довольно частое явление, когда, допустим, интернет у вас приходит просто как отдельный Вилан, и вы говорите, да, окей, провайдерский провод включаем в один из свечей, например, в дистрибьюшн-блоке. И, соответственно, вот мы говорим, что там Вилан, к примеру, 777, это будет просто Вилан с интернетом. Кому вдруг надо будет, мы ему предоставляем доступ к этому Вилану. А дальше с помощью интервилан-роутинга или с помощью роутера на палке мы уже начинаем обрабатывать этот интернет.

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

То есть, допустим, 24 576 на одном свече, 28 672 на другом свече. И вот у всех остальных нормальные приоритеты 32 768. В такой ситуации кто-то из этих двоих будет рутом, и оба они будут присылать BPDU-ушки в сторону аксесс-свечей. То есть они будут диссигнать этот портами, смотреть на абонентские свечи. Пардон. Так. Вот. Если вдруг у нас какой-то аксесс-свечь примет BPDU-ушку от абонента, или сам внезапно станет рутом, то есть он скажет, у меня будет приоритет не 32 768, а не знаю, 20 тысяч, сколько там, 480. В такой ситуации у нас получится, что вместо того, чтобы смотреть диссигнать портами на абонентские свечи, дистрибьюшн свечи будут смотреть либо рут портом на абонентские свечи,

либо альтернет портом на абонентские свечи. А, соответственно, сам аксесс-свечь перехватит роль диссигнать порта на интерфейсе, в его сегменте. Так вот, мы можем сказать, что если у нас есть свечи, которые должны в норме быть рутами, то мы можем сказать, что в некоторых случаях мы можем отдать роль этого рута соседнему свечу, или мы можем не отдавать роль этого рута соседнему свечу, но мы ни в каких ситуациях не можем смотреть рут портом на абонентские свечи. То есть мы можем сказать, что некоторые порты, которые у нас есть на нашем свече, по определению не могут быть рутовыми. Ни рутовыми, ни альтернетами. Они могут быть только диссигнаетами. Соответственно, если вы указываете на порту, что на этом порту будет работать механизм root guard, вы фиксируете, что этот порт обязан быть только designated и никаким другим. Вот, например, у нас есть switch, там, допустим, designated switch 1, и мы на интерфейсе в сторону обычного абонента говорим,

фиксируем там spawning 3 guard root. То есть мы говорим, этот порт всегда может быть только и исключительно designated и никаким другим. Вот этому порту мы designated порт роль прибиваем гвоздями. Если приходит BPDU-шка superior по отношению к той, которая отправляет сам designated switch 1, то есть access switch говорит, что он знает, как добраться до рута, в этом случае мы ему не верим, и мы говорим, на этом порту приходит какая-то херня, выключаем порт целиком, но не R-disable-им его, а именно выключаем до тех пор, пока оттуда приходят кривые BPDU-шки. Если BPDU-шка хорошая, ну, бля, superior BPDU-шка приходит на таком порту, мы объявляем состояние root guard inconsistency. У нас пробегает сообщение spawning 3 root guard block, что на порту gigabit 0.0 в первом VLANе мы получили невкусную BPDU-шку, точнее вкусную BPDU-шку, но не ту, которую мы ожидали. И на этом порту у нас роль designated, прибитая гвоздями, но состояние blocking, вот это BKN, я напомню, какие у нас состояния должны быть штатно в быстром spawning 3.0.

У нас должно быть block, это blocking, на самом деле discarding, у нас есть learning и у нас есть forwarding, FVD. Вот это вот BKN означает, что у нас на этом порту есть какое-то состояние inconsistency, в результате которого коммутация на порту временно выключена. Она не совсем выключена, как, допустим, в случае с R-disable, она выключена до тех пор, пока на этом порту есть BPDU-шки. При получении такой BPDU-шки на время оставшейся жизни такой BPDU-шки, на время до MaxAge, минус MessageAge, вы коммутацию на этом порту блокируете. Если BPDU-шка пришла одна, то вы заблокировали коммутацию, говорите, пока эта BPDU-шка не протухнет, мы коммутацию не включаем. Приходит другая BPDU-шка, мы обновляем этот таймер и снова блокируем коммутацию на 19 секунд. Но если вдруг BPDU-шки перестают приходить, то через некоторое время, когда эти BPDU-шки протухают, на порту состояние inconsistency счищается,

и порт начинает нормально работать. Очень удобная вещь. И фактически, когда вы root guard включаете, вы прибиваете гвоздями роль designated порта на этом порту. Как определить, на каких портах мы хотим повесить этот самый механизм root guard? На всех тех, которые не должны становиться rootовыми. То есть в нашем случае, например, мы говорим, у нас вот этот вот switch, он root по определению в каком-то дереве. Значит, вот этот вот порт, он всегда designated. Вот этот вот порт всегда designated. Вот этот вот switch, он может быть rootом, соответственно, а может быть запасным rootом. Поэтому вот этот вот порт, у него может быть rootовым. На нем включать эту штуку не надо. Но вот этот вот порт, например, тоже всегда designated. Поэтому root guard мы включаем вот здесь. Root guard мы включаем вот здесь. Ну и опционально можно root guard включить вот здесь. Хотя на самом деле смысла в этом особого нету, потому что мы защищаемся от ситуации, что у нас второй distribution switch перехватил роль rootа первого. Вот. Так что root guard мы смотрим, да, на свечи,

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

например, вот так вот, то есть второе волокно нормально работает, а первое не работает, то получается, что мы, что-то отправляя в это сломанное волокно, никогда не можем добиться того чтобы это дошло до соседа получателя но при этом то что сосед отправляет нашу сторону но при этом нормально проходит нам очень типичная проблема в случае с двуглазой оптикой когда у нас случается односторонний отказ то есть в одну сторону пакета проходят а в другой не проходит особенно эта криминальная штука будет как раз при использовании spaning 3 потому что если у вас есть например нормальный root свеч и у нас есть кто-то другой и вот root говорит я дисс 촉ры этот на всех портов я тут самый умный и отсылает свою рот оави бы башки говорит я тут самый крутой один из этих портов объявляется room版 tool другой из этих портов является альтернет портом ну и соответственно блокируется дальше у нас случается односторонний отказ на одном из этих link of и бабушки на одном опортов нормально доходит до соседа оба п quo на другом порту не проходит в сторону соседа и соответственно

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

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

она у вас сожрет все ресурсы коммутатора, сожрет все ресурсы ваших свечей, будет порождать бесконечное получение копии кадра на всех портах, и будет, что самое главное, порождать нестабильность базы MAC-адресов. Поэтому, если у вас есть такой односторонний отказ, и если есть альтернативный способ доставки трафика до свеча жертвы, то, соответственно, у вас возникнет полупетля и сеть ляжет. Есть два механизма, как с этим можно будет бороться. Даже не два, а больше. И один из этих механизмов будет называться LoopGuard. LoopGuard. Механизм, который позволяет бороться с односторонними отказами, как раз тогда, когда у нас есть два волокна, по одному трафик уходит, но не приходит до получателя, а по-другому все нормально проходит. LoopGuard позволяет бороться с такими отказами, и механизм, который он будет использовать, будет прямо противоположен по смыслу RootGuard.

То есть они называются RootGuard и LoopGuard похожим образом, и они ведут себя на самом деле похожим образом. Но если RootGuard прибивает гвоздями статус Designated порта на интерфейсе, то LoopGuard говорит, что порт никогда, ни при каких условиях, не меняет роль на Designated. Каким образом этот механизм будет работать и почему он будет полезен? Дело в том, что если у вас есть такой вот случай, когда у нас два коммутатора, и у нас есть, например, два линка между ними, один из этих линков как раз такой вот оптический, и в нем случился односторонний отказ. То есть в одну сторону трафик не проходит, а в другую сторону по подушке ответные приходят, но они приходят inferior. И в этой ситуации, соответственно, мы говорили, что у нас односторонний отказ, говорит, что этот у нас коммутатор, ну, например, Root, он у себя говорит, я буду Designated портом, этот говорит, я буду Root портом. Здесь у нас идет указание, я Designated порт, потому что я Root.

И этот правый свеч на нижнем линке говорит, я тоже буду Designated линком, Designated портом, потому что я не получаю ответные BPD-ушку, когда посылаю свою. То есть мне там ничего не приходит, а мне там ничего не приходит, потому что там случился односторонний отказ, но я про это ничего не знаю. И вот в этой ситуации, если мы на порту, который в норме никогда не должен становиться Designated, включаем Loop Guard, то когда к нам перестают приходить superior BPD-ушки, они к нам перестают приходить, потому что мы их перестаем видеть, они там отправляются, но они до нас не приходят. Мы вместо того, чтобы сказать, это у нас Alternate порт, и порт со своей стороны блокировать, мы не будем включать Designated порт на этом интерфейсе. То есть мы не будем говорить, раз мы ничего с той стороны не видим, мы будем сами Designated, мы будем сами отправлять BPD-ушки в этот интерфейс. Если мы включаем Loop Guard, то мы говорим, что то, что к нам перестали приходить superior BPD-ушки, означает лишь то, что мы смотрим на соседний свитч, который не работает,

потому что Designated должен быть он. Если мы не получаем BPD-ушки от него, то это потому что он сдох. Вот стандартная логика, спонент-трешная, говорит, что если мы не получаем BPD-ушки от Designated свитча, мы должны сами стать Designated. Порт с Loop Guardом говорит, в нарушении стандартной логики, если мы не получаем BPD-ушки, superior BPD-ушки от соседа, то это не потому, что надо сейчас обслуживать трафик пользователей, которые находятся в коаксиале между нами и соседом, потому что зачем нам Designated порт объявлять здесь? Потому что вдруг здесь у нас пользователь сидит, и он бедолага, после того, как действительно настоящий root перестал присылать нам BPD-ушки, потому что он, видимо, сдох, вот бедолага пользователя остался без связи, надо включить Designated порт для этого пользователя. Нет. Loop Guard говорит, что у нас нет никаких больше shared link, у нас нет никаких больше этих самых коаксиальных проводов с пользователями между коммутаторами. Если Designated Bridge настоящий перестал присылать BPD-ушки,

все, расстреливаем порт целиком. Ну, то есть нет смысла его включать просто. И порт, который мы объявляем Loop Guardом, он никогда не Designated. И он никогда не получит роль Designated. Если перестают приходить superior BPD-ушки, порт выключается. Включать его надо на всех, на самом деле, не портфастовых портах. И дополнительно к тому, да, не надо включать его на Designated портах, которые у вас будут штатно Designated. То есть если у вас есть, например, вот этот вот root switch, то не надо Loop Guard включать на тех портах, которые Designated здесь, Designated здесь, там это бессмысленно. Но в то же время вы же знаете, какие порты у вас будут рутовые, какие порты у вас будут alternate. Вот на них включать как раз и надо. Команда будет либо на интерфейсе Sparrowing Tree Guard Loop, либо можно на всех не портфастовых портах, которые будут в peer-to-peer включать Sparrowing Tree Loop Guard Default.

То есть она противоречит по смыслу root guardу. Вы должны либо включить на интерфейсе root guard, либо включить на интерфейсе loop guard. Но нельзя их включить одновременно, потому что они работают прям принципиально по противоположным механизмам. Root guard прибивает гвоздями роль Designated, loop guard говорит, никогда не становимся Designated. Если root guard мы можем включить и сказать, что этот root guard имеет смысл на тех интерфейсах, которые смотрят в сторону ниже стоящих свечей, то вот, соответственно, loop guard включается как раз на вышестоящие свечи, на те порты, которые у нас рутовые или alternate должны быть в норме. И Sparrowing Tree Loop Guard Default как раз включает это автоматически. Так. Да. Когда у нас приходит WPD-ушка, которая Superior, а потом она переходить пристает, то у нас включается как раз вместо того, чтобы объявить порт Designated портом, включается механизм loop guard inconsistency.

И опять же, порт у нас падает в состоянии Designated Bacon. И со звездочкой указывается, почему это BKN. Loop inconsistency на это как раз указывает весьма недвусмысленно. То есть у нас loop inconsistency показывает, что этот порт когда-то был рутовым, а теперь он перестал быть рутовым, и мы такой порт пристреливаем. Пристреливаем до тех пор, пока не придут Superior BPD-ушки. То есть если в случае root guard мы говорим, пока приходят кривые BPD-ушки, расстреливаем порт. Если перестают приходить кривые BPD-ушки, порт включаем обратно. Здесь логика прямо противоположная. Пока не приходят правильные BPD-ушки, расстреливаем порт. Если BPD-ушки правильные начинают приходить, порт расслабляем, начинаем работать. Далее. Далее, далее, далее. Альтернативный механизм борьбы с односторонними отказами. Это UDLD. Протокол фирменный, цисковский, который использует специальные отдельные пакетики.

Эти пакетики не Spanning 3. То есть это отдельный протокол, который своего рода пингает соседа. И если сосед пингается, то мы говорим, что все хорошо. А если сосед не пингается, то мы гасим порт. Эта штука не является частью Spanning 3, но она очень хорошо сочетается со Spanning 3. И механизм специально создан для того, чтобы работать на линках, которые Spanning 3 будут использовать. То есть это не является частью Spanning 3, но является комплементарным к Spanning 3 протоколу. Смысл будет следующим. Вы отправляете пакетики, специальные UDLD, Unidirectional Lean Detection. Отправляете их и ожидаете ответа на эти пакеты. Соответственно, отправляете по умолчанию раз 15 секунд и говорите, в течение 45 секунд после отправки у нас должен прийти ответный пакет. Если в течение 45 секунд не приходит от соседа пакет, то мы, соответственно, с портом что-то сделаем. Сразу видно, что таймеры, которые здесь используются,

они прямо сильно отличаются от Spanning 3. То есть UDLD за время жизни пакета 45 секунд гарантированно вам односторонний отказ, соответственно, обнаружат за это время. То есть мы отправляем пакетики и говорим, через 45 секунд пакет должен вернуться. Если у нас случился односторонний отказ, то мы за время порядка 45 секунд обнаружим этот отказ и со своей стороны что-то сделаем. Ну, например, порт выключим. Почему такой таймер? Именно как раз потому, что если у нас есть стандартный Spanning 3 таймер, стандартный таймер Spanning 3 Max Age 20 секунд, то есть к нам приходили бы подушки от соседа, а сейчас перестали приходить, но порт вроде живой. Ждем Max Age, ну то есть на самом деле Max Age минус Messages, ну не суть важна. Ждем Max Age 20 секунд, после чего запускаем пересчет топологии, Forward Delay Timer, Listening Learning, каждый по 15 секунд, в итоге как раз 30. И получается, что через 50 секунд после того,

как сосед сдохнет, точнее через 49, там через 48, после того, как root перестанет, ну или не root, а designated switch перестанет присылать боподушки, тот switch, который находится дальше от урта, свой порт включат в designated. Но через 45 секунд после аварии, то есть на 5 секунд раньше, UDLD такой порт пристрелит. Таймеры не случайны, таймеры как раз специально подстроены под Spanning 3. И у UDLD есть два режима работы, один из них не нужен, второй из них агрессив. Ненужный режим называется Normal, и вы, если вдруг обнаруживать отказ, можете выполнить команду show UDLD и посмотреть на то, что у вас там что-то случилось. Как вы понимаете, чисто посмотреть, ну для этого есть протокол Spanning 3. А для того, чтобы автоматически отреагировать на односторонний отказ, нужен второй режим, который называется aggressive. Если у нас обнаруживается односторонний отказ, порт падает вар-дизейбл. Это намного лучше, чем просто информативно сообщать. У нас, кажется, там что-то с портом не то. Порт падает вар-дизейбл,

и, как следствие, петлю на этом порту уже устроить просто не получится. Вот. Сразу возникает вопрос. UDLD, значит, у нас обнаруживает отказ, и он понимает, что у нас случилась какая-то беда, то есть сосед не пингается. Если у нас таймер раз 15 секунд пингает соседа, и через 45 секунд сосед признается трупом, то может сложиться такая ситуация, что мы отправили три пакета подряд, ну, два пакета подряд, они потерялись. И, соответственно, третий пакет мы отправим, и он тоже, возможно, там как-то потеряется. И вот, чтобы не случилась ситуация вида, ну, просто три кадра подряд потерялись, потому что у нас, не знаю, линк перегружен, для того, чтобы избавиться от этой проблемы, дополнительно перед выключением, перед тем, как наступит 45 секунд, в попытке переподключения вы отправляете 8 пакетов раз в секунду. То есть, на самом деле, UDLD, когда выключает порт PowerDisable,

он выключает его не потому, что он потерял 3 пакета подряд, а потому что он потерял 11 пакетов подряд. И вот 11 пакетов подряд, если хотя бы один вернулся, то, значит, интерфейс все-таки живой, и с интерфейсом все нормально. А вот если 11 подряд потерялось, и ни одного не прошло, то это уже явно криминал, и такой порт, конечно, надо будет пристрелить. С UDLD настройки, в общем-то, достаточно простые. Вы должны будете включить автоматически на всех оптических портах команды UDLD Aggressive этот механизм, и затем, если захотите, можете таймеры подкрутить, команда UDLD MessageTime. Но таймеры по умолчанию, как уже понятно, специально подстроены под медленный Spanning 3. UDLD Port Aggressive можно включить UDLD на любом интерфейсе, не только оптическом, но сразу надо понимать, что UDLD это фирменный цисковский механизм, поэтому имеет смысл его включать только на интерфейсах фирменных цисковских, потому что если с той стороны будет не циска, то ничего не произойдет.

Он не определит, что сосед не работает. Так, да. Вы можете сочетать и LoopGuard, и UDLD. Они, на самом деле, нормально сосуществуют друг с другом. Работают они на разных, скажем, уровнях. UDLD просто пингает соседа. Если сосед перестает пингаться, выключает порт. LoopGuard говорит, что у нас должны приходить BPD-ушки. Если BPD-ушки не приходят, выключаем порт. То есть это защищает от разных отказов. Может быть такое, что сосед пингается на уровне UDLD, но Spanning 3 на нем завис, и в этой ситуации LoopGuard нас, соответственно, UDLD нас не спасет, а LoopGuard нас спасет. Может быть такое, что, например, у нас какую-нибудь ситуацию, где LoopGuard не спасет, а UDLD спасет. Сейчас соображу.

Ну да, очевидно, что если у нас не оптический линк, то есть там какой-то другой линк имеет какую-то другую природу, или сосед не цисковский, UDLD на нем не поддерживается. В этом случае LoopGuard нас спасет. Альтернативный механизм, который есть в цисках, это... А, вот еще что. Ситуация, когда LoopGuard не спасает, UDLD спасает. Если у вас был односторонний отказ, а вы этого не заметили и пересгрузили циску, вот тогда LoopGuard штатно не сработает, потому что порт, который сначала переводится в designated port, а потом только уже, соответственно, свич начинает познавать, что на этом порту никогда не должно быть роль designated, потому что LoopGuard сработал, это на самом деле не вызывает порт inconsistency. Да, сейчас вернусь на предыдущий слайд, где у нас про LoopGuard говорится. LoopGuard работает на уровне, что порт меняет роль на designated.

То есть у нас, когда мы штатно начинаем работу, все порты начинают свою работу с designated. И смысл заключается в том, что если вы этот свич только включили, вы себя считаете рутом, и вы считаете, что у вас все порты designated. То есть у вас процедура сменной роли не происходила. Если вы имели нормальную работу, и вы говорили, что у вас порт был, например, alternate портом, давайте сейчас попробую стереть с картинки, у нас был свич, ну, типа вот рутовый, свич какой-то другой, и, соответственно, два линка между этими двумя свичами. Один говорил designated port, designated port, другой говорил root port и alternate port. Вот. И у вас случился односторонний отказ. Сообщения от рута на alternate порту перестали приходить. Вы говорите, окей, значит, мы говорим, что у нас это порт не alternate, а designated, и мы говорим, что у нас раньше, если был включен loop guard на этом порту, соответственно, была роль другая, не designated port.

Сейчас мы поменяли роль на designated, поэтому мы со своей стороны фиксируем BKN состояние, что у нас inconsistency, loop inconsistency, и, соответственно, мы BPDU-шки в этот порт не отправляем. То есть мы говорим, что мы ждем BPDU-шки superior, которые придут на этот порт от рутового свича. Но теперь смотрите за руками. Мы выключаем правый свич, просто по питанию дергаем, и включаем заново. У него все порты начинают свою работу с designated, и с designated forwarding. Ну, соответственно, designated там, дискардинг, designated learning, designated forwarding. Они не меняют роль на designated. Они начинают с того, что они designated. И поэтому loop guard после перезагрузки, соответственно, не сработает. То есть он скажет, что да, вот мы до перезагрузки поборолись с петлей, а после перезагрузки мы с петлей бороться уже не можем. Мы не знаем, что раньше там на этом порту была какая-то другая роль. Поэтому вот эта вот штука включения на всех не-портфастовых портах,

она на самом деле срабатывает, потому что на тех портах, которые получили роль root или alternate, там loop guard по факту включается. Если у нас какой-то порт был, который designated, не порт фастовый, а какой-то другой, но designated, то там этот механизм ничего просто не делает. Он не спасает ни от чего. И в такой вот ситуации, да, если вы знаете, что у вас есть loop guard, вы должны будете очень быстро реагировать на ситуацию односторонних отказов. Вы должны будете смотреть влоги, вы должны будете следить за тем, чтобы у вас нигде никогда не пропустилось какое-то вот сообщение, что loop guard сработал. Потому что если вы прошлябите это сообщение и перезагрузите ваш свитч, вы получите петлю. Про это Cisco не очень любят говорить в литературе, но да, это факт. Вот. Да. Альтернативный механизм для loop guard это bridge assurance. Он не совсем прям альтернативный-альтернативный. Он, скажем, дополняет loop guard. Не столько даже дополняет,

сколько развивает идею loop guard. Вот. Смысл заключается в том, что вы на порту цисковского свитча отправляете боподушки в любом случае. Внезапно может показаться, ну и что, ну и отправляются. А то, что вы отправляете боподушки на вообще всех портах, включая на тех портах, где вы в норме эти боподушки не отправляете. То есть нормально вы отправляете на designated портах и на тех портах, которые вы получаете боподушку с пропознанным, вы отвечаете агриментом. Вот bridge assurance это механизм, который говорит, боподушки отправляются всегда. Нет смысла экономить на этих самых боподушках. Если у вас есть там какой-то свитч, не знаю, 10-гигабитный, да даже гигабитный. То, что вы раз в секунду или раз в 2 секунды отправите лишнюю боподушку по 500 байт размером, ну и хер бы с ней. То есть она не съедает полосу, не съедает ресурсы свитча. Поэтому мы отправляем боподушки на всех портах всегда, независимо от того, какие роли у этих портов будут. И вы указываете,

соответственно, что на порту вы ожидаете приема боподушек, даже если вы десигнаted порт в сегменте. Если боподушка на десигнеет два порта чужая перестает приходить, то есть вы говорите, я ближе всего к роту, я отправляю боподушку, я указываю, что я ближе всего к роту. Но вы указываете также, что на этом порту должна приходить чужая инфериор боподушка. И если чужая инфериор боподушка на этом порту не приходит, то мы такой порт выключаем. это в общем расширение идеи спальнинг 3 до того что вы фактически пингаете соседа спальнинг 3 шнурными по подушками если сосед пингается окей мы на него десерин порт включаем если сосед не пингается мы говорим да мы ближе всего круту в этом сегменте но это point to point сегменты в нем есть ровно один сосед этот сосед обязан быть свечом если соседа свеча нету то этот порт не надо переводить десерин фарвардинг его надо переводить в десерин этот блокинг потому что на этом порту у нас

инконсистенция включается это на жирных свечах то есть не на любом свече у вас bridge assurance будет характерно это для жирных свечей типа 6 тонников или 4 тонников но в принципе можно встретить на некоторых других моделях тоже вы указываете глобально что вы включаете механизм bridge assurance что вы отправляете бы подушки на всех портах спальнинг 3 bridge assurance включаете сам движок и дальше вы на уровне отдельного интерфейса указываете спальнинг 3 порт fast network давайте я напомню вам ну или даже не напомню что там напоминать я вам покажу что у нас есть наш свечек был конфт интерфейс ethernet 0 допустим спанинг 3 порт fast порт и здесь у нас есть три варианта спанинг 3 порт fast disable спанинг 3 порт

fast edge или спанинг 3 порт fast network и если вы включаете спанинг 3 порт fast edge что вы говорите на этом порту не надо принимать бы подушки никогда потому что если вы указываете спанинг 3 порт fast edge вы говорите это порт смотрит в сторону обычного абонента на нем нету портфа на нем нету бабушка приходящих в нашу сторону если спаринг 3 порт fast edge у вас есть и на нем приходит бы подушка мы говорим ой у нас соответственно администратор нам наврал на этом порту у нас ну дальше начинается что будет если у нас пришла бы подушка на под фастом парту но если у нас есть бы подушка так где мышка мышка мышка мышка да если у нас есть порт который спаринг 3 порт fast network на этом порту обязательно всегда должна приходить бы подушка если она не приходит значит у нас на порту inconsistency поэтому команды спаринг 3 порт fast edge и спаринг 3 порт fast network они друг другу противоположны по смыслу на порт fast edge порту мы говорим никогда не приходит чужая бопадушка

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

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

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

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

access ну вот в частности есть свечи которые с большей степени должны стать рутами и свечи которые с меньшей степени должны становиться рутами тут аксесс свечи рутами становиться не должны потому что если у вас аксесс свечи становятся рутами то это беда значит у вас весь distribution уже сдох в нормальной ситуации у вас приоритет акция свечей явно должен быть ниже чем приоритет distribution of поэтому distribution 1 и distribution 2 они будут смотреть диссигнатор портами на акции свечи а акции свеч соответственно одним портом будет смотреть рут портом и другим соответственно альтернатор портом если мы запускаем спанинг 3 и если у нас аксесс свеч говорит что у нас сдох рут порт то после того как запустится полноценный пересчет топологии гипотетически это должно привести к тому что у нас вместо рут порта вот этот вот спанинг 3 соответственно скажу что порту подохлый а вместо этого альтернатор порта порт будет

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

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

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

на access свеча сколько у нас юзеров обычно на штук 50 ну даже если 100 будет ну 200 ну 500 ну тысячи вот больше вряд ли поэтому 1000 кадров можно достаточно быстро отправить в сторону distribution свечей это явно будет быстрее чем устраивать смену топологии по-честному вот дальше если вы включаете этот механизм то вы обязуетесь быть никогда не быть транзитным свечом потому что если у вас есть какие-то свечи ниже стоящие то есть вы не абонентский свеч а вы какой-то транзитный свечи у вас за вашей спиной есть еще абоненты то вы тем самым влияете на топологии возможно вы будете устраивать в этом случае петлю вот оплинг фаст работает только в ситуации когда вы строите сеть по модели циско enterprise architecture и соответственно вы на аксесс свечи указывать что вы не транзитный свеч если вы включаете механизм оплинг фаст он включается глобальной системе он будет автоматически выставляет

bridge правил эти вот такое вот значение то есть он будет заведомо хуже по приоритету чем любой другой свеч ну который с дефолтными настройками будет даже 32 тысячи 768 брич про рвется 49 тысяч 152 она прям сильно хуже поэтому такой свеч никогда не будет рутом вы увеличиваете стоимость порт кост на 3000 то есть дополнительно к стоимости стандартный у вас порт кост на всех портах будет увеличиваться помните до сто 1942 если у вас работает pvst медленный то вот там будет 3100 310 19 и так далее ну и соответственно если у вас теряется root порт то alternate порт немедленно становится root root forwarding вот такой вот простой механизм на основе этого механизма дальше мы увидим несколько других механизмов будет циско построены у них смысл тоже будет заключаться в том что вы с одного порта на другой можете перескакивать почти мгновенно ну а плинг фаст он хотя и использует топологию спанинг 3 но он при

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

у нас есть просто какой-то другой альтернативный способ добраться до рута что это означает если у нас работает бэкбон фаст то в ядре вот как например нас 4 свеча в ядре у нас есть один способ добраться до рута и есть какой-то альтернативный способ добраться до рута про который мы заранее можем не знать сейчас попробую на паузу поставить нет не получится поставить на паузу или получится получилось так смотрите у нас есть рут и у нас есть соответственно наши свечи вот в нормальной ситуации у нас этот порт и сильный этот порר рут этот порт рут этот порт и сильный атт этот порт Y signaytit этот порт рут этот порт oczywiście data на гэде отправляется бп exatamente они отправляются на диах тifs партах вот сюда отправляться сюда отправляется сюда отправляется и сюда отправляется если вдруг на одном из свечей ядра дохнет интерфейс или дохнет интерфейс или max age у нас начинает соответственно истекать то есть мы

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

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

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

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

это механизм защиты из арченнала от неправильной сборки то есть на самом деле он даже не испанник 3 имеет отношения к за чинала но он использует спальнинг 3 жены бы подушки для своей работы смысл заключается в том что если у вас есть интерфейс который вы считаете что интерфейс будет из арченнала вский и соответственно у вас есть сосед который тоже так считает у вас два линка вы их объединяете в один спокой 악трр будет по такому линку работать как по одному общему проводу то есть он не знает что там два разных физических проводов он рассматривает такой композитный линк как один общий провод и соответственно трафик приложений sp desperation 3 всегда отправляется и принимается по одному тому же линку то есть вы отправляете всегда сп leben three ж towns и все пакеты по одному проводу и вы ожидаете что сосед сп Something później сообщения тоже вам будут прицеловать по одному тому же провода может быть потому же что и вы отправляете может быть по-другому но не может быть такого что соседские душки будут приходить по разным проводам ну уж в крайнем случае не может быть такого что соседские

б February будут приходить по двум разным проводам и они при этом будут не одинаковые потому что мало ли что с той стороны будет настроен нас там link is coming уж нам балансировщик будет который будет разбрасывать кадры по разным интерфейсом без привязки к приложению но не может быть такого что в из арчен лавский линк вам будут приходить сообщения и у них sender порт айди будет различаться вот соответственно с одной стороны sender порта где будет допустим единичка с другой стороны sender порта где будет двоечка и все это приходит на один и тот же логический линк если вы на из арчен или ловите несколько разных выпадушек с несколькими разными sender порта где то ваш интерфейс просто сам интерфейс портча на 1 выключается в артезе был по умолчанию эта штука включена вы можете и выключить если захотите на уровне глобальную вот как здесь спарник 3 за челнгвард мисконфиг можно сделать ноуспоник 3 за челнгарты сконфиг но эта штука хорошая выключать ее не надо она не может дать вам случайно такое

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

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

нашем случае мы видим рэпид pv ст используется ли схема секс тэнда система иди используется ли порт fast edge по умолчанию порт вас дефолт это про то как раз что все порты которые в аксессии будут по умолчанию включаться спорт фастом порт fast edge бы под угар дефолт будете ли вы защищать все портфастовые порты по под угарда ну аналогичным бы буду фильтр дефолт будете ли вы заключать порт вас твои порты порт фильтром луп гард дефолт я вам показывал что можно ее тоже включить она включается автоматически на всех point to point не портфастовых портах можно включить она в принципе не вредная по веста simulation это механизм для для мст она тоже по умолчанию включена вы можете сделать так чтобы вашем остея свитч не отслеживал приходящий по вестащие бы подушки от по вестащих цисок но да по умолчанию включена просто в рэпид pv ст она не используется если вы будете в мст переключать ваш свитч

что по веста и simulation будет как раз вам полезно опять же можно выключить по умолчанию ну хотя она по умолчанию включена bridge assurance здесь показывает что включена по идее по умолчанию должна быть выключена из арчена мисконфиг гард это вот как раз и за чел гардона по умолчанию включена проб и подушки которые приходят на разных линках пор ченнала порт паскост метод short ну вы уже знаете 119 42 а блин fast выключен был от вас выключен если вы хотите посмотреть на поведение конкретного порта то есть команда show spanning 3 интерфейс и дальше вы смотрите на тот интерфейс который у вас есть там покажется работает ли порт вас на интерфейсе там покажется есть либо под угар на этом интерфейсе бы буду фильтр на этом интерфейсе ну в общем какие то вещи про отдельный порт можно будет тоже посмотреть два одинаковых слайда что ли прикольно так а ну вот собственно да про интерфейс show spanning 3

интерфейс портфаст нашем случае портфаст выключен show spanning 3 интерфейс инконсистенции покажет выключена ли коммутация на этом порту временно в результате либо root guard либо луп гарда либо bridge assurance ну то есть до инконсистенции вполне говорящее слово и если вы хотите вы можете посмотреть show spanning 3 интерфейс detail опять же там про все будет рассказано будет рассказано что порт нас в режиме и джо вам то есть портфастовым тип линка point to point потому что это линк полно полно дуплексный по умолчанию полно дуплексные линки получают тип point to point на порту включен бы под угар на порту включен root guard ну и некоторое количество выпадушек у нас отправлены там получено вот вы можете такие команды использовать для диагностики спонят 3 давайте попробуем на нашем мст сейчас чем включить и посмотреть к чему это все приведет где у нас наши циски для начала я предлагаю

посмотреть какие механизмы у нас задействованы show spanning 3 саммари сейчас у нас включен мст и здесь показывается что свитч у нас работает в режиме как раз в режиме мст так мышка куда-то делась мышка мышка да вот мышка показывается что в режиме мст наш свитч показывается что сперл используется схема с extended system id так вот вот здесь вот я мышку не вижу поэтому прошу прощения за то что кликаю в случайные места в надежде что кликнуть куда надо дальше портфас дефолт по умолчанию вы выключен мы его не включали bp2 guard выключен bp2 фильтр выключен лоб guard выключен pvst симуляция включена опять же она работает только для мст но мы как раз в мст поэтому она у нас включена bridge assurance включен странно опять же мы его не включали из арчан он мисконфиг guard включен он по

умолчанию работает конфигурить пост пост пост метод показывается что текущий метод используют длинные метрики то есть мы 20 терабит делим на скорость интерфейса фраза очень странная что конфигуратор под пост метод short но да она означает что если бы мы работали в pvst то мы бы использовали short метрики но мы работаем вам остается по умолчанием остается пользует лонг метрики а блин fast и backbone fast выключены давайте попробуем повключать какие-то механизмы которые у нас используются если мы захотим так что такое если мы хотим включить порт fast то есть быстрый перевод порта в работащее состояние на всех access интерфейсах то мы используем команду спанинг 3 порт fast дефолт система предупреждает что-то штука временно может создать петлю поэтому надо быть

осторожным и если у вас есть линки которые смотрят на соседские свечи но эти линки почему-то в порт фасте до кратковременно петля может породиться и это может влечь повлечь за собой всякие неприятные последствия но в любом случае не через некоторое время вы опознаете что петля у вас произошла и порт такое заблокируете сейчас у нас спальник 3 порт fast edge включился на всех портах которые в аксессии работают у нас объявился режим работы порт fast объявился более более точно стандартный режим работы edge что на этом порту мы посылаем по подушки но мы не ожидаем приема этих бы подушек и такие порты мы переводим в 10 лет фарвардинг сразу но мы можем дополнительно усилить это утверждение сказав что на всех порт fast портах порт fast edge bpdu guard дефолт что на всех порт фастовых портах мы включаем bpdu guard и тогда мы отправляем по подушки на всех абонентских портах но если вдруг приходит соседская бабушка то мы

такой порт пристреливаем под им варде сейбл рекомендую определенно рекомендую две эти команды держать на всех абонентских свечах которые у вас есть если вы не проведера если вы обычное предприятие защищаетесь от вражеских бы души которые вам пользователи будут присылать не верьте ни единому слову пользователи которые начинают говорить что они рут что они вам присылают суперер бпдушку если вдруг на порту абонентском приходит вражеская бпдушка расстреливайте порт без зазрения совести дальше спаминг 3 и ну понятно да что можно включить бпду фильтр также можно включить loop guard так гарт дефолт включаем лоб гарту на всех портах которые не портфастовые у нас включается лоб гард и сейчас вот у нас как раз есть два порта которые транковые на них портфаст не включился на них должен был включиться лоб гард оба порта эти ну соответственно нас root порт и alternate порт там лоб гард как раз уместен и имеет смысл

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

указываем что этот порт смотрит не на абонента а на свеч всегда и что на этом порту абонентов быть не может спорник репорт fast edge указывает что на этом порту у нас будет только абонент но никогда не соседний свеч спалинг 3 портфас network указывает ровно противоположное что на порту всегда свеч и ни в коем случае не абонент а раз там свеч то если оттуда не приходят бы подушки со включенным bridge assurance то мы такой порт пристреливаем ну и в общем можно будет посмотреть на то что у нас в итоге получилось шоу спанинг 3 саммари мы включили портфаст но по умолчанию на абонентских портах мы включили бы под угар на портфастовых портах мы не включали бы буду фильтр на сети предприятия по умолчанию это делать не надо но и на цисковских свечах для предприятия catalyst он работает крайне некорректно если мы включаем бы поду фильтр по дефолту не надо использовать каталистовские свечи

как свечи провайдерские говорит нам циска если бы мы были например провайдером то надо было бы купить специальные свечи которые циска продает для провайдеров это свечи metrezor net это те же самые каталиста только с другим шильдиком и там по умолчанию попаду фильтр ведет себя иначе но вот на каталистах попаду фильтр ведет себя так дальше лупгард по умолчанию включили bpvst симуляция по умолчанию работает и так мы даже видели что она работает и bridge assurance вот мы не трогали он так по умолчанию вроде как работает и соответственно если мы сейчас посмотрим на то что у нас получается show спальник 3 мст 0 то мы тут возможно что то вот даже и увидим вот на эзернете 0 первом порту я вот вот она да вот на рутовом порту я включил тип network я сказал что на этом порту у нас используется связь с соседним свечом и на этом свече всегда постоянно должны отправляться бы по дружке если они

не приходят расстреливаем такой порт не переходим в диссиг на этот ну и соответственно а о еще чё забыл надо еще тип порта научить вас менять вот он в интерфейс ethernet 0 дробь 1 спалинг 3 link type здесь на слайде почему-то и не было да но вы можете объявить тип порта либо point to point либо шарит тупой означает что на этом интерфейсе можно использовать ускорение я спалинг 3 не то есть проповзал агрим это все остальное а шарит означает что на этом порту мы работаем в медленном режиме ну вот я указываю на интерфейс ethernet 10 0 1 point to point режим и теперь если я выключу на core s где у нас есть такой с коры с так так я пытаюсь угадать где я не угадал вот курс не был конфт

ethernet 0 так из ethernet 1 дробь 3 выключаю со стороны центрального свеча интерфейс который вот там был и сейчас по идее на маленьком свече я должен перестать ловить бы подушки на этом порту но если я действительно перестану ловить бы подушки на это порту то бритшу раз должен отработать не включая 10 гный этот порт так не как бы мне переключиться на эту на закладку то 3м ст 0 вот видите да ethernet 01 получил состояние bridge assurance inconsistency на ethernet и 0 первом порту перестали приходить бы подушки от центрального свеча поэтому бритшу он сказал этот порт объявлен

network портом с той стороны всегда свечи никаких пользователей в сети между нами и тем свечом нету если оттуда перестает приходить бы подушки да мы можем сказать что споник 3 говорит предписывает нам сказать что этот порт должен быть десигна этот этот порт никогда не должен становиться десигна этот в отсутствии входящего подушек ну то есть в отсутствие входящего подушек пусть даже inferior поэтому очень удобная штука если она вас поддерживается опять же включайте но опять же фирменная цисковская фигня и совершенно не факт что остальных вендоров такое тоже будет можно будет посмотреть свойства конкретного интерфейса show spanning 3 дальше интерфейс ethernet 0 дробь 1 detail и здесь вот показывается что мы знаем про этот про этот порт с точки зрения мст и он по каждому инстанцию походу на сейчас будет

прогонять и говорить как у нас все плохо что у нас bridge assurance все выключил но тем не менее до показывается что на этом порту у нас работает порт fast network режим что мы на этом порту порт fast обычно естественно не включали у нас работает на этом порту pvst симуляция у нас работает на этом порту лук гарт предпоследняя строчка ну ибо подушки отправляются там принимаются так что если вдруг у вас есть какие-то проблемы со спальнинг 3 то вот эти вот команды show spanning 3 сам решил спалинг ты и дальше название дерево либо show spanning 3 интерфейс дефил вам покажут по каждому порту его состоянии покажут почему порт находится в том или ином режиме ну на сегодня я предлагаю завершать наш рассказ про спалинг 3 толкид давайте резюмирую то что мы прошли сегодня с вами включаете порт fast на абонентских портах дополнительно защищаете на абонентских портах порт fast бы под угар дам эти механизмы прямо созданы друг для друга на портах которые смотрят на на соседей включаете bridge assurance если

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