Безопасность (часть 2)

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

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

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

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

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

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

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

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

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

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

Так что наличие петли, оно сразу, даже каждый отдельный маленький пакетик порождает много-много-много-много-много-много раз обработку одной и той же копии кадра, которая идет по часовой стрелке на каждом свече и против часовой стрелки на каждом свече. То есть вы отправили один кадр, а дальше каждый свитч эту копию кадра обрабатывает, ну вот в зависимости от своей скорости, допустим, 10 миллионов раз в секунду или 10 тысяч раз в секунду, не важно сколько. Отправили один пакетик, 10 тысяч раз в секунду вы обрабатываете копию этого кадра. Отправили еще какой-то другой пакетик, может быть, какой-то другой узел его отправил, не важно кто. Главное, чтобы на эти свитчи, формирующие петлю, этот кадр попал. Снова вы начинаете каждую из копий нового кадра тоже обрабатывать 10 тысяч раз в секунду. Если у вас, соответственно, свитчи достаточно мощные и каналы связи между ними достаточно быстрые, но время обработки каждого кадра не очень большое, если наоборот не очень маленькое, то вам потребуется достаточно большое время для того, чтобы полностью эту самую петлю заполнить вашими браткастами.

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

В кадре Ethernet нет никакого идентификатора, который позволил бы коммутаторам понять, что это копию они уже обрабатывали, и не надо с ней больше ничего делать. То есть Ethernet на уровне физической топологии требует, чтобы у вас петель не было. Как бы там ни было, вы обязаны предоставить ему сеть без петель. Если петля появляется, Ethernet от этого дохнет. Вот тут простой довольно сценарий. Если вы допустили формирование петли, ну вы сам себе злобный буратино. Да, можно заметить, что в принципе браткасты будут всегда выдавать такое вот явление. А соответственно с Unicast, с Unown Unicast кадрами, которые будут Unicast владиться, в принципе все то же самое будет. То есть главное, что вы не знаете, куда такой кадр девать, поэтому вы разбрасываете этот кадр по вообще всем портам. Если вы отправите какой-то кадр на MAC-адрес FFFFFF, он в таблице MAC-адресов никогда не будет присутствовать. То есть вы его всегда будете в этой самой петле гонять по кругу. Если вы будете отправлять на какой-то MAC-адрес, которого просто в сети нету, неважно Unicast он будет или допустим Multicast вы отправляете,

его опять в таблице MAC-адресов не будет. Поэтому вы его будете опять гонять и гонять и гонять по кругу. Если же вы отправляете кадр какой-то Unicast и свечи ничего не знают про этот MAC-адрес, они его начинают гонять по кругу, но потом от этого самого Unicast кадра приходит какой-то MAC, в смысле от этого Unicast мака приходит какой-то кадр, все свечи начинают примерно понимать, что это совсем неизвестный MAC и что-то будет другое происходить. Что будет происходить с известными Unicast маками, мы сейчас отдельно разберем. Но вот Unicast точно будут зависать в петле и Broadcast точно будут зависать в петле. Тут без вариантов. Вторая проблема, которая у вас будет, это множественные копии одного и того же кадра. Как это будет выглядеть? Допустим, у вас есть какой-то кадр, который вы отправили. Например, это может быть Broadcast кадр. Вы его отправили в петлю, дальше он в этой петле начинает крутиться в двух экземплярах, как мы помним, по часовой и против часовой стрелки.

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

ну допустим, там не знаю, у вас 10 гигабит канала, представьте себе, вот они рано или поздно забьются Broadcast'ами целиком и полностью. И соответственно, каждый из свечей будет обрабатывать Broadcast'овый поток 10 гигабит. А дальше у вас будут абоненты, которые сидят на скорости в, допустим, 100 мегабит или в гигабит, неважно. Главное, что обычно связи между свечами более быстрые, чем связи свеча с абонентом. И соответственно, получается, что в каждой из портов у вас будет напихана на исходящий буфер очередь из Broadcast'овых кадров. И эта очередь будет полностью забита. А если вдруг даже какой-то интерфейс до абонента сможет отправить какой-то кадр, с очень большой вероятностью это место, освободившееся, снова будет записано Broadcast'ом. Поэтому каналы до абонентов будут скорее полностью забиты Broadcast'овыми кадрами. Никакие Unicast'овые кадры до абонентов, даже если вдруг свечи смогут их поставить в очередь, в смысле не поставить в очередь, даже если смогут их правильно получить и правильно прокоммутировать,

они не могут быть поставлены в очередь на отправку, потому что там уже все забито Broadcast'ом. И каналы до абонентов, да, они более медленные, чем между свечевые линки, и они будут забиты ненужными Broadcast'ами. Соответственно, у вас абоненты перестают получать нормальный боевой трафик. Да, абоненты по-прежнему могут отправить кадр в сторону свеча, но обратно получить ответ они уже не могут, потому что они получают ненужные Broadcast'овые кадры. Более того, эти Broadcast'овые кадры, которые будут приходить, они же, еще раз подчеркнем, нет возможности определить, что конкретный абонент их уже получал и их уже обрабатывал. Что делает абонент? Он берет, получает какие-то нулики-единички, формирует из них кадры, видит в этом кадре, MAC-адрес-получатель, Broadcast, говорит, «О, Broadcast, мне это тоже нужно». Видит внутри, соответственно, вложение 0800 протокола IP, говорит, «Ага, я сейчас возьму вот это самое вложение, которое там есть, допустим, полтора килобайта или сколько-то, неважно, передам в сторону обработчика IP и дерну его хендлер,

что вот, дорогой IP, я тебе принес, посмотри, пожалуйста, что внутри». IP смотрит, чего внутри, видит там, допустим, не знаю, что он может там видеть. Давайте, допустим, DHCP, там запрос будет. Вот IP пришел, соответственно, к нему Ethernet, говорит, «Я тебя притащил что-то». IP говорит, «Да, слушай, что-то пришло, да, действительно, я возьму, я прочитаю внутри того, что пришло, этот самый чек-сумму, интернет-хейдер, да, я вижу, что чек-сумма сошлась, я вижу, что это адресовано мне в том числе, потому что IP-адрес получателя 255, 255, 255, 255, local broadcast. Я это пытаюсь воспринять как правильный легитимный IP-пакет, я, соответственно, должен посмотреть, что внутри, вижу внутри UDP-шное вложение 17 в поле протокол, срезаю заголовок IP, передаю обработчику UDP, обработчик UDP говорит, «Ага, я вижу, да, действительно,

пришел UDP, UDP-датаграмма пришла». У нее чек-сумма правильная, у нее номер порта, на который оно пришло, там 67. А кому 67-й порт принадлежит на нашем компьютере? И тут до большинства доходит, что, в общем, 67-й порт никто не слушает. Да, у нас есть теоретический DGCP-сервер, но этот самый сервер, он всего один, а все остальные абоненты, которые получают много-много-много-много копий DGCP-запросов, на них 67-й порт никто не слушает. Ну и в этом случае все ваши вот эти абоненты одновременно говорят, «Блин, а что ж мы столько напрягались? Чек-сумму кадры изернет считали, дергали обработчик IP, это же переключение контекста, это все неприятно». А дальше, это самое, чек-сумму IP считали интернет-хедер, смотрели, что внутри лежит, видели UDP, дергали обработчики UDP, перекладывали содержимое из одной области памяти в другую, опять переключение контекста, опять все. Потом чек-сумму опять интернет-хедер считали UDP-шную, снова определяли, что действительно данные пришли правильно,

и только потом мы понимали, что, в общем, мы все это делали зря. Поэтому в случае с множественными копиями кадров у вас действительно бродкасты в основном будут отправляться абонентами, каждый раз абонент будет сидеть и долго думать, «что он такое делает, почему он такое делает?», а главное, ему это все будет не нужно. Большинство бродкастов, которые ему были отправлены и которые были ему интересны, он прочитал в первый раз, а все остальное ему интересно уже не будет. Если, соответственно, даже вдруг бродкасты интересны, это еще хуже. Представьте, что вы DHCP-сервер, и к вам приходит кадр, соответственно, который действительно вам интересен, который DHCP-запрос, и вы видите каждый раз, что к вам приходит миллион DHCP-запросов в секунду. Да вы повеситесь, пока будете эти самые DHCP запросы обрабатывать. У них у всех будет идентификатор запроса одинаковый. И пока вы дойдете до того, что у вас там сначала обработал все это дело обработчик Ethernet, а потом передал все это дело на обработчик IP, обработчик IP дернул обработчик UDP, обработчик UDP дернул обработчик DHCP. И DHCP сказал, а я это уже видел, у меня идентификатор в этом пакете,

такой, которому я уже выдал предложение. Но, наверное, он просто тупит. Наверное, он не получил мой ответ с предложением адреса DHCP-оффер. Наверное, ему надо переотправить этот самый оффер. И вы ему в ответ оффер кидаете. Вот приходит к вам миллион запросов в секунду, вы ему миллион офферов кидаете. Ну вот для тех, кому это неинтересно, у них ситуация как бы получше. Для тех, кому это интересно, ситуация становится просто катастрофической. Вот. Так что, вот есть такой вот момент, что Unicast-овый трафик перестает ходить, а Broadcast-овый трафик забивает все интерфейсы, забивает полностью ресурсы абонентов. Если абоненты слабенькие, то есть представьте себе, что там у вас какой-нибудь маленький, маленькая железочка, не знаю, какой-нибудь сенсор стоит или какая-нибудь веб-камера. Она все, что приходит, обрабатывает на своем маленьком центральном процессоре. Центральный процессор у нее, ну какой-нибудь там 400 МГц. Это еще хороший процессор, а то еще и меньше.

И вы на нее кидаете там, допустим, 100 Мбит DHCP-запросов. И каждый запрос она должна обработать. То есть она должна дойти до того, что на ней нет того, что способна обработать 67-й порт UDP-шный. Вот чек-сумы все просчитать, убедиться, что это все правильно, контекст передернуть много-много раз. И вот только ради того, чтобы понять, а это все на самом деле не ей. Поэтому множественные копии кадра, они тоже будут в петле вызывать проблемы. Нормальный трафик фактически ходить перестает. Ну и последнее. Даже если вдруг вы берете такую сеть, которая супер-сверхмощная, или у вас браткасты редко отправляются, или не отправляются даже вовсе. Вы отправляете юникастовый кадр от узла А, например, до узла Б. И предположим, что это кадр, который пока что unknown unicast. То есть хотя бы один раз этот кадр пройдет по петле,

потому что свечи пока еще не знают, кто где сидит, и, соответственно, разбросают его по всем портам. Или узел А отправляет браткаст. Что произойдет с таблицей MAC-адресов на наших свечах? Произойдет следующее. Узел А отправляет, ну, допустим, браткаст. В этом браткасте написано MAC-адрес получателя FFFFFF, MAC-адрес отправителя, MAC-адрес А. Вот этот вот свеч получает кадр и говорит, я получаю кадр. Соответственно, я должен записать, откуда пришел кадр. Записывая, что узел А сидит вот за вот этим вот портом. Пока все честно. Дальше разбрасывает браткастовый кадр по всем портам, как он это должен делать. У вас одна копия кадра уходит вот сюда, другая уходит вот сюда. В принципе, обе копии этого кадра дальше будут вызывать проблемы. Но мы сейчас разберем только одну из них. Одна из копий кадра уходит против часовой стрелки на один из свечей, оттуда на другой. И оттуда возвращается на наш оригинальный первый. Вот этот вот свеч, за которым реально сидит абонент А, он что делает?

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

И пока узел А не отправит еще какой-то один юникастовый кадр, или неважно какой кадр, он просто пока не отправит какой-нибудь кадр и не покажет свой MAC, вот этот вот свитч будет думать, что абонент А сидит на самом деле за неправильным портом. И когда до абонента А придет какой-нибудь юникастовый кадр за чем-нибудь, вот допустим узел С, попробует отправить юникаст к компьютеру А, и даже, допустим, этот кадр попадет каким-то образом на нужный нам свитч, вот этот вот свитч скажет, а что ты мне присылаешь это? Хотя ты на самом деле сам должен знать, как доставить трафик до этого абонента. У меня показано в моей таблице MAC адресов, что абонент А сидит вот здесь. А дальше они начнут друг другу посылать этот кадр, и этот кадр на самом деле почти никогда не будет выходить из этой самой петли. То есть даже юникастовые кадры в этой самой петле будут зависать. Тут может быть сценарий вида. Юникастовый кадр был отправлен верхним свитчом нижнему,

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

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

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

Но все остальные абоненты от сдохшего одного абонентского свитча страдают не сильно. То есть, там у вас тысяча портов, условно, 50 коммутаторов по 20 абонентов на каждом. Вот один коммутатор сдох, да, 20 абонентов потеряло доступ к сети, но остальные 980 нормально работают. Если же вы берете и строите сеть, как мы сказали, по модели access свитчей, distribution свитчей, core свитчей, вот на тысячу абонентов вы берете и те самые 50 свитчей подключаете к одному достаточно большому дистрибьюшн свитчу, и у вас этот дистрибьюшн свитч дохнет. Соответственно, все абоненты разваливаются на отдельные куски, никак не связанные друг с другом, не могут выходить никуда, ни на сервер, ни в интернет, ничего с ними не сделаешь. Вот если у вас, соответственно, есть такой важный свитч, который хочется защитить, то вам наверняка захочется сделать так, чтобы этих свитчей было, ну, хотя бы два. Чтобы у вас каждый абонентский свитч подключался к двум дистрибьюшн свитчам. Вот. Тут возможен сценарий вида, а что будет, если у нас, соответственно,

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

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

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

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

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

Вот. Можно будет сделать следующее. Можно будет включить протокол Spanning 3 и заблокировать ненужные порты. Иногда это хорошо. Но у Spanning 3 есть ряд очень неприятных особенностей. В том числе и то, что первая версия Spanning 3, которая была придумана, а это далекий 1985 год. Да, его действительно придумала женщина. Есть легенда про то, что она придумала его за один вечер, ну общую логику работы. А еще неделю она допиливала эти самые особенности, всякие нюансы работы. Ну и в итоге получилось, что вот действительно за неделю этот самый протокол был в основном написан. Сказать, что придумала она его плохо нельзя. То есть на 1985 год это было очень круто. То, что вот действительно Spanning 3 позволяет защититься от петель. Опять-таки не забудьте, что 1985 год придуман Spanning 3. 1983 год стандартизирован Ethernet. То есть это технологии, которые появились практически одновременно. И Spanning 3 вообще говоря не завязан на использовании обязательно Ethernet.

Он может использоваться с любую технологию, в которой есть MAC-адреса. То есть фактически любую технологию семейства 822 комитета. Технически можно сделать Spanning 3 допустим с Wi-Fi. То есть это бредово звучит, но это можно сделать. Или там допустим с Bluetooth тоже можно сделать. В реальности Spanning 3 получил распространение именно для Ethernet. Хотя изначально Spanning 3 не писался для того, чтобы с Ethernet работать. Он писался для любой технологии семейства 822 комитета. И соответственно этот самый Spanning 3 1985 года он был придуман для того, чтобы защитить вас от петель. Но он не был придуман для того, чтобы защитить вас от петель быстро. То есть он решает задачу достаточно долго и нудно. Та версия, которая была придумана в 1985 году, она допускала падение сети от возникновения петли. Или скажем от подозрения на возникновение петли. На время до 50 секунд.

Ну скажем 50 секунд никогда не было. Там 49 если уж совсем честно быть. Вот максимальное время, на которое он может выключить сеть, если вдруг возникла петля. 49 секунд. Но на самом деле в большинстве сценариев это будет чуть побыстрее. То есть он будет приблизительно 30 секунд реагировать на каждую смену топологии. Если вдруг она у него возникнет. Вы подключаете какой-то порт. А он говорит, а я вижу порт поднялся. Надо бы его проверить на то, что не формирует ли этот новый порт петлю. И кладет вам сетку на 30 секунд. А потом соответственно она через 30 секунд поджигается и начинает работать. А потом кто-то еще прибегает и говорит, а я тоже готов работать. Я тоже поджигаю порт. И снова вы включаете сеть на 30 секунд. И снова через 30 секунд оно начинает работать. В 1985 году такой подход был возможен. В 2015 году, спустя 30 лет, от Ethernet ожидается несколько больше, чем то, что он иногда работает, но иногда может на 30 секунд взять и упасть.

То есть технологии шагнули далеко вперед. Ожидания от этих технологий тоже шагнули далеко вперед. И если вы возьмете там какой-нибудь, допустим, 100 гигабитный канал и его уложите на срок в 30 секунд, вы можете сами посчитать, сколько трафика вы потенциально потеряете. 100 гигабит умножить на 30 секунд это 3 терабита. Вот потерять 3 терабита просто потому, что Spanning 3 вздумалось, а не случилось ли там петли, это очень-очень дорогое удовольствие получается. Поэтому, соответственно, в реальном мире вы Spanning 3 именно в версии 1985 года использовать не будете уже никогда. Важный и тонкий момент. На многих коммутаторах, которые вы будете покупать, Spanning 3 по умолчанию работает и работает именно в медленном режиме в 1985 году. То есть 2015 год. Cisco продает коммутаторы Catalyst, на них работает медленный Spanning 3 по умолчанию. То есть если вы возьмете и купите Cisco в надежде, что Cisco такой крутой производитель, гламурный, правильного цвета коммутаторы, правильный логотипчик на них,

повключаете в сеть и оно у вас будет поджигать эту самую сеть раз в 30 секунд. Свитч уже загрузился, коммутировать уже все можно. А он еще не принял решение, что петель нету, даже если этих петель вообще нету. То есть он просто видит, что два коммутатора есть в сети, допустим. Он все, он говорит, я вижу BPD-ушки приходящие, объявляем выбор рута, объявляем выбор рут портов, designated портов, проходим состояние listening learning. И вот только через 30 секунд после того, как все завелось полностью, начинается фарвардинг кадров. Если вдруг вы там третий свитч подоткнули, все, сразу выключаем полностью всю сеть, начинаем снова перевыбирать рута, начинаем рут порты перевыбирать, designated порты. То есть медленный Spanning 3 действительно в 2015 году все еще встречается. И вы должны будете знать, в каких случаях у вас по умолчанию на этом самом свитче работает какой протокол Spanning 3. И если вы знаете, что он у вас медленный, искусственно переключать его в быстрый режим.

Быстрый режим это 2000... нет, вру. 98-й год и 2004-й год. В 98-м году был придуман Rapid Spanning 3. И в 2004-м году был адаптирован этот самый Rapid Spanning 3 до того, чтобы работать хорошо на нынешних сетях с нынешними, скажем, масштабами. Ну тоже 10 лет, в общем, не так мало. Но, по крайней мере, те версии, которые есть сейчас, они более-менее актуальны. 2008-й год, там еще год изменений были. Что в Rapid было допилено по сравнению с обычным Spanning 3 и с медленным? Хороший вопрос, там можно много чего рассказать, но в основном там используется следующая вещь. Тот Spanning 3, который придумали в 85-м году, он использует то определение Ethernet, которое изначально для него было. Это был этот самый Ethernet с общей шиной. То есть коаксиальные провода длиной 200 метров, на них подключаются абоненты. И у вас может быть такое, что вот есть Bridge.

Bridge это такая железка, которая на уровне центрального процессора берет и перекладывает кадр. То есть фактически то же самое, что и Switch, только на программном уровне работало. Вот если вы, соответственно, взяли бы компьютер и в компьютер воткнули три сетевые карточки, поставили бы операционную систему Windows на этот компьютер. И три сетевые карточки выделили мышкой в перечисление адаптеров и сказали бы Bridge. Вот у вас получился бы софтовый Switch, который бы принимал кадры на одном интерфейсе и отправлял бы кадры с другого интерфейса. Да, кадры были бы одинаковые, но вы эти кадры просто бы клонировали. С одного интерфейса на другой перекладывали. Вот Switch делает то же самое, только быстро. У него нет центрального процессора, который занимается этим всем делом. Он оперирует аппаратным чипом, который аппаратно берет кадры, читает с одного порта и перекладывает на другой. Та же самая техника, только быстрее намного. Sparring 3 говорит именно про бриджи. У него нет термина Switch, у него есть термин Bridge.

И ему не важно, какой это бридж. Софтовый, железный. Да, я понял, что вопрос был по-другому. Я сейчас расскажу тогда разницу обычного и Rapid, а потом расскажу про изменения в Rapid, которые происходили позже. Соответственно, чем Rapid отличался от обычного Sparring 3? Он отличался тем, что работал не с общей шиной в основном. То есть он стал поддерживать физические каналы, точка-точка. Обычный Rapid Sparring 3, Common Sparring 3 1985 года. Он ожидал, что у вас везде будут топологии с общей шиной. Он не знал ничего про Point-to-Point каналы в Ethernet. И он, соответственно, ожидал, что у вас может быть 3 бриджа, которые друг на друга смотрят одним проводом. У вас есть провод, и в этом проводе 3 типа свеча. Например, коаксиальный провод. И, соответственно, если вы отправляете какие-то данные в провод,

то вы не можете просто получить один ответ «Да, я твои данные услышал». Вы даже не можете сказать, сколько этих ответов должно быть. Вы не можете отправить вопрос вида «Чуваки, кто меня услышал, поднимите руки» и услышать, допустим, 4 ответа «Я тебя услышал, я тебя услышал, я тебя услышал». Потому что непонятно, сколько этих соседей будет. В Sparring 3 нет процедуры установления соседства, как, например, в SPF или в EJRP. Вы просто отправляете какой-то пакетик и ожидаете, что соседи точно услышат. А на случай, если вдруг вы отправили пакетик, а он потерялся по дороге, потому что там наводка какая-то прошла или что-то еще, вы этот пакетик отправляете много раз подряд. Испарник 3 обычный, который работает поверх общей шины, он действует следующим образом. Давайте мы отправим достаточно много пакетов, так чтобы точно все, кто в этой сети есть, точно нас услышали. И он будет оперировать понятием «таймер». Мы говорим, что если мы будем отправлять, допустим, пакетики раз в 2 секунды,

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

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

а их всего один, потому что это Point2Point канал, они все точно получили ваше сообщение. Вот если вы точно знаете, что у вас на порту все получили ваше сообщение, вы точно знаете, что с соседом вы работаете в общей логике, вы можете сразу порт включить или сразу порт там выключить, например. Потому что вы будете знать, что сосед с вами синхронизирован, других соседей там нету, и, соответственно, если вы сразу порт разблокируете или порт сразу заблокируете, это будет правильно. Вот такого рода допущение было в RapidSparing 3 98-го года. Там появился механизм вопрос-ответ, то есть вы отправляете сообщение и получаете на него ответ сразу. И тем самым RapidSparing 3 избавился от необходимости использовать таймеры. А если вам больше не нужно использовать таймеры, то, соответственно, сообщения, которые будут разбегаться по сети, они будут разбегаться вот со скоростью, сколько вам нужно на то, чтобы сообразить, что надо что-то отправить соседу. У вас произошло событие вида интерфейс упал. Как мы помним, 48 миллисекунд максимум вам на это будет нужно.

Ну, там плюс-минус немножечко, там 50 миллисекунд. Обычно говорят про то, что Spanning 3 успевает потратить на то, чтобы обработать событие упадения интерфейса. И вы отправляете вашему соседу по PointToPoint каналу сообщение. У меня упал интерфейс. Давай перестраивать топологию. И сосед вам сразу отвечает. Я тебя понял, давай перестраивать топологию действительно. И друг с другом сразу договаривайтесь, что вот кто-то из вас, допустим, один оставляет канал рабочим, а кто-то другой блокирует. Или наоборот, вы оба сразу оставляете канал рабочим, потому что вам нужно между собой трафик передавать. Этим будет отличаться протокол класса Spanning 3 обычный, Common Spanning 3, от того, который быстрый, Rapid Spanning 3. В любом случае, логика у них будет одинаковая. То, что они делают по факту. Они определяют, какие порты входят в петлю. И из каждого физического домена коллизий, который у вас будет, из каждого, условно говоря, провода, если мы говорим про PointToPoint каналы, или зоны, в которые распространяется электрический сигнал, допустим, с хабами,

это вот пачка хаб плюс провода к нему подключенные. Ну, домен коллизий. Вот это все будет в терминологии Spanning 3 называться сегментами. В каждом сегменте у вас остается только один порт от свеча, который в этот самый сегмент смотрит. И этот порт будет называться designated портом. А все остальные порты, которые в этот самый сегмент будут смотреть, они будут выключены, будут заблокированы. Тем самым вы не позволите формировать петлю. Вот. Общий принцип работы у всех протоколов Spanning 3 одинаковый. Определяем главный центральный коммутатор, определяем, скажем, кто на этот центральный коммутатор выгоднее всего смотрит. В каждом сегменте оставляем один designated порт. Самый выгодный способ добраться туда тоже оставляем включенным, все остальное выключаем. Обычный Spanning 3 делает это с помощью таймеров. Rapid Spanning 3, при условии, что у него везде поголовно каналы PointToPoint, будет делать это на основе сообщений вида «Ты понял, я понял». Есть вендорские реализации PVST и PVRST.

Первый лан Spanning 3 и Первый лан Rapid Spanning 3, например, это цисковские реализации. Они будут, соответственно, дополнять работу классического Spanning 3, для того, чтобы эти протоколы могли работать с виланами. Что касается обычного Spanning 3? Он будет приводить вашу физическую топологию, кто на кого каким проводом смотрит, именно кто на кого каким физическим интерфейсом смотрит, к топологии без петель. То есть он выключает именно интерфейсы целиком. Если вы будете работать с виланами, то есть у вас теоретически могут быть порты, которые находятся в разных виланах абонентские, либо теоретически могут быть транки, в которых передается трафик нескольких виланов. В этом случае логическая топология того, как трафик может ходить по вашей топологии в одном вилане и в другом вилане, не могут различаться. Вот обычный Spanning 3, что обычный, что Rapid, в смысле, что Common Spanning 3, что Rapid, стандартные, они не различают трафик разных виланов.

Цисковская вариация PVST и PVRST, это, соответственно, обычный и быстрый, но с поддержкой виланов. Они умеют различать трафик разных виланов. И они позволяют вам блокировать не интерфейс целиком, а только лишь передачу кадров определенного вилана в определенном порту. В любом случае, все технологии класса Spanning 3, они будут влиять на коммутацию. Почему я сейчас про это рассказываю? Потому что Spanning 3 позволяет вам повлиять на то, как выполняется коммутация. Вы все равно какие-то кадры на интерфейсе будете отправлять, и какие-то кадры вы на интерфейсе будете принимать. Например, протокол CDP, если мы говорим про Cisco. Вот он все равно отправляется, все равно принимается на свечах, независимо от того, есть там петля, нет там петли, заблокировал порт Spanning 3, не заблокировал. Spanning 3 лишь позволяет вам не коммутировать чужие кадры, если вы не хотите испытывать проблемы от того, что чужие кадры будут в петле там зависать, например. Вот Spanning 3 он будет говорить, на этом порту запрещается отправка пользовательских кадров.

Или на этом порту запрещается прием пользовательских кадров. То же самое, фактически. Или говорите вы, например, на этом порту нельзя отправлять пользовательские кадры, которые относятся к такому-то VLAN. В любом случае это влияет на коммутацию и влияет на то, как у вас свечи начинают себя вести. Вот Spanning 3 он действительно так себя и вел. По поводу других протоколов, которые еще в Spanning 3 бывают, именно которые называются Spanning 3. Это MST, например. Multiple Spanning 3, который стандартный, 802.1S. Он, соответственно, позволяет работать со многими VLAN-ами. Он позволяет это делать более эффективно, чем вендорские реализации. Соответственно, вот тот же самый PVST, PVRST. Под капотом у него работает Rapid обычный. И единственное его отличие от Rapid Spanning 3-шного MST, соответственно, от Rapid классического 802.1W, это то, что у MST другие метрики. Соответственно, если посмотреть на то, как было предложено определять выгодность доступа до RUT,

выгодность маршрута до RUT в классическом RSTP 1998 года, там и предлагалось использовать стоимость маршрута до RUT. То есть у вас RUT, когда вы его выбрали, центральный коммутатор, он начинал рассылать сообщение, виды ЯРУТ. Когда вы принимали сообщение от RUT, вы говорили ЯРУТ, следовательно, он сам себя знает, как до себя добраться за 0 копеечек. Вы к стоимости, как он знает, как до себя добраться, прибавляли стоимость, как вы знаете, как до него добраться, и начинали своим соседям рассылать сообщение Я знаю, как добраться до RUT за столько-то копеечек. В итоге, если у вас есть коммутатор, который может добраться до RUT ровно одним способом, вот ровно один сосед будет к нему приходить и говорить Я знаю, как добраться до RUT, кстати, это стоит 15 копеек. Если у вас есть несколько способов добраться до RUT, это означает, что вы сформируете петлю. Это значит, что у вас есть вариант добраться до RUT через левое плечо и через правое плечо петли.

И, соответственно, к вам один сосед приходит и говорит Я знаю, как добраться до RUT за 11 копеек. Второй говорит Я знаю, как добраться до RUT за 13 копеек. Вы говорите, мне нужно выбрать самый выгодный способ, как добраться до рута через 11 копеек. Получается более выгодно, чем за 13. После того, как вы принимаете решение, что вы знаете, как добраться до рута за 11 копеек. Кстати, есть еще за 13, но за 11 выгоднее. Вы своим соседям рассказываете. Я знаю, как добраться до рута за 11 копеек. И они, в свою очередь, могут через вас построить более выгодный канал до рута. Или сказать, что через вас менее выгодный. И свои порты там тоже заблокировать. вот вот соответственно то как эти самые копеечки назначаются они изначально в обычном классическом спаминг 3 назначали следующим образом у вас был формула по которой вы определяли стоимость интерфейса и это стоимость интерфейс назначала следующим образом выбрали референсную полосу пропускания 1 гигабит и делили и и на стоимость она скорость вашего интерфейса если у вас был там

допустим интерфейс 10 и габит то вы брали гигаби отделили на 10 нигабит получали стоимость 100 вот ироста копеечка было если вы хотели drank и нести стоимость интерфейса 100 мегабитного вilde габит делили на 100 мегабит получали стоимости кейз то есть чем быстрее интерфейс все монтешевле и И, соответственно, получается вполне логично, что если там у вас есть вариант либо посмотреть на рута одним интерфейсом 10-мегабитным, но напрямую, либо 20-ю 100-мегабитными, но в обход через огромную длинную петлю, то логично, наверное, пойти напрямую. В противном случае лучше было бы, наверное, интереснее пойти в обход, потому что там просто быстрее, там трафик больше пролезает. Ну вот такой способ. Достаточно легко и эффективно оценить качество доступа до центрального коммутатора. В 802.1D, изначально придуманный стандарт Sparling 3, вот именно такая формула использовалась. Гигабит делили на скорость интерфейса и получали стоимость интерфейса, а потом складывали все эти циферки, стоимость интерфейсов, через которые проходил маршрут до рута, и получали совокупную стоимость доступа до рута.

Если есть два способа добраться до рута, через левое и через правое, вы смотрели, какой из них дешевле и говорили, вот тот, который дешевле, у нас один основной, а тот, который подороже, он формирует петлю, поэтому мы должны его выключить. И выключали. Вот. Далее. Что тут еще такое у нас будет из интересного? В 802.1W. RSTP 1998 года. Формулу изменили. Она, очевидно, не подходила для быстрых каналов. В 98 году уже появились 10-гигабитные интерфейсы. И поэтому формулу изменили следующим образом. Она уже не легко вычислялась. То есть, если посмотреть стандарт, стандарт описывает типичные скорости и соответствующие им стоимости. Вы, соответственно, в оригинальном Spanning 3 могли сами посчитать скорость вашего интерфейса, если она была какая-то нестандартная и соответствующая ей стоимость.

В версии 98 года у вас была именно табличка, по которой вы должны были найти свою стоимость. И в этой табличке были далеко не все скорости. Там были 10 мегабит, 100 мегабит, гигабит, 10 гигабит. И кратные им, соответственно, варианты 2 гигабита, 200 мегабит, всякое вот такое. Но если вы взяли, допустим, 3 провода, объединили в один из R-Channel, у вас получился канал номинальной производительностью 300 мегабит, то вы не могли с помощью такой таблички легко оценить свою правильную стоимость доступа до рота. В принципе, ничего страшного нет, то есть не обязаны все вообще узлы в одной логике назначать стоимость интерфейсов. Вы вполне можете взять и переопределить стоимость интерфейса, сказать, что дефолтная стоимость, которую вам посчитала система, она неправильная. И надо на самом деле не метрику 100 назначить, а метрику 101. Никаких проблем не будет. Но все равно был какой-то вот такой легкий недостаток, связанный именно с тем, что формула покрывала не все возможные варианты.

Точнее, не формула, а табличка. Формула покрывает все возможные варианты, а табличка нет. Вот в 98 году была именно табличка, которая покрывала основные скорости и рассказывала про то, что 10-мегабитному интерфейсу по-прежнему назначается метрика 100, 100-мегабитному 19, гигабиту 4 и 10-гигабитки 2. В, соответственно, 2004 году произошло изменение, появился протокол 802.1.s, и в этом протоколе снова изменили табличку, снова изменили метрику. У вас вернулась именно формула, табличке решено было отказаться, и формула получилась 20 терабит, деленная на скорость интерфейса. Если у вас был 10-мегабитный интерфейс, вы 20 терабит делили на 10 мегабит и получали метрику 2000. Если вы, соответственно, говорили, что у нас там есть 100-мегабитный канал, то получалась стоимость...

Погодите, у меня с математикой не сошлось. 20 терабит делить на 10 мегабит... 2 миллиона получается, да. Тера – это гига и мега потом, 2 миллиона. Соответственно, дальше 100 мегабит – это 200 тысяч. Гигабит – это 20000, и 10 гигабит – это 2000. Вот такие вот метрики дефолтные. Вы, опять же, можете взять и переназначить эту самую метрику, сказать, что вот конкретный интерфейс, он не 2000 будет, а там 3000, или 1000, или 10. Никто вам не запрещает назначать любые метрики, которые вы захотите. Главное, что это все будет влиять на то, как у вас Sparrow 3 будет принимать решение о том, какие порты будут заблокированы, а какие нет. Ну и, соответственно, вот в стандарт Rapid Spanning 3 эта формула тоже переехала. Хотя 802.1s – это как бы типа отдельная версия Spanning 3,

но в RSTP тоже метрики переехали те, которые вот эти вот миллионные. 20 терабит деленные на скорость интерфейса. Что касается других вариантов, как можно будет, соответственно, использовать технологии класса Spanning 3. Вы не должны будете Spanning 3 использовать для сценария вида. Давайте заранее проложим петли и потом запустим Spanning 3 для того, чтобы этот Spanning 3 при старте нам какие-то компоненты петли заблокировал. А потом, когда у нас случится авария, он заблокированные B-порты разблокировал по необходимости. Почему это плохо? Дело в том, что каждый раз, когда у вас Spanning 3 будет чего-нибудь подозревать, он вам будет класть сеть. Даже если он кладет сеть ненадолго, даже если он кладет сеть там на десятки миллисекунд, это все равно неприятно. То, что Spanning 3 обнаруживает отказ за 50 миллисекунд, означает, что через 50 миллисекунд после отказа канала он начинает рассылать сообщение

в виду «У меня какая-то авария, давайте с вами переподружимся и убедимся, что рут у нас правильный». Да, даже если вы это сделаете, даже если вы начнете рассылать сообщение всем соседям, если этих соседей много, вы сначала заблокируете порты, а потом сразу их разблокируете после того, как получите оповещение от соседа, что сосед знает, как добраться до рута. Если вдруг сосед присылает рассказ про то, что «Да, давай с тобой дружить, только я знаю рута более крутого», то, соответственно, вы там опять снова переключаете интерфейсы, указываете, что вот этот интерфейс будет жить, а вот этот вот жить не будет. Все эти переключения, они так или иначе влияют на коммутацию, они влияют на то, как у вас боевой трафик будет ходить. И вот если у вас очень большая сеть, у вас в ней начинается кавардак по перевыборам рута, даже если у вас там Rapid Spanning 3 используется или MSTP, внутри которого под капотом опять-таки Rapid используется, вы будете получать то, что у вас в течение пусть даже десятков миллисекунд, но сеть колбасится. Если это десяток миллисекунд, представьте себе, что у вас канал опять-таки 100 гигабитный.

Вот вы взяли, купили там за бешеный тысячи коммутатор, который работает со 100 гигабитными каналами. За одну десятую миллисекунды, которую Rapid Spanning 3 будет переколбашиваться, вы потеряете 10 гигабит трафика. Это много. Поэтому если вдруг есть возможность использовать какой-то очень простой механизм, который вам позволит в случае обнаружения отказа за минимальное время перескочить на запасной порт, вот есть у вас там 50 миллисекунд, которые вы обнаруживаете отказ, вот желательно было бы в этих самых 50 миллисекундах и остаться. Со стороны того коммутатора, который смотрит на какие-то другие коммутаторы, на самом деле всегда можно будет сделать следующую штуку. Вы всегда можете, например, сказать, что у вас есть Access Switch, у вас есть Distribution Switch. Access Switch на Distribution смотрит двумя проводами, левым и правым. И в норме работает левый порт, а правый в норме выключен. Но если левый линк дохнет, вот мы это за 50 миллисекунд определили,

то тогда включается правый линк. Вы такое решение сможете принять вот ровно за 50 миллисекунд. Вам не нужно для того, чтобы это решение принять, ничего договариваться ни о чем с соседями. Не надо получать от них сообщение вида «я понял, ты можешь со своей стороны включить порт». На все это требуется время. Не нужно, допустим, если там на соседе что-то произошло, у соседа перевыборы, вот возникла у него гениальная идея, давайте перевыбор объявим. Не нужно вам все свои порты блокировать и потом разблокировать, потому что с вашей стороны вообще ничего не произошло, вас вообще смена топологии не касается. Вот все вот эти технологии вида «давайте не будем между коммутаторами штатно гонять Spanning 3», давайте будем между коммутаторами просто включать наши интерфейсы и каким-то образом другим включать и выключать по мере необходимости, если у нас происходит авария. Они все заметно ускоряют работу. Самый простой вариант, если говорить про технологии, которые используются в предприятии, это FlexLink. Цисковская реализация, но у других вендоров то же самое, все есть.

Это именно технология вида. У вас два порта на абонентском свече, которые смотрят на дистрибьюшены, левый и правый. Вы левый объявляете основным, правый – запасным. Он так и называется, бэкап-порт. Бэкапный к основному. И если у вас на основном порту происходит какая-то штука, что интерфейс падает в даун, вы включаете запасной порт, правый, и начинаете весь трафик отправлять в него. Со стороны вашего свеча весь трафик, который идет в остальную сеть, он сразу начинает ходить в сторону всей остальной сети. То есть у вас вот ваш свеч перестает обрабатывать трафик в течение только лишь того времени, когда вы еще не сообразили, что случился отказ канала на основном порту. Вы патч-корт выдернули из основного порта, или его мышка перегрызла, все, порт упал в даун, вам потребовалось 50 секунд на то, чтобы это осознать, ну в смысле на то, чтобы свеч осознал, что на самом деле стоит порту тащить в даун, потому что он перестал получать импульсы. Условно говоря, 50 миллисекунд, хотя на самом деле меньше.

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

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

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

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

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

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

Ethernet Automatic Protection Switching, она называлась. Ну и, соответственно, у CISC и в стандарт, то, что стало фактически стандартом, это называется Ethernet Ring Protection Switching, ERPS. У Huawei эта же штука называется Rapid Ring Protection Protocol, RPP. Но смысл у них у всех одинаковый. То есть у нас есть какие-то сообщения, которые мы посылаем на свечах. У нас нет сообщения вида «давайте изменять топологию». У нас есть сообщение «быстро передай руту», ну как бы руту, что все сдохло. И тогда рут на все остальные ничего не посылает. Он не пытается со всеми остальными договориться. Он просто принимает решение «мы сейчас не передаем трафик по петле» или «мы передаем трафик по петле». Если прибежало сообщение «у меня сдохло что-то», то тот мастер свитч говорит «разблокируем петлю». Если на рут прибегает сообщение «у меня все восстановилось», то рут, соответственно, говорит «тогда я блокирую со своей стороны».

Опять же, чем быстрее у вас будет разбегаться сообщение по сети, тем лучше. Вот в случае работы такого самого механизма Ethernet Ring Protection Switching у вас время обнаружения отказа 50 миллисекунд плюс время, необходимое для того, чтобы добраться до, условно, до рута, до вот этого мастера свитча. Оно будет минимальное за счет того, что кадрики, которые вы будете отправлять, они отправляются сразу при обнаружении отказа. И как только со стороны соседа вы приняли сообщение «у нас отказ», вы дальше своему соседу другому, который в петле у вас есть, тоже передаете сообщение «там где-то случился отказ». Мастер свитчу, в принципе, пофигу, но со стороны какого именно свитча случился отказ. Ему главное принять сообщение, видо «где-то произошла проблема», и он где-то может сразу выключить канал. Учитывая, что обычно это все делается на скоростях, начиная от 10 гигабит, нет смысла провайдеру покупать такие свитчи, которые умеют это поддерживать, и делать гигабитную сетку. Если мы говорим про Ethernet, но упорная сеть, она грешновато делать сетки меньше, чем 10 гигабит.

Время, которое требуется на отправку маленького пакетика, оно будет копеечное. То есть там речь идет про микросекунды, даже, наверное, меньше. И, соответственно, если вы отправляете сообщение, которое у вас есть в сторону соседа, за единицы микросекунд, соответственно, сосед пересылает это сообщение своему соседу, тоже единицы микросекунд, и так дальше. Оно разбегается по сети. Вот время, которое требуется от одного конца сети до другого, чтобы добежало вот это маленькое сообщение, там, где-то авария, оно будет исчисляться именно микросекундами. Плюс 50 миллисекунд, которые требуются на обнаружение отказа. Отсюда и растут ноги у вот этого самого утверждения, что механизмы типа Ethernet Ring Protection Switching работают за 50 миллисекунд. Потому что им не надо договариваться, им не надо блокировать какие-то там порты, решать, какие порты заблокировать, какие нет. Только один свитч принимает решение, только один свитч, максимум один порт будет блокировать. Вот.

Что здесь еще можно будет проговорить? Хотелось бы заметить следующее. Вы, несмотря на то, что Spanning 3, вот я сейчас поругал, сказал очень-очень плохо, когда Spanning 3 фу-фу-фу, на самом деле означает ли это, что от Spanning 3 надо отказываться? Нет. Spanning 3 это протокол, который вас практически единственный, будет защищать от нежелательных петель, те, которые вы заранее не запрогнозировали. Для прогнозируемых петель у вас есть всякие вот эти механизмы, вроде EAPS и прочего. Но если у вас есть незапрогнозированные петли, то ничего кроме Spanning 3 вас не спасет. Вы должны будете всегда помнить мудрые слова, если мне память не изменяет, Пепельняк сказал, что петля в Ethernet это не вопрос того, произойдет она или нет. Вопрос только в том, когда она произойдет. Если петля в Ethernet происходит, то вы сразу теряете вообще всю вашу сеть, у вас перестает работать вообще все. Поэтому в тех местах, где нежелательная петля на этапе планирования отсутствовала,

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

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

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

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

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

Зачастую, кстати, это вызывает вопросы. То есть говорят, вот если у нас есть, допустим, два порта Ethernet, мы их объединяем в один логический канал, в Ether Channel, в Ether Channel, не важно, как хотите так и называйте. Почему номинальная скорость суммарная двух портов будет 200 Мбит, если, допустим, 200 Мбитных портов объединяем, но 200 Мбит туда не пролезают? То есть, казалось бы, что проще? Мы берем и меряем, допустим, очередь на каждом интерфейсе, и новые кадры, приходящие в этот логический интерфейс, складываем в тот физический интерфейс, у которого очередь меньше загружена. Тогда будет то, что оба интерфейса загружены по-честному, и вот каждый из них отправляет данные, пока в очереди кадры есть, на скорости 100 Мбит в секунду. В суммарной два интерфейса отправят 200 Мбит данных. Вот так не происходит именно потому, что свитч, который будет пытаться отправлять данные в такой агрегированный канал, если мы говорим про циску, например, он старается трафик одного и того же приложения упаковывать в один и тот же физический интерфейс.

И, соответственно, совершенно не факт, что у вас получится все кадры, которые к вам приходят, распределить по двум интерфейсам так, чтобы они всегда были загружены по максимуму на 100%, ну или схожим образом были загружены. Если к вам приходит, допустим, одно приложение от одного и того же компьютера, от одного и того же Mac, от одного и того же IP-шника, от одного и того же порта UDP-шного или TCP-шного, и оно идет на один и тот же порт, на один и тот же IP-шник, на один и тот же MAC-адрес, как вы его определите, что этот кадр надо бросить налево, а вот этот вот направо? Нельзя так делать именно потому, что если вдруг один из кадров возьмет и сдохнет, то, в смысле, не один из кадров, а один из интерфейсов возьмет и сдохнет, вы потеряете все данные, которые у вас в этом приложении предавались. Вот, поэтому гарантировать, что вам получится загрузить оба интерфейса одинаково, однотипно, система не может. Она старается это делать, механизмы, которые позволяют балансировать трафик по двум, трем,

пяти, неважно скольким интерфейсам, входящим в Azure Channel, они есть. Насколько эффективно они будут работать в каждом конкретном случае, это большой вопрос. Второй момент, то, что у вас интерфейс Azure Channel, этот логический, должен быть собран правильно. Там нужны будут следующие, скажем, ограничения выполнять. Во-первых, у вас обычно будет требоваться, чтобы скорость интерфейсов, входящих в агрегированный канал, была одинаковой. То есть, если вы используете 100-мегабитный канал, вот чтобы они все 100-мегабитными были. Нельзя собрать логический интерфейс из одного 10-мегабитного и одного 10-гигабитного интерфейса. Второй момент, это то, что дуплекс должен быть тоже одинаковым, и режим транкетга тоже обычно должен быть одинаковым. И самое важное требование. То есть, все остальное, как бы здесь можно договориться, можно придумывать какие-то косяки, которые... Не косяки, костыли, которые позволят вам собрать Azure Channel из 10-мегабитного и 10-гигабитного канала.

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

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

Вот как это сделать? Никак это не сделаешь, если у вас между вот этими двумя свитчами не проходит какое-то взаимодействие, которого штатно в Ethernet нет. Нельзя сделать так, чтобы два свитча между собой в Ethernet штатно договорились о том, что два провода на двух разных железках входят в один какой-то логический канал. Если вы будете отправлять браткасты, допустим, через один физический интерфейс, и две железки с другой стороны интерфейса не синхронизированы между собой, браткаст, полученный по одному из интерфейсов, бросится на другую железку, другая железка, полученный браткаст, бросит на все порты, ну, кроме порта-источника, и к вам вернется обратно в петлю браткаст. Это нежелательное явление, и, соответственно, его нужно будет пресекать. Вот пресекать его нужно либо, пробрасывая два параллельных провода всегда между двумя железками, два, три, пять, неважно, либо, соответственно, сделав так, чтобы две вот эти вот машинки могли синхронизировать свои мозги между собой, чтобы они знали, что кадр, который приходит на один из портов,

можно было отправить на другую железку с указанием, если что, знай, пожалуйста, что это пришло из логического канала номер 11. И сосед, получивший такой кадр с дополнительной меткой, это пришло через порт номер 11, обратно бы в логический порт номер 11 это дело не посылал. Механизмов, которые позволяют такое делать, может быть несколько, то есть вы должны будете синхронизировать каким-то образом контрол-плей на этих двух железок. Это может быть стек. То есть обычно, если у вас два свеча входят в один большой стек, то вы можете из R-Channel строить до двух свечей в стеке, и они между собой договорятся именно через межстековую связь. Опять-таки это все зависит от реализации стека, но на конкретных железках вы должны будете проверить, что это будет работать или это работать не будет. Чаще всего работает. Второй вариант – это использовать технологии типа VSS на 45-65 каталистах. Это есть, например, вы можете сказать, что две железки, стоящие рядышком друг с другом, они будут объединены в единую виртуальную коммутируемую систему,

и как раз до них можно будет строить вот эти самые логические каналы из R-Channel. Один провод до одной железки, другой провод до другой железки. У них между ними будет специальный провод, который будет называться VSL – Virtual Switch Link, и по этому проводу как раз будет синхронизироваться информация контрол-плейна и дата-плейна для того, чтобы вот эти самые интерфейсы работали у вас нормально. Может быть такое, что у вас будет использоваться какая-то супер-мега-навороченная система, ну, например, те же самые Nexus, уже упоминавшиеся неоднократно. Там есть схожая технология с VSS, она позволяет строить порт-ченнелы, которые будут идти до двух разных Nexus. То есть стоят два, допустим, семитонника, 70, там, 7709, например, 7718 Nexus. И у вас абоненты подключаются двумя проводами к двум разным этим самым Nexus.

Со своей стороны они делают самый обычный порт-ченнел, со стороны Nexus у вас происходит внутри связи между ними, синхронизация того, какие порты в какой логический канал будут входить. Ну, там будет именно маркировка трафика происходить. Вот такие вот штуки. В общем и целом, вы можете вполне, допустим, использовать EtherChannel для того, чтобы подключаться к двум дистрибьюшн-свечам для Access-свечей подключения делать. То есть у вас, например, используются два 45-х каталиста на дистрибьюшне, вы к ним подключаете какие-нибудь 29-е каталиста на Access-се, связываете два провода, тянущихся до двух 45-х свечей в один логический канал, со стороны 45-х свечей поднимаете Virtual Switch Link. Ну и в этом случае у вас получается два оплинка со стороны Access-свечей на дистрибьюшн, и оба задействованы, оба используются. Если хочется чуть более сложную топологию,

то есть не одна железка смотрит двумя проводами на одну и ту же, ну или по крайней мере на две железки, если у вас там какие-то хитрые штуки используются, а хочется, допустим, что-то совсем сложное сделать. То есть чтобы у вас 10 свечей друг на друга, каждый смотрит отдельным проводом, каждый на каждого, у вас такая full mesh, и хочется, чтобы все провода одновременно работали тоже. Тогда для этого тоже есть протоколы, которые позволяют вам использовать одновременную работу отправки и коммутации изорнет-кадров по такой сети. Но, естественно, это уже будут железки именно серьезного операторского, не операторского, а дата-центрового класса, когда у вас все провода одновременно задействованы, по всем проводам одновременно можно будет пересылать трафик. Здесь можно будет упомянуть протоколы SPB и Tril. Вот они пишутся SPB и Tril. Суть у них будет в следующем. Вместо достаточно тупого механизма коммутации кадров по таблице MAC-адресов,

которая пополняется автоматически из приходящих кадров, свечи между собой будут обмениваться служебной информацией, на основании которой они будут строить карту сети и будут говорить, как именно надо коммутировать трафик, до определенных MAC-адресов. То есть через какого из соседей будет лучше всего отправить трафик, отправить какой-то кадр до нужного MAC-адреса. Да, действительно, можно будет использовать любой из интерфейсов технически. То есть вы можете отправить кадр любому соседу, но до некоторых соседей будет ближе кинуть трафик, то есть они смогут куда-то еще ближе передать, и еще ближе, еще ближе. Соответственно, как это будет все физически выглядеть? У вас что SPB, что Tril будут на самом деле запускать внутри себя протокол динамической маршрутизации. Для того, чтобы оба этих протокола работали, вам не требуется поднимать routed protocol типа IP или IPv6 или чего-то еще. То есть протокол там будет использоваться и Sys,

который работает совершенно независимо от IP. Он поднимает свою собственную сетевую адресацию. Вы на нее не должны влиять. Он сам поддерживает свою собственную адресацию и сам назначает эти самые адреса. У вас все узлы, которые будут формировать такую большую сетку, они будут составлять одно большое вот такое вот поле динамической маршрутизации. И маршрутами в таком протоколе динамической маршрутизации будет как раз пара MAC-адрес источника и MAC-адрес назначения. После того, как у вас построится топология сети, протокол Sys, как мы помним, это протокол класса LinkState, то есть он построит карту сети. По карте между всеми свечами построят кратчайшие маршруты. А дальше каждый из свечей скажет, какие MAC-адреса сидят непосредственно на нем за границей вот этого самого поля SPB или Tril. И после того, как это произойдет, у вас все свечи будут знать, какие MAC-адреса сидят за соседями.

И для каждой пары MAC-адрес источника и MAC-адрес назначения будет понятно, какие свечи должны быть по дороге между вами и точкой выхода из вот этого вот самого поля SPB или Tril. Что касается реальных технологий, которые используют эти механины, то есть сами эти протоколы, они есть, и они поддерживаются разными вендорами. Зачастую, кстати, они вендоры несовместимые, то есть имеете в виду, что если вы такую штуку будете делать, то вам потребуется оборудование одного и того же вендора. Даже если написано, что Tril, допустим, там у вас используется на железке одной и на железке на другой, это могут быть несовместимые между собой версии Tril. Все это достаточно свежая вещь, то есть все это началось в 2012 году, бурное развитие этих технологий, и они на сегодня обкатаны достаточно неплохо, чтобы сказать, что внутри вендорской линейки продуктов оно все работает, но междувендорское взаимодействие все-таки еще не реализовано нормально. Если говорить про какие-то вендорские сценарии использования подобных механизмов,

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

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

что FlexLink, это все влияние на коммутацию. Механизмами, тем не менее, Spanning 3 подобных технологий влияние на коммутацию совершенно не ограничивается. Вы можете использовать совершенно другие механизмы какие-то, которыми ваше оборудование будет обладать, для того, чтобы так или иначе повлиять на то, как ваш коммутатор будет коммутировать трафик. Можно будет сказать, например, что ваш коммутатор, если вдруг он обнаруживает петлю, но не обнаруживает петлю, если он видит характерные для петли проявления, он может коммутировать кадры как-то по-другому. Например, он может сказать, если приходит много браткастов на порту, эти браткасты коммутировать не надо. Ну, то есть, если их приходит слишком много, больше, чем какое-то разумное количество. У вас есть 100-гигабитный интерфейс. Вот на 100-гигабитном интерфейсе браткастов не может быть, допустим, 30 гигабит. Ну, вообще ни при каких раскладах. Или там, если говорить про какой-то более реальный сценарий,

у вас есть сеть предприятия, у вас есть аксесс-свитчи, которые предоставляют абонентам трафик, ну, в смысле, скорость, допустим, 10 на 100, и все цепляются на сотки. 29,60 какие-то свитчи. И дальше аплинки у этих свитчей гигабитные, и они объединяются в, допустим, в порт-ченел, и все это дело приходит на какой-то дистрибьюшн, который, допустим, с ядром 10-гигабитными интерфейсами смотрит. И вы не хотите использовать Spanning 3 в каком-то месте, потому что, ну, мы уже говорили, Spanning 3 это в целом плохо в тех местах, где от него не получается избавиться вовсе. Вот если вы хотите, вы можете сказать, когда у нас петля получается, да, это нестабильность базы MAC-адресов, да, это множественная доставка кадров, даже и не кастовых, но в основном проблема будет с браткастами. И если браткастов приходит сильно много, то мы просто тупо выключаем обработку браткастов совсем. Ну вот нечего тут. Допустим, есть у вас гигабитный интерфейс, который на аплинке дистрибьюшн свитча висит.

Все, на этом интерфейсе нельзя больше 10% браткастовых кадров принимать. Если браткастов, кадры приходят больше, чем 10%, это сразу означает, что точно петля. От одного гигабита 10% 100 мегабит. Никогда столько браткастов у вас не будет. И, соответственно, вы просто говорите, вообще все браткасты выключаем до тех пор, пока их количество на порту приходящее не снизится до какого-то разумного предела. Это будут технологии класса Storm Control, и они будут достаточно эффективно избавлять вас от негативных последствий петли, которые возникают в сети и которые не обрабатываются с помощью Sparning 3, либо FlexLink, либо чего-либо еще. То есть вы случайно допустили возникновение петли, но проблемы от нее становятся все-таки более компактными, более локализованными. Все равно вы при этом будете испытывать проблемы от того, что где-то будет неправильно формироваться база MAC-адресов. Все равно вы увидите множественную доставку кадров, то есть Unicast, например, unknown Unicast будут приходить.

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

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

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

которые тоже могут общаться с портом роутера, но не с вот теми вот предыдущими абонентами, которые вам нравятся. То есть можно взять и разделить один широковещательный домен на несколько таких маленьких частично пересекающихся широковещательных доменов. Это все костыли, то есть в любом случае все вот эти PrivateVLAN и прочее, это костыли, которые означают, что вы не смогли решить задачу как-то более красиво. ProtectedPort чуть меньше костыль, PrivateVLAN всегда большой костыль. Если есть возможность обойтись без PrivateVLAN, лучше обойтись без них. Они иногда будут полезны, но в большинстве случаев использование PrivateVLAN будет означать, что вы не смогли задизайнить сеть нормально, где каждый кусочек широковещательного домена будет нормальным VLAN. Обычно PrivateVLAN используют как раз в тех случаях, когда когда-то был уже один большой широковещательный домен, и вы хотите сверху костылями подоткнуть все это дело так, чтобы повысить безопасность внутри имеющегося домена Ethernet. Вот тогда, да, тогда приходится использовать PrivateVLAN. Новое развертывание PrivateVLAN с нуля в новом дизайне делать,

ну, наверное, неправильно будет. В случае с провайдерскими сетями, вы будете, как правило, использовать свечи некорпоративного класса. То есть это будут специальные провайдерские свечи, на них будет специально написано, что это особенные свечи хитрые. Обычно там будет называться либо Carrier Ethernet, либо Metro Ethernet. Ну вот Metro Ethernet это как раз свечи, которые, да, это обычный Ethernet, да, на электрическом уровне это те же самые нолики-единички, те же самые 0,7 вольта. Точно так же они в кадры складываются. И кадр, отправленный обычным свечом на Metro Switch, тоже придет и совершенно нормально воспримется. И наоборот, кадр, отправленный Metro Switch на обычный свеч придет и будет коммутироваться. Но у Metro Switch логика коммутации будет изменена по сравнению с обычными свечами. Metro Switch всегда штатно делят все порты, например, на три класса. Вот наиболее, скажем, популярный тип портов на Metro Switch это порты Uni,

юзерский интерфейс, который по умолчанию будет вот такой вот ущербный и недоделанный, недотепа, как Protected Port в случае с корпоративными свечами. То есть юзерский порт на юзерский порт на Metro Switch, а трафик посылать не может, не имеет права. Будет другой класс портов это NNE, то есть порт, смотрящий в сторону всей остальной сети. Юзерский порт имеет право послать кадр в сторону всей остальной сети, и такой кадр надо будет прокоммутировать. Там есть много разных особенностей в случае Metro Switch, но вот основные особенности это как раз именно штуки, характерные для провайдеров, потому что обычные свечи с обычной логикой коммутации провайдерам не сильно подходят. Приходится костылями закрывать всякие разные штуки, которые в провайдерских сетях абоненты будут пытаться делать, а вот не хочется, чтобы они это делали. Вот типичный сценарий, это абонент не хочет платить денег, хочет сидеть через соседа и кадры соседу посылать. Нефига, говорит Metro Switch.

Юзерский порт в сторону юзерского порта, трафик посылать не может. Юнит у Юни не пройдет. Далее. Чего еще? Может быть такое, что ваш свеч захочет просто выключить коммутацию на порту, потому что ему что-то не понравится. Если говорить про ЦИСК, этот механизм будет называться R-Disable. То есть что это будет такое? У вас есть свеч, он на порту получает что-то, какой-то кадр, какое-то, скажем, поведение, которое ему очень сильно не нравится. Ну, например, вы включили Spanning 3, и включили в Spanning 3 режим порта, при котором он при получении БПДУшки будет выпадать в панику и будет просто валиться выключать весь порт. Вот это вот самое выключает весь порт. Это как раз сообщение вида R-Disable. То есть порт выключен из-за прошедшей на порту активности, которая нашему порту не нравится. Это ошибочная активность. И, как следствие, мы такой порт выключаем.

Не на уровне мы перестаем там нолики-единички отправлять или принимать, а на уровне мы перестаем коммутировать из этого интерфейса приходящие кадры и в этот интерфейс уходящие кадры. То есть вот такой вот R-Disable порт, он вроде бы включен, у него link activity горит, он пульсы отправляет, пульс принимает, но он в R-Disable, то есть он не коммутирует трафик. Да, про порт security 802.1x мы уже говорили, что можно будет сделать так, чтобы вот это вот состояние вида не коммутируем трафик было условным по принципу, что если нам представились, нам отправляют хорошие кадры, мы по каким-то признакам знаем, что кадры хорошие, мы их коммутируем. 802.1x позволяет нам использовать проверку хорошей или плохой кадры по признаку «Чувак с этим маком прививил пароль» или «Чувак из-под этого порта предъявил пароль». У 802.1x будет два режима работы, как я уже говорил. Один режим, при котором достаточно просто предъявить пароль, и тогда любая активность на порту становится нормальной.

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

Еще на что можно будет повлиять в плане коммутации? Есть такая штука Span, Switch Port Analyzer, она опять же у разных вендоров по-разному устроена, и нужна она для следующей модификации процесса коммутации. Вы можете сказать, что вас интересует то, что происходит на определенном порту. Вот у вас есть свитч, на этом свитче у вас есть абоненты. Один абонент другому кадры какие-то посылает, и вас интересует, что это за кадры. Вы хотите, чтобы вам копию этих кадров отправляли на какой-то третий порт. Вот Вася, Петя посылает кадр, свитч доставляет Пете копию этого кадра, и еще копию кадра сливает в порт, который сказал администратор. А администратор на этом порту может что-нибудь сделать хорошее, либо снифер запустить и услышать, что Вася, Петя передает, либо поставить какую-нибудь систему обнаружения вторжений, IDS, которая просто копия всего трафика валится,

и она отслеживает, что происходит в сети, и она понимает, что вот там кто-то чего-то делает нехорошее. Вот. Во всех случаях, соответственно, у вас изменяется логика коммутации. К вам приходит какой-то кадр на свитч, а свитч делает вместо одного кадра два. Один отправляет в правильный порт, а другой копию этого кадра с такими же заголовками из Орнета отправляет в порт, который вы назначаете в качестве порта мониторинга. У механизма этого есть ряд разновидностей. Бывает ремонт, спан, бывает упаковка данных отправителя в определенный Вилан и разное другое. Вот такой вот. Ну, во всех случаях вы будете, соответственно, иметь возможность получать копию кадра, которую вам прокоммутировали дополнительно к оригинальному получателю. Что касается мультикаста. В мультикасте ситуация будет следующая.

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

они будут браткастовые кадры пересылать на вас. Большинство современных свечей на такие штуки все-таки реагируют не очень позитивно, и они будут блокировать передачу кадров, которые имеют неправильный браткастовый MAC-адрес, в качестве источника. Но что касается мультикаста Браткаст, понятное дело, он всегда разбрасывается по всем портам Потому что его нет в таблице MAC адресов Или он есть, но он сделан специально так, чтобы разбрасывать данные по всем портам Чтобы нельзя было его добавить и перебить или что-то еще с ним сделать И если к вам приходит мультикастовый кадр, вы его тоже разбрасываете по всем портам Ну то есть обычный неуправляемый свитч Он просто смотрит, приходит, кадр на адрес 010000C Такого Mac нет в таблице MAC адресов Потому что это не Unicast и мы никогда не видим кадры из-под не Unicast Такого Mac нет в таблице MAC адресов, поэтому мы его разбрасываем по всем портам Так же как и Unown Unicast То есть свитч не делает разницы между Unown Unicast, Multicast и Broadcast

Он просто все разбрасывает по всем портам, кроме порта источника В случае, соответственно, с умными свитчами, которые могут обрабатывать правильно мультикасты в изернете Вы можете каким-то образом повлиять на ваш свитч и сказать Смотри, когда ты видишь кадр мультикастовый, отправляющийся на адрес 010000C Ты можешь каким-то образом узнать, за каким портом сидят легитимные получатели такого трафика Ты можешь сказать, что вот этот мультикастовый MAC адрес Известно, что за портом 11, 12, 13, 15 сидят получатели такого кадра Мы не знаем, как он это получит, но мы можем представить себе, что он, допустим, каким-то образом может догадаться В случае с мультикастом мы говорили, когда мы обсуждали, что такое мультикаст в изернете Мы говорили, что чаще всего узел начинает слушать мультикастовый трафик, потому что на нем запускается какой-то софт Как правило, этот самый софт будет каким-то образом сообщать

Что он запустился и что он начинает, собственно говоря, слушать этот самый мультикаст Если говорить про, допустим, протокол IP, в нем тоже есть мультикаст, он устроен немножко по-другому относительно изернетовского мультикаста Но, если вы присоединяетесь к IPv4 мультикастовой группе, то тем самым вы говорите Я присоединился к IPv4 мультикастовой группе с IPшником вот таким-то И, пожалуйста, выдайте мне копию этого потока И вы отправляете сообщение по протоколу IGMP Internet Group Membership Protocol Ваш свитч может поймать такое сообщение Может поймать такой IPv4 пакет Да, передающийся в кадре изернета Который будет идти с указанием Чуваки, дайте мне копию, пожалуйста, вот этого группового трафика Посылайте мне, пожалуйста, тоже такие мультикастовые IPv4 пакеты И ваш свитч может сказать Да, я вижу, что кто-то присоединяется к IPv4 мультикастовой группе

Что для меня, как для свитча, это означает? Что на него скоро пойдет мультикастовый IPv4 трафик На этот IPшник, который он заказал Как будет выглядеть мультикастовый трафик в изернете На мультикастовый IPv4 адрес? Он будет иметь предсказуемый вид У вас мультикастовые IPv4 адреса Однозначно формируют мультикастовые изернет адреса Мак адреса То есть, когда вы будете присоединяться к мультикастовой IPv4 группе В мультикасте в изернете тоже будете участвовать Вы будете слушать кадры, приходящие на определенный мультикастовый мак И этот мак адрес можно угадать Он заранее известен Строится по хорошо известному правилу У вас есть левая часть 20, ну скажем, 5 бит И правая часть 23 бита, которые вы можете использовать Или 20, там 6 бит Вот, и вы, соответственно, можете построить тот мультикастовый мак Который потребуется этому участнику Который заказал участие в IPv4 мультикастовой группе Если вы будете, соответственно, знать

Что приходит какой-то кадр на вот этот вот самый специальный IPv4 мультикастовый IPшник И он приходит в кадр изернет на специальном мультикастовом маке Вы сможете сказать Те, кто заказывал эту группу Те, кто хотят присоединиться к этой IPv4 группе Те отправили IGMP сообщение Те, кто не заказывал эту группу И не хотят слушать этот трафик Они не посылали IGMP сообщение Поэтому мы такой кадр мультикастовый Не будем разбрасывать вообще по всем портам Мы точно знаем, что именно вот этот вот кадр Соответствует IPv4 мультикасту И мы точно знаем, что никто за некоторыми портами Не просил этот трафик Следовательно, если мы не будем коммутировать в сторону некоторых портов Кто не просил этот трафик Ничего страшного не произойдет А те, кто просил в сторону них Мы будем коммутировать такой трафик И соответственно Из-под тех портов На которых пришло IGMP сообщение Дайте мне копию этого трафика Оно было адресовано не свечу Оно было адресовано другому какому-то роутеру

Но вы как свеч такое сообщение подслушали И сказали Окей, мне это интересно Это очень интересно И соответственно вы начали пропускать копию такого трафика В те порты, которые заказали такое взаимодействие Так что клиент, который посылает IGMP сообщение Он начинает получать копию IPv4 трафика Завернутого в мультикастовый Ethernet кадр И свеч такие кадры будут коммутировать в сторону запросившего такой трафик абонента Если говорить про именно IPv4 мультикаст завернутый в Ethernet То MAC адреса у него будут формироваться по известному правилу Сейчас скажу какому Вы можете взять и запустить на операционной системе Windows Например, команду ARP пробел минуса И увидеть, что вы присоединились на определенных интерфейсах К определенным мультикастовым группам У вас запущен софт, который умеет слушать определенный IPv4 мультикастовый трафик

И соответственно Этим мультикастовым IPv4 адресам Будет соответствовать предсказуемый мультикастовый MAC 01005e И еще потом Нулевой битик То есть там 25 бит будут относиться к левой части MAC адреса в Ethernet Который будет соответствовать IPv4 мультикасту У него 25 левый бит зафиксирован 23 свободные Для соответственно IPv6 Если у вас есть IPv6 адрес мультикастовый Вы можете получить мультикастовый MAC следующим образом Там 3333 будет Вот так вот 3333 16 бит И соответственно оставшиеся 32 бита будут отведены на последний хвостик Последние 4 байта IPv6 мультикастового адреса

Вот опять же можете посмотреть Каким группам вы присоединились в IPv6 И соответствующий MAC адреса С помощью хитрой командочки Команда будет нетшинт IPv6 шоу Блин по русски пишу Нетшинт IPv6 шоу нейброс Вот такая вот команда Она вам покажет Какие MAC адреса Каким IPv6 адресам будут соответствовать И соответственно вы увидите Что напротив многих адресов У вас будет 3333 Это вот как раз будет мультикастовый MAC Соответствующий IPv6 мультикастовым IPv6 адресам Вот там 3333 первые 2 байта А оставшиеся 4 байта Это хвостик мультикастового IPv6 адреса Так далее На самом деле протоколом IGMP Механизм уведомления свеча об адресах

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

Там очередь забилась У вас есть другой интерфейс Входящий, так называемый На котором вы получаете какие-то кадры И вы знаете, что там кадры очень полезные Очень важные, очень интересные И вы начинаете коммутировать эти кадры И понимаете, что эти кадры адресуются в тот самый перегруженный интерфейс А отправитель-то ничего не знает про то, что у вас там интерфейс перегружен Он вам посылает, посылает, посылает кадры, посылает А вы все говорите Ну блин, ну что мне с ними делать? Мне их некуда девать Они все должны уйти в выходящий интерфейс, который перегружен Да И вы можете, если вы захотите, использовать протокол, который называется 802.3x Flow Control Вы можете отправить специальный кадрик Со словом пауза Притормозит и слишком быстро отправляешь Я не успеваю обрабатывать У меня тут какая-то проблема Затык В случае, если говорить про 802.3x Он максимально тупой, этот протокол Он на фиксированное время Вам приостанавливает отправку данных То есть, если вы отправили сообщение Притормози соседу

И сосед это сообщение услышал Он вам посылать кадры перестает Вы имеете некоторое время на то, чтобы разобрать Соответственно завалы, которые у вас там есть И позволить дальше обрабатывать трафик в сторону нужного вам интерфейса Проблемы с 802.3x будет несколько Первая проблема связана с тем, что вы там указываете время в миллисекундах По-моему, даже в десятках миллисекунд что ли И соответственно на старых интерфейсах 10 мегабит, 100 мегабит Это было нормально Ну то есть, у вас как раз время разгребания буферов Оно как раз порядка там Единиц десятков миллисекунд и было В новых интерфейсах там 40 гигабит, 100 гигабит Ну для вас скорости вида 100 гигабит Вы там за одну секунду отправляете 100 гигабит данных За одну миллисекунду вы отправляете 100 мегабит данных То есть, за то время, пока вы отправляете сообщение Ну-ка притормози на одну миллисекунду Вы не то что разгребете свои завалы

Вы еще и во всей сети успеете разобрать все эти завалы У вас сеть будет простаивать в течение времени Сильно большего, чем это необходимо Изменять протокол не стали Придумали другие протоколы Которые позволяют чуть более гуманно относиться к процедуре паузы Но мы про них сейчас чуть попозже проговорим Вторая проблема, которая будет у 802.3x Она будет заключаться в следующем Вы его должны включать вообще везде Вообще везде это значит, что если у вас есть сеть Абонент смотрит на Access Switch Access Switch смотрит на Distribution Switch Distribution Switch смотрит на ядро Ядро смотрит на какой-то Distribution Switch серверной фермы Distribution Switch серверной фермы смотрит на Access Switch Серверная ферма подключается к Access Switch Так вот, если вы начинаете отправлять какие-то кадры В сторону, допустим, сервера Вы отправляете с стороны абонентского порта на Switch Switch отправляет этот кадр дальше на Distribution Distribution на ядро Ядро на другой Distribution Distribution посылает данные все на сервер

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

Был перегружен Кем-то Или даже Switch не в ядре Switch перегрузился Вот какой-нибудь абонентский Switch Абонентский Switch на серверной ферме Сказал при этом мази одному Switch Один Switch другому Switch Все это дело дошло и до ядра Ядро у вас работает на скорости Ну допустим 10 гигабит Из-за того, что кто-то там Где-то заткнулся в сети У него У кого-то там перегрузка произошла Вы должны Ваш ядро Выключить там Допустим на 1 миллисекунду За эту 1 миллисекунду Вы потеряете 10 мегабит данных Оно вам надо Оно вам не надо И соответственно Вот 802.3X Да, действительно Вот он не разбирает То, что надо там Допустим Какой-то только конкретный Трафик перестать передавать Он говорит Притормозить целиком Вообще любую отправку данных В сторону меня И другой Switch Который получает такое сообщение Он должен Должен сказать А мне теперь не надо Посылать вообще никакие данные Не то что Не надо мне посылать данные До вон того чувака

У которого перегрузка Вообще Выключи всю отправку данных На меня Просто ничего мне не посылай И у вас сообщение 802.3X Которое будет правильно Распространяться По сети Оно будет вообще Всю передачу блокировать На пути От абонента До Места вызвавшего проблему Включая И чужого трафика тоже Поэтому 802.3X Технология В общем такая Специфическая Если у вас сеть Правильно построена То Вы должны будете Каким-то другим образом Реагировать на перегрузки Не таким Злобным Не таким Скажем Механизмом Как из пушки По воробьям бьющим Который вообще Всю передачу трафика Будет блокировать В первом приближении Да Кажется круто А что мы сейчас Быстро кинем сообщение А ну-ка притормози И сосед начнет тормозить А вот на самом деле Нифига На самом деле Не сосед начнет тормозить А вообще Вся сеть начнет тормозить От того что у кого-то Там где-то случилась Перегрузка Для сценариев Там где перегрузка

Возможна И случается часто Есть специальный Отдельный набор методик Который называется DCB Data Center Bridging И соответственно Он будет заключаться В следующем У вас Можно будет Кинуть сообщение Не просто Перестань отправлять Не вообще Весь трафик А можно будет Кинуть сообщение Перестань не отправлять Трафик Очень определенного типа То есть вы можете сказать Что у вас трафик Разделяется на классы И вы будете Кидать сообщение Перестань отправлять Трафик определенного класса Все-таки Это будет существенно Более мягкое Сообщение Потому что Не вообще Вся передача Будет блокироваться А будет передача Блокироваться Только того трафика Который вызывает проблему Да Возможно Какой-то другой трафик В том же самом классе Идущий в совершенно Другую сторону Тоже пострадает Но по крайней мере Большая часть классов Не пострадает При этом Вы будете разделять Трафик на Классы Вы будете говорить У нас случилась Перегрузка В классе Допустим В классе Стораджа Да

Весь сторидж Блокируем Нафиг Но при этом Интернет остается Рабочим Вот Или мы говорим У нас Произошла перегрузка В классе Неважного сториджа Неважный сторидж Блокируем Важный сторидж Продолжает работать Сюда же будут На самом деле Относиться Дополнительные Всякие технологии То есть DCB Это не один Какой-то протокол Это сразу Целая пачка Протоколов И все они Будут относиться К тому Как коммутировать Трафик в сетях Дата-центров Там где перегрузка Возможно Там где она Гарантированно будет И как сделать так Чтобы можно было С такими сетями С перегрузками Нормально работать И чтобы минимизировать Трафик Минимизировать потери Трафика В случае Этой самой перегрузки Вот механизмы Взаимодействия Между свечами Они будут как раз В DCB Описываться Вот Опять же Не забывайте Что все равно В любом случае У вас эти самые механизмы Должны быть реализованы Вообще везде End to end То есть вообще На всех узлах Вообще на всех промежуточных узлах На конечных узлах На серверах Этот самый DCB должен быть

Именно Поэтому на самом деле Вы возможно видели Там допустим В Windows Server 2012 Появилась отдельная роль Поддержка DCB И там описание Какое-то совершенно непонятное Про то Зачем эта роль нужна Так вот Она нужна как раз для того Чтобы если вы Используете правильные технологии Построения дата-центра Вы бы Поддерживали Все те сообщения Которыми узлы могут Сообщать друг другу Перегрузка произошла Вот такая-то Вот там-то Не надо вон туда Посылать вот такой-то Трафик Вот именно это И будет как раз Поддержкой Дата-центра Блейджинга Что касается Указания Всяких модных штучек Типа Времени На которые Надо сделать паузу Да Естественно Что Точность Гранулярность Скажем Времени Которое В дата-центр Блейджинге Будет для того Чтобы перестать Отправлять трафик Это то самое Сообщение паузы Оно будет существенно меньше Не на миллисекунды Вы уже будете Выключать Интерфейс А на то время Которое реально Надо потратить

Для того Чтобы у вас Буферы освободились Вы работаете на скорости 100 гигабит в секунду Буфер у вас Допустим Мегабайт Ну или там 5 мегабайт Не важно сколько Вы оцениваете Что 5 мегабайт На скорости 100 гигабит в секунду Вы отправите За вот такое-то время И вы отправляете сообщение Мне нужно 3,5 микросекунды Для того Чтобы это все разобрать На 3,5 микросекунды Вот этот трафик Мне перестань посылать И вы перестаете Пересылать вот этот трафик Опять же Если у вас Допустим На исходящем Интерфейсе Есть очереди И вы говорите Что вот в приоритетную очередь Вы отправляете Один трафик А в неприоритетную Другой Вы можете сказать Приоритетную очередь По-любому Должна работать Поэтому мы сейчас скажем Не надо нам посылать Тот трафик Который падает В нашу неприоритетную очередь Допустим Этот трафик Не знаю Того же Неважного сторожа Вот И вы сообщение посылаете Не надо посылать Неважный сторож У всех порты Продолжают работать По крайней мере Какие-то кадры Во всех интерфейсах

На определенное небольшое время Их отправка Приостанавливается Вот Это конечно намного лучше Чем просто из пушки по воровьям Кричать А ну вообще Перестань мне отсылать Вообще все Что у тебя есть И передай соседям Чтобы они тоже Вообще перестали Посылать вообще Все что у них есть Не только тебе Но и вообще всем Так Ну чего В общем-то Про все что хотелось Рассказал Quality of Service Механизмы На основе поля КОС Рассказал Когда говорили Про Виланы Можно вспомнить Всякие РСВП И прочее Но опять же Это уже лучше Рассказывать В специальной теме Про Quality of Service В отдельной серии Вебинаров А что касается Протокола Ethernet То что хотелось Рассказать Я все рассказал Если есть какие-то вопросы Вы можете всегда Мне написать Спросить Я отвечу На сегодня все Спасибо Спасибо Спасибо Спасибо Спасибо