Упорядочение событий при передаче данных по Ethernet

Следующий модуль будет посвящён тому, что я уже давно порываюсь вам рассказать, но всё как-то меня уводит в сторону физики. Сейчас будет про логику, про то, как упорядочиваются биты при передаче данных по Ethernet. Что мы сейчас с вами проходили — касалось именно передачи отдельных битов, это всё касалось физического уровня модели OSI. И мы рассказывали про то, какие провода, какое там сечение оптики, какие сорта стекла — это всё касалось физики. Результатом работы физического уровня является поток из отдельных битиков — нолики, единички. Я вам даже рассказал, как эти нолики-единички кодируются в Ethernet 10-мегабитном. Но дальше мы говорили, что у нас есть много разных Ethernet-ов, у них у всех одинаковый формат кадра. И вот мы как раз дошли до того, как упорядочиваются нолики-единички в упорядоченные последовательности, которые называются кадрами. Мы плавно переходим ко второму уровню модели OSI. У всех стандартов Ethernet кадр

одинакового формата. Бывают иногда незначительные отличия, но это всё будет для нас не сильно интересно. В основном, в самых важных деталях они все будут одинаковые. Некоторые биты, которые по факту будут передаваться по сети, будут дополнительные, служебные. Не всё, что передаётся по сети, реально является частью кадра. Некоторые биты будут служебные — они будут разбавлять те полезные биты, которые несут в себе собственно сам кадр. Не пугайтесь, это нормально. Если мне память не изменяет, в 100 мегабит в секунду там добавляется на каждые 4 полезных бита один бит специальный для контроля чётности. И там для, допустим, 10 гигабит, там, по-моему, схемы 8 на 10 используются. Тоже там добавляются служебные биты, которые изначально частью кадра не являлись, но они нужны были для того, чтобы контролировать

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

У нас есть коаксиал, в этом коаксиале у нас сидят пользователи, и эти пользователи могут гипотетически устроить между собой коллизию. Учитывая, что максимальный размер коаксиального провода, который мы с вами используем в 10BASE5, ограничен длиной 500 метров, 500 метров, то у нас максимальное расстояние, которое может пройти сигнал, будет 500 метров туда, 500 метров обратно. Если мы разделим это на скорость электромагнитной волны в коаксиальном проводе, то мы получим, что время, в течение которого сигнал распространяется туда-обратно, будет сильно меньше slot time, и оно будет по факту порядка 64 bit time. Получается, что если у нас какой-то узел начинает передавать данные в среду, и этот сигнал начинает бежать, бежать по сети, доходит до самого

дальнего участка в пределах 500-метрового кабеля, который нам был допустим по стандарту Ethernet 2, и дальше он начинает сталкиваться с другим сигналом, который другой узел, увидев свободную среду, начинает отправлять, то у нас происходит коллизия, и сигнал, который устраивает коллизию, начинает распространяться обратно. И вот у нас это расстояние проходит в общей сложности километр за 64 bit time. Как следствие, если мы начинаем передавать какой-то сигнал, мы можем быть уверены, что если у нас соблюдается ограничение в 500 метров на расстояние провода, то коллизия, если она произойдёт, она произойдёт за время первых 64 битов, за время передачи первых 64 битов. И специально для того, чтобы коллизия никогда не происходила по данным в 10-мегабитном Ethernet, сделали следующую штуку.

Сказали, что первые 8 байт у нас будут хитрые. Они будут называться преамбула, и они будут фактически нужны для того, чтобы занять среду. Вы начинаете своего рода звонить в колокольчик. Динь-динь-динь-динь-динь-динь-динь-динь-динь. «Я занимаю среду». Это не боевые данные, это именно колокольчик, который состоит из чередующихся битиков. 1-0, 1-0, 1-0, 1-0, 1-0, 1-0 и так далее. Вот так, 64 бита подряд. Если вы передали эти 64 бита подряд и коллизию не услышали, значит, вы её уже дальше и не услышите, потому что максимальное расстояние в 10-мегабитном Ethernet 10BASE5 — это 500 метров. По стандарту, если вы помните, у нас есть так называемый slot time. Это в предположении, что вы используете репитеры, вот этих 10 репитеров подряд поставите и сделаете ограничение в 5 километров на максимальную длину провода. Сигнал тогда будет распространяться до самой-самой дальней точки и обратно. Если вдруг репитеры будете использовать.

И тогда slot time — это время, в течение которого сигнал будет распространяться до самой-самой-самой дальней точки в сети, оно будет как раз — slot time — это 512 bit time. Но если вы репитеры не используете, используете только 500-метровые линки, то 64 bit time — это время распространения сигнала туда-обратно в этом самом проводе. И оно занимается именно преамбулой. Помимо того, что эта преамбула нужна для того, чтобы успеть занять среду, чтобы если вдруг кто-то коллизию устроил, он бы с вами столкнулся тоже по преамбуле, у неё есть ещё одно ценное свойство. Она состоит из чередующихся единичек-ноликов. Вы сначала передаёте единичку — это сначала поменьше сигнала, потом побольше. А потом нолик — это сначала побольше, потом поменьше. А потом снова единичку — поменьше, побольше. А потом снова побольше, а потом поменьше. У вас получается такая синусоида на электрическом

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

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

И по признаку, что прошло два битика-единички, вы понимаете, что преамбула закончилась, дальше начинается мясо кадра. Дальше два адреса. Адрес получателя 6 байт, адрес отправителя 6 байт, про адреса чуть попозже. Потом указание, что за содержимое внутри лежит, какого оно типа. Это поле называется EtherType, 2-байтовое. Дальше идут сами данные, которые можно будет передавать. У них есть ограничения на размер сверху и снизу. И поле, которое называется FCS, Frame Check Sequence. Оно нужно для того, чтобы получатель мог понять, что данные пришли корректно или некорректно. Как вы помните, Ethernet 2 — это стандарт DIX-овский, Digital Intel Xerox, и выпущен он был в 1982 году. А в 1983 году вышел формат 802.3. Точно тот же самый формат, только чуть-чуть отличается. Та часть, которая изначально называлась преамбулой,

инженеры 802.3 переименовали. Милицию переименовали в полицию. Они сказали: некрасиво получается, что преамбула — это 63 битика, чередующиеся единички и нолики, потом ещё одна единичка. Давайте мы разобьём их на две части. Назовём преамбулой 1-0, 1-0, 1-0, 1-0, чередующиеся 7 раз подряд, а Start of Frame — это последний байт, будет 1-0, 1-0, 1-0 и 1-1. Просто битово — то же самое. Что преамбула в Ethernet 2, что преамбула и Start of Frame в 802.3 формате — они побитово абсолютно одинаковы. Просто они называются по-разному, потому что преамбула получается красивая, всегда одинаковая и легко описываемая, а Start of Frame — это такой характерный признак того, что преамбула закончилась. Дальше начинаются уже данные. Иногда его ещё называют Start of Frame Delimiter, разделитель преамбулы и начала кадра.

Дальше. MAC-адрес получателя, MAC-адрес источника. И здесь у инженеров из IEEE возник вопрос. Эта штука у DIX называется EtherType и она указывает на то, что внутри лежит. Инженеры Xerox и, соответственно, Digital, Intel сказали, что мы сделаем свои фирменные протоколы, и в этих фирменных протоколах мы будем передавать какие-то свои фирменные данные. И мы никому не будем рассказывать, что за данные в каком формате передаются, но зато мы будем в эти два байта EtherType вкладывать номер нашего фирменного протокола — либо Xerox, либо Digital, либо Intel протокола, который умеет передавать какие-то полезные данные. И когда мы будем передавать данные, сразу обработчик этого протокола будет понимать, что за данные передаются, сколько их там передаётся, и что с ними вообще дальше делать. Но был нюанс. У поля с данными есть ограничение на размер снизу.

46 байт минимум. Меньше передавать нельзя. 46 можно, 47 можно, а 45 уже нельзя. Поэтому если вам очень сильно хочется передать, например, 45 байт данных, вы должны записать 45 байт данных, а потом остальное пространство забить произвольным мусором, чтобы добить до 46. И проблема была в том, что если вы это делаете, то непонятно, сколько данных по факту там передаётся. Понятно, что передаётся, но непонятно, сколько этого. А иногда бывает нужно понять, сколько полезных данных внутри лежит для каких-то целей. Мало ли, вдруг зачем-то пригодится. Поэтому инженеры IEEE сказали: нехорошо, что мы не видим, сколько этих самых полезных данных. Мы, может быть, даже видим код протокола, но все транзитные узлы не обязаны знать все протоколы в мире, которые могут передаваться по Ethernet. Для транзитных узлов намного полезнее знать длину. Поэтому поле EtherType они переделали по смыслу. Они сказали: это будет поле, то же самое двухбайтовое,

но длина полезных данных, которые дальше лежат. И дальше сами данные, которые передаются, MAC Client Data. У этого поля ограничение то же самое было, С 46 по 1500 байт. Но от этого поля были откушены некоторые байты под дополнительные заголовки, для того чтобы показать, что там передаётся. Потому что транзитные узлы узнали, сколько там полезных данных передаётся, но всё-таки конечному узлу не помешало бы узнать, что именно там было. И от 46 до 1500 байт — то, что после длины, может быть размером, но от этого большого поля некоторое количество байт было откушено под дополнительные заголовки. Эти заголовки получили название 802.2. На самом деле не сразу получилось так, что эти заголовки были откушены, там были промежуточные состояния,

типа новелловский RAW, так называемый RAW-сокет, который сказал: давайте мы будем использовать только длину, и сразу будет понятно, что внутри лежит. Внутри лежит наш собственный новелловский протокол. На это инженеры посмотрели криво и сказали: хорошо, что вы такие крутые чуваки из Novell придумали, что только ваш новелловский протокол может внутрь вкладываться, но всё-таки не мешало бы как-то разнообразить попытки вложения, сделать что-то более интересное. И сначала придумали штуку, которая называется LLC, Logical Link Control. Дополнительный заголовок, занимающий три байта, и он состоит из трёх полей по одному байту. Одно поле — это так называемое Source Service Access Point, другое — Destination Service Access Point, и третье — это Control Word. Формат поля немножко дурацкий, но он был заимствован из другого протокола, который мы с вами будем проходить на ICND2. Поэтому по факту там Source Service Access Point

и Destination Service Access Point они всегда были одинаковые, и по факту получилось, что можно внутрь вложить указание, что внутри лежит, но это указание было однобайтовое. Потому что два поля — Source Service Access Point, SSAP и Destination Service Access Point — они фактически всегда были одинаковые. И вы должны были два раза однобайтовое значение повторить. А Control Word — оно вообще всегда было одинаково предсказуемо, и туда вкладывалось число 3. Поэтому вы хотели указать, что внутри лежит, например, протокол Spanning Tree, и вы должны были вкладывать 0x42, дальше ещё раз 0x42, а потом ещё раз 0x03. И у вас получалось, что весь заголовок занят. И количество различных вариантов протокола, которые можно было сюда вложить, оказалось равно 250 штукам, что оказалось, конечно же, неприемлемо малым. Поэтому пришлось этот заголовок расширять, и расширили его 5-байтовым заголовком 802.2 SNAP,

SubNetwork Access Protocol. У него будет 3-байтовый код производителя протокола и 2-байтовый код самого протокола. Этого уже хватило всем. Но за счёт того, что 8 байт отгрызли от поля с данными, когда у нас было поле с данными, которое принимало размер от 46 до 1500 байт, 46 — это был минимальный размер данных для того, чтобы обеспечить минимальный размер кадра, тот самый 512 биттаймов — это 64 байта. Если посчитать все эти заголовки, то выяснится, что всё это — 64 байта. И получается, 64 байта минус всё остальное — это 46 байт. И 46 байт было принято именно исходя из того, что кадр должен быть не меньше определённого размера. Если у нас 8 байт отъедены под заголовки, то 46 минус 8 будет 38. И 1500 — максимальный размер поля с данными, плюс 18 байт заголовков.

Если мы 8 байт из этих 1500 отъедаем, то у нас остаётся 1492. В реальности оба этих формата использовались довольно долго параллельно, и они конфликтовали между собой, и они были конкурентами до тех пор, пока индустрии не надоела эта ситуация и инженеры IEEE не вынесли вердикт: давайте заканчивать эту вражду. То, что у нас два разных формата кадра, несовместимых между собой — это плохо. Поэтому современные версии Ethernet, начиная с 1997 года, позволяют использовать любой из этих форматов по своему усмотрению. Просто есть договорённость, что если вы используете длину, она не должна быть больше, чем 1500 байт. А если вы используете что-то другое, то это EtherType. В EtherType не должно быть значения меньше, чем 1500. На самом деле, 1536.

Так что если вы укладываете туда что-нибудь маленькое, то это длина. Если вы укладываете туда что-нибудь большое, то это EtherType. Если вы будете, например, передавать протокол IP, он сегодня передаётся именно в кадре формата Ethernet II, потому что ему все эти дополнительные заголовки, вся эта штука с ограничением по длине не сильно интересна. В то же время кадры эти вы тоже можете увидеть. Например, всякие служебные протоколы типа Spanning Tree и прочее, они тоже будут использовать именно такой 802.3 формат. Давайте пробежимся по всем этим полям кратенько, для того чтобы понять, зачем они нужны. Преамбулу и Start of Frame Delimiter я уже вам рассказал. Используется для занятия среды. Среда состоит из чередующихся битиков. Нужна для синхронизации тактовой частоты. И чтобы, если вдруг произойдёт коллизия, она произошла именно по преамбуле. Если у вас есть ограничение на 500 метров,

которое в 10BASE5 используется, то коллизия не происходит после преамбулы. Есть, кстати, ещё одна штука, которую можно рассказать. Если вы всё-таки используете репитеры, взяли сегмент 500 метров и поставили репитер, и поставили ещё сегмент 500 метров, и третий сегмент 500 метров, то у вас коллизия, конечно же, может произойти после преамбулы. Но этих репитеров нельзя ставить больше, чем 10 штук, чтобы соблюсти максимальное расстояние в 5 километров. Если вы поставили больше 10 репитеров, вы сами себе злобный Буратино, потому что сигнал будет передаваться туда и обратно, и он будет проходить туда-обратно за время больше, чем slot time. И пока он будет бегать туда-обратно, у вас может быть такое, что вы начали передавать кадр, потом вы его закончили передавать, потому что он был очень маленький, вы его успели передать побитово, и у вас не возникла коллизия, вы его выкинули из буфера, и тут до вас добежал ваш собственный сигнал. Не ваш собственный, а тот сигнал, который на самом деле со всеми остальными устроил коллизию.

Но вы уже с этим ничего сделать не можете, потому что свой кадр выпихнули из буфера. Эта штука неприятная. Есть специальный термин. Это коллизия, которая произошла после передачи первых 64 байтов. Это коллизия, которую вы случайно отловили, а могли бы не отловить, потому что кадр мог оказаться ровно 64 байта, и вы бы его закончили передавать, и коллизию дальше просто бы не зафиксировали, что она произошла. Даже если бы зафиксировали, то ничего бы с ней сделать не смогли. Называется late collision, и обычно late collision возникает либо из-за того, что у вас несовпадение режимов дуплекса, когда один из узлов выключил схему CSMA/CD, а другой нет, либо вы сами себе злобный Буратино и поставили 10 репитеров подряд. Скорее, конечно, в современном мире это несовпадение режимов дуплекса. Если у вас растут счётчики late collision, то вы накосячили с дуплексом. Зачем нужна преамбула, ведь практически везде коллизии произойти не могут?

Справедливый вопрос. Преамбула нужна просто потому, что договорились во всех Ethernet'ах использовать одинаковый формат кадра. Кто-то когда-то где-то договорился, а мы теперь страдаем. Другой причины нет. Она не нужна. Она нужна была в коаксиале. Там она действительно была нужна. А сейчас она совсем не нужна. От слова никак. Но она всё равно есть, потому что так привыкли. Далее. Самое первое поле у нас — преамбула. Самое последнее поле будет называться FCS, Frame Check Sequence. Это поле, с помощью которого кадры проверяются на целостность. В какой ситуации кадр может прийти нецелым, побитым? Во-первых, может прийти наводка какая-то, и у нас какие-то битики случайно флипнутся. Мы передавали нолики, а они принялись как единички. Может такое быть? Может. Во-вторых, существенно более вероятно то, что произойдёт — это произойдёт как раз коллизия.

И из-за коллизии где-то что-то у нас поломается. Какой-то узел начал что-то передавать, а потом он осознал, что случилась коллизия, и либо просто бросил передачу на середине, либо дополнительно ещё в догонку jam-последовательность послал. И тем самым он искусственно портит нам эту самую чексумму. И мы проверяем чексумму от приходящего кадра. Если она сходится, то мы говорим: кадр не побился по дороге, он целый, он нормальный, коллизия не произошла, всё хорошо. Если мы видим, что чексумма не срослась, мы же не знаем, произошла коллизия или не произошла. Коллизию опознаёт только тот, кто её устроил. Только те, кто её устроил. А те, кто просто сидят и слушают, они просто слышат какие-то вольты. Плюс 0,7 вольта, минус 0,7 вольта, плюс 1,5, минус 1,5. Они сидят и слушают и пытаются услышать, что они там такое наслушали. И пытаются бороться с наводками, пытаются бороться с какими-то ещё штуками. И он что-то услышал и пытается понять,

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

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

И вы заполняете его ровно таким образом, чтобы CRC32 от содержимого кадра, всего того, которое вы не контролируете, и Frame Check Sequence, который вы контролируете, если взять их и обработать вместе, у вас всегда получается одно и то же. Как это сделать? Очень просто. Полином, который используется в функции CRC32, подобран хитрым образом. Вы, когда хотите отправить какой-то кадр, у вас он имеет определённый формат. Там сначала destination адрес, потом source адрес, потом что внутри лежит — поле EtherType, потом данные. И потом вы должны передать эту самую FCS. Когда вы хотите что-то принять и проверить на целостность, вы считаете CRC32 от всего этого, и у вас должно получиться определённое значение. Но для того чтобы это получилось, вы в Frame Check Sequence должны вписать нечто, от которого уже потом всё вместе посчитается и даст именно нужный результат. Как это посчитать?

Примитивно просто. Вы считаете CRC32 от всей остальной части. И результат записываете в Frame Check Sequence. Когда вы что-то отправляете, вы сначала записываете, что вы хотите отправлять, считаете от него CRC32, результат записываете сюда. И магия — когда считается CRC от всего вместе, получается всегда одинаковое значение. Очень красивая вещь. На мой взгляд, человек, который это придумал — просто математический гений. Оно прозрачно для нас работает. И каждый раз, когда мы что-то в Ethernet отправляем, всегда такая красота происходит. Что с этим самым CRC32 можно будет заметить? Эта функция, CRC32, она дает нам понять, побился кадр или не побился. Понятное дело, что если мы берем маленький какой-то кадрик, например, 64 байта, и считаем от него 32-битную чек-суму, то она дает нам достаточно неплохую надежду на то, что если мы посчитали CRC32 и она сошлась правильно, то значит все хорошо.

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

Поэтому искусственно ограничивают размер кадра сверху, чтобы он никогда не был слишком большим, для того, чтобы эта функция начинала ломаться. Насколько большим кадр можно сделать для того, чтобы она не ломалась? Это абсолютно чистая математика. Если у нас больше размер кадра, может быть такое, что два слова — слово в математическом понимании — два варианта кадра будут различаться, но у них будет одинаковая чек-сума. Есть такая штука — расстояние Хемминга. Это фактически количество бит, в которых два слова будут различаться. И если у нас есть кадры размером до такого количества, 11450 байт, или, если вам интересно точное значение, до 9640 бит, то функция CRC32 заведомо ловит до трех битовых ошибок в кадрах такого размера.

Если у вас есть кадры не больше, чем такого размера, CRC32 заведомо поймает до трех битов ошибки в них. Если у вас кадры меньшего размера, или если у вас ошибки возникают достаточно редко, то CRC32 может обрабатывать и большее количество ошибок. Она может сказать — у нас пять ошибок, десять ошибок. Но чисто математически она заведомо работает при таких условиях. У Ethernet есть вполне четкие и посчитанные вероятности возникновения ошибок при сферических проводах нужного качества в вакууме. Ethernet рассчитан на то, что у вас будет bit error rate, или BER, это 10 в минус восьмой степени на кадровом уровне. Если вы отправляете кадры, то примерно один кадр в 100 миллионов будет побит. Если у вас кадры меньше, чем полтора килобайта, этот самый BER будет обеспечиваться, и ошибки в этих самых кадрах будут достаточно неплохо ловиться.

Исходя из этих свойств — что при размерах кадра до таких размеров у вас ловится до трех битовых ошибок. Если у вас есть bit error rate, который на уровне битов возникает примерно в 100 миллионов раз, то есть 100 миллионов битов передали, дальше на них ошибка. Еще 100 миллионов битов передали, еще ошибка. Может сложиться такая ситуация, что они же не ровно через 100 миллионов бит идут подряд. С некоторой вероятностью они пойдут — 200 миллионов бит передали, а дальше подряд две ошибки. Или 300 миллионов бит передали, а дальше подряд три ошибки. Исходя из теории вероятности, подобрали такие коэффициенты, такого рода размера кадров, эти самые полтора килобайта, полторы тысячи байт, для того, чтобы минимизировать вероятность того, что CRC32 даст сбой, даст ложное негативное срабатывание. Максимальный размер кадра, как вы уже понимаете, выбран исходя именно из этой самой функции CRC32. При этом это все основано на вероятностях.

Если число 11455 — это жестко посчитанное математическое число, то 1500 байт — это уже вероятность. Это значит, что с некоторой вероятностью мы не получим проблем, если мы будем использовать достаточно небольшие кадры размером до 1500 байт. Мы можем использовать 1501-байтовые кадры, можем использовать 1502-байтовые кадры, и там просто чуть-чуть будет расти вероятность, она не будет расти скачкообразно. Максимальный размер поля с данными выбран исходя из как раз этого поля, которое при 1500 байтах все вроде бы должно быть хорошо. Снизу мы ограничены 46 байтами за счет того, что у нас в заголовке, давайте я еще раз нарисую формат кадра, у нас есть destination address, дальше source address, дальше ether type — что внутри лежит, дальше данные, и чек-сума FCS.

Destination address — 6 байт, source address — 6 байт, ether type — 2 байта, поле с данными минимум 46 байт, и frame check sequence — это 4 байта. 6 плюс 6 — 12, плюс 2 — 14, плюс 4 — 18, плюс 46 — это в сумме 64 байта. Если мы берем поле с данными ровно 46 байт — минимум допустимый, если мы к нему прикладываем все заголовки и поле check sequence, то у нас получается минимальный размер кадра со всеми заголовками — 64 байта. Это как раз 512 битов. 64 байта — это 512 битов, которые у нас составляют slot time. Минимальный размер кадра выбран таким образом, чтобы, если он пролетит через 10 репитеров и обратно, он бы вернулся до нас до того, как мы закончили передачу этого кадра, чтобы мы успели словить эту самую коллизию. Максимальный размер поля MacLineData, полезных данных,

будет определяться как раз этой самой функцией CRC32. Она нормально работает на 1500-байтовых кадрах. Она, в принципе, неплохо работает на кадрах большего размера, но 1500 — просто красивое число. Далее. Если вы хотите, вы можете искусственно убрать ограничение в 1500 байт. Это не какое-то жестко прибитое гвоздями значение. Если вам не хочется передавать 1500-байтовые кадры, вы хотите передавать 2-килобайтовые, 3-килобайтовые кадры, пожалуйста, делайте это на здоровье. Вы можете своей администраторской волей сказать: я хочу передавать кадры 3 килобайта. Если у вас маленький bit error rate, если у вас мало ошибок, если у вас нет коллизий, вы можете это сделать. Почему джамбо-фреймы — это хорошо? Они, во-первых, снижают накладные расходы. Если у вас много данных надо передавать, и кадры, которые вы хотите передавать, могут быть большими,

то у вас одни и те же заголовки, которые будут передаваться в каждом кадре, они будут встречаться все реже и реже. Смотрите, если вы будете передавать кадры 1500 байт размером, у вас есть заголовок и полезные данные. И потом снова заголовок и полезные данные. Заголовок всегда одинаковый, он не зависит от содержимого. Но если вы будете передавать кадры большего размера, то у вас будет заголовок и большие данные. И снова заголовок и большие данные. Можем даже посчитать, какой гипотетический выигрыш мы можем получить. Если у нас есть кадры до 1500 байт полезных данных, получается у нас на данных 1500 байт данных, и дальше пошли заголовки. 6 байт MAC-адрес получателя, 6 байт MAC-адрес отправителя, 2 байта — что внутри лежит, 4 байта чек-суммы, 18 байт все заголовки. Плюс 8 байт преамбула, которая не считается частью кадра,

хотя всегда к нему присоединена. Кадр плюс преамбула будут называться специальным словом — пакет. Пакет Ethernet, подчеркну. Дальше. Между любыми двумя кадрами у нас обязательно должен быть так называемый interframe spacing, который ничего не передает, но если бы вдруг там что-то передавалось, то можно было бы успеть передать 12 байт. Поэтому всего эта штука в сумме занимает 38 байт. На каждые 1500 байт мы 38 байт тратим заголовков или того времени, в течение которого мы могли бы что-то передать. Если взять и посчитать, то получится, что мы на передачу этих заголовков, или, назовем это, служебных данных, тратим 38/1538 долей. Это приблизительно 2,5% времени у нас уходит на передачу заголовков. Если мы 1500 заменим на 9000, например,

скажем — давайте передавать пакеты до 9000 байт размером, ну или кадры, здесь как хотите, то у нас здесь получится 9038. И это будет уже не 2,5%, а примерно 0,5%. И получается, что мы 2% полосы выиграли просто за счет включения этих самых джамбо-фреймов. Еще одна фича, которая здесь будет — это то, что мы за счет включения джамбо-фреймов уменьшаем количество пакетов. Если у нас есть, допустим, гигабайт данных, которые мы будем передавать, мы можем их поделить либо на, в кавычках, мелкие пакеты, и тогда их будет много, либо на, в кавычках, большие пакеты, тогда этих пакетов будет мало. Учитывая, что производительность большинства сетевых устройств выражена, как правило, именно в пакетах или в кадрах в секунду, то мы тем самым, получается, в кавычках, снижаем нагрузку на оборудование. Мы можем отправить много мелочей и загрузить железку сильнее, либо отправить мало пакетов,

но больших, и загрузить железку слабее, у нее останутся силы или мощность на какие-то другие задачи. Поэтому у джамбо-фреймов есть преимущество в виде того, что они снижают накладные расходы в некоторых случаях. Либо 2% полосы, либо вы можете довольно сильно сократить пакеты в секунду, если вы будете их использовать. В некоторых случаях джамбо-фреймы будут очень полезны тем, что они позволяют инкапсулировать в Ethernet протоколы, которые требуют передачи больших данных. Например, есть такая штука — это команды SCSI. Они используются для подключения систем хранения данных. Вы, например, можете взять и передавать команды SCSI с помощью Fibre Channel. Есть такая штука, которая берет Fibre Channel, который в свою очередь несет команды SCSI, и упаковывает их в Ethernet. Эта штука называется Fibre Channel over Ethernet, FCoE. И для того, чтобы она работала,

вы должны будете включить джамбо-фреймы до 4 килобайт, если мне память не изменяет, чтобы он нормально работал. Потому что команды SCSI сами по себе могут быть довольно жирными. Вы не можете, если вы хотите Fibre Channel over Ethernet использовать, не включить джамбо-фреймы — он просто не будет работать. Может быть, иногда будет полезно включить джамбо-фреймы, например, для iSCSI. По сути своей, те же самые команды SCSI, только внутрь IP упакованы, и когда их в Ethernet вы упаковываете, тоже там может быть имеет смысл включить джамбо-фреймы и тем самым, опять же, получить преимущество от того, что у вас все это дело корректно работает. Но джамбо-фреймы не всегда хорошо. Если вы работаете с тем, что хорошо с ними работает, это замечательно. Фишка в том, что почти все технологии, с которыми вы сегодня работаете, они не предназначены для джамбо-фреймов. Они предназначены для того, чтобы у вас все эффективно упаковывалось в полтора килобайта данных.

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

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

которые вы ему отправляете, дробить на 1,5-килобайтные пакеты, которые приняты в отрасли, в частности, в интернете. Поэтому, если вдруг ваша сеть подключена к интернету, не надо там включать джамбо-фреймы. Это плохая идея. Прям очень плохая идея. Неплохая идея может быть включить джамбо-фреймы на обособленной среде. Типичный случай – это сеть передачи данных для сториджа, storage area network, SAN. Она обособлена, она в интернет не смотрит, включайте там джамбо, и это будет, как правило, неплохо. Но если у вас просто обычная компьютерная сеточка в офисе, джамбо-фреймы там не то, что не нужны, они там противопоказаны. Понятное дело, очень плохой идеей будет включать джамбо-фреймы там, где у вас большой bit error rate, потому что там CRC32 и так не будет хорошо справляться со своими задачами, а тут вы ещё и дополнительно снижаете эффективность. Резюмируя, джамбо-фреймы может быть неплохой идеей включить на сети для storage network, но во всех остальных случаях

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

предыдущего кадра. Фактически, да, это просто пустое время, в течение которого ничего не передаётся. Далее. Про EtherType, просто указание, что внутри лежит. Если мы говорим про современные версии Ethernet, в этом поле у нас может быть двоякая трактовка: если лежит что-то маленькое, это длина, и предполагается, что дальше идёт 802.2 заголовок. Если там что-то большое, больше, чем 1500, а точнее, больше, чем 1536, то это EtherType. Для экзамена нужно будет знать характерные EtherType для основных протоколов, которые у нас в курсе будут встречаться. Это 0x0800 для IPv4, шестнадцатеричное значение, 0x0806 для ARP, 0x86DD для IPv6, и 0x8100 для 802.1Q, который у нас будет дальше в курсе.

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

Но вы, когда что-то отправляете, как правило, хотите это отправить кому-то конкретно. Поэтому вы должны будете указать, кто конкретно является получателем, и, как следствие, кто получателем не является. Поэтому вы указываете самым первым полем, кому этот кадр предназначен. 6-байтный уникальный адрес того, кому вы хотите отправить данные. У каждого узла есть свой адрес, и, соответственно, каждый узел смотрит на то, какой адрес указан в качестве получателя для каждого входящего кадра. Если указан его собственный адрес, он слушает этот кадр, он его читает, он его анализирует и дальше обрабатывает. Если там указан какой-то чужой MAC-адрес, то он его не читает и не обрабатывает. Он зажмуривается и говорит, это не мне, я не буду его обрабатывать. Я даже чек-сумму считать не буду. Чего напрягаться-то? Соответственно, адрес получателя — это очень важная вещь, на ней основано очень многое. Адрес отправителя. Штука, которая в Ethernet,

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

по 2 шестнадцатеричных разряда. Одна группа, вторая группа, третья группа, четвёртая группа, пятая группа и шестая группа. Каждая группа символизирует один байт, и байты отделяются друг от друга разделителями, либо минусом, либо двоеточием. У Cisco такой подход вызвал неприятие, и Cisco решила записывать MAC-адреса немножко по-другому, тремя группами по 4 шестнадцатеричных разряда. Смысл не меняется, это одно и то же, что 0123456789AB, что здесь 0123456789AB. То есть это один и тот же адрес, просто записанный в двух разных формах. И разделяются Cisco'ские МАК-адреса точками. Вот. Физически это все равно просто 48 бит. То есть как бы их не записали, это просто формат записи удобный для человеков. Компьютеры, ни вот эти вот минусики, ни точки, они их не обрабатывают. Строго говоря,

они частями МАК-адреса не являются. Есть отдельные граждане, которые просто пишут все слитно. Ну, потому что, а что, компьютер все равно не читает все эти точки. Вот. Эти самые МАК-адреса, они не совсем случайны. Они строятся по схеме EUI48. И мы сейчас с этой схемой познакомимся. Как адрес будет задаваться? EUI48 — это Extended Unique Identifier способ организации уникального идентификатора длиной 48 бит. Не все из этих 48 бит будут совершенно произвольными. Есть самые два первых передаваемых по сети адреса. Если смотреть на МАК-адрес, то есть 0,1, допустим, 2,3, 4,5, 6,7, 8,9, AB. Вот самый первый байт, который есть, у него 8 бит

внутри него содержится. Вот самый младшенький, самый, если хотите, правый бит, ой, самый правый бит, вот, он будет, соответственно, называться M-бит или Multicast-бит или Individual Group-бит, то есть I-G иногда еще называют. Он указывает на то, мультикастовый это адрес или нет. Про мультикаст будет на следующем слайде, не переживайте, если вы не знаете, что это. Вот если там в этом самом младшеньком битике стоит 0, то это адрес одиночный или индивидуальный, а если там единичка, то это адрес групповой. Дело в том, что в Ethernet можно отправлять кадры одного участнику или нескольким разным участникам. Если вдруг вы хотите отправить какой-то кадр и указать, что несколько участников вы должны получить, то вам следует все равно какой-то указать адрес, но этот адрес как раз должен быть групповым. А если вы хотите указать, что адрес какой-то принадлежит ровно одному узлу, то вы можете использовать как раз этот битик и проставить там нолик.

Тот адрес, который есть у каждого отдельного узла, он всегда одиночный его собственный адрес. Ну, это как, если хотите, паспорт. Вот одиночные адреса, да, индивидуальные адреса, это как паспорт. У каждого свой. У каждого свой собственный паспорт, своим собственным номером. Не бывает другого человека, у которого такой же паспорт, как у вас. Вот. Рядышком с ним почти самый младший бит, он будет называться X-Bit или Universal Local U-slash-L. Этот бит определяет уникальность адреса, то есть зону уникальности адреса, если хотите. Дело в том, что схема EU-48, она устроена таким образом, чтобы с завода каждое устройство выходило со своим собственным уникальным идентификатором. То есть вы производитель сетевых железок, вы делаете железку, каждая железка выходит со своим собственным номером, и этот номер уникальный никогда ни с кем не повторяется. Вы, как производитель устройства, обязуетесь следовать схеме

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

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

вот два битика. А все остальные биты, которых 22 штуки, они, соответственно, будут присваиваться IEEE производителю сетевого устройства. То есть, например, делает D-Link сетевые карточки. D-Link идет в IEEE, получает там так называемый OUI, Organizational Limit Identifier, свой идентификатор организации, как D-Link. И вот на все свои железки он, значит, клепает вот эти вот самые 22 бита, которые ему сказали. То есть у абсолютно любых железок, которые он будет производить, левая половинка будет, по факту, одинаковая. А правая половинка, она будет различаться, и он, соответственно, если он хочет производить сетевые карточки, он обязан делать так, чтобы всегда те железки, которые он будет производить, отличались бы вот по этой правой части. Соответственно, если у вас есть две железки двух разных вендоров, они отличаются по левой половинке, гарантированно. А если у вас есть железки одного производителя, то они отличаются по правой половинке. Правая половинка будет называться vendor assigned ID.

Обычно обозначается vendor ID. И если вы переустанавливаете universal/local bit в единичку, то вы можете 46 бит выставлять по своему усмотрению, как захотите. Есть нюанс, заключающийся в том, что на этот почти самый младший бит очень мало кто смотрит. Софт, как правило, игнорирует его. Поэтому вам никто не мешает, даже если вы задаёте адрес уникальный самостоятельно, выставить этот почти самый младший бит в ноль, и никто вас по рукам бить не будет. Циска, может быть, будет, а больше никто особо нет. А вот на самый младший бит, действительно самый младший бит, действительно много софта смотрит, и вы не можете просто так взять и сделать себе адрес и не назначить нолик в самом младшем бите первого байта. Практически все чипы, которые вы будете встречать на рынке, они будут ругаться, если вы пытаетесь это сделать.

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

биты обрабатываются в естественном порядке. Когда у вас есть MAC-адрес, он обрабатывает сначала первый байт, потом второй байт, потом третий байт. И когда вы по сети эти биты передаёте, они тоже передаются сначала первый байт, потом второй байт, потом третий байт. Но внутри самого процессора и внутри сетевого интерфейса эти байты передаются в обратном порядке. Сначала передаётся самый младший бит, потом почти самый младший бит. Порядок байтов естественный, а порядок битов неестественный, он противоположный. Так называемый big-endian и little-endian. Байты передаются от младшего к старшему, а биты передаются задом наперёд. Сначала восьмой битик, тот, который самый младший, потом седьмой битик, который почти самый младший, и так далее. Эта штука называется little-endian или сетевой порядок. Соответственно, самый младший бит передаётся самым первым. И когда начинает вылезать какой-то кадр, вылезла преамбула 64 бита,

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

Мы хотим отправить от узла А кадр в сторону узла Д. Мы проставляем адрес получателя Д, адрес отправителя А, отправляем эти биты в сеть в виде ноликов и единичек. Дальше и Б, и Ц, и Д эти биты видят. Дальше Б и Ц из первого поля destination address в заголовке кадра понимают, что это не им, и зажмуриваются. Они не принимают этот кадр. Они говорят: это не мне, мне неинтересно. Я мог бы это прочитать, но я же не буду подслушивать кадры, которые не мне. А узел Д не подслушивает. Он говорит: это действительно мне, здесь всё честно, я совершенно открыто заявляю, что это мне, я это буду слушать. Поэтому Б и Ц зажмуриваются, Д не зажмуривается и кадр читает полноценно. Бывает другой тип взаимодействия, когда вам нужно один и тот же кадр отправить нескольким узлам сразу. И есть вариант либо отправить несколько разных юникастовых кадров, когда вы знаете, кому вы отправляете,

либо отправить какой-то один кадр, чтобы его прочитало несколько узлов, чтобы они не зажмурились одновременно. И в этом случае вы говорите: я хочу от узла А отправить какой-то кадр, и в качестве адреса я указываю какой-то адрес, например, Е. Это не юникастовый адрес, нет узла, у которого был бы такой адрес. Но у нас есть узел С, который говорит: я присоединяюсь к группе Е. И узел Д, который тоже говорит: я присоединяюсь к группе Е. И когда вы передаёте такой кадр и указываете в качестве адреса получателя адрес Е, соответственно, С не зажмуривается и читает такой кадр. Д тоже не зажмуривается и тоже читает такой кадр. А Б зажмуривается, потому что говорит: я не знаю, что такое Е, это не мой адрес, я его не знаю. Здесь возникает вопрос: а как С и Д понимают, что им надо присоединиться к группе Е? Обычно ответ на этот вопрос очень простой.

Мы на них запустили какой-то софт, который каким-то образом это узнал. Например, мы запустили на них процесс маршрутизации. И сам факт того, что на них запущен процесс маршрутизации, сам процесс маршрутизации сказал: все маршрутизаторы должны услышать группу Е. И он сказал им, какой именно MAC-адрес им следует слушать. Например, если говорить про конкретные примеры, такие, с которыми вы можете встретиться в реальной жизни, у нас есть такая штука, как мультикаст в IPv4. И раз уж мы говорим про маршрутизаторы, любой маршрутизатор в IPv4 обязан слушать адрес 224.0.0.2 в IPv4. Но если мы слушаем этот мультикастовый IP-адрес, то, соответственно, мы заставляем также слушать групповую рассылку на уровне Ethernet. 01:00:5e:00:00:02. Мы запустили движок маршрутизации, например, это не узел D, а маршрутизатор Cisco.

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

А в качестве адреса получателя вы указываете того, кому вы хотите это отправить. Или адрес той группы, кому вы хотите это отправить. Юникаст-адрес есть обязательно у любого узла. Он либо есть прошитый на заводе, так называемый burnt address, либо, если его переопределил администратор, эта штука называется locally administered address. Вместо заводского адреса вы говорите: я администратор, хочу, чтобы ты использовал какой-то другой адрес. Он обязан быть уникальным, как минимум в пределах широковещательного домена. И если вы отправляете какие-то кадры, то в качестве адреса отправителя вы всегда используете свой собственный юникастовый адрес. Либо заводской, либо тот, который админ сказал. Мультикастовые адреса нигде не прописываются в настройках интерфейса. Вы нигде этот адрес не должны будете видеть, что он принадлежит именно вам, потому что он вам не принадлежит. И для того чтобы слушать какую-то мультикастовую группу, вам нужно, чтобы у вас появилось желание

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