Эволюция и работа коммутаторов в современных сетях

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

При этом, естественно, для того чтобы обеспечить обратную совместимость, эта самая коммутация должна происходить абсолютно прозрачно для пользователей. Пользователи, конечные оппоненты, они ничего не должны знать про эти коммутаторы. И с их точки зрения, что эта коммутация есть, что коммутации нет — для них должно быть абсолютно всё равно. Вы не должны иметь возможность, как обычный пользователь, определить, есть ли у вас в сети коммутатор или его нет. Давайте разбираться, как это получилось сделать. Все современные сети, как уже было сказано, строятся на коммутаторах. Причём коммутаторы бывают разные. Бывают маленькие, вот как внизу справа нарисован коммутатор на 8 портов, на 9 или на 10, как посмотреть. Есть коммутаторы чуть побольше, назовём их стоечные. В стопочку сложены 4 коммутатора, 3850 из Cisco. Сейчас попробую прямо показать на слайде.

Вот эти товарищи. Это 3850 коммутаторы. Их 4 штуки. Первый, второй, третий и четвёртый. И бывают совсем большие модели. Вот этот холодильник — это не шкаф, набитый свитчами. Это один большой коммутатор. Это не стойка со свитчами. Это одна большая железяка, которая ставится в стойку. И в неё вы можете включать линейные карты. Это модульный коммутатор. У него есть две, назовём это думалки, два супервизора и куча линейных плат. Вот это раз линейная карта, два линейная карта, три линейные карты и так далее. Каждая линейная карта имеет на себе набор каких-то портов. И этих портов, как вы можете видеть, может быть довольно много. Если исходить из того, что в один модуль в принципе может влезть 48 медных портов, и этих модулей может быть 16 штук, то 48 умножить на 16 — это сколько получается?

768, что ли? В общем, много. Короче говоря, в один такой свитч можно насовать много-много-много портов. Что это за модель — это Cisco Nexus. Если мне память не изменяет, 7718. У него 18 модулей, из них 16 под линейные карты и два под супервизора. Модель уже не самая свежая, и сейчас есть более новые модели, в том числе такие же большие шкафы, но тем не менее вы можете в него насовать много-много-много портов. Более того, есть для этой линейки, для семитысячников, возможность использования так называемых экстендеров. Вы можете взять линейные карты, в которые воткнут специальный провод, в которые воткнут специальный юнит. Он выглядит как обычный стоечный свитч, но это при этом не свитч. У него есть порты физические, которые вы можете видеть глазками.

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

в какой-то степени, может быть, даже лучше. Но Cisco просто потому, что она является эталоном для образовательных программ. Вот мы берём её в качестве образца. Что делает любой коммутатор? Очень часто есть такое заблуждение, что коммутатор перекладывает кадры. Он берёт кадр на одном порту и перекладывает его на другой порт. Это неправильно. Если вы хотите понять, как он вообще в принципе работает, и вам хоть как-то, хоть кривенько, косенько понять хочется, вы можете такую логику использовать. Но это на самом деле не то, что делают коммутаторы. Коммутатор делает следующую вещь. У него есть порты. Давайте представим себе, что у нас есть коммутатор на 4 порта. У нас есть интерфейс, первый порт, на котором приходит какой-то аналоговый сигнал. Там плюс 0,7 вольта, минус 0,7 вольта. Эти вольты декодируются в биты, в нолики-единички.

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

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

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

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

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

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

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

Каждый коммутатор может одновременно работать с многими разными кадрами. У него эта матрица коммутации, которая перекладывает кадры между буферами, она одна, но она довольно быстрая. А буферов, с которыми она может работать, довольно много. И может быть такое, что у коммутатора есть... Давайте нарисую коммутатор. У него есть раз порт, два порт, три порт и четыре порт. И матрица коммутации каким-то образом положила в разные буферы много-много-много разных кадров. И вот они одновременно отправляются. Один кадр отправляется на одном интерфейсе, другой на другом, третий на третьем, четвёртый на четвёртом. Может быть такое, что разные кадры отправляются на разных интерфейсах одновременно. В случае с хабом это физически было невозможно. Хаб в принципе не работал на уровне кадров. Он работал на уровне электрических сигналов. Вы подаёте плюс 0,7 вольта на один порт, плюс 0,7 вольта отправляются на все порты. Здесь это разные кадры, которые передают разные нолики-единички,

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

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

но тем не менее оно достаточно важное. И существуют устройства, которые очень сложно отнести к определенному классу. Они могут быть одновременно и коммутатором, и маршрутизатором. И если говорить про конкретные примеры, например, есть линейка CISCO, 65-я линейка, 65 тысяч, 65-09, например, 65-13. И есть линейка CISCO 76, 76-06, 76-01, 09. И это, по большому счету, одна и та же железка. Это всё модульные устройства, но одни из них почему-то называются роутеры, маршрутизаторы, а другие почему-то называются свичи. Хотя на самом деле у них всё одинаково. У них практически одинаковые линейные карты, у них практически одинаковые супервизоры, только формы немножко разные. И почему мы некоторые устройства называем коммутаторами, а некоторые маршрутизаторами? Как раз потому, что коммутатором мы будем обычно называть

то устройство, у которого много портов. Как следствие, стоимость одного порта получается довольно небольшая. Если портов много, это скорее коммутатор. Если портов мало, это скорее маршрутизатор. Дальше. Каждый порт на коммутаторе может быть совершенно обособленный. Он никак не завязан на другие порты, которые есть на этом же коммутаторе. Это всё должны быть порты Ethernet, потому что мы говорим про коммутаторы Ethernet. Но тем не менее Ethernet — это у нас целое семейство стандартов. Есть 100BASE-T, 10BASE-T, 1000BASE-T, гигабитные Ethernet, оптические Ethernet. В принципе, у вас может быть коммутатор, у которого один порт работает сейчас в режиме 10 Мбит, другой в режиме 100 Мбит, третий в режиме гигабита медного, и четвертый в гигабите оптическом.

Тут SFP будет торчать, и по оптике будет что-то передавать. Это физически разные Ethernet, но тем не менее за счет того, что формат кадра у них одинаковый, можно принять кадр на одном интерфейсе по 10-мегабитной меди и отправить кадр на другом интерфейсе, который гигабитная оптика, без каких-либо проблем. Это не электрический сигнал мы дальше передаем по оптике, что бы это ни значило, а мы кадр, который получен по 10-мегабитному интерфейсу, передаем по гигабитной оптике, потому что формат кадра у Ethernet, оптического и медного, одинаковый. Порты могут отличаться по используемому стандарту, по используемой среде передачи — оптика или медь, по скорости работы, по режиму дуплекса. У них всё может быть разное. Но за счет того, что Ethernet — это семейство стандартов с одинаковым форматом кадра, мы между ними можем перекладывать кадры. Коммутаторы бывают разные. По максимальной поддерживаемой скорости на портах,

по количеству портов, по всяким другим фичам. И часто возникает вопрос: если пойти в магазин, можно там купить гигабитный коммутатор на 24 порта, на 16 портов за, к примеру, 10 тысяч рублей. А можно пойти и купить Cisco. И Cisco вроде бы тоже с 24 портами, тоже вроде гигабитная, но она будет стоить 100 тысяч рублей. И возникает вопрос, а почему так? За что Cisco деньги берет? За бренд, что ли? Если разницы нет, зачем платить больше? На самом деле у каждого коммутатора есть определенный набор характеристик, которые сильно влияют на его стоимость. И если вы видите коммутатор, который стоит 10 тысяч рублей, 100 тысяч рублей, и наверняка можно найти коммутатор, который при схожих характеристиках будет стоить реально миллион, у каждого коммутатора есть причины, по которым он может стоить условно миллион. Потому что есть эти самые характеристики, и вы их должны знать. Очевидная характеристика — это количество портов. Чем портов больше, тем коммутатор дороже.

Стандарты, скорости, поддерживаемые интерфейсы. Понятно, что гигабитный коммутатор будет дороже, чем 100-мегабитный при прочих равных. Как правило, медные порты дороже, чем SFP, если мы говорим про гигабит. SFP-шные порты проще устроены, и 1000BASE-T приемо-передатчик сам имеет какую-то стоимость по сравнению с обычной SFP-шкой, с дыркой под SFP-шку. Получается немножко дешевле сделать SFP. То же самое для 10 гигабит. Дальше. На каждом интерфейсе у вас есть буферы. SFP ещё купить надо, да. На каждом интерфейсе у вас есть буферы, есть входящий буфер и исходящий буфер, как минимум один. На простых моделях у вас может быть он реально один. Один входящий, один исходящий. На более сложных моделях эти буферы могут быть больше, сам буфер может быть больше,

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

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

если мы хотим Voice over IP обрабатывать в приоритете? Нам нужно два разных буфера на вход. У нас есть чип, который умеет принимать кадры, и он на уровне каких-то очень простых механизмов может принимать решение, в какой из двух буферов положить кадр, когда он его принимает. Например, мы можем сказать: у нас в кадре есть какой-то служебный битик, важный или неважный этот кадр. Какой-нибудь битик мы можем выделить для принятия такого решения. Если чип при приеме кадра, чисто на физическом уровне нолики-единички прибежали, видит, что в каком-то предсказуемом месте это важный кадр, он его кладет в один буфер. Если он видит, что там такого битика нет, он кладет этот кадр в другой буфер. И матрица коммутации, когда доходит очередь до этого интерфейса, она в первую очередь разгребает приоритетный буфер, и только потом, если он свободен, разгребает неприоритетный. Буферы на каждом порту отдельные, но речь про то,

что может быть не один входящий буфер на каждом порту, а несколько. Один, например, для приоритетного трафика, второй для неприоритетного. И наш чип, наш сам интерфейс, может принимать решение на основе каких-то очень простых механизмов, в какой именно буфер положить какой конкретный кадр. Естественно, это потребует от вас каких-то базовых настроек, чтобы вы сказали, какие кадры в какой буфер мы складываем. Естественно, нельзя будет на основе каких-то очень продвинутых методов принимать решение. Нельзя будет сказать, например: посмотри на то, что пришло, если ты видишь, что там Ethernet-кадр, в котором лежит IP-пакет, в котором лежит UDP-датаграмма, в которой лежит RTP-пакет, и всё это дело пришло на нечетный порт, положи это в приоритетную очередь. Такое он сделать не сможет. Но тем не менее по каким-то простым критериям разобрать трафик по двум буферам он может. И когда мы будем говорить про транки, увидим, что есть такое поле 802.1p,

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

вы положили в общую очередь торрент, потом ещё один торрент тоже в общую очередь, а потом Voice over IP вы хотите обработать, вы его кладете в более приоритетную очередь, оно уйдет раньше... вы поняли идею. Он уйдет, по крайней мере, максимально быстро, насколько это вообще будет возможно. Понятно, он не сможет растолкать какой-то кадр, который уже начал передаваться по интерфейсу, но когда он закончится, и чип будет брать следующие кадры из очереди для отправки, он будет брать в первую очередь данные из приоритетной очереди. Поэтому чем больше этих буферов, тем более точные гранулярные политики Quality of Service вы сможете настроить, тем дороже будет железка, потому что все эти буферы делаются из очень быстрой и довольно дорогой памяти. Поэтому если буфер у вас один, это одна история. Если буферов у вас много, и они позволяют гранулярные настройки делать, и по каким-то продвинутым критериям позволяют разбрасывать трафик по этим буферам, это сильно будет влиять на стоимость.

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

которые используются в современном мире, объём этой самой таблицы коммутации порядка тысячи записей. Тысячу адресов она способна в себе хранить. Более продвинутые модели могут хранить 10 тысяч, 50 тысяч записей. Но наиболее типичный для небольших сетей объём — это как раз в районе тысячи записей. 1024, если быть точным. На совсем простеньких моделях это может быть совсем мало. Там 500 записей, 250 записей. 250 — это совсем никуда. На более производительных моделях, как уже было сказано, она может быть и больше. Но в любом случае это не миллион записей. Это именно порядка тысяч записей. Чем больше записей, тем больше требуется дорогой памяти, тем дороже будет ваша железка. Сама матрица коммутации, которая будет перекладывать кадры между интерфейсами, тоже заметно влияет на стоимость.

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

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

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

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

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

Может быть такое, что у вас есть какие-то дополнительные фичи, которые на коммутаторах могут быть полезны. Самое очевидное, что здесь может быть, это Power over Ethernet. Оно реально повышает цену в два раза. Свитч без поддержки PoE и свитч с поддержкой PoE будут различаться в два раза. Может быть, у вас есть какие-то механизмы по безопасности, которые вы можете использовать. Мы в рамках нашего курса кое-что про безопасность поговорим. Все эти механизмы действительно позволят вам отбить ряд неприятных атак и повысить надёжность и стабильность вашей сети. Но за них придётся платить. Может быть такое, что свитч без поддержки этих механизмов стоит 10 тысяч рублей. А свитч с поддержкой этих механизмов стоит 30 тысяч рублей, или 50 тысяч рублей, или 100 тысяч рублей. Всё это влияет на цену. Поэтому, если вы видите в магазине гигабитный 48-портовый свитч за 10 тысяч рублей, и вроде такой же гигабитный 48-портовый свитч за 100 тысяч рублей с надписью Cisco,

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

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

из-под какого порта и с каким MAC-адресом источника эти кадры пришли. Помните, я вам говорил про формат кадра Ethernet, что есть два адреса. Это адрес получателя, который важный, и адрес отправителя, который в обычном Ethernet был неважный. Этот неважный адрес очень сильно пригодился при построении коммутаторов. Он хотя и был неважный изначально, но потом получил очень важную роль. Он позволяет коммутаторам смотреть, из-под каких портов пришли какие кадры, и запоминать, какие MAC-адреса источника на каком порту коммутатор видел. Он ведёт табличку, и в каждой строке говорит, что такой-то MAC-адрес соответствует такому-то порту. Он говорит: я вижу MAC-адрес A, он сидит за первым портом. Я вижу MAC-адрес B, он сидит за вторым портом. Я вижу MAC-адрес C, он сидит за третьим портом.

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

Эта табличка пополняется автоматически. Вы ничего специально не делаете для того, чтобы она пополнялась. И процедура MAC-learning, пока всё работает стабильно, справляется со своей задачей очень неплохо. Если вдруг так получилось, что абонент какой-то был известен за одним портом, потом он вытащился из-за своего порта и воткнулся в какой-то другой порт, то информация, которая была в табличке, стала неактуальной, неверной. Если мы получаем кадр из-под другого порта с тем же MAC-адресом, который мы уже знаем в табличке, допустим, мы знали, что узел C сидит за третьим портом, а сейчас мы его видим за первым портом, то старая информация удаляется, и новая информация перезаписывается на место старой. Нельзя сделать так, чтобы мы знали про какой-то MAC-адрес, что он сидит за двумя разными портами. Каждый MAC-адрес мы знаем только за одним портом. Понятное дело, что если у вас есть свитч,

он может быть включён довольно долго. Свитчи бывают с аптаймами год-два. Самый долго живущий свитч, который я видел, имел аптайм 11 лет. И понятное дело, что информация о том, что какой-то узел вы 11 лет назад видели за некоторым конкретным портом, не сильно вам сегодня полезна. Поэтому записи в этой таблице, как правило, живут ограниченное время. И если вы видите кадры, которые приходят из-под какого-то MAC-адреса, то вы продлеваете срок жизни записи в этой табличке. А если в течение некоторого времени никаких кадров из-под определённого MAC-адреса вы не видите ни за каким портом, то записи из таблички вычёркиваются. Это то, как выглядят таблицы коммутации, то, как выглядит процедура MAC-learning. Давайте я немножко проиллюстрирую этот процесс. У нас есть простенькая сеть, четыре узла, подключённые к одному коммутатору. Узел A хочет отправить кадр узлу B. Он говорит, я хочу отправить кадр узлу B, отправляет такой кадр в сторону коммутатора,

и коммутатор дальше принимает решение, что с ним делать. Сначала он его получает в виде аналогового сигнала, декодирует нолики-единички, составляет из ноликов-единичек кадр, смотрит в этом кадре, из-под какого адреса он пришёл. В нашем случае мы видим, что узел A прислал кадр, поэтому в табличку адрес-порт заносится запись, что узел A сидит за первым портом, если предположить, что это первый порт. Это, допустим, второй, третий и четвёртый. Дальше. В таблице мы ищем адрес получателя. В нашем случае узел B мы пытаемся найти, мы его там не находим, и мы говорим: мы не знаем, где сидит получатель. Он может сидеть за любым портом. Поэтому мы ни на каком порту не можем сказать, что там получателя точно нет. Поэтому мы не блокируем отправку кадров на порты 2, 3 и 4. Однако мы блокируем передачу данных на первом порту, потому что там этот кадр уже видели. Коммутатор всеми силами старается прикинуться толстым жёлтым коаксиалом. Толстый жёлтый коаксиал никогда не отправляет данные обратно.

Он распространяет данные только вперёд. Поэтому коммутатор блокирует отправку копии кадра на первом порту, не блокирует на втором, не блокирует на третьем, не блокирует на четвёртом. И копия кадра отправляется на все эти порты. Процесс, когда вы не знаете, где сидит получатель в таблице адресов и разбрасываете копии кадра на все порты, имеет своё собственное специальное название. Это не какой-то специальный отдельный процесс, это просто название ситуации, в которой у вас есть коммутатор, который не знает, где сидит получатель, и он разбрасывает копии кадра на все порты, кроме порта источника и некоторых других. Он называется Unicast Flooding. Вы можете, как человек, который видит, что узел A хочет отправить данные узлу B, понимать, что это взаимодействие Unicast. Узел A хочет отправить данные только узлу B и никому больше. Но если бы здесь у нас вместо свитча был толстый жёлтый коаксиал, в любом случае и узел C получил бы копию этого кадра, и узел D получил бы копию этого кадра, и узел B получил бы копию этого кадра, только C и D зажмурились бы и не читали этот кадр, а B этот кадр прочитал бы.

Коммутатор стремится вести себя как толстый жёлтый коаксиал, но при этом пытается повысить эффективность работы сети по сравнению с толстым жёлтым коаксиалом, и если он знает, что получатель заведомо не находится за каким-то портом, то он в этот порт просто не отправляет данные. Но если он не знает этого, он ведёт себя практически как толстый жёлтый коаксиал. Поэтому у нас ситуация, когда мы не знаем, где сидит получатель, мы разбрасываем копию кадра на все порты: и на второй, и на третий, и на четвёртый, и там уже C зажмуривается, D зажмуривается, B не зажмуривается и читает кадр. Попутно мы ещё запоминаем, что узел A сидит за первым портом. Здесь я всё на одном рисунке показывал, на самом деле здесь разбито всё по шагам на отдельных частях этого рисунка. Если вы знаете, где сидит получатель, процесс точно такой же. Вы принимаете кадр, например, узел B хочет отправить кадр узлу A. B отправляет кадр, говорит: я B, я отправляю кадр A, отправляет на своём интерфейсе этот кадр.

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

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

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

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

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

Дальше матрица коммутации определяет, куда его девать, и перекладывает в те порты, куда его надо отправить. Понятное дело, что чем больше кадр, тем больше у вас будет задержка. Вам надо целиком кадр принять во входящий буфер перед тем, как начнется процедура коммутации. Если кадр маленький, процедура коммутации запускается почти сразу после начала приема кадра. Если у вас кадр большой, пробежал джамбо-фрейм на 9 килобайт, вы должны его целиком принять, и относительно начала приема кадра в буфер у вас задержка будет, соответственно, больше. Поэтому задержка будет зависеть от размера кадра, и в некоторых ситуациях, опять же, тот самый высокочастотный трейдинг и прочее, режим store and forward будет неудобен, потому что он вносит непредсказуемую задержку и будет этим неприятен. В принципе, для современных скоростей, для современных задач, эта цифра 99,9% действительно говорит сама за себя, что по большому счету неважно, будет эта задержка побольше или поменьше, потому что на современных свитчах матрица коммутации настолько быстрая, что будет ли эта задержка 100 наносекунд или 200 наносекунд — всё равно.

Это доли микросекунды, которые нас не сильно интересуют. Но если вы работаете в определенных приложениях, которым требуется минимизация задержки, причем желательно, чтобы задержка была не просто минимальна, а еще везде одинаковая, этот режим будет не очень удобен. Второй режим, который существует, точнее, раньше существовал, — это режим cut-through. Заключается он в следующем. Вы принимаете первые 6 байт кадра в буфер и сразу дергаете матрицу коммутации. Дело в том, что коммутация будет происходить на основе 6 байт MAC-адреса получателя, которые вылезают из канала передачи данных самыми первыми. У вас есть свитч. У него есть интерфейс входящий и интерфейс исходящий. Здесь есть буфер, в который падают какие-то кадры. Кадры пробегают, они складываются в этот входящий буфер, и как только кадр начинает вылезать в виде ноликов-единичек и попадать в этот буфер, он там потихоньку вылезает, потихоньку попадает.

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

Эта штука позволяет вам минимизировать задержку и сделать ее всегда одинаковой. Она позволяет вам фиксировать время задержки, потому что коммутация осуществляется по первым шести байтам, и у любого кадра вы начинаете эту процедуру, как только показываются первые шесть байт MAC-адреса получателя. И готовое коммутационное решение будет у всех кадров одновременно появляться. Поэтому начало коммутации не будет зависеть от размера кадра, оно будет маленьким, оно будет у всех одинаковым. Но есть проблема, и проблема заключается в том, что если у вас будет где-то коллизия, например, может сложиться ситуация, при которой вы получаете какой-то кадр, он лезет, лезет, лезет, а потом выясняется, что у него чек-суммы не сходятся. И что с ним делать? Если бы вы работали в режиме store and forward, вы бы сначала приняли целиком кадр, посчитали чек-сумму, если не сошлась — выкинули. В режиме cut-through вы принимаете начало кадра, принимаете коммутационное решение, начинаете отправлять копии кадра еще когда он целиком не появился.

А когда он целиком появился, вы посчитали чек-сумму и выясняете, что она не сошлась. Но вы уже на всех остальных интерфейсах наполовину кадр отправили. Поэтому ничего здесь не сделаешь, вы вынуждены будете отправлять, что есть. И как следствие, в режиме cut-through есть проблема с распространением ошибок. Как раз я говорил, что есть одно небольшое исключение, заключающееся в том, что не всегда вы принимаете кадр целиком и потом его отправляете. Есть такая штука — режим cut-through, при котором вы не принимаете кадр целиком и коммутируете его прямо в процессе. У режима cut-through фиксированная задержка, маленькая фиксированная задержка причем, но есть проблема с распространением ошибок. В то же время эти ошибки в основном возникают из-за коллизий. Маловероятно, что у вас на нормальной рабочей среде внезапно кадры будут ломаться сами по себе. На битрейтах, для которых Ethernet создается, вероятность того, что кадры будут приходить с ошибками, с несошедшейся CRC, очень-очень маленькая.

И если вы видите кадр, у которого чек-сумма не сошлась, это, скорее всего, коллизия. Был режим, который назывался fragment-free. Это тот режим, который изначально был придуман для того, чтобы избавиться от проблемы с коллизией. Смысл был в следующем. Вы принимаете не 6 байт MAC-адреса получателя, а первые 64 байта. Тот минимальный размер кадра, который обязательно вы должны будете передавать. И если вы передали 64 байта и не обнаружили коллизию, значит, коллизия уже дальше не должна произойти. И режим fragment-free как раз говорит: запускаем процедуру коммутации не после 6 байт MAC-адреса получателя, а после 64 байт. Задержка будет фиксирована. У всех кадров одинаковая, потому что как минимум 64 байта любой кадр будет занимать. И если вы за 64 байта не увидели несошедшуюся чек-сумму, то вероятность того, что дальше она будет несошедшейся, крайне мала.

В современных свитчах бывает режим, который называется cut-through. На самом деле это что-то среднее между cut-through и fragment-free. Смысл заключается в том, что вы принимаете первые, а дальше какое-то промежуточное значение между 6 и 64, например, 40 байт. Вы принимаете 40 байт кадра и дальше принимаете коммутационное решение. Проблема в том, что коллизий в современных сетях практически не бывает. А в некоторых случаях коммутацию интересно производить не по первым 6 байтам, а по первым и дальше n байтам. В случае, если ваш коммутатор, например, занимается маршрутизацией по IP, и происходит это с помощью аппаратного движка, он, например, ожидает получить, во-первых, 14 байт MAC-заголовка, 14 байт Ethernet-заголовка, потом плюс 20 байт заголовка IP, и потом еще, например, UDP. Ему было бы интересно, соответственно, плюс 8 байт UDP,

или там 6 байт UDP. Короче говоря, здесь получается 40 или 42 байта. И смысл заключается в том, что вы принимаете первые 40 байт кадра и по ним уже принимаете коммутационные решения. В большинстве ситуаций вы можете достаточно продвинутые решения принимать на основе этих самых 40 первых байт. И называется это, как правило, именно cut-through, хотя по смыслу это ближе к fragment-free. Почему режимы в итоге не прижились? Потому что это всё катастрофически усложняет схему работы самого чипа, схему работы матрицы коммутации. Поэтому, если вы готовы заплатить десятикратную премию за все эти фишки, добро пожаловать в эти режимы. Для всяких дата-центров и высокочастотного трейдинга и прочего. Они работают, они есть. Но будете ли вы покупать в обычном предприятии свитч, который в 10 раз дороже, потому что в нём есть фича, которая вам не нужна? Не будете. Поэтому в 99% случаев вам достаточно будет режим store and forward, который простой как барабан,

тупой как барабан, дешёвый как барабан и надёжный как барабан. Если нет разницы, зачем платить больше. Таблица, которая будет оперировать матрицей коммутации, эта самая таблица MAC-адресов и, на самом деле, буферы — про буферы отдельно. Таблица. Эта самая таблица будет храниться в специальной памяти. Память называется по-русски ассоциативная память, по-английски она называется content addressable memory. И название у английского термина вполне говорящее. Это память, адресуемая по содержимому. Смысл в следующем. Представьте себе, что вы программист. И вы хотите написать обработку кадров Ethernet, которые приходят на ваш коммутатор. И, соответственно, у вас есть эта самая табличка, в которой вы должны будете хранить, кто за каким портом сидит. Память в обычном своём смысле адресуется по адресу.

У вас есть ячейка с номером 1, и дальше вы в ячейку с номером 1 можете записать какое-то значение. Переменные, если хотите, с номером 1. Дальше переменная с номером 2, переменная с номером 3, переменная с номером 4. Вы можете сказать, что в ячейку с номером 1 мы, допустим, можем записать MAC-адрес узла А и соответствующий ему порт номер 1. Потом в ячейку с номером 2 мы можем записать MAC-адрес Б и порт номер 2. И так далее. С — три, D — четыре. Понятное дело, здесь всё очень условно. И когда вам нужно по этой таблице быстро провести поиск, вы столкнётесь с проблемой. Вам нужно быстро ответить на вопрос, есть ли в этой таблице MAC-адрес C, и если есть, за каким портом он сидит. Если у вас просто обычная память, которая адресуется по адресу, по смещению, то вы должны посмотреть первую ячейку, потом посмотреть — MAC-адрес тот или не тот. Если не тот, посмотреть во вторую ячейку, посмотреть — тот или не тот адрес. Третья ячейка — тот или не тот адрес. Четвёртая ячейка — тот или не тот.

Представьте себе, что у вас MAC-адресов в таблице, не знаю, 50 тысяч. Если бы у вас была память, которая была бы просто обычная память, адресуемая по смещению, то вы должны были бы на каждую запись, на каждую попытку резолвинга, на каждое коммутационное решение пробежать по всей этой таблице и поискать в каждой ячейке то, что вас интересует. Это операция, во-первых, непредсказуемая по задержке. Может быть так, что вы прямо сразу угадаете, сразу в первую ячейку ткнётесь, и там обнаружите то, что вас интересует. А может быть такое, что вы должны всю таблицу пробежать и в самой-самой последней ячейке обнаружить то, что вас интересует, или не обнаружить вообще нигде. Поэтому запрос к такой памяти, обычной, обыкновенной памяти, занимал бы непредсказуемое время. Главное — это было бы медленно. Что сделали инженеры? Они придумали память, которая адресуется по содержимому. Она не пронумерована — не ячейка с номером 1, ячейка с номером 2,

ячейка с номером 3, ячейка с номером 4, а ячейка с ключом, в которой записывается MAC-адрес. И вы можете в такую таблицу записать: ячейка с номером MAC-адрес А, ячейка с номером MAC-адрес Б, ячейка с номером MAC-адрес С. И, соответственно, в каждой ячейке у вас будет храниться либо ничего, либо номер порта. Что-то примерно в этом духе. Там чуть более сложно устроено. Я сейчас не хочу вдаваться в то, как это действительно устроено. Если интересно, почитайте Википедию. Смысл заключается в том, что, допустим, адрес А вы знаете, что за первым портом, адрес Б за никаким портом, адрес С за никаким портом, адрес Д за вторым портом. И запрос к такой табличке будет фактически эквивалентен: посмотри в ячейку с номером MAC-адрес С, и она выполняется за один проход. По крайней мере, за одинаковое, небольшое, предсказуемое время. И эта штука, Content Addressable Memory, память, адресуемая по содержимому, она как раз и используется для хранения MAC-адресов.

Недостаток такой памяти — она жутко дорогая. Поэтому таблица не может быть очень большой, и количество MAC-адресов, которые вы можете в неё записать, будет ограничено. Более того, производительность этой памяти будет тем ниже, чем больше записей вы будете в неё пытаться записать. Если у вас есть табличка на тысячу MAC-адресов, вы в неё можете записать 100 адресов, 200, 500, и она будет работать нормально. Но если вы в неё запишете 999 адресов, то поиск будет уже идти всё дольше и дольше. Производительность её будет деградировать в зависимости от количества записей в ней. И если вы записали в неё вообще всё, что только можно было, и пытаетесь записать всё новые и новые записи, то у вас либо будет производиться затирание самых старых записей, потому что напротив каждой записи есть дополнительная информация — когда вы в последний раз видели этот адрес. Либо не будет производиться запись вовсе. Нельзя впихнуть невпихуемое. Если у вас место под тысячу адресов, и вы пытаетесь записать 1001,

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

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

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

Матрица будет пытаться эти пакеты положить в исходящий буфер на одном единственном порту. Давайте попробую проиллюстрировать. 48 портов. Все 48 рисовать не буду, но сколько есть, столько нарисую. И, соответственно, один порт, на нём сидит сервер. Сюда валится гигабит трафика, сюда валится гигабит трафика, сюда валится гигабит, сюда валится гигабит. И всё это предназначено для одного несчастного порта. Наш волк, наша матрица коммутации, успевает разобрать все пакеты, которые валятся во входящие буферы. Она для этого достаточно производительная. Но буфер, который на отправку, он не резиновый. Он очень быстро забивается. Наш волк очень быстро на него складывает всё, что нужно. И рано или поздно у нас случается tail drop в этом месте. Волк хочет положить все яйца, которые он собрал, в этот самый интерфейс. Но ему некуда положить. Буфер целиком забит. И уже волк из своей корзинки просто выкидывает эти яйца, потому что он не может ничего с ними сделать. Не потому он выкидывает, что он не успевает их разобрать,

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

считают: если мы возьмём пакеты максимального размера, например, 9 килобайт, включаем jumbo frame, поддерживает свитч jumbo frame — прекрасно. Берём пакеты в 9 тысяч байт, дальше умножаем их на максимальное количество пакетов, которые наша матрица может обработать, и получаем какую-то колоссальную цифру — там 100 тысяч миллионов мегабит. Соответственно, если вы измеряете производительность матрицы коммутации и хотите её именно в битах в секунду измерить, то это нечестно, потому что по-хорошему тогда надо брать минимальный размер пакета, минимальный размер кадра, и уже его умножать на ту же самую цифру, и вы получите существенно меньшее значение. Поэтому, если вы хотите пустить своему клиенту пыль в глаза, вы выпускаете коммутатор, и вам хочется написать цифру побольше, то вы считаете, конечно, самый большой пакет, который вы можете обработать, и умножаете на количество пакетов, которые вы можете обработать. Если вы хотите по-честному посчитать, то корректно будет привести отдельно цифру на минимальном размере

пакета, отдельную на разумном размере пакета, обычно в районе 256 байт, и отдельно на 1500 байтах, которые являются стандартными для современных сетей. И вы получите несколько разных цифр в этих самых мегабитах. А ещё более красивый, более правильный способ — это показать пакеты в секунду. Это на самом деле снимет большинство вопросов. Просто производители очень сильно пытаются иногда скрыть количество пакетов в секунду, которые их матрица может обработать. Потому что сразу будет понятно, что бывают ситуации, когда матрица захлёбывается. В принципе, неблокирующая коммутация часто встречается на современных, даже недорогих свитчах, потому что сейчас миниатюризация и новые техпроцессы позволяют делать достаточно производительные чипы. И можно встретить даже коммутаторы недорогих производителей, которые обеспечивают неблокирующую коммутацию. Но если мы говорим про какие-то модели с серьёзными скоростями, там 10-гигабитные, 40-гигабитные интерфейсы,

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

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

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

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

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

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

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

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

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

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

у абонента столько просто нигде не возьмется. Не может обычный абонент сгенерировать 10 гигабит трафика. Неоткуда столько взять. Продумывайте отказоустойчивость: что будет, если случится отказ, как ваша сеть будет перестраиваться. И резервируйте те узлы, которые могут отказать, чтобы у вас не было единых точек отказа. Как было сказано, вы должны будете использовать правильные модели свичей. И как определить, какая модель правильная, просто по ее, условно говоря, названию, по ее позиционированию. Я использую здесь классификацию Cisco, но, в принципе, у большинства вендоров примерно такая же классификация идет. Вы можете зайти на сайт вашего любимого вендора, и вы увидите, что свичи, которые этот вендор продает, будут делиться, как правило, на семейства, на классы. Самый простой класс — это Campus Access. Это самые дешевые свичи для подключения обычных пользователей. Это свичи, в которые подключается просто обычный абонент.

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

и у него производительность будет намного выше. А чтобы не случилось какой-то проблемы, если вдруг он отвалится, мы таких свичей ставим пару. Про пару отдельно потом поговорим. Если у вас этих абонентских свичей много, то вы их подключаете к каждому из двух Distribution свичей, ставите, ставите, но возникает проблема. Если у вас этих Access свичей становится слишком много, там 50 штук, они в два Distribution уже просто не лезут. Distribution свичи, например, по 48 у нас портов, а чаще всего даже меньше, по 24 порта. И 50 свичей в них просто не включаются. Нам потребуется тогда этих Distribution ставить больше. Еще пару, например. А потом еще пару, если у нас свичей становится совсем много. И возникает вопрос, как их уже соединять в единую сеть? Опять же, по схеме

каждый с каждым соединять некрасиво. Если у нас этих Distribution свичей, например, 50 или 30, что значит, что у нас сеть огромная, то нам потребуется еще следующий уровень. Над этими двумя Distribution мы ставим еще два свича Campus Core. Это ультрапроизводительные и ультрадорогие свичи, которые нужны для того, чтобы связывать между собой Distribution. Если у вас сеть меньше, чем на тысячу абонентов, вам Campus Core свичи не нужны. Вы обойдетесь просто Distribution по схеме каждый с каждым. Далее. Это что касалось обычной сети предприятий. Эти свичи, как правило, называются Campus, кампусные свичи. Если смотреть в сторону дата-центровых свичей, это своя отдельная песня. Как правило, в дата-центрах требуется неблокирующая коммутация. Как правило, там колоссальные скорости, которые в обычном предприятии не встречаются. Обычная нормальная скорость абонентского порта в дата-центре — это 10 гигабит. И, соответственно,

кампусные, Access свичи, если хотите, в дата-центре — это 10-гигабитные свичи. Distribution свичи — либо сороковки, либо сотки. И Core свичи — это уже там... Если они даже есть, то они очень-очень дорогие и они очень-очень производительные. У провайдеров тоже своя отдельная песня. У них, правда, Core свичей нет. У них, как правило, есть Edge свичи. Это пограничные свичи, но фактически это Access. И Distribution свичи, если хотите, они переименованы, называются Aggregation. Но смысл точно тот же самый. Теперь, поскольку вы знаете, как называются какие модели, вы уже можете понять, какие модели куда надо покупать. Если вы работаете в предприятии, если вы хотите организовать правильную сеть в предприятии, вы покупаете для подключения конечных абонентов Access свичи и соединяете их друг с дружкой через Distribution. Примерно так это выглядит. Здесь нет резервирования на этой картинке, но оно предполагается, что вы можете вот так сделать

и, соответственно, его получить. И то же самое с Core. Если у вас есть Core, то свичи будут включаться в Core тоже двумя линками. Nexus — да, линейка для дата-центров. В некоторых случаях Nexus можно использовать на уровне агрегации, потому что там есть некие удачные модельки, которые выходят дешевле, чем классические свичи для Distribution в предприятии. Некоторые модельки у Nexus такие интересные есть. В целом, да, это дата-центровые свичи. По такому правилу есть смысл строить сеть, если вы хотите это сделать. Опять же, до Core свичей вы вряд ли дойдете когда-нибудь, потому что это для очень больших сетей, где очень много Distribution. Если вы строите просто сеть для небольшого предприятия, у вас будет 4, 5, 6, 7, 8 Access свичей, они все соединяются с парой Distribution, и у вас все хорошо

работает. Резюмируя, коммутаторы уровня доступа — это те, которые нужны для подключения отдельных абонентов. Их основная задача — просто предоставить порт для каждого пользователя. Возможно защититься от каких-то простеньких атак, они не умеют детально анализировать трафик, который проходит через них, но от каких-то простеньких вещей они защитить вполне могут. Типа того, что пользователь MAC-адрес подменил или IP-шник подменил — вот это всё нормальный коммутатор доступа решить может. И самое главное, для чего он нужен — это после того, как он предоставил доступ пользователю, передать трафик пользователя до вышестоящих Distribution свичей. Эти свичи дешевые. Они дешевые, потому что они не предназначены для каких-то очень продвинутых задач. У них классический паттерн потребления — это то, что порты загружены не сильно, загрузка редкая, небольшая. И в принципе,

производители, когда делают свои свичи уровня доступа, они исходят из того, что средняя загрузка порта будет порядка 5%. Дальше. Весь трафик, который будет проходить через этот свич, он будет либо в пределах этого свича разбрасываться по другим пользователям, либо быть транзитным в сторону вышестоящего Distribution свича. Distribution свичи — да, там уже продвинутые, умные модели, которые могут каким-то хитрым образом обрабатывать трафик. Про это мы поговорим на I7-2. Так, это что касалось коммутаторов. Коммутаторы мы теперь знаем, как устроены, что они делают, почему они делают это и как именно. Любой коммутатор разбрасывает копии всех кадров на все порты, за исключением некоторых портов, куда копии кадров отправлять не нужно. Два простых правила, по которым коммутаторы принимают решение, какие кадры куда отправлять не нужно.

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