Коммутация

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

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

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

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

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

Он эти нолики-единички составляет в большой кадр. Он смотрит, получилось ли что-то из этого самого кадра прочитать, сошлась чек-сумма или нет. И дальше этот кадр куда-то там девает. В зависимости от того, сколько абонентов ваш коммутатор может обслуживать, он может иметь некоторое количество портов. Самые маленькие коммутаторы, они обычно порта на 4, но меньше уже как-то редко делают. Вот на картиночке нарисован, допустим, коммутатор относительно маленький на 8 портов в нижнем правом углу. Либо, если у вас абонентов может быть побольше, это может быть такой большой стоечный коммутатор, на 24 абонента, на 48 абонентов. Либо он может быть совсем большой. Вот на картинке слева нарисован коммутатор, такой большой, серьезный провайдерский, ну, дата-центровый, скажем, коммутатор. Это нарисован такой большой толстый шкаф, похожий на холодильник, но это не холодильник. Это один коммутатор. У него много-много-много дырочек, куда можно воткнуть патч-корд для того,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот если у него много портов, это коммутатор. Если у него мало портов, это маршрутизатор. А то, что там процессоры одинаковые стоят, все одинаковое стоит, софт одинаковый стоит, это уже как бы всем пофигу. Ну то есть, например, там 76 роутер цисковский и 65 свечи каталисты. Это одна и та же железка. У нее одни и те же процессоры, один и тот же софт, одна и та же схемотехника вся сделана. Просто вот портов у коммутатора больше. Если вам нужно много портов, вы покупаете коммутатор. Если вам нужно мало портов, но нужен софт, нужен процессор. То есть, нет смысла платить больше за то, что вам не нужно, за те порты, которые вам не нужны. Вы покупаете эту же железку, только в форм-факторе маршрутизатора, у которого портов мало и платите за это чуть поменьше. Порты при этом на коммутаторе, ну и на маршрутизаторе тоже, если это маршрутизатор. Ну мы сейчас говорим про коммутаторе. коммутаторы. Порты могут быть разные. Если мы говорим про коммутаторы Ethernet, у него все порты будут Ethernet. Но Ethernet много и они разные. Они могут быть 10 мегабит, 100 мегабит, гигабит, 10 гигабит, 40 гигабит, 100 гигабит, 25 гигабит. То есть они разные бывают и за счет того, что они могут

быть разные, вы соответственно можете на одном коммутаторе иметь сразу целую пачку портов, которые будут разные по стандартам. Они могут быть мультистандартными и каждый конкретный порт может работать на какой-то своей скорости, в каком конкретном стандарте. Если у вас коммутатор, допустим, 10 на 100, может быть половина портов в десятке работать, может остальная половина портов работать на сотке. Точно так же режим дуплекса на каждом порту будет независимый. Половина портов может быть half-duplex, половина full-duplex. Кадры при этом все равно у всех отправляются одинаковые. Да, битики будут разные, а кадры будут одинаковые. Именно благодаря тому, что коммутаторы требуют, чтобы кадры у всех были одинаковые, на самом деле в современных эзернетах и будут те самые рудименты, про которые мы говорили. Мы говорили, что в 100 гигабитном эзернете все равно есть интерфрейм спейсинг, который там не нужен, но он все равно есть. Это нужно для совместимости с старыми эзернетами, потому что кадры у всех должны быть одинаковые. И формат кадра должен быть одинаковый,

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

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

Почему зачастую нужно вести драку за каждую миллисекунду? Дело в том, что... не даже не миллисекунду, масштабов порядка микросекунд на самом деле. Представьте себе, что у вас есть голосовое какое-то соединение. Вы говорите там, мама, мыла раму. Если говорить про наиболее, скажем, популярные стандарты отправки голоса через IP-связь и через, как следствие, Ethernet, потому что мы сейчас говорим про случаи, когда IP-пакеты упаковываются в Ethernet, вы будете отправлять примерно 30 пакетов в секунду. То есть, там можно будет поиграть этим, сказать, 10 пакетов, 20 пакетов, 30 пакетов в секунду. Ну, вот, допустим, 30 пакетов в секунду вы отправляете. Соответственно, время, в течение которого пакет идет, не должно различаться у разных пакетиков больше, чем на 30 миллисекунд. Если вы отправляете в 30 пакетов в

секунду, вы ожидаете, что придут они с такой же скоростью, 30 пакетов в секунду. Если, соответственно, они у вас будут проходить по сети за разное время, допустим, один пакет пройдет по сети за 20 миллисекунд, а второй пакет за 50 миллисекунд, у них перепутается порядок. Потому что, если вы отправляете первый пакет, и он идет 50 миллисекунд, потом последующий через 30 миллисекунд, который идет 20 миллисекунд, они придут одновременно. И, возможно, даже тот, который отправлен был раньше, он придет на получателя позже. Поэтому, чем больше у вас вот этих промежуточных железок, тем больше вероятность того, что отправитель отправляет какие-то пакеты, надеясь, что они придут вот ровно за определенное время, а дополнительные какие-то задержки, они вносят изменения во время прохождения пакета по сети. Может быть такое, что вы сейчас говорите, там, мама мыла раму в микрофон, микрофон ловит колебания, преобразует это все дело в голосовые пакеты, пакет упаковывается в IP, IP упаковывается в Ethernet, дальше отправляется по сети, и один пакетик прошел через Ethernet нормально, никаких дополнительных

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

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

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

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

У вас физический интерфейс, который принимает данные. Он принимает эти данные по битву, и вот у него начинает прибегать первая преамбула. Сначала там был интерфейс пустое место, когда никто ничего не передавал. Потом начинает выбегать преамбула. 1, 0, 1, 0, 1, 0, 1, 0, 1, 0 и так далее. 64 бита. Ну, последняя единичка. Start of frame delivery. Потом вылезает 48 бит мак-адриса получателя. Вы эти самые 48 бит получаете. Дальше пойдет еще много байт, много бит. Как мы говорили, минимальный размер кадра это 512 бит, не считая преамбула. Но вот первые 48 бит из 512 или больше показались. В принципе, на основании 48 бит будет приниматься коммутационное решение. Вы будете знать, за каким портом сидит получатель. Вы сразу примете решение, что вот этот кадр будет пихаться в тот выходной интерфейс. Понятное дело, что на ваши коммутационные решения могут повлиять какие-то данные из самого кадра. Но большинство коммутаторов принимает решение именно исходя из мак-адриса. Они знают, кто за каким портом сидит.

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

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

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

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

насколько будет ваша железка мощная или не мощная, насколько она будет дорогая или дешевая. Соответственно, если у вас таблица коммутации на каком-то маленьком свече, она обычно выражается в единицах тысяч штук. То есть объем МАК-адресов в таких маленьких глупых свече, он там 2000 адресов, 4000 адресов, 8000 адресов. Если говорить про крупные, более дорогие модели, то там количество МАК-адресов будет больше. Для вас нужно знать следующее. Вы не должны будете ожидать, что эта таблица может быть заполнена полностью. Более того, она не должна быть заполнена полностью. Она начинает... Физически организация этой памяти с таблицы коммутации такова, что она позволяет очень быстро считывать данные по известному ключу. Но если вдруг в этой таблице количество записей становится больше, чем половина от максимального объема, то процедура чтения данных из этой таблицы начинает резко тормозить. Особенно, если таблица начинает быть загружена практически полностью.

Поэтому, если у вас сеть, допустим, на 1000 абонентов, это значит, что маленькие дешевые домашние свечи в этой сети не могут существовать нормально. Если вы всех 1000 абонентов потыкаете на маленькие, тупенькие, дешевенькие свечи, купленные в ближайшем магазине, 4 абонента в первый свеч, потом 2 свеча соединяете проводом, 4 абонента в второй свеч, второй и третий свеч соединяете проводом, и такая вот длинная колбаса из 250 свечей, в каждом из которых 4 абонента, и каждый друг с другом соединен в гирлянду такую. Вот эта вот штука, она работать не будет, просто потому, что таблица коммутации на каждом свече будет практически переполнена, и эффективность работы той самой памяти, которая будет обеспечивать работу таблицы коммутации, она будет резко проседать. То есть эффективность работы таких свечей резко понижается по сравнению с моделями, у которых вот эта самая таблица коммутации будет побольше по размеру. Плюс, естественно, что коммутаторы, они бывают разные. Бывают коммутаторы, которые на самом деле маршрутизаторы, как я уже говорил, что они там делают всякие разные штуки.

Бывают коммутаторы, которые умеют принимать коммутационные решения не только от MAC-адреса, но и от каких-то других полей в заголовке Ethernet. Бывают коммутаторы, которые поддерживают дополнительные поля в заголовке Ethernet. Мы про них не говорили, но это все нестандартные вещи для 802.3. Например, 802.1Q. Доп-заголовок пишется в кадр. И, соответственно, можно заставить коммутатор принимать коммутационные решения в зависимости от этого заголовка. Можно будет сказать, что коммутатор у вас будет выполнять задачи маршрутизации. То есть он принимает кадр Ethernet. И вместо того, чтобы этот кадр сразу в неизменном виде переложить куда-то еще, как это делает нормальный коммутатор, он берет, счищает заголовок Ethernet. Содержимое передает какому-то обработчику. И на основании этого обработчика делается новый кадр Ethernet с другими заголовками, которые отправляются в другой порт. Естественно, что все вот эти дополнительные штуки будут влиять на цену. Именно по этой причине, по всем шести пунктам, которые здесь указаны, коммутаторы будут различаться по стоимости.

Если вы видите коммутатор, который слева лежит маленький 5-долларовый коммутатор, который вы купили в ближайшем супермаркете, а справа стоит ящик 7718, да, они будут стоить очень сильно по-разному. Именно благодаря тому, что у них и количество стандартов портов разное, и там все разное, все пункты, которые здесь есть, они все одинаковые. Но, если вы видите слева, допустим, коммутатор Cisco, у которого 48 портов, все порты 10 на 100 или 10 на 1000, и все равно они при этом по цене отличаются кардинально. Допустим, возьмите гигабитный 2960 есть с аксессорами гигабитными? 2970? По-моему, есть. 2960 точно не было? 2970, по-моему, гигабитный есть, да ведь? Да, ну вот возьмите 2960 Switch и, соответственно, какой-нибудь 3750 с гигабитными портами. Вот, или 3850 свежий. Вот они будут сильно по цене различаться.

Количество портов одинаковое, название портов одинаковое, у всех это гигабит Ethernet, но они, соответственно, все равно стоят по-разному. Почему? Вот именно потому, что у них поддерживаются всякие дополнительные штуки, потому что у них там матрица коммутации может одинаковая, но, соответственно, технологии у них разные. Там 2960, он, конечно, может работать с маршрутизатором, но хреновенько. А 3750, он там хорошо умеет работать маршрутизатором. Возьмите рядом Nexus, поставьте. У которого, ну ладно, у Nexus будут 10 гигабитные порты, но там можно маленький взять, который будет гигабитный. Чем он будет отличаться? Он будет отличаться тем, что у него матрица коммутации неблокирующая, что производительность матрицы коммутации такова, что у вас switch Nexus никогда не захлебнется от того, что на него прибежало слишком много трафика. На маленьких дешевых switch у вас матрица коммутации не обязана переваривать все кадры, которые приходят на все порты. У вас может быть такое, что номинально на switch 48 гигабитных портов, но если вы попытаетесь на каждом из портов отправлять гигабит трафика в сторону каких-то других портов, даже если на каждый порт не будет уходить больше гигабита.

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

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

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

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

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

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

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

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

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

И получится, что у вас от того, что вы эту самую петлю сделаете, сигнал будет очень сильно деградировать и скорее всего даже просто не будет читаться. Поэтому петель в топологии с общей шиной быть не может. Петлю в случае с коммутируемой сетью вы можете попытаться сделать, но приведет это к негативным последствиям, о которых мы чуть-чуть попозже проговорим. Поэтому просто запомним, что когда Ethernet работает хорошо, у вас петель нет. У вас кадры ходят всегда по одной и той же трассе. И это кратчайший путь между двумя узлами. Соответственно никаких петель нет, так что нет возможности пойти к какой-то другой трассе. У вас всегда от одного участника до другого ровно один маршрут. Если, соответственно, вы видите какой-то кадр, полученный от какого-то абонента, и у этого абонента MAC-адрес указан, MAC-адрес отправителя, мы помним, что всегда кадры, которые вы отправляете, вы подписываете своим Unicast-адресом, который у вас как минимум один есть. Он, как правило, прошит на заводе. Или вы его поменяли, и он становится Local Administrator-адресом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мне кажется, там должен быть MAC адрес A, B, B, C, C, D, E, E, F, F. И система говорит, да, ты угадал, там реально такой MAC адрес есть. А если вы тыкнули пальцем и не угадали, то это должен быть окончательным ответом, нет, в этом месте такого MAC адреса нету, и не надо во все остальные ячейки тыкаться, там тоже их не будет. Это будет быстрая память по чтению, быстрая память по доступу, и она организована специальным образом, таким, чтобы вы знали, где искать MAC адрес, до того, как вы вообще первый запрос к этой самой памяти соорудили. Соответственно, эта память должна быть специальным образом организована, и у нас для такой памяти будет специальное название. Это будет называться ассоциативная память, по-русски, если говорить. В терминологии других вендоров, ну, например, CISC, она будет называться Content Addressable Memory, CAM. Эта память будет организована в виде специальным образом сбалансированного дерева. То есть у вас все ячейки, которые в ней будут, они будут организованы в виде дерева,

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

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

То есть у вас стоимость операции по добавлению, это O от логарифма числа записей, O от N. Если вы, соответственно, хотите удалить запись, там тоже O от N. Если только не нужна перебалансировка дерева, но она нужна относительно редко. Если вы добавляете новую запись, и у вас требуется перебалансировка, это значит, что либо вы добавляете много записей, и у вас дерево как-то очень перекосило в одну сторону, какая-то из веток стала очень длинной. Либо, соответственно, у вас просто маленькое дерево, и вот вы добавили немножко, и его уже сразу перекосило. Но в этом случае его перебалансировать снова становится возможным. Какая информация используется? Блоки укороченных MAC-адресов или нет? Нет, используются именно сами MAC-адреса. То есть в качестве ключа используется именно MAC-адрес. Вы можете вот этому блоку ассоциативной памяти сказать, скажи мне, за каким портом лежит вот ровно вот этот MAC, и ровно его дай мне. И система по ключу MAC-адреса найдет вам нужную ячейку, скажет,

я нашла ее за очень маленькое время, за log2n. Соответственно, я тебе отдаю вот то, что хранится в этой ячейке. В этой ячейке хранится, что такой MAC-адрес есть, и он сидит за 17-м портом. Либо я тебе отдаю информацию о том, что такого MAC-адреса нет и точно нет. Опять же, за очень маленькое время я взяла и нашла нужную ячейку, и определила, что вот его действительно точно нет. Да, производительность, соответственно, будет деградировать с ростом числа хранящихся записей. Если у вас количество ячеек памяти большое, ну, типа там вот 8000 записей хранится в табличке, и общее количество ячеек памяти тоже 8000, то все процедуры вида перебалансировать дерево и прочее, они становятся действительно довольно дорогими. Добавление новой записи дорого, удаление записи, дорого, в общем, все становится дорогим. Поэтому, несмотря на то, что записей в таблице в ассоциативной памяти может быть много теоретически,

не надо доводить до того, что у вас количество записей в таблице становится сравнимо с размером этой таблицы. Проще было бы использовать массив памяти, в котором для адресации используется сам MAC. Ну, так и есть. Адресация – это и есть сам MAC. Или вы имеете в виду, что использовать размер таблицы, в которой вообще все возможные MAC адреса будут. То есть 2 в 48 степени. Простите. 2 в 48 степени бит только на ключи. Замечу. Это много. 2 в 48 – это приблизительно 10 в 20 степени. Ну, чуть меньше. 10 в 15. Да. 10 в 15 степени бит – это 10 в 12 степени байт.

Это терабайт придется хранить чисто на перечисление MAC адресов. И еще надо под номер порта чего-нибудь хранить. А, простите. Это количество адресов. А каждый MAC – это… Ну да, собственно, количество. Он по номеру есть. Рядом с такой штукой надо будет еще иметь, собственно говоря, номер порта. Перебор. Много. То есть терабайт хранить только под таблицу адресации MAC на каждом коммутаторе. При том, что количество адресов в этой таблице будет все равно порядка тысячи. Смысла нет. Да. Если вы будете хранить 2 в 48 степени строчек, и в каждой строчке вам нужно будет хранить номер порта, скорее всего, такой объем памяти будет на очень дорогих моделях. Скорее всего, на очень дорогой модели будет много портов. Скорее всего, на очень большой модели вам придется иметь как минимум 2 байта под хранение номера порта. То есть вы должны будете 2 в 48 раз по 16 бит имеется для того,

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

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

И, соответственно, после того, как чек-сумма будет проверена, матрица коммутации будет кадр каким-то образом пытаться анализировать. Вы должны будете время обработки каждого кадра коммутатором складывать из двух основных составляющих. Это полностью принять кадр, если у вас дешевый свитч. Оно зависит, естественно, от приема кадра, от того, какой кадр у вас будет. Чем больше кадр, тем больше времени вы его получаете. Если к вам приходит 512 бит, вы должны потратить 512 биттаймов. Если к вам приходит 1,5-килобайтный пакет, сколько получается, почти 10 тысяч битт. Вы должны 10 тысяч биттаймов потратить в 20 раз больше. Дальше, собственно говоря, начинается обработка этого кадра. Здесь у вас нужно будет все, что к вам прибежало, все вот эти биты переложить между портами, из входящего буфера на входящем порту переложить в исходящий буфер на исходящем порту. Понятное дело, тут тоже чем больше кадр, тем больше времени потратится на перетаскивание этих самых данных.

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

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

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

типа, не знаю, D-Link, вот D-Link просто отличился тем, что на своем сайте они пишут якобы производительность матрицы коммутации. То есть вы можете взять, зайти на сайт D-Link.ru, там будет дата-шит на свитчи, и даже самые маленькие дешевые свитчи, если вы возьмете, почитаете дата-шит на них, они пишут производительность коммутации и дальше указывают математическую сумму скоростей портов. То есть они указывают там производительность коммутации, допустим, 17,5 гигабит, если у них там 16-портовый гигабитный свитч. Так вот, это же вранье, это просто откровеннейшее вранье, потому что не может такого быть, чтобы маленький дешевый свитчик с абсолютно точно простейшей матрицей, которая там стоит тысячу рублей, не знаю, две тысячи рублей, чтобы он имел неблокирующую коммутацию в себе. Скорее всего, матрица коммутации захлебнется существенно раньше. Поэтому вот в случае с D-Link просто это откровенное вранье, которое можно проверить, что не справляется свитч с 17 гигабитами трафик,

если эти кадры будут меленькие. Но, в принципе, теоретически, можно себе представить такое, что вы включаете джамбо-фреймы, вы будете отправлять на матрицу коммутации огромные 9-килобайтные, 100-килобитные кадры, и производительность в пакетах, в кадрах, она на самом деле будет уже более-менее похожа на правду. Будьте, пожалуйста, аккуратны с тем, что производительность зачастую выражают в битах в секунду, но это не совсем правда. Производительность матрицы будет именно пакеты в секунду, кадры в секунду. Это более правильно. Матрица коммутации не работает с самим мясом кадра. Вот когда кадр приходит, матрица коммутации работает только с его заголовком. Заголовок у всех одинаковый. Поэтому производительность матрицы коммутации правильно мерить только в кадрах в секунду. В спецификациях зачастую на хорошее оборудование пишутся и пакеты в секунду, и биты в секунду. Но вот для коммутаторов очень редко

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, все сжечь. Оборудование несоответствующего класса использовать не надо. То есть, если у вас там тысяча абонентов, и это здание из 10 этажей на каждом этаже 100 абонентов, не надо там использовать свечи уровня Small Office, Home Office. Это не Small Office и не Home Office. Это оборудование Enterprise класса. Да, оно дороже по сравнению с оборудованием Соховским, но оно, соответственно, заточено специально под такие задачи. Если у вас сетка в тысячу портов навернется от того, что вы петлю забудете каким-то образом побороть, и сеть упадет, и все тысячи портов будут недоступны, то размер швабры, который вам будут запихивать соответствующий разъем, оно будет резко отличаться от размера швабры, который вам запихнут в соответствующий же разъем, если у вас упадет сетка на 4 порта. Поэтому, если у вас маленький свечек на 4 порта используется, используйте его для сетки на 4 порта. Если вам предлагают на 4-х портовых свечках построить сеть на 1000 портов, вот купить 600 свечей, и соединить его в 10 гирлянд на 10 этажей,

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

все равно вы будете до каждого кабинета тянуть один провод, если мы предполагаем, что там 4- unacceptable свитчей, да, вот несколько проводов протянуть примерно столько же стоит, сколько один провод. Поэтому все равно в каждый кабинет тянуть провода. Ну, значит, можно лучше протянуть вообще до каждого абонента тогда отдельный провод. Хороший дизайн сети, которая будет использовать коммутаторы, на самом деле будет примерно у всех производителей, которые будут рекомендовать такие дизайны, примерно одинаковый. У вас будут естественно использоваться правильные соответствующие оборудования, правильных соответствующих линеек. Таких свечей, которых будет много и которые будут, скажем, менее важны, они будут подешевле. Те свечи, которые будут испытывать большую нагрузку по сравнению со всеми остальными, они будут более дорогие, более надежные, более производительные. Ну, логично, что того, чего много, лучше бы сделать подешевле. Того, чего мало, но оно важно, логично, что оно будет чуть подороже, но оно будет более надежное, более устойчивое к проблемам.

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

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

если мы говорим про Ethernet. Если мы говорим про стык L2 и L3, то есть Ethernet плюс IP, то тогда придется использовать не чистый IP, а IP плюс какой-то костылик. Ну, где-то вам придется использовать костыль, либо на уровне Ethernet, либо на уровне IP. Далее. У вас будут важные свитчи и неважные свитчи, важные должны будут резервироваться, неважные будут подешевле. На абонентских портах у вас будут относительно небольшая скорость. То есть в том смысле, что если ваши свитчи технически могут поддерживать 10 гигабит, это не означает, что вам везде срочно нужно вообще 100% портов иметь в 10 гигабитном стандарте. То есть абонентские порты, они не должны быть быстрые. Почему? Потому что в любом случае скорость портов, которые смотрят на абонента, не может превышать скорость портов, которые на свитчи друг на друга смотрят. Свитчи между собой будут передавать агрегированный трафик со стороны всех пользователей. И поэтому скорость портов между свитчами должна быть сильно выше, чем скорость абонентских портов.

Чтобы если вам много абонентов одновременно пихать трафик, чтобы вы этот трафик смогли передать дальше куда-то в сеть. Понятное дело, вы не должны будете закладывать в большинстве случаев на то, чтобы у вас скорость между свечового линка, interswitch link, в точности была равна сумме абонентских скоростей портов. То есть, если у вас 100 абонентов по 100 мегабит, вы не должны будете говорить, что вам потребуется ровно 10 гигабит для того, чтобы весь этот трафик передать. В большинстве случаев вы можете использовать поменьше скорость. Вы можете сказать, что дизайн ваш предусматривает oversubscription, то есть в нормальной ситуации ваши абоненты не загружают сеть на 100% все одновременно. Oversubscription именно эта ситуация, когда у вас агрегированный трафик в норме будет меньше, чем математическая сумма скоростей портов, через которые этот трафик будет приходить. Пример из жизни вы

наверняка видели, как провайдеры продают интернет. Они притаскивают к себе какой-нибудь апплинк, допустим 10 гигабит и дальше начинают его продавать. И продают эти 10 гигабит тысячи пользователей по допустим 100 мегабит или по 10 мегабитам. Скорее по 100. математическая сумма скоростей тех каналов, которые они продали, она выше, чем тот апплинк, который по факту есть. Но поскольку пользователи одновременно не ломятся в интернет, там кто-то пьет чай, кто-то пьет кофе, кто-то играет в игрушку, кто-то запустил торрент, вот в среднем у вас загрузка вашего интерфейса получается вот та, которую вы ожидаете от пользователя. И когда вы среднюю загрузку считаете, суммируете по всем портам, получается, что вот вам ее должно быть достаточно для того, чтобы загрузить ваш порт. А больше порт более производительный покупать смысла уже нет. Если у вас, вы знаете, что в среднем нагрузка на порт вашего провайдерского клиента, там допустим 1 мегабит, вы ему можете продать десятку. Да, в какой-то момент в пике он будет сосать 10 мегабит,

но в среднем он будет занимать там 1 мегабит. И вы говорите, вот у таких абонентов у меня допустим там тысяча штук, поэтому совокупный трафик от них будет 1 гигабит объема. Вот 1 гигабит. И вы, соответственно, можете купить апплинг гигабитный, продать его 1000 пользователей по 1 мегабиту и бурно радоваться. Да, в каждый конкретный момент времени кто-то разгонится до 10 мегабит и кто-то не будет сосать трафик вовсе, будет пить чай или играть в игрушку. Поэтому в среднем вам этого хватит. Вот, соответственно, такая же штука у вас должна быть и в предприятии. В большинстве случаев то, что пользователи у вас будут сидеть на скорости 1 гигабит физически подключенной не означает, что они будут все одновременно сосать трафик со скоростью 1 гигабит. Вы должны будете предусмотреть, если вам это необходимо. Вот, если вы точно знаете, что иногда бывают ситуации, когда у вас все пользователи одновременно пытаются на одном гигабите сосать данные и это штатная ситуация, отдаст doit STEP не обрабатывать и на гигабите всем отвагать трафик. Вот тогда вы должны будете предусмотреть, чтобы вам агрегированного канала хватило. Но в обычной ситуации, в подавляющем большинстве нормальных ситуаций, которые бывают в предприятии, такого не бывает. У вас нормальный пользовательский сценарий это немножко поработать, немножко пойти попить чай, немножко поработать, немножко пойти попить чай. И никогда агрегированный трафик не будет равен математической сумме скорости портов.

Да, рекомендации существуют, то есть вы можете по, скажем, по тому месту, которое занимает конкретный линк в вашей топологии, примерно оценить, какая должна быть для него рекомендованная загрузка. Так, далее, что у нас тут еще будет? Откуда берется вот эта вот самая модель, аксесс, агрегация, ядро? Я начал про это говорить, но что-то как-то отвлекся слегка. Вспомните хабы. Правило четырех хабов. Мы уже проговорили про то, что эти самые хабы, они строились, вот это самое правило четырех хабов строилось, исходя из максимального расстояния между узлами в 500 метров. 500 метров это 5 проводов по 100 метров. С двух сторон к этим пяти проводам подключается пользователь, посерединке может быть не больше четырех хабов. После того, как вы эти самые четыре хабы поставили, вы можете взять и попытаться нарисовать картинку, как они могут располагаться друг относительно друга. То есть понятно, что возьмите, просто нарисуйте колбаску с четырех хабов и попытайтесь добавить к этой колбаске хабы таким образом, чтобы вот между любыми двумя абонентами не больше четырех хабов было, между любыми, скажем, хабами было не больше трех линков.

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

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

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

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

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

Смысл этих устройств будет именно такой, что в них пользователи не подключаются, в них подключаются Access Switch. И, соответственно, нагрузка на порт у этих моделей будет сильно выше по сравнению с пользовательскими свечами. Если говорить про Enterprise-идеологию построения сети, то эта модель называется Distribution. Если, соответственно, у вас используется провайдерская технология, то это будет агрегация. У провайдеров еще, кстати, Access уровень иногда называется уровень Edge пограничники. Но это, опять же, типичная провайдерская технология. Вы можете смело использовать оба названия, все вас поймут, если вы говорите именно про провайдерскую тему. В предприятиях Access и Distribution более правильно. Да, на Access может быть по Е, если он вам необходим. На Distribution по Е не нужен, потому что абоненты Distribution Switch'ей – это Access Switch'и, а Access Switch'и, запитывающиеся по по Е, явление все-таки достаточно редкое. Модели существуют, и у CISC есть модели, запитывающиеся по PowerWeatherNet и у других вендоров,

но в предприятиях они все-таки редко используются. Дальше, соответственно, может быть следующий сценарий. Вы взяли, поставили на Access дешевые свечи, поставили на Distribution умные свечи, умные свечи там чего-то делают, выполняют задачи безопасности, обработки, трайф, маршрутизации, возможно, чего-то еще. Quality of Service здесь же. В общем, много чего они делают, молодцы, но их становится слишком много, и вы не можете все Access свечи воткнуть в ваши дистрибьюшены. Они просто у вас не хватает количества портов. Допустим, взяли, на Access уровень решили ставить 29.60, на Distribution 37.50. Типичные такие рабочие лошадки в предприятии. 37.50 купили, 48 портовые, но у вас этих самых Access свечей, допустим, 200 штук. И у вас получается, что стоит пара дистрибьюшенов, и у этой пары дистрибьюшенов 96 портов на двоих. А надо воткнуть 200 свечей. Но 200 в 96 математика не позволяет воткнуть.

Для того, чтобы, соответственно, воткнуть 200 свечей в дистрибьюшены, вам потребуется больше свечей, чем 2. Ну, допустим, 4 или 5 или 6, я не знаю, сколько это получится. Опять же, здесь уже загрузка будет важна каждого конкретного свеча. Способен ли будет ваш дистрибьюшен вытянуть нужное вам количество трафика. То есть, если вы хотите там строго 37.50 ставить, вы берете и считаете производительность каждого конкретного свеча. Смотрите, сколько трафика к вам приходит на дистрибьюшен от каждого абонентского Access. Перемножаете одно на другое, точнее, делите одно на другое, и получается, сколько вам свечей нужно. Покупаете нужное количество свечей, и возникает вопрос, а как их соединять между собой? Пока свеча 2 дистрибьюшен, их можно соединить прямым проводом. Свеча 3 можно соединить там 1 со 2, 2 с 3, 3 с 1 в кольцо. Но, опять же, придется тогда бороться с кольцом. Можно сказать, а пусть у нас тогда 1 будет свеч соединяться с 1 и с 2. 1 со 2, 1 с 3. Тогда трафик между 1 и 3 будет ходить через 2, и на 2 будет мало того, что нагрузка от абонентских свечей, так еще и транзитная между 1 и 3.

То есть, для случая, когда у вас повышенная нагрузка идет на какой-то 1 свеч, у вас всегда начинаются те же самые проблемы, с которых мы начинали этот разговор, что повышенная нагрузка на какой-то свеч, повышенная нагрузка на канал, и это всегда проблемы. Поэтому, если у вас свечей и дистрибьюшенов становится много, вы должны будете какие-то из свечей назначить транзитными для связи между собой дистрибьюшен свечей. У вас этих дистрибьюшенов много, вам требуется взять какой-то, выделить один или два или больше свечей, сказать, вот это свечи специальные, транзитные, они супербыстрые, они способны переживать сколько угодно трафика, и, соответственно, вы втыкаете все свои дистрибьюшен свечи вот в этот специальный, и назначаете его нелюбимой женой, конечно, но вы его назначаете уровень ядра, скажем так. Это будут свечи уровень ядра, Campus Core. По поводу того, что не больше четырех для дистрибьюшена, вы можете, если захотите, соединить любое количество свечей между собой прямыми линками,

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

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

будет интересовать нас ядро, он будет вносить дополнительную задержку. До тех пор, пока вам все равно, вы можете делать все, что угодно. Если вы начинаете бороться за сокращение этих самых задержек при передаче пакетов, при передаче кадров, лишние, ненужные вам свечи, они будут вам вредить. Поэтому, если есть возможность обойтись без дополнительного ядра, лучше обойтись без него. Да. По поводу стеков, то есть, тут разные цифры, 4, 6, 9. Опять же, зависит от вендора, зависит от платформы. Если вы будете соединять 2960, и свечи 2960s позволяют соединиться, там будет технология FlexStack, если мне память не изменяет, и они будут 4 свеча соединять между собой. Если говорить про 3750, у них будет StackWise технология, и другой тип технологии стекирования, и там, вероятно, будет все другое. Если вы будете смотреть какую-то совсем третью, там Huawei, Extreme и прочее, там будет совсем третье. Вот Huawei, в смысле, Extreme свечи, у них 4 свеча соединяются между собой, если у меня память не изменяет.

Так, далее. Что у нас еще? Про Campus Core, да, я сказал. Производительность таких свечей будет колоссальная. Эти свечи, как ни странно, Campus Core, они достаточно тупые. Дело в том, что основная задача ядра это быстро перекинуть трафик между двумя дистрибьюшенами. Поэтому, если вам нужно выполнять какие-то сложные задачи, вы это делать будете на дистрибьюшене. Поэтому дистрибьюшены свечи умные, они дорогие, и они вот чего-то там мудрое такое будут делать. Если вам нужно между дистрибьюшенами трафика перебросить, вы это перебрасываете на Core, и Core дальше кидает на другой дистрибьюшен, там нечего уже делать. Все умные задачи, которые были, они решены на дистрибьюшене. Поэтому Campus Core свечи, они тупые, но они дорогие за счет того, что они очень быстрые. Так, есть ли смысл заморачиваться на стековых 29.60, есть ли от этого реальный профит? Все зависит от того, что вы хотите получить. Если вы берете 29.60 для того, чтобы их соединять в стек,

считайте производительность межштековой коммутации, внутри стековой коммутации. Если она вас устраивает, то да, есть смысл это заморачиваться. Всегда стек это хорошо. То есть вы не должны будете использовать Spanning 3 между коммутаторами, вы не должны будете думать на тему того, что вот у вас стек Vice какой-нибудь или что-то еще. Ой, не стек Vice, простите, в Flex Link для связи с дистрибьюшеном. То есть это всегда позитивно. Стек вносит заметное упрощение в топологию. Если у вас можно соединить в вашем сценарии свечи в стек, и свечи стоят между собой относительно недалеко друг от друга, то, конечно, имеет смысл их соединять в стек. Можно не Spanning 3 и Ether Channel, но если соединять между собой 4 свеча, не между собой, а тянуть от каждого Access свеча, допустим, 4 штуки у нас рядышком стоят, тянуть до дистрибьюшена от каждого свеча 2 провода,

соединять их в Ether Channel до какого-то одного абонента, до одного дистрибьюшена, потом тянуть два провода другого, соединять в другой дистрибьюшен, все это дело соединяется в другой Ether Channel, и все это дело закрывать FlexLink, для того, чтобы не гонять там Spanning 3, то просто эффективность страдает. А если то же самое сделать, но в сценарии с Астеком, то у вас эффективность будет заметно выше. Так, что у нас тут еще будет? Вот классификация коммутаторов, да, она будет делить коммутаторы на Access Distribution ядро. Есть модели Campus Access, Campus Distribution, Campus Core. Это модели типичные для предприятий, то есть если у вас просто компания, вы хотите просто пользователей подключать, там где-то будет у вас серверная ферма, где-то будет модуль, выходящий наружу Enterprise Edge, но вот вы хотите основную коммутируемую сеть сделать, вы покупаете модели Campus Access, Campus Distribution, Campus Core. Есть модели дата-центровые, то есть они также называются Data Center Access, Data Center Distribution, Data Center Core.

Это все то же самое, только с неблокирующей коммутацией. Если у вас, для вас важно, чтобы трафика сколько бы ни было, он бы не терялся, особенно если это не вы виноваты в том, что вы нахидагачили много трафика, а кто-то еще вам испортил малину, то вам нужны будут дата-центровые свечи. Ну, если мы говорим, допустим, про Cisco, это будет линейка дата-центровых свечей Cisco Nexus. Такие свечи будут по сравнению с обычными свечами Access Distribution Core сильно дороже, но они в некоторых сценариях будут очень важны. То есть дата-центровые сценарии, например, это у вас есть сервер, и этот сервер по какому-нибудь iSkyze цепляется к дисковой полке, которая стоит в этом же дата-центре, но в соседней стойке. Если вы будете по обычному Ethernet угонять данные, то они могут потеряться. Это нормальное явление, когда у вас в Ethernet данные теряются. То есть Ethernet старается доставить все настолько хорошо, насколько это возможно, но если что-то не доставилось, никто об этом ничего не узнает. Отправитель об этом не узнает,

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

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

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

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

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

если вы, допустим, на аксессе скажете, о, это голосовой кадр, мы его приоритетно выпустим в сторону дистрибьюшена, но не повесите на него мигалку, то тогда дистрибьюшен свитч, чтобы определить, что это очень важный кадр, должен будет сделать очень тяжелые вещи. Он должен будет разобрать изорнад заголовок, посчитать чек сумму, убедить, что там внутри легитимный кадр. Посмотреть MAC адрес источника, записать его в табличку и все остальное. Дальше надо будет понять, что внутри. Голос там или не голос. А для этого надо будет расковырять. Сначала посмотреть, что внутри лежит IPv4 или IPv6. Прочитать заголовок IPv4 и IPv6. Убедиться, что внутри лежит, допустим, протокол UDP. Расковырять протокол UDP. Убедиться, что внутри лежит что-то похожее на протокол RTP. По портам этого не видно. Вам придется взять и сказать, окей, UDP-шный заголовок мы прочитали, теперь мы расковыриваем содержимое и читаем данные, которые внутри UDP бегут. Если мы видим по каким-то сигнатурам

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

Штатный Ethernet не позволяет в заголовок IP пакета писать, в смысле в заголовок Ethernet кадра не писать ничего, не позволяет, что у нас там очень фиксированное количество полей, и, ну, то есть, ни в MAC-адрес источника, ни в MAC-адрес получателя, ни в Ethertype, ни в Checksum, мы написать ничего свое не можем. Это все поля предетерминированные, мы обязаны их сохранить. Но бывает дополнительный протокол, 802.1.p, например, который, часть протокола 802.1.q, который позволяет вам в заголовок Ethernet дописать несколько своих желаемых полей. То есть, вообще-то говоря, это про Вилан речь, но там же есть специальное поле, 3 бита, в которое вы можете написать что-нибудь свое. Например, вы можете написать, если там нолики, три нуля битовых, это ноль десятичные, то вы говорите, это очень неважный трафик. Если вы туда единичку напишите, это будет чуть поважнее, чем неважный, но все равно неважный. Ну, например.

А можете написать туда, допустим, 7, три битовые единицы. И тогда это будет суперважный трафик. А можете наоборот поступить, допустим, сказать, что у вас есть вот эти вот самые три бита, и вы можете сказать, что если там лежит 7, это неважный, а если там лежит ноль, это важный. То есть, вы получаете три бита, в которые вы можете что-нибудь написать, и эти три бита можно как-нибудь дальше будет прочитать. Это все будет частью Ethernet заголовка. Когда коммутатор получает какой-то кадр, вообще-то говоря, содержащий внутри IP-пакет, внутри IP-пакета лежит UDP, внутри UDP лежит RTP, и этот RTP голосовой. Вот. Вы можете сказать, мы не будем расковыривать IP. Мы не знаем, что там внутри лежит UDP или не UDP. По заголовку кадра Ethernet мы видим, что там вроде бы IP, но мы не будем читать этот заголовок IP. Мы прочитаем дополнительный заголовок, который у нас там есть, 802.1 Q-шный, и внутренний его три бита, 802.1 P-шный. Увидим там число 7, и на основании числа 7 примем решение, что этот трафик важный или не важный. То есть,

вы ему такую вот допметочку сделали, мигалку повесили. У обычных машин мигалки нет, а у этого есть. И все остальные коммутаторы, которые знают, что мигалка это важно, они такой кадр пропускают специальным образом, освобождают для него полосу. А те, кто не знает, что такое мигалка, они, в общем, удивятся и скажут, какой странный мужик едет, какую-то синюю хреновину сверкающую на себя повесил. Что это такое? Непонятно. И просто его прокоммутируют дальше, как есть. Вот. Ну да, вот эти вот три бита, они иногда называются словом Class of Service, COS. Не путайте с QoS, Quality of Service. То есть, 802.1p это три бита, для которых предусмотрено место в заголовке 802.1q. И если вы эти самые биты читаете, анализируете, то да, вот эта вот метка будет называться Class of Service и она будет анализироваться в рамках методологии Quality of Service. Здесь есть некоторая путаница, которая может смущать, но в принципе достаточно все просто.

Обычные коммутаторы не читают заголовок 802.1p, следовательно, они не выполняют никакие методы Quality of Service, следовательно, им все вот эти вот метки COS по барабану. То есть, если, допустим, вы думаете, что сейчас вы хотите обмануть своего интернет-провайдера и все кадры, которые вы в сторону интернет-провайдера своего будете отправлять, промаркировать этим самым COSом-семеркой, вас ждет жестокий облом. С вероятностью близко к единице, соответственно, у вас это сделать не получится. Потому что даже если ваш провайдер будет принимать кадры, отправляемые вами с вот этой самой дополнительной меткой 802.1q, с вероятностью близко к единице, он вашим этим меткам COS доверять не будет. Он будет говорить, что все, что пришло от вас, на все он будет вешать метку COS какую-то свою. Вот он будет говорить, что все, что пришло от вас, это метка COS единица. Поэтому смысла указывать там что-то свое, особенного нет. Тема про quality of service, она большая, мы ее сейчас детально рассказывать

не будем, то есть, наверное, про нее можно рассказывать очень долго. В свое время у ЦИСКи было аж два курса недельных, посвященных quality of service. Сейчас тема эта разъехалась по нескольким разным трекам, и специального отдельного курса COS нет. Ну, да, то есть, вот технически вот здесь вот имеет смысл на Аксессии выполнять маркировку трафика для того, чтобы классификацию трафика всем остальным облегчить. Здесь, соответственно, ну, на Аксессии, вот да, базовая задача по безопасности и основная задача Аксесс уровня это передать трафик в сторону дистрибьюшена. Дистрибьюшен дальше должен уже сделать какие-то свои задачи. Типичные задачи на дистрибьюшене это маршрутизация, например. То есть, у вас обычно в сетях корпоративных трафик Ethernet не ходит через ядро. То есть, сеть, как бы ядра есть, но тут маршрутизация на самом деле выполняется. То есть, вот тут вот будут бегать хотя и кадры Ethernet, но они будут содержать IP-пакеты и по этим IP-пакетам

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

просто не очень хорошо приспособлены, как правило. В большинстве ситуаций, на самом деле, в реальном мире на Аксессе стоят тупые железки, которые куплены непонятно кем, непонятно когда и непонятно зачем, у которых просто никакой даже веб-морды нету и консоли нету и вообще ничего нету и они неуправляемые и они просто работают и это единственное их преимущество. Поэтому все задачи по безопасности, они, как правило, решаются вот именно на Distribution. Хорошо, если Аксесс у вас управляемый, хорошо, если он умеет делать всякие разные клевые штуки. Чем раньше вы сбросите ненужный трафик, тем лучше, если можно на Аксессе решить задачу безопасности и он нормально с этим будет справляться, то нет ни единой причины этого не делать. Спускайте все задачи как можно ниже, как можно ближе к пользователю и срезайте ненужный трафик как можно раньше. Но типичное место, где это можно делать, это как раз Distribution. Так, есть смысл применять Class of Service, когда есть кадры в очереди TX, RX, Ring, софтовых. В противном случае кадры будут обрабатываться сразу без задержек. Ну,

там это уже особенности реализации каких-то конкретных алгоритмов, какого-то конкретного вендора, конкретного софта. Вы должны будете их, конечно, принимать в первую очередь. И вообще в тему Class of Service и Quality of Service соваться лучше только со специальной подготовкой. Тема Quality of Service, она очень такая интересная тем, что в нее хочется залезть сразу. Когда NeoFit слышит, что можно каким-то кадрам дать приоритет, каким-то IP-пакетам дать приоритет, какие-то данные обрабатывать лучше, чем все остальные, у него загораются глаза и он говорит, мне срочно надо, у меня торренты плохо работают, я хочу, чтобы мои торренты лучше работали, я хочу все промаркировать, чем попало и отправлять все это дело. Да, его надежды разобьются, они могут разбиться на границе с провайдером или даже раньше. То есть, не исключено, что во многих случаях до провайдера все дело можно дойти. например, как бы, то, что ближе всего ко мне, вот у меня от меня на расстоянии

где-то 60 сантиметров стоит ADSL модем. Я точно знаю, что этот модем отправляет прямо вот в любую секунду ровно 512 килобит трафика, просто потому, что я знаю, что у меня есть большой объем данных, которые надо выкачать в интернет, у меня домашний сервер стоит, и на этом домашнем сервере объем данных, которые надо забэкапить, он примерно полтора терабайта. Вот, я его начал бэкапить примерно год назад, и он до сих пор не забэкапился. Но я знаю, что вот он медленно, потихонечку льется, и данные все отправляются менее приоритетно по сравнению с любым другим типом трафика. Вот трафик, допустим, вебинаров, он приоритетный. Мой голос, он супер приоритетный, слайды чуть менее приоритетные, но они все равно более приоритетные, чем все остальное. Ну, да, микротик стоит. Стояла и циска, но с циской, да, я купил 877 циску пожадности, она мне обошлась в 20 баксов, но мои надежды разбились, а то, что она не умеет выполнять нормальную, так как мне хотелось,

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

которую, безусловно, настраивать надо. Но, что бы я ни делал, как бы я ни старался, торрент от этого лучше работать не будет. И, соответственно, если я буду шаманить с этими самыми метками, если я буду шаманить там с чем угодно, с Class of Service, Quality of Service, IP Preference, с DSCP метками, я все равно больше, чем 512 килобит туда не отдам. Да, вот такая вот штука. Соответственно, да, вы должны будете понимать, для чего настраивается Quality of Service, как он настраивается, почему он настраивается именно так, какие методы, какие методологи там есть. Вот, допустим, в случае, если я хочу отдать в сторону провайдера 512 килобит трафика, но я хочу, чтобы всегда, допустим, мои голосовые данные отправлялись в приоритете, я не могу сказать, я сейчас свалю на свой роутер все подряд, а он дальше будет отправлять в сторону ADSL какие-то маркированные данные, потому что маркированные данные, они важные голосовые. Все это сведется к тому,

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

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

Если вам нужно шейпить трафик, вы должны правильно отобрать трафик для шейпинга в первую очередь. Ну вот, а дальше в промежуточные какие-то буферы будут складываться данные, которые будут надо отправить не сейчас, а чуть попозже. Такого количества памяти на аксесс-свечах нету. На дистрибьюшен-свечах они есть. Большие буферы памяти, которые можно использовать для этого самого шейпинга. На core-свечах ничего этого не делается. Core-свечи тупые. Они быстрые и тупые. Вот. Если говорить про примерные загрузки свечей, какие они бывают. У разных вендоров понимание того, какой свеч к какому классу будет относиться. То есть, возьмете какую-то конкретную модель, 2960, 3750 и прочее. На сайте вендора может написано быть разное. То есть, допустим, на 3750 написано, что это аксесс-свеч. В то же время практика показывает, что он как дистрибьюшен-свеч вполне себе неплохо справляется. Почему так? Дело в том, что в зависимости от того, какая у вас сеть, какая нагрузка на эту сеть,

один и тот же свеч действительно может выполнять разные задачи. Маркетинг здесь не столько маркетинг. То есть, понятное дело, что вы будете иметь некий пул пользователей, которые зайдут на сайт, выберут просто модель, на которой написано, что это аксесс-свеч, и купят ее, и переплатят тем самым по сравнению с другим свечом, который тоже аксесс-свеч, но дешевле. Но в реальности может быть такое, что действительно у вас будет такая сеть, для которой 2960 не подходит на аксессе, потому что он просто не справляется с таким объемом. Да, 3750 или 3850 он мощнее. Но может быть у вас пользователи такие, которые реально отправляют много трафика. Может быть у вас там, не знаю, используется какая-то жутко неоптимизированная DNS, которая постоянно порт 100% на загрузку кладет. Да, она не 100% времени в 100% загрузку порт кладет, но она там, не знаю, 30% времени в загрузку кладет, и вот вы там нажимаете кнопку, она вот начинает вам гигабайты трафик сосать. Потом снова другую кнопку нажимаете, она снова начинает гигабайты трафик сосать.

Мало ли, вдруг у вас вот такие пользователи. Поэтому да, 3750, 3850 может решать задачи аксесса. Он умный, но он при этом достаточно мощный для того, чтобы быть и на уровне агрегации в небольших сетях, и на уровне доступа в сетях с большим количеством трафика. Соответственно, если говорить про дистрибьюшн, вот в такой классической модели интерпрайзной сети, принятой в нормальном мире, если говорить опять же про оборудование ЦИСК, это вот 3750 такая рабочая лошадка. Кроме того, можно, соответственно, подумать в сторону каких-нибудь, ну, допустим, 65-й линейки. Вот. И, соответственно, уровень ядра это даст. 45-й линейка, да, 45-й, простите. Я начинаю думать, что вот это самое шасси, вот это что-то как-то у меня в голове переклинено. 45-й линейка, простите, конечно же. И, соответственно, уровень ядра это будет либо 49-й, либо 65-й каталисты, большие, толстые.

Но, опять же, он для ядра как бы может подходить. У него есть недостатки, которые мешают ему быть полноценным ядром, но он может им работать. Вот. Или вы можете сказать, что не надо нам иметь там 65-й каталист на уровне ядра, потому что это много портов, теоретически много портов. Это всегда как минимум 4 линейные, там, сколько, 2 линейные карты. То есть столько дистрибьюшн свечей у вас будет совсем мало. Вот. Поэтому, совсем маловероятно. Поэтому вот можно 49-й свечи использовать, если у вас точный гарантированный дистрибьюшн уровень будет не очень большой. Но зато, да, 49-й и 65-й свечи, они позволяют использовать наиболее быстрые типы портов, которые доступны в линейке Cisco Catalyst. То есть 10 гигабит доступно только там. Так. Что у нас там еще будет из интересного? Да. Вот на уровне доступа ставятся коммутаторы подешевле, на уровне распределения, на уровне дистрибьюшн ставятся подороже.

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

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

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

они будут просто теряться. К вам приходят новые нолики, единички, а вам их сложить некуда, у вас все буферы забиты. Но, соответственно, да, вы в таких ситуациях будете терять кадры. Если вы знаете, что ваша средняя загрузка портов порядка 20%, вы можете быть уверены, что ничего не теряется. Так, да, исходя из этих цифр, обычно рассчитывается тот самый Eversubscription. То есть если вы знаете, что у вас средняя загрузка порта абонентского 5%, вы знаете также, что у вас, допустим, 48 абонентских портов, вы также представляете, что у вас там 48 абонентских портов, загруженных в 5%. Это дает вам приблизительно 2 гигабита трафика. Ну вот вы можете сказать, вот на нашем 100-мегабитном свиче 48 100-мегабитных портов и 2 гигабитных апплинка. Мы их объединяем в один из R-Channel с логической скоростью, там, в 2 гигабита. Это не означает, что туда 2 гигабита всегда можно пропихнуть, но с некой надеждой 2 гигабита туда пролезть теоретически, наверное, иногда может. Вот вы говорите, при средней загрузке нам этого вполне будет достаточно.

Тем более, что механизмы балансировки из R-Channel, основывающиеся на MAC-адресах, они будут каждый раз видеть в каждом кадре от разных абонентов разные MAC-адресы и источники, и, скорее всего, балансировка там будет более-менее равномерная. Если же вы будете прогнозировать загрузку, допустим, distribution link между свичами или загрузку link distribution ядро, то вы должны будете ориентироваться на цифру в 20%. Если у вас есть свич 24-портовый, у которого 24 гигабитных порта, и загружены они в 20%, то вы можете примерно прикинуть, что у вас, соответственно, есть некая производительность того канала, которым вы смотрите на оплинком на ядро. Эта производительность, скорее всего, ограничена, и вы не можете всех пользователей, все порты на distribution switch забить, потому что иначе у вас over-subscription будет превышать те самые цифры, которые вы запланировали.

Поэтому вы в этом случае на distribution switch, как правило, будете занимать не все порты. Именно по этой причине distribution switch, допустим, 3750, если используются, они чаще всего используются 24-портовые, а не 48-портовые, хотя линейка имеет 48-портовую модель, но 48-портовая модель предназначена для уровня аксесса, чтобы агрегированный трафик передавать в сторону distribution, и этого трафика было бы не очень много, он бы влез в тот самый оплинк. Потому что если у вас уровень distribution, тогда трафика будет приходить на этот свитч слишком много, если вы повтыкаете туда 48 аксессов, вы его, а, не сможете обработать, и, б, вы не сможете его дальше передать на ядро, если это будет необходимо. Так что понимайте, пожалуйста, какие модели, куда вы в сети ставите, целеположение каждой модели нужно будет понимать, и среднюю загрузку модели тоже надо будет понимать, сколько трафика на вас приходит, что вы с этим трафиком дальше будете делать, куда надо будет его прокоммутировать, сколько кадров прокоммутировать,

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