Коммутация в Ethernet: история и технологии

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

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

которые одновременно отправляют кадры, и как следствие это не вызывает коллизии, потому что у нас электрические порты свеча не связаны между собой. Может быть такое, что у вас пользователи одновременно отправляют данные на ваш свеч, это не вызывает проблемы с физической точки зрения. И, соответственно, в 10 BST и в 100 BSTX с течением времени появились такие режимы передачи, которые позволяют использовать одновременно и отправку данных, и прием, то есть и полудуплексную, и дуплексную передачу. Может быть такое, что вы отправляете какие-то данные на свеч, на коммутатор, а коммутатор в это время одновременно посылает данные вам. Вот в случае, если бы вы работали в общей шине, такую штуку делать было бы нельзя. А если вы используете коммутаторы и каналы точка-точка, то такое сделать можно. Здесь не совсем правильно написано, то есть вот это вот не читайте, здесь вот это вот, это не совсем так.

И вот это тоже не совсем так. Работает это следующим образом. То есть у вас на полудуплексной передаче, та, которая была раньше по умолчанию, она была нужна в среде с общей шиной. Всегда работала схема CSM и CD. Если вы отправляли что-то, то вы слушали среду, и вы там слушали, чтобы появилось что-то отличное от того, что передаете вы сами, или пустоты. То есть в зависимости от того, какой стандарт вы использовали, 10BS5 и 10BS2, как сиалы, вот вы там слышали то, что сами передаете. В Ethernet вы, соответственно, должны были, в Ethernet 10BS2, вы должны были слушать пустоту. Если вы передавали что-то и слышали пустоту, вы понимали, что коллизия не произошла. Если вы передавали какой-то сигнал и слышали что-то другое, не пустоту, то вы понимали, что коллизия произошла, что вот это кто-то другой начал передавать что-то другое. Больше там ниоткуда никакие данные взяться не могли. И вы объявляли состояние коллизии, дальше запускали джемпоследовательность,

back-off-таймер, и дальше мы тоже проходили. Так вот, если вы используете коммутаторы, то у вас нормальная ситуация будет такая, что вы передаете что-то и вам что-то передают. Как следствие, схема CSMACD не нужна. То есть вы отказываетесь от объявления коллизии в ситуации, когда вы передаете какие-то данные и вам передают какие-то данные в тот же самый момент. То есть при дуплексной передаче вы отключаете схему CSMACD. С точки зрения логики half-дуплексная работа более сложная, чем full-дуплексная. То есть, как получить full-дуплекс? Это взять half-дуплекс и отрезать от него CSMACD. В 1000BST предусмотрен только дуплексный режим. На самом деле, там не написано в стандарте в явном виде, что не надо делать half-дуплекс. Там написано, что может быть, гипотетически, кому-нибудь когда-нибудь пригодится half-дуплекс, поэтому черт его, нехай с ним пусть будет. Но на практике

никто не стал делать гигабитные хабы, поэтому хабов на 1000BST просто не существует в природе. Стандарт не запрещает в явном виде работу half-дуплекса на гигабите. То есть, если вам очень сильно захочется, вы можете включить схему CSMACD, если вдруг вам это будет сильно нужно. Но, соответственно, все равно хабов на него вы не увидите. И эта самая схема CSMACD и half-дуплексный режим, как следствие, она никакой пользы вам особо не принесет. В 10 гигабитах и выше, то есть, 10 гигабит, 25 гигабит, 40 гигабит по меди, в принципе, теоретически невозможно включить half-дуплекс, потому что его там просто нету по стандарту. То есть, написано, что его там в явном виде нету. Так, что будет, если у вас есть несколько узлов в сети и у них настроен каким-то образом дуплекс? То есть, либо включили схему CSMACD, либо не включили схему CSMACD.

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

там произойти не может. Если вы используете провод точка-точка с коммутаторами или просто провод точка-точка между двумя узлами, то вы можете отключить схему CSMACD с обеих сторон. Можете и не отключать, то есть никто вам не запрещает взять и на коммутаторе сказать, а давайте мы half-duplex сделаем и на узле тоже сказать, давайте сделаем half-duplex, работать все будет, но иногда будут ложные срабатывания схемы CSMACD, когда у вас одновременно отправляются и принимаются данные, оба узла, если они настроены на использование схемы CSMACD, то есть half-duplex, они будут говорить, что у нас случилась коллизия и будут делать вид, что действительно коллизия произошла. Она на самом деле не произошла, но они себя будут вести так же, как будто она произошла. Вот, то есть они будут придумывать back-off-таймер, они будут посылать jam-последовательность, они будут затыкаться на произвольное время, дальше вы уже знаете, что будет происходить. Эффективность снизится, но работать при этом будет. Если у нас будет не совпадать режим дуплекса

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

через какое-то случайное время, когда ему это захочется сделать. Но при этом вы, как узел с полным дуплексом, не будете повторно отправлять ему те данные, которые он будет выкидывать. Поэтому если у вас есть два узла, я нарисую два компьютера, раз компьютер и два компьютера, и вы их включаете между собой друг в друга одним проводом, и вот это у нас будет half-дуплекс, а вот это будет full-дуплекс. Что будет происходить? Full-дуплексный сосед начинает посылать данные своему соседу, и half-дуплексный сосед начинает одновременно посылать данные своему соседу. Электрически эти данные идут по разным парам, по разным проводам, они не сталкиваются между собой, но у half-дуплексного соседа включена схема CSMA/CD, он говорит: у нас случилась коллизия. То, что присылает нам full-дуплексный сосед, мы выкидываем, мы этому не верим, там точно все побилось по дороге, пусть он перепошлет через случайное время, так же, как и мы это сделаем через случайное время. Half-дуплексный сосед прерывает свою передачу,

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

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

На картинке нарисована сетевая карта, у которой есть два интерфейса, верхний и нижний. Это вас сейчас может немножко смутить. Давайте представим себе, что там только одна дырка. Один просто интерфейс, на котором просто один разъем для подключения витой пары. И здесь есть 10 мегабит, 100 мегабит и 1000 мегабит. Это три стандарта, в которых может работать эта сетевая карта. 10BASE-T, либо 100BASE-T, либо 1000BASE-T. Один из трех стандартов. Она не может работать ни в каких других стандартах. Она может работать либо в 10BASE-T, либо в 100BASE-T, либо в 1000BASE-T. Никаких альтернатив. Когда вы будете видеть такую настройку, как выбор скорости, вы должны будете понимать, что это не управление скоростью. Это управление тем стандартом, в котором будет работать ваш интерфейс. Либо один, либо другой, либо третий,

но никаких других промежуточных вариантов там нет. Вы не можете заставить ваш интерфейс работать на скорости 50 мегабит в секунду или 29 мегабит в секунду. Ни один из трех стандартов не позволяет передавать данные на скорости, отличной от референсной скорости. 10BASE-T позволяет передавать ровно на скорости 10 мегабит и никак иначе. 100BASE-TX позволяет передавать ровно на скорости 100 мегабит в секунду и никак иначе. И гигабит позволяет передавать ровно миллиард бит в секунду и никак иначе. Поэтому вы не играете скоростью, вы играете стандартом, в котором работает ваш интерфейс. Чаще всего вы, если будете работать с Ethernet-интерфейсами, будете видеть именно такие мультистандартные интерфейсы, где вы можете выбрать один из нескольких стандартов. Это будет либо обозначение типа 10/100, когда можно либо 10BASE-T, или 100BASE-TX выбрать, либо 10/100/1000 — 10BASE-T, 100BASE-TX, 1000BASE-T. Еще иногда бывает 1/10. Это порт, в который вы можете вставить либо гигабитный разъем, либо 10-гигабитный разъем.

Поскольку чаще всего что гигабит, что 10 гигабит не будут медными, они будут оптическими, а в оптике у нас есть зоопарк, то там чаще всего дырка будет SFP-шная или SFP+. Они выглядят абсолютно одинаково, они электрически очень похожи между собой, у них физические контакты одинаковые. Вы можете вставить в такой порт либо SFP-разъем, либо SFP+. И у вас получится, что порт может работать как на гигабите, так и на 10 гигабитах. Далее. Если вы фиксируете конкретный стандарт, в котором работает ваша сетевая карта, то есть вы прибиваете жестко гвоздями, что мы будем работать на 1000BASE-T, на гигабите. Мы делаем жестко, что эта сетевая карта работает на гигабите. Если вы рядышком такую же сетевую карту поставите,

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

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

В любом случае передаются такие полубитики, если хотите. Причем независимо от стандарта, в котором вы работаете. Хотите на 10 мегабитах, хотите на 100 мегабитах, хотите на гигабите — у вас все равно раз в 16 миллисекунд будут бегать так называемые линк-пульсы. Линк-пульс — это как раз такая половинка битика, если хотите. Именно по этим линк-пульсам ваш интерфейс определяет, что поднялся линк. Может быть, вы замечали, что берете две сетевые карточки, соединяете их проводом, и у вас сразу лампочка загорается. Эта лампочка загорается как раз по наличию линк-пульсов, которые отправляются всегда в любом случае раз в 16 миллисекунд, и они составляют половинку бита. Они никогда не могут быть восприняты как полноценный битик, но при этом они нужны как раз для индикации того, что связь есть. Фишка в том, что вы можете дополнительно к этим линк-пульсам,

которые бегают раз в 16 миллисекунд, добавлять еще служебные линк-пульсы. Эта схема называется Fast Link Pulse. И с помощью этих FLP, Fast Link Pulse, вы можете закодировать некоторую дополнительную информацию. Ее не так много можно передать, но тем не менее, для того чтобы сказать, какие режимы вы поддерживаете, этого вполне хватит. И вы заявляете с помощью Fast Link Pulse, которые передаются вместе с этими полубитиками, какие режимы вы поддерживаете. И вы говорите: я поддерживаю 10BASE-T, я поддерживаю 100BASE-T4, я поддерживаю 100BASE-TX в полудуплексном и в полнодуплексном варианте. И вы заявляете, какие режимы поддерживаете вы. То же самое делает сосед. Если он поддерживает эту штуку, он заявляет, что я поддерживаю, например, 100BASE-TX и 100BASE-T4. Half duplex, full duplex. И вы выбираете среди всех этих вариантов самый быстрый, который вас устроит, с максимальным режимом дуплекса, который вас устроит. И вы говорите: 10 мегабит здесь нам неинтересно,

100BASE-T4 и 100BASE-TX. Из этих вариантов здесь тоже 100BASE-T4 и 100BASE-TX. Они оба одинаковы, поэтому мы выберем 100BASE-TX. И, соответственно, full duplex или half duplex. Один заявляет, другой говорит, я тоже поддерживаю full duplex или half duplex. И в таком варианте мы говорим, full duplex интереснее, чем half duplex, поэтому мы будем работать именно в нем. 100 BASE-TX – full duplex, 100 BASE-TX – full duplex. Этот механизм автосогласования есть и он очень удобный. Я рекомендую вам пользоваться всегда им, если он у вас поддерживается. Иногда бывают случаи, когда он, к сожалению, не поддерживается, но они экстремально редкие. Если у вас есть автосогласование, и оба узла его поддерживают, то они выбирают максимально быстрый стандарт скорости и максимально хороший дуплекс,

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

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

высоким или низким напряжением. В любом случае, от нуля будет разница в 0,7 вольта. Это не похоже на бит, но это также не похоже на случайный шум. Поэтому хорошо видно, передаются ли эти линк-пульсы раз в 16 миллисекунд или нет. Так, autosensing. Вы пытаетесь угадать стандарт, в котором работает сосед, просто пытаетесь подслушать, что сосед передаёт, если он что-то передаёт. Если ничего не передаёт, то вы говорите: сосед какой-то дурачок, он, наверное, в десятке работает. И если вы угадали, что он работает в десятке или в сотке, то вы используете дуплекс по умолчанию, а для десятки и сотки это half duplex. Потому что если сосед настолько тупой, что он не поддерживает автосогласование, наверное, он очень старый, наверное, он просто был придуман тогда, когда автосогласование было не нужно, потому что full duplex не было на тот момент. Поэтому если мы угадали,

что сосед работает в десятке или сотке, то мы сваливаемся на half duplex. Если сосед работает на гигабите, то мы совершенно точно можем сказать, что сосед гарантированно поддерживает автосогласование. Сосед гарантированно поддерживает полный дуплекс, потому что в гигабите полный дуплекс есть по стандарту. Поэтому он просто от нас скрывает, что именно он поддерживает, и поэтому мы будем работать в режиме по умолчанию с полным дуплексом. Такая история. Надо запомнить, что если вдруг один из узлов поддерживает автосогласование, а второй нет, то мы пытаемся угадать стандарт, а потом угадываем режим дуплекса. Для десятки и сотки это half, для гигабита это full. Такое поведение. Коротенький модуль, но он про физику, про выбор стандарта и, соответственно, дуплекса.