Работа с канальными средами (часть 1)

Давайте поговорим про то, чем связываются между собой маршрутизаторы. Когда у нас есть некоторое количество устройств в сети, которые работают с протоколом IP, они не просто какой-то абстрактный трафик по сети гоняют абы как, они передают конкретные данные в виде отдельных нуликов и единичек по разным каналам связи. Мы с вами должны будем понимать, поверх чего именно гоняется IP-шный трафик, потому что у каждого из различных способов связи есть какие-то свои особенности, свои преимущества, недостатки. Естественно, что в большинстве ситуаций мы будем использовать Ethernet, но не только Ethernet. Как минимум есть еще Wi-Fi. Безусловно, в курсе кроме Wi-Fi и Ethernet рассматриваются и другие варианты. Во-первых, есть, конечно, Serial Link, поверх которого можно запустить PPP, можно запустить Frame Relay, можно запустить HDLC.

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

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

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

И коммутирует кадры, я напоминаю, на сессии может быть вы помните, может быть, если вы на наши сессии не ходили, вы этого еще не помните или не знаете. Любой коммутатор разбрасывает копии кадра на вообще все порты. Любые кадры он пытается разбросать на все порты, за исключением тех портов, куда он точно знает, что кадр посылать не надо. Классический рассказ про то, как работает коммутатор, предполагает, что вам говорят, что есть отдельный Unicast forwarding, который коммутатор смотрит по таблице, куда трафик послать, а есть отдельно Multicast, а есть отдельно Broadcast, а есть отдельно Unknown Unicast, и все это дело по-разному обрабатывается. Нет, на самом деле все это брехня. Коммутатор все кадры обрабатывает абсолютно одинаково. Он пытается все кадры разбросать на все порты, но на некоторых портах он эти кадры не отправляет. Копии кадров. Я про это подробно рассказывал в Ethernet, те, кто на CCNA были, те помнят.

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

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

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

хотя обычно этого не происходит, потому что процедура пополнения таблицы коммутации, основанная на MAC learning, она достаточно неплохо работает в большинстве случаев, и пока все идет по плану, Unicast-овый трафик между узлами ходит как предполагается, Broadcast-овый трафик ходит как и предполагается. Но здесь есть нюанс, заключающийся в том, что если где-то в таблицу коммутации начнут вторгаться какие-то нехорошие изменения, то весь процесс пойдет и потрещит по швам. Дальше бывают кроме Ethernet и другие варианты связи между узлами. Во-первых, могут быть связи по логической топологии point-to-point, когда у вас есть просто электрический провод между двумя узлами, и вы в этом электрическом проводе можете передавать отдельные биты. Например, Serial Link. В этом Serial Link вы можете сказать: окей, мы умеем передавать нолики и единички, но нам из

этих ноликов и единичек надо передавать какие-то кадры, и мы будем из этих ноликов и единичек строить кадры. И мы можем сказать, какого формата кадры мы будем отправлять: либо PPP, либо Cisco HDLC-шный кадр. Это, я опять же на сессии рассказывал, это кадры, которые заимствуют формат у древнего протокола HDLC, но немножко модифицируют для нужд, чтобы можно было там передавать что-то полезное кроме данных терминальных мейнфреймов. И в принципе логическая топология point-to-point может еще часто встречаться в VPN-туннелях, когда мы, например, поверх интернета организуем VPN-соединение. Там точно так же, как и в случае с прямым проводом, который соединяет два роутера, у нас получается такой псевдопровод, и в этом псевдопроводе мы тоже можем гонять что захотим. Можем гонять PPP, можем в определенной ситуации сразу эти пакеты вкладывать в виртуальный провод, потому что там никакого промежуточного заголовка не надо, у

нас сразу же размер передаваемых данных известен и никакие специальные служебные протоколы для промежуточного заголовка уже не требуются. Это может быть GRE, может быть IP-in-IP, может быть что-то еще, например там IPsec в туннельном режиме, с образованием интерфейса. У IPsec проблемы есть, но тем не менее. Дальше может быть такое, что у нас есть среда, в которой мы можем отправить кадр, и этот кадр дойдет не до всех. Например, у нас есть такая штука как Wi-Fi. В Wi-Fi может быть такое, что кадр вы отправите, но на чисто физическом уровне этот кадр не дойдет вообще до всех участников вашей среды. Это абсолютно нормальное явление, если пытаться себе представить, как устроена беспроводная связь. У вас есть антенна-передатчик, и вы ограничены некоторой мощностью этого передатчика. Если вы

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

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

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

Поэтому во Frame Relay у нас может быть такая ситуация, что Петя здесь на самом деле есть, но трафик до него ходить не может, потому что коммутатор это дело запрещает. В Ethernet такие штуки тоже бывают, но предполагают специальные отдельные настройки со стороны администратора. Мы про это будем говорить на свитчинге. Классические коммутаторы «из коробки» такое делать не позволяют, чтобы у нас к одному коммутатору было подключено два узла, которые друг другу передавать трафик не могли, но например оба могли бы передавать трафик третьему. Такое взаимодействие возможно, но требует настройки. Дальше, что у нас еще бывает. Бывает DMVPN. Это VPN, в котором у нас, как раз на картинке здесь нарисовано, несколько узлов подключаются к одному и тому же облаку и строят поверх этого облака виртуальную как бы сеть, и есть всего один интерфейс, который в эту сеть смотрит. У нас интерфейс смотрит в виртуальную среду, и в этой виртуальной

среде находится много получателей. DMVPN — такая прикольная штука, которая позволяет такие вещи сделать. Там же можно будет сделать всякие разные вещи, типа отправить кадр такой, который дойдет не до всех получателей. Можно будет отправить кадр, который дойдет до Васи и до Пети, а вот до Коли не дойдет. У таких сред могут быть какие-то забавные особенности, которые вносят разнообразие, так скажем, в жизнь администратора, который с ней работает. В Ethernet все легко и просто. В Ethernet мы просто отправляем кадры, и они обязательно дойдут до всех получателей. В Serial Link с PPP или HDLC все очень просто. Мы просто отправляем кадры, и они обязательно дойдут до всех получателей, до того единственного получателя, который в этом канале есть. Как только мы вторгаемся вот в эту фигню, либо Wi-Fi, либо NBMA, либо что-то еще, здесь сразу возникают вопросы. В первую очередь возникают вопросы с мультикастом. У нас есть кадры, которые мы хотим отправить, например, всем получателям

мультикаста. А NBMA- среда не позволяет нам доставить трафик до всех. Она говорит: а я вот тебе только до этого или до этого могу доставить трафик, а до того не могу. И сразу возникает вопрос, а как такой мультикаст будет работать? Как вы понимаете, мультикаст — это основа работы протоколов типа OSPF или EIGRP, поэтому если у нас мультикаст работает некорректно, сразу все эти протоколы — OSPF, EIGRP, RIP — тоже начинают работать некорректно. Мы должны будем знать, как работает мультикаст в таких средах, и мы должны будем уметь с ними работать. Так, Ethernet — протокол жутко старый. 1974 год, лаборатория Xerox, Роберт Меткалф придумывает свой протокол эфирной связи по общей шине. И протокол получился удачный. Сегодня мы так или иначе работаем именно с ним. Точнее не с ним, а с протоколами, которые наследуют от того Ethernet формат кадра. Ethernet — это не какой-то один протокол, это целое семейство. И

с тем оригинальным Ethernet их роднит только общий способ доступа к общей среде. MAC — Media Access Control. Это формат кадра, это организация передачи данных в общей среде. И каждый конкретный протокол, с которым мы будем работать, который называется Ethernet, это на самом деле комбинация вот этого подуровня MAC — Media Access Control — и комбинация какого-то физического уровня, который реализует уже передачу отдельных битиков по среде. Физика у всех Ethernet будет разная, а MAC-подуровень, способ организации кадров из битиков, переданных по физическому уровню, у всех Ethernet одинаковый. Коммутаторы, которые в Ethernet появились примерно в 1989 году, в 1990 году они были стандартизированы в протоколе 802.1D. 802.1D. Это протокол как раз коммутации.

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

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

Вы можете сделать так, что вы отправляете мультикастовый кадр в Ethernet, и его прочитают некоторые узлы, а некоторые другие не прочитают. Они его получат, но они зажмурятся и не будут его читать. В Ethernet за счёт того, что мультикаст и бродкаст есть, всякие протоколы типа OSPF, EIGRP и прочих чувствуют себя просто превосходно. Они с помощью мультикаста обнаруживают соседей, и благодаря этому мы не должны прописывать, что у нас на этом интерфейсе есть сосед с каким-то конкретным IP-шником или что-то ещё. Мы просто включаем OSPF на интерфейсе и мультикастом обнаруживаем соседей. У 802.3 Ethernet есть два формата кадров. На самом деле один и тот же формат, просто допускающий две разные интерпретации. По стандарту есть интерпретация, которая называется Ethernet 2. Эта интерпретация заимствует формат кадра, который был придуман Робертом Меткалфом в 1974 году. Такой кадр будет состоять из нескольких полей.

Сначала, перед каждым кадром, я просто напоминаю, как это всё устроено, идёт преамбула. Преамбула — чередующиеся битики 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, и она длится 7 байт. Восьмой байт будет состоять из битиков 1, 0, 1, 0, 1, 0, 1, 1. Этот восьмой байт будет называться SFD, Start of Frame Delimiter. Или его иногда называют SOF. S-O-F. Start of Frame. Дальше начинается мясо кадра. Мясо кадра состоит из адресной информации — 12 байт. Дальше два байта того, что внутри лежит. Это указывается тип содержимого. Когда Меткалф придумывал свой протокол, он сказал, что всё, что будет передаваться с помощью протокола Ethernet, будет фактически сделано лабораториями Xerox. И лаборатории Xerox будут указывать, какие типы вложений допустимы в Ethernet.

Два байта дают нам возможность указывать с 0 по 65535, то есть 65536 различных вариантов вложения. Фактически это означает, что Меткалф заложил для лаборатории Xerox 65 тысяч с копейками различных вариантов того, что может передаваться по Ethernet. Дальше передавалось уже мясо. И в конце поле Frame Check Sequence, чексума, которая используется для обнаружения коллизий и для проверки корректности того, что прибежало по каналу. На это дело посмотрели инженеры IEEE и сказали, что очень клёво, конечно, то, что лаборатория Xerox придумала такой клёвый протокол, но мы не хотим, чтобы лаборатория Xerox определяла то, что можно передавать по этому протоколу. А то потом с ними не договоришься. И поэтому сказали: мы заимствуем у них формат кадра. Мы берём эту штуку, они придумали хорошую преамбулу и Start of Frame. MAC-адреса они придумали хорошие, мы их используем.

Но дальше вместо поля EtherType мы говорим, что 2 байта будут отдаваться под что-нибудь другое. Мы не будем указывать в этих 2 байтах, что внутри лежит. У нас уже есть стандартный протокол, с помощью которого можно указывать, что внутри лежит. Это протокол 802.2. Это отдельный протокол от 802.3 Ethernet, который указывает, когда мы хотим передать что-то внутри какого-то другого вложения, для того чтобы указать, что внутри лежит, мы используем вложение, которое называется LLC. Оно трёхбайтовое. И в этих 3 байтах есть 3 подполя. Это поле Source Service Access Point, Destination Service Access Point и Control Word. Протокол дурацкий, потому что он был придуман в далёких концах 60-х, начале 70-х. И поэтому он реалии современного мира совершенно не отражал. Но у него есть одно замечательное свойство. Он позволяет внутрь себя вложить другой протокол, который тоже постепенно стал частью стандарта 802.2.

И он называется вложением SNAP. SNAP-заголовок уже 5-байтовый, и он позволяет указать фактически 5 байт того, что внутри лежит. EtherType был 2-байтовый, и его назначала лаборатория Xerox. А SNAP — это 5-байтовое поле. И оно позволяет регламентировать то, что будет внутри лежать, уже не какой-то частной компании, а международному институту инженеров и электронщиков. IEEE. У него там 2 подполя: 3 байта — это OUI, Organizational Unique Identifier, и 2 байта — указание того, что внутри. Здесь у нас 2 байта указывала лаборатория Xerox, а здесь мы указываем 3 байта того, кто придумал протокол, и 2 байта — внутренний номер протокола у того, кто его придумал. Эта штука, она, конечно, существенно более гибкая. А 2 байта освободившихся решили другую задачу, которую не решил Меткалф в своё время. Меткалф, когда придумывал протокол Ethernet, сказал, что давайте мы сделаем ограничение на размер кадра снизу, для того чтобы бороться с коллизиями.

Что у нас кадр не получился слишком маленький, мы его не будем делать меньше, чем 64 байта. 12 байт MAC-адреса, плюс 2 байта что внутри, плюс 46 байт клиентские данные, плюс 4 байта — это чексума. Всего получается как раз 64 байта. Минимальный размер кадра у нас будет 512 битов, и передаваться он будет за время 512 биттаймов, или за так называемый слоттайм. Это время, которое требуется на обнаружение коллизии. Если мы передаём кадр даже самой маленькой длины, он передаётся в течение того минимального времени, за которое мы гарантированно обнаружим коллизию. И получается, что меньше чем 46 байт в Ethernet классически вложить нельзя. Что делать, если очень хочется? Использовать как раз это освободившееся поле, сказали инженеры IEEE, и сказали: давайте мы будем указывать внутри, сколько полезных данных передаётся конкретно в этом кадре.

Если мы передаём кадр, и в нём данных меньше чем 46 байт хочется переложить, то мы добиваем размер с данными до 46 байт и указываем, сколько полезных данных по факту там передаётся. Хотим передать 10 байт полезных — указываем в поле Length число 10. А дальше добиваем в поле с данными: здесь 10 байт, и добиваем всё остальное нулями, для того чтобы получить минимальный размер кадра. Фишка в том, что это именно две разные интерпретации одного и того же явления: того, что у нас есть какие-то кадры, и эти кадры должны быть определённого размера по своим свойствам, чтобы у нас работали механизмы обнаружения коллизий и прочее, что в сегодняшнем мире уже не сильно интересно, но тем не менее всё ещё актуально. Актуально, потому что прописано в стандартах. И это на самом деле одни и те же кадры. У них точно такие же преамбулы: что здесь, что здесь — одинаковые. У них точно такие же адреса проставлены. Здесь и здесь адресная информация одинаковая.

У них точно так же считается чексума. И на самом деле, когда коммутатор пропускает через себя кадр, он ориентируется как раз на преамбулу, на адресную информацию и на чексуму. Обычному коммутатору абсолютно не интересно, что здесь лежит и что здесь лежит. Фактически мы говорим, что если мы указываем значение либо в одной трактовке, либо в другой, мы это делаем только для того, чтобы конечному абоненту можно было разобраться, как с конкретным кадром работать. Мы можем сказать, что здесь лежит EtherType, либо мы можем сказать, что здесь лежит длина. Есть договорённость такая, что если мы указываем, что тут лежит EtherType, то для EtherType определены такие диапазоны значений. Как минимум 1536 здесь будет передаваться. Это шестнадцатеричное число 0x0600. Если мы указываем длину, то мы указываем её в диапазоне от 0 до 1500. Потому что 1500 — это размер вложения, который в Ethernet допустим. Это размер поля MAC Client Data.

Оно должно быть не больше чем 1500 байт по стандарту. И если мы указываем значение с длиной, то это предполагает, что мы используем LLC плюс SNAP заголовок. Чистый LLC используется крайне редко, но тем не менее, если вдруг оно используется, то SNAP там не будет. Чаще всего всё-таки это LLC плюс SNAP. И поле с длиной мы указываем именно сколько данных вложено в MAC Client Data. Все эти дополнительные заголовки, которые мы используем, они отъедаются от этого поля. Если мы указываем, что у нас кадр передаётся с 1500 байтами содержимого, то мы говорим: 1500 байт — это содержимое. А то, что там заголовки часть из этих 1500 байт отъедают — такова жизнь. Получается, что если у нас есть и LLC заголовок, и SNAP заголовок, которые отъедают 8 байт, и всего MAC Client Data занимает 1500 байт, значит содержимого в этот кадр можно положить не больше чем 1492 байта. И ограничение снизу, которое у нас 46 байт, тоже никто не поменял.

MAC Client Data должно быть не меньше 46 байт. Значит если у нас 8 байт из них будут служебные, то полезных данных можно положить только 38. Если коммутатор получает кадры, ему абсолютно всё равно, что там лежит. EtherType там лежит, длина там лежит. Транзитному коммутатору вообще абсолютно наплевать на это. Он коммутирует кадры в зависимости от того, куда эти кадры идут, и пополняет свою таблицу коммутации в зависимости от того, от кого эти кадры идут. Всё остальное для него тёмный лес. Чексуму он ещё проверяет. Здесь можно вообще всё что угодно написать — транзитному коммутатору неинтересно, что внутри. На это он не смотрит. Для него это просто payload. Единственное исключение. Когда коммутатор поднимает кадр на транковом порту, он смотрит, нет ли там случайно 802.1Q метки. И если он видит там 802.1Q метку, то есть он в следующие 2 байта заглядывает и видит там шестнадцатеричное 8100.

Он на неё ориентируется. Он говорит: я понимаю, что следующие 4 байта — это метка. Надо будет её срезать. А так для обычных пользовательских кадров там может лежать всё что угодно. Фактически коммутатор, когда принимает какой-то кадр, помимо того что может какие-то транзитные кадры обрабатывать, он ещё будет ожидать, что некоторые кадры не подлежат транзиту. Что некоторые кадры надо будет обработать самостоятельно. Это всякие CDP, LLDP, VTP, DTP и прочие служебные протоколы, которые надо принять самому и не отправлять дальше. В этом случае процедура определения того, интересен ли кадр самому коммутатору или нет, будет выполняться до того, как кадр отправится на коммутацию. Мы посмотрели на то, что внутри лежит. По каким-то косвенным признакам поняли, что это нам интересно или не интересно. Если интересно — прочитали. Если не интересно — отправили на коммутацию. В процедуре коммутации вложение вообще никакой роли не играет.

Что там будет длина, что там будет тип, что там вообще какое-нибудь странное значение будет лежать — транзитному коммутатору это вообще не интересно. И для того чтобы не было путаницы между тем, какое конкретно значение где использовано, есть договорённость, что диапазон от 1501 до 1535 не определён и в нормальной ситуации встречаться не должен. В нормальных кадрах либо меньше чем 1500, и тогда это длина, либо больше чем шестнадцатеричное 0600, и тогда это тип. Это актуальное поведение Ethernet в текущем стандарте 802.3 редакции 2015 года. Когда-то давным-давно в очень далёкой галактике было много разных форматов кадров. Были кадры Ethernet чистые, прямо без какого-либо EtherType, просто сразу тут клалось мясо. Так называемый новелловский формат.

Были кадры, в которых был только LLC. Это было мясо. Были кадры с LLC и с SNAP. И были кадры Ethernet 2. Это были четыре несовместимых между собой формата. И коммутаторы, которые делались, они делались именно с расчётом на то, что они должны были проверять, что кадр пришёл корректный. Сетевое железо, конечные узлы, компьютеры делались — они тоже проверяли, что кадр пришёл корректный. Эти форматы были несовместимы между собой. С 1997 года всякие экзотические форматы кадров умерли совсем. И осталось фактически два варианта формата кадров, которые объединены в одном стандарте 802.3 2015 года. Если мы смотрим, что у нас есть MAC-адреса 12 байт, и после них заглядываем в 2 байта и видим там число, которое больше чем 1536, мы говорим: это EtherType. Если мы видим там число меньше чем 1500, мы говорим: это длина. Это такая двойная интерпретация формата кадра.

Если мы запускаем IP поверх Ethernet, тут всё достаточно просто, предсказуемо, привычно. Нам для того, чтобы IP хорошо себя чувствовал поверх Ethernet, нужно будет запустить всякие служебные протоколы. Как правило, ARP будет использоваться для того, чтобы по известному IP-шнику получать MAC-и. Потому что нам, когда мы отправляем кадры в среду с общей шиной, обязательно нужно указать адрес того, кому мы это отправляем. Можно, конечно, бродкастом всё шарашить, но это будет как-то неспортивно. Нам нужно будет использовать какой-то механизм настройки IP. Как правило, там DHCP будет использоваться. Ручками можно, конечно, настроить всё, но это тяжело. И нам нужно будет какие-то протоколы, которые будут позволять управлять маршрутизацией. Классический стандартный протокол, который самый первый появился, это будет ICMP Redirect, который позволяет нам принять какой-то кадр на маршрутизаторе и сказать: нам не нравится, что ты посылаешь, дорогой клиент, этот трафик нам,

ты лучше посылай его кому-нибудь ещё. В Ethernet, если у нас есть среда с общей шиной, давайте попробуем нарисовать её. У нас толстый коаксиал, в нём несколько абонентов сидят, и среди прочих сидят, допустим, два роутера. Роутер один, роутер два. И у одного из роутеров есть выход в интернет. У нас есть абонент, который посылает зачем-то кадр на другой роутер и говорит: отправь, пожалуйста, этот кадр в интернет. Для того чтобы отправить этот кадр в интернет, надо по той же самой среде, по тому же самому интерфейсу, по которому мы этот кадр получили, его отправить дальше на другой роутер. Роутер это делает, но он отправляет встречное сообщение ICMP Redirect, типа: в следующий раз посылай ему напрямую. В IP такая штука есть. У классического IP эта штука была, сегодня это достаточно редко используется, потому что, во-первых, ситуация, когда несколько разных роутеров предоставляют несколько разных услуг, она достаточно редкая.

А во-вторых, есть определённый ряд вопросов в части безопасности к такому поведению, поэтому зачастую это поведение отключается, и даже если к вам приходит ICMP Redirect, вы на него особенно не реагируете. Но тем не менее в классическом стандарте она была. Что ещё тут бывает? Если мы хотим отправлять мультикаст IPv4 поверх Ethernet, то мы должны будем упаковать мультикастовый IPv4 пакет в мультикастовый же кадр. И в мультикастовом кадре у нас есть MAC-адрес источника, MAC-адрес получателя. С MAC-адресом источника всё предсказуемо, а вот MAC-адрес получателя в мультикастовом Ethernet, который несёт в себе IPv4 мультикаст, он будет интересный, и его надо будет на самом деле запомнить. Для этого используется специальная OUI-шка, OUI 01-00-5E. Это хорошо известная мультикастовая OUI-шка для IPv4. Дальше первый битик нулевой,

от вендорного идентификатора, который вообще 24 бита, первый битик будет нулевой всегда. А оставшиеся 23 бита мультикастового адреса заполняются здесь в качестве 23 бит мультикастового MAC-а. Например, если у нас есть мультикастовый адрес 224.0.0.5, я думаю, что вы уже должны знать, что это за адрес — это все OSPF роутеры. У него последние 23 бита — это 0.0.5. Это 8 бит, это 24 бита. 23 бита и отдельный нолик. Такой IP-пакет на адрес 224.0.0.5 — все OSPF роутеры — пойдёт в Ethernet-кадре на мультикастовый адрес 01-00-5E-00-00-05. Такая вот штука. Если говорить про IPv6, там очень похожее поведение. Понятное дело, там другие протоколы,

там нету ARP, там нету ICMP Redirect, но там есть ICMPv6, там есть DHCP, который может работать в двух разных режимах — stateless и stateful. Про это мы поговорим на свитчинге. Но из того, что нам здесь интересно для IPv6, у него немножко другое поведение, как упаковаться в Ethernet. Если у него есть мультикастовый пакет, который надо отправить, например, для FF02::5 — все OSPFv3 роутеры, мы берём хорошо известный префикс 33-33 и дальше последние 4 байта IPv6 адреса. У IPv6 адреса FF02::5 последние 4 байта — это у нас 00-00-00-05. Поэтому IPv6 мультикастовый пакет, который несёт в себе OSPFv3, будет упаковываться в Ethernet на MAC-адрес 33-33-00-00-00-05.

Эти MAC-и хорошо бы знать, не обязательно они на экзамене понадобятся, но в реальном мире вы их будете встречать обязательно и наверняка. Я предлагаю на сегодня закругляться и завтра проговорить с самого начала нашего занятия про протоколы, которые будут иметь отношение к Point-to-Point, то есть либо Serial Link, либо виртуальные всякие соединения типа GRE, ну и заодно про всякие NBMA. среды, FrameRelay и DMVPN. На сегодня всё. Спасибо за внимание и пока-пока.