Альтернативы STP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

железных свечей то есть и остальные железные свечи они перестают думать они говорят мы целиком по управлению подчиняемся мастеру и дальше мастер говорит нам как надо работать мы консоль к подключаемся к мастеру настраиваем настраиваем его или тел на этом подключаемся к мастеру настраиваем его а дальше конфигурация мастера автоматически скажем настраивает все остальные сливы если говорить про свечи cisco catalyst то есть несколько разных семейств внутри этого 20 внутри железок катались внутри линейки катались есть 29 60 свечи у них есть линейка который называть не линейка у них есть опция которая называется flex так есть 37 50 38 50 свечи у них стек называется стек вайс по сути своей это плюс-минус километра одно и то же но соответственно просто каждый конкретный стек он использует какие-то свои ограничения и поэтому flex так например используется только

на 2960 вы можете эту опцию купить только с 29 60 свечами стек вайс может работать на 37 50 на 38 50 свечах ну то есть на 29 60 его использовать уже не получится хотя по факту технология там одна и та же стек вайс позволяет вообще говоря объединять до 9 свечей и если вы используете стек вайс без каких-либо дополнительных буквок дополнительных всяких вот обозначений типа плюс или 480 то у вас свечи вот соединяться вот этим проводами на жопке специальными то есть они через морду соединяются через жопку и на каждом свече будет 2 2 разъема под стек видите специальным модуль который называется стек 1 стек 2 разъема именно это 29 60 свечи на 37 50 их там точно также и соответственно вы их соединяете по схеме в кольцо то есть у вас там первый свечи на нем две дырки второй свечи на нем две дырки третий свечи на нем две дырки 4 свечи на нем две дырки и так далее и вы говорите вот мы их вот так вот

соединяем и соответственно здесь вот так вот и в такой ситуации у нас каждый вот этот провод будет иметь пропускную способность обычный стек вайс на 37 50 встречается до 32 гигабит в секунду то есть это специальные быстро интерфейсы которые соединяются штатно в кольцо которые заставляют эти все железки управляться как единое целое и повод этим бэкбон линком у вас производительность передачи трафика будет достаточно большой учитывая что стек передает на очень высокой скорости данные а сами 37 50 свечи на самом деле они как правило с 100 мегабитными линками и у них два там допустим гигабитных link получается то по факту да даже если мы на 48 портов это размажем плюс еще там 2 гигабитных линка у нас будет то 32 гигабита для бэкбона это в более чем достаточно вот есть разновидности этого стек вайза есть вот например для 38 50 свечей более продвинутая версия его который называется стеклась 480 проблема

заключается в том что 38 50 свечи они сами намного быстрее чем 37 50 изначально если 37 50 32 гигабита было более чем достаточно то что у него 100 мегабитные порты были потом с гигабитными портами ну как бы там тоже получается да не то чтобы прям уж очень хорошо но тоже 32 гигабита как бы плюс-минус километр еще дотягивала там берете 248 портовых гигабитных свеча уже начинается вопрос до что 32 гигабита между двумя свечами и 48 гигабит трафика на каждом свече но как-то не бьется вот но 38 50 и они вообще бывают 10 гигабитные поэтому там уже прям совсем большая проблема с производительностью этого стека было поэтому для 3850 сделали отдельную версию стеклой за 480 гигабит в каждом вот этому шнурке это уже больше похоже на правда опять же вы можете взять и соединить несколько свечей 10 гигабитных в том числе этими самыми жопными линками у вас вот до 480 гигабит интерконекта между свечами получается flex

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

на них общий дата plane и получается что вы двумя ногами смотрите фактически в один и тот же свеч вам там споник 3 не нужен вы обвиняете все это дело в порт ченнел радуйтесь жизни то есть если вы объединяете две железки в стек то все другие железки которые порт ченнелами смотрят на компоненты этого стека они на самом деле нормально работают даже несмотря на то что физически они смотрят два разных железных свеча есть для специально для access свечей расширение этого штуки который называется стек power но это не то что расширение это отдельная тема скажем что вы можете помимо стекирование самих вот железных свечей помимо стекирования коммутаторов объединить еще и бюджеты power over azar net то есть у вас на там на access свеча может быть свой собственный питальник то например там 750 ватт а вам надо побольше туда питание догнать вот в этом случае вы можете одолжить немножко питания у соседних свечей с помощью опции стек power до отличительной особенность этого механизма

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

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

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

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

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

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

коробки они будут иметь номера gigabit 2 дробь 0 дробь 1 то есть у них номер порта сохраняется номер модуля сохраняется а вот номер коробки изменяется и в такой ситуации когда вы указываете что у вас есть свечи железные которые входят в наш стек получают какую-то другую нумерацию вы можете к этим портам обращаться как своим собственным то есть вот эту штуку вы на мастере выполняете вот switch конфиг он на самом деле мастер вот вы указываете что вы присоединяете свечи с вот такой вот моделью как второй номер и дальше вы видите его номера портов gigabit 201 202 203 и так далее судя по всему 12 портовый свечи 3750 g и вот шел свечи команда показывает да что мы мастер у нас здесь рядышком есть еще второй свеч который слэйв у него тоже мак адрес какой то есть какой-то приоритет какой-то вот версия и текущее

состояние тоже рейси значит все хорошо ну и показывается на каждом железном свечи какие стекируем и порты у вас на каждом свечи работают какие нет то есть на каждом свечи возвращаясь к предыдущей картинке у нас есть два железных порта один порт соответственно левой другой правой вот и здесь показывается show switch stackport summary что на железном свеча первом у нас есть первый и второй порт и на железном свеча 2 у нас есть первый и второй порт судя по всему здесь два железных свеча соединены одним проводом и у нас на втором проводе где-то случилась беда разрыв ну судя по тому что порт и в да у них просто не соединили никем ну и да и показывается длина стекируемого кабеля 50 сантиметров и кейбл лент здесь три метра ну на самом деле даже просто никуда в никуда эти парты смотрят и все link ok link active ну в нашем случае link active показывает да нормально ли на этом линке обнаружено

что-то и показывается если обнаружено что-то то кто именно обнаружен альтернативный вариант что можно сделать если у нас есть два свеча который нам хочется объединить в одну логическую сущность это в сс так в с не вертол свеч систем это механизм который будет альтернативен стекам на более жирных свечах стекированию поддаются модели 3750 3850 2960 2960 2960 немножко урезанный стек который называется flex стек ну вот 3 3 3 линейка 3750 3850 у них стек войс на старших свечах шеститонниках нету стеков иногда очень хочется заиметь что-то аналогичное стеку и для этого есть вот штука которая называется virtual switch system вы берете 26 тонника или 4 тонника и объединяете два шасси две коробки в одну

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

отличие от стека у в с с объединяются только плоскости контрол плейна то есть при этом плоскость управления management plane у них по факту будет общее но вы можете подключиться консоль к к любому из этих свечей и там что-то понастраивать при этом по факту вы будете настраивать только один супервизор также как и в случае с настоящим стеком железным здесь будет использоваться контекст управления свеч то есть show switch вы можете посмотреть для просмотра стака show switch virtual вы сможете посмотреть virtual switch system показывается соответственно что у нас в с с на этом свеча работает показывается номер домена как ни странно несмотря на то что в с с коробки можно соединить только две есть такая штука как номер домена и вы можете сказать к какому именно домена относится ваша конкретная коробка зачем

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

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

соответственно они будут считать что у них одинаковый айпишник там допустим 10 0 0 1 здесь 10 0 0 1 они будут адонсировать одни и те же сетки ну и да вот эта вот штука называется brain split когда у вас случается dual active vss то есть дул дуал актив это ошибка такого быть не должно и в нормальной ситуации у нас по в сс у свечи договариваются virtual switch link договариваться кто из них актив кто из них стендбай если в сель падает соответственно они оба считают себя активными и считают что сосед просто сдох ну и соответственно у нас это приводит к очень неприятным последствиям в частности это будет приводит к неприятным последствиям если у нас есть опять же какие-то абонентские свечи которые объединяют два провода в портченнел вот это у нас оба access switch и 2 шести тоника

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

хотите посмотреть как он работает вот show switch virtual покажет вообще работает он или нет и и show switch virtual link покажет состояние virtual link а самое важное здесь vsl статус справочно показывается uptime показывается какой порт вы используете и используете ли вы шифрование по умолчанию она не используется но можно настроить так можно посмотреть кто вы и как вы работаете show switch virtual roll покажет что у вас в сс работает нормально обнаружен один сосед и соответственно вот система в сс работает что мы первый switch сосед который обнаружен это свечи 2 здесь настроены приоритеты мы стали мастер свечом стали вот этим активом потому что у нас настроен приоритет 200 ну опять же да у кого больше что ты прав поэтому мы выбрались активным свечом и соответственно у нас стендбай свеч сосед у которого приоритет немножко поменьше так вот сюда dual active recovery mode dual

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

и она все-таки уже в меньшей степени зависит от поведения соседних устройств смотрите в чем смысл если у нас есть два ну например тех самых 37 50 38 50 их свеча пусть например 48 бортовых 30 там 8 50 48 портов одна железка и 3850 тире 48 вторая железка мы их можем соединить между собой например в стек у нас получится как бы один большой мега свеч можем даже двумя проводами их соединить стек у нас получится такой отказоустойчивый стек но если у нас прямо много этих 38 50 их больше чем 9 штук там их в стек уже в один соединить не можем и в такой ситуации мы как правило говорим что ну по-хорошему надо тогда уже поднимать полноценный l3 поднимать между всем этим самым делом там у спи ф или биджи пи или еще какую-нибудь хрень и у нас получается каждая коробка независимая если вдруг она отваливается мы соответственно до потеряем доступ к тому что за ней было но при этом вся остальная система продолжает

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

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

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

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

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

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

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

данности получалось сократить время переключения с одного супервизора на другой с нескольких минут до там примерно 40 секунд механизм достаточно простой тупой ну да появился лет наверное 15 назад может чуть поменьше но действительно сократил время переключения с одного супервизора на другой заметно лет десять назад появилась фича который называлась стейтфул свеча over эта штука которая одновременно загружает два супервизора то есть они оба переходят в ап по факту forwarding information base формирует только один а второй просто копирует к себе всю информацию которая есть у основного если основной сдохнет то переключение на запасной происходит практически мгновенно но не при не совсем мгновенно там за единицы секунд это происходит просто потому что у вас на запасном супервизоре все таблицы будут заполнены у него все таблицы соседей заполнена все таблицы там и лосейк воспитывая заполнена вся таблица макадресов заполнена то есть он находится в таком горячем резерве да он

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

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

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

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

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

предполагают перекладывания разных сущностей между разными интерфейсами которые позволяют использовать петли я сейчас естественно намекаю на протокол айпи интернет-протокол протокол меж сетевого взаимодействия если у нас есть один линк нас есть другой линк у нас есть третьи линк ну три линка три разных провода перекладывать между ними кадры надо не кадры только уже специальные сущности которые предназначены для перекладывания между разным легенками мы используем и пив которым есть ттl в котором есть маршрутизаторы в котором есть таблицы маршрутизации которую можно заполнить с с помощью BGP, OISPF и прочего. Все эти технологии, они штатно заточены под перекладывание пакетов между разными проводами. Ethernet не заточен под перекладывание кадров между проводами. Ethernet – это протокол, который создавался для толстого желтого коаксиала. Каждый раз, когда вы говорите, давайте мы перекладываем кадр из одного провода в другой в Ethernet, вы эмулируете толстый желтый коаксиал.

Вот эмулировать толстый желтый коаксиал, который формирует петлю, нельзя. Да, вы должны будете разрывать эту петлю с помощью Spanning 3, либо использовать другие протоколы типа того же Virtual Switch, Virtual Switch Link или стекирование для того, чтобы каким-то образом более элегантно разбираться с трафиком, который в эту петлю приходит. Но все это, еще раз повторю, либо Spanning 3, который блокирует все, кроме одного способа доставить трафик до центра звезды, либо черная вендорская магия, которая неизвестно, каким образом себя поведет в каждой конкретной ситуации. Я вам рекомендую для, скажем, упрощения всего-всего-всего отказываться от коммутации Ethernet, который не предназначен для коммутации, и переходить к маршрутизации IP, который для маршрутизации изначально был предназначен. Вот такой вот кратенький рассказ про то, что делать, если очень не хочется использовать Spanning 3. А Spanning 3 использовать очень редко, когда хочется, потому что деньги платим за много проводов, а он, собака, страшно все блокирует.

Но, тем не менее, да, Spanning 3 совсем выключать не надо. Как минимум, до портах доступа пусть остается, пусть работает. Ну, а вот между портами доступа и дистрибьюшеном уже имеет смысл гонять IP. Используйте маршрутизацию на аксессии, будет вам счастье.