Коммутация и виртуальные локальные сети (VLAN)

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

стало понятно, что можно, в принципе, объединять несколько разных доменов коллизий в несколько разных широковещательных доменов. И, соответственно, это ровно то, что называется VLAN. Когда мы делаем несколько разных широковещательных доменов и объединяем домены коллизий в них. Если мы говорим про, в кавычках, обычные коммутаторы, то, соответственно, в обычном коммутаторе любые пользователи могут друг другу передавать какие-то данные. Давайте начнем с вспоминания того, как устроен желтый каксиал. У нас есть каксиал, в нем есть абоненты. И, соответственно, любой абонент может передать сигнал в толстый желтый каксиал, так что все другие пользователи этот самый сигнал услышат, его декодируют и увидят там какой-то кадр. Когда мы придумали использовать коммутаторы, соответственно, у нас может быть такое, что любой пользователь захочет отправить какой-то кадр, и этот кадр дойдет до всех остальных участников. Самый простой вариант, когда отправляется бродкаст. То есть мы отправляем кадр на MAC-адрис FF, FF, ну, я не буду писать много F, но, короче говоря, бродкастовый кадр мы отправляем, и широковещательный домен так называется, потому что бродкасты в этом домене доставляются до всех участников.

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

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

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

Вы можете отправлять кадры от имени вашей жертвы, и никто никогда не догадается, что это вы отправили кадр от имени вашей жертвы, а не сама жертва. То есть представьте себе, что у нас есть вот узел А. И кто-то вот здесь вот начинает отправлять нолики-единички, в которых кодируют кадры, в которых написано «это кадр от узла А до узла Б». Но это не сам узел А сделал, а вот кто-то другой, там, узел С. Есть Алиса, Боб и Ева. Ева, потому что она злоумышленник. Или рядышком еще Мэлори часто сидит, потому что Е — это ивздроппер, подслушивающий, а М — это malicious user. Вот он активно пытается что-то сделать. Вот некий Мэлори, он пытается отправить кадр, в котором пишет «я узел А, я отправляю кадр к какому-то другому узлу». Узел Б, который получает такой кадр, он не может понять, кто ему его отправил. Действительно, Ашка ли его отправила, или кто-то другой, кто представился Ашкой. Поэтому в большой сети все вот эти вот проблемы, они существуют. Насколько бы ваши дорогие свечи ни были,

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

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

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

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

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

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

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

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

То есть если мы говорим про актуальное состояние в 2019 году, то да, сейчас используется по факту только один способ. Но вы должны будете понимать, что модифицированный кадр и вот тот самый способ, которым все пользуются, это не одно и то же. Это две разные сущности. То есть модифицированный кадр может быть гипотетически модифицирован и другими способами, не только с помощью протокола 802.1. Если вдруг вы знаете, что это такое. Давайте я вам сначала расскажу про другой способ, который CISCO фирменный придумал, способ свой, когда-то давным-давно. Он назывался ISL, InterSwitchLink. И фактически, когда у вас был какой-то кадр, который вы хотели передать соседу не просто, а с указанием, что вы этот кадр отправляете, потому что он относится к определенному VLAN, вы его инкапсулировали в другой заголовок. То есть у вас был какой-то вот пакетик, который вы хотели отправить. Вы говорите, мы его кладем в новый пакет. И, соответственно, у него новый заголовок Ethernet,

у него все новое. И там, среди прочего, пишется, ну, так называемый номер VLAN. Вот. Там 26 байт нового заголовка и 4 байта новая чексума. Потому что кадр, который вы брали, у него был какой-то свой заголовок, у него была какая-то своя чексума. И вот вы вместе с заголовком, вместе с чексумой, вместе со всем остальным брали, упаковывали его в новый пакет. 30 байт — это довольно много. Номер VLAN, соответственно, в этом самом заголовке указывался. Номера VLAN там были 15-битные, но при этом по факту использовать можно было не 15-битные номера VLAN, а с 1 по 1001. Вот. 1002, 1003, 1004, 1005 VLAN тоже можно было использовать, но они были для специфических нужд. 1002, 1005. Дальше. Понятное дело, что если вы брали, допустим, 1500-байтовый пакет и дальше окружали его

ещё дополнительно 26-байтным заголовком и 4-байтной чексуммой, то у вас максимальный размер кадра фактически вырастал на те самые 30 байт. Поэтому максимальный размер такого кадра был на 30 байт больше. Если вы включали этот режим, что соседу вы отправляете модифицированные кадры с помощью ISL, то, соответственно, у вас максимальный размер кадра на именно этом интерфейсе автоматически увеличивался на 30 байт. После того, как вы получали такой кадр на соседнем свиче, вы его распаковывали, выбрасывали этот самый дополнительный заголовок, восстанавливали оригинальный кадр и дальше могли его передавать куда-нибудь, но там уже был разумного размера. Эта штука сегодня дохлая. Cisco от неё отказывается, от ISL, новые свичи типа тех же Nexus его уже не поддерживают. На наших лабораторных железках он ещё есть, мы его сможем пощупать, чисто посмотреть, что он есть. А так в реальном мире вы его вряд ли встретите. В первую очередь потому, что 30 байт — это много.

Если говорить про сегодняшний мир, то, скорее всего, вы будете пользоваться стандартным способом, который поддерживается всеми вендорами, не только Cisco. Этот способ называется 802.1Q. Заключается он в том, что вы в заголовок Ethernet добавляете новое поле. Соответственно, заголовок Ethernet, если вы забыли, выглядит следующим образом. 6-byte destination address, 6-byte source address, дальше, что внутри лежит, 2 байта EtherType, потом данные, и, соответственно, в конце frame check sequence. 4 байта. Этот самый 802.1Q добавляет сюда 4 байта. У нас появляется здесь дополнительное поле размером 4 байта. И поэтому он меньше накладные расходы даёт, он позволяет работать с 12-битными номерами VLAN, но при этом все 12 бит можно использовать. Номера VLAN с 1 по 4094. Первый, последний нельзя.

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

то чек-сумма, которая старая была, она выкидывается, на её место записывается новая 4 байта вместо старой. Когда вы кадр такой отправляете по сети, и он доходит до соседа, сосед выбрасывает эти 4 байта и восстанавливает оригинальную чек-сумму, так что проблем с этим не возникает, потому что она в любом случае считается как CRC32 от всей этой колбасы, поэтому даже если вы её выкинули, её всегда можно пересчитать и восстановить оригинально. Так, что конкретно вкладывается в эти самые 4 байта? Сюда вкладывается число 8100, шестнадцатеричное. Учитывая, что на этом месте, в принципе, у нормальных кадров находится EtherType, вы можете сказать, что если вы видите кадр, у которого EtherType 8100, это кадр с 802.1Q-шной меткой. Дальше у него какая-то контрольная информация 2 байта, и дальше у него в данных, соответственно, хранится что-то полезное.

Если мы говорим про то, что можно взять и отправить просто какой-то абстрактный кадр, а дальше он обрастёт этим самым дополнительным заголовком, то, например, мы можем взять и сказать, что у нас здесь кадр содержит IPv4. Тут у нас IPv4-пакет. Соответственно, в этом поле EtherType у нас будет лежать число 0x0800. И поэтому, когда мы добавляем эти самые 4 байта, 0x0800 переезжает сюда, дальше это наш оригинальный IP-пакет, и здесь у нас будет 8100, 0x8100, и здесь у нас будет какая-то контрольная информация. Это самое TCI, Tag Control Information, там 2 байта, 16 бит, из которых 12 бит — это номер VLAN, 3 бита — флаги приоритетов, и 1 бит такой, ни туда, ни сюда, ни рыба, ни мясо, про него мы детально поговорим на CCNA D2. Что касается этих самых 802.1Q-шных модифицированных кадров,

опять же, когда у вас есть два свича, которые друг на друга смотрят, они решают, что они будут отправлять друг другу модифицированные кадры, то есть у них кадры будут отправляться с метками, с флажками. Эти метки занимают 4 дополнительных байта, поэтому если у вас оригинальный кадр был 1500 байт, плюс 18 байт заголовков, то, когда вы добавляете 4 байта, у вас фактически максимальный размер со всеми заголовками возрастает на 4 байта и становится больше, чем стандартный 1518 байт. Кадры, которые могут быть больше, чем стандартный 1518 байт, называются специальным словом Baby Giant. Стандартное определение, что Baby Giant — это больше, чем 1518 байт, строго больше, но, соответственно, меньше, чем 1600 байт. Если у вас кадр в таком диапазоне находится по размеру, то он называется Baby Giant. Эти самые кадры могут получаться как раз за счёт каких-то дополнительных заголовков. 802.1Q — это стандартный случай,

когда у вас кадр получается немножко побольше, чем должен быть. Он автоматически разрешается и для отправки, и для приёма. Когда вы включаете транк на Cisco, вы можете не заботиться о том, что надо как-то специально включать обработку таких Baby Giant, они на порту автоматически включаются и начинают обрабатываться автоматически. Фактически, когда мы говорим про 802.1Q-шные кадры, это нормальные кадры Ethernet. У них в предсказуемом месте MAC-адрес, в предсказуемом месте отправитель, получатель. У них даже то, что внутри лежит, фактически тоже стандартное. Там лежит число 8100 на месте того, что указывается, что внутри лежит, EtherType. И фактически, когда мы говорим, что там 8100, мы говорим, да, это кадр модифицирован, у него дальше идёт метка, а дальше после неё настоящий EtherType. Транзитному коммутатору на самом деле не сильно интересно, что внутри лежит. Когда транзитный коммутатор принимает такой кадр, ему фактически не нужно знать, что внутри. IPv4 или не IPv4.

Ему важно знать, есть там метка или нет. И он смотрит 8100, есть или нет. Если видит метку, говорит, окей, хорошо, этот кадр со флажком. Если не видит, то дальше обрабатывает его каким-то образом своим хитрым. Формат, как уже было сказано, у этого кадра фактически как у кадра с EtherType 8100. Это фактически получается хоть и новый кадр с содержимым и добавленным заголовком, но при этом он всё ещё остаётся практически валидным кадром Ethernet, если говорить, что он кадр в формате Ethernet 2. Единственная проблема, которая с ним может быть, это то, что если вдруг вы, например, возьмёте и в разрыв между двумя коммутаторами, которые отправляют друг другу такие модифицированные кадры, вставите третий коммутатор, который не поддерживает 802.1Q, то он такие кадры всё равно будет коммутировать. Ему-то как раз не сильно интересно, что там внутри лежит.

Он оперирует только MAC-адресами. И, соответственно, если он не пытается найти там 802.1Q-шную метку, он просто говорит, вижу какой-то кадр, пропускаю его дальше. Вижу новый кадр, просто пропускаю его дальше. Если он только не натолкнётся на кадр, который больше, чем максимальный размер, который он может пропустить, то есть как раз те самые 1522 байта, то, соответственно, он такие кадры всё равно будет коммутировать. С его точки зрения, кадры с метками, которые он всё равно не умеет читать, это просто нормальные кадры Ethernet. Поскольку кадр у нас по факту меняется, меняется его в кавычках содержимое, то портится frame check sequence оригинального кадра, но она выкидывается. Новая чек-сумма добавляется на тот момент, когда у нас есть метка. Пока кадр бежит по транку, доходит до соседнего получателя, соседний получатель метку выкидывает и восстанавливает исходную оригинальную чек-сумму. При этом он может быть уверен, что кадр не побился по дороге, потому что он всё равно, пока у него есть эта самая метка,

защищён чек-суммой, пусть и другой, пусть и временной. Если вдруг вам интересно, в этом самом поле Tag Control Information, двухбайтовом, 16-битном, есть следующие поля. 12-битное поле VLAN Identifier, собственно, сам номер VLAN. Не принято записывать нулевой VLAN, не принято туда записывать VLAN из всех единичек, то есть 4095. И всё остальное записывать можно. Дальше. Три бита приоритета. Чем больше, тем лучше, если руководствоваться рекомендациями 802.1p. Однако это именно рекомендации, конкретная реализация может эти метки трактовать по-своему. Если вдруг вы не уверены точно, что соседняя железка на эту метку ориентируется, нет смысла её заполнять никаким образом, потому что надо специально, активно заставить железку её обрабатывать, эту метку, чтобы она начала каким-то образом приоритизировать трафик.

Обрабатывают ли коммутаторы BabyJunt без какой-либо специальной настройки? Не факт. Всё зависит от конкретной реализации, но, как правило, тупые коммутаторы, которые не конфигурируемые, неуправляемые, обрабатывают такие BabyJunt без специальной настройки. Что касается, например, Cisco, Cisco не обрабатывает такие кадры, если вы просто вставляете Cisco в разрыв между двумя коммутаторами, которые отправляют друг другу такие BabyJunt. Если этот свитч, который просто в разрыв воткнулся, без каких-либо настроек, без ничего, он будет тогда такие BabyJunt дропать. Он будет считать, что это ошибка. Как правило, да, если у вас коммутатор управляемый, то он будет нервничать, если будет видеть кадры больше, чем 1518 байт, считая заголовки. Так, и последний битик, который здесь написан — canonical формат identifier,

это старое название этого поля. Дело в том, что когда-то давным-давно 802.1Q позволял инкапсулировать в себя не только Ethernet кадры, но и кадры, у которых был схожий заголовок, по крайней мере, там тоже были MAC-адреса. Это был протокол, который назывался TokenRing. И вы могли взять токен-ринговский кадр, у которого тоже были MAC-адреса, но, соответственно, другие, и упаковать его в 802.1Q. И, соответственно, там был destination address, source address, и дальше 802.1Q-шная метка. И чтобы показать, что MAC-адреса это не Ethernet-овские, а другие, у вас был этот флажок canonical формат identifier, который на самом деле указывал на то, что MAC-адрес не каноничный, если он был выставлен в единицу. Здесь неправильно написано, всегда ноль — в Ethernet он был, а если он единица, то это был TokenRing.

Поэтому иногда в литературе неправильно написано, что этот флаг назывался признак TokenRing. Да, он, конечно, был признаком TokenRing, но назывался он при этом canonical формат identifier. Если там был ноль, то MAC-адреса каноничные. Если это была единица, то это TokenRing-овский кадр, упакованный в формат Ethernet. Да, TokenRing в Ethernet, в CCNA больше нет, потому что его в принципе больше нет, он сдох, и слава богу, земля ему стекловатой, но, соответственно, поскольку его больше нет, то по факту в актуальной версии Ethernet это поле переименовали. Оно больше не означает, что в Ethernet вложен TokenRing. Актуальное название этого поля — Drop Eligible Identifier, DEI, и оно фактически расширяет поле приоритета, поэтому у вас теперь четыре бита для того, чтобы можно было поиграть приоритетом. Далее. В случае с цисками

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

с 802.1Q мы можем передавать кадры с метками. Соответственно, у нас есть свитч. На этом свитче у нас есть виланы, например, виланы айтишников и виланы HR. И мы говорим, что кадры айтишников передаются с меткой, кадры HR передаются с меткой. И мы говорим в этом случае, что у нас и виланы айтишников на этом порту, и виланы HR на этом порту будут tagged. То есть передаваться кадры на этом порту будут с метками. Этот tagged-untagged — это привязка именно к конкретному вилану, именно к конкретному порту. Просто вы говорите, кадр передаётся с меткой или без метки. На транковом порту, на котором у вас работает инкапсуляция 802.1Q, не ISL, не 802.10, а именно 802.1Q, ровно один, один-единственный вилан вы можете сказать, что он будет передаваться без метки. Фактически отсутствие метки своего рода тоже является меткой. Это прозрачная метка,

и вы не можете два вилана объявить такими прозрачными метками. Прозрачная метка всегда может быть только у одного вилана. Я попытаюсь как-то прозрачно нарисовать. Если её нет, вы указываете, что это тот самый вилан, который вы договорились передавать без метки. Стандартное в индустрии обозначение — такой вилан на таком порту будет называться untagged, и он может быть только один. У Cisco своя дорога, она называет такой вилан native вилан. Вы на транковом порту можете только один вилан объявить native или untagged. Почему нельзя два разных вилана объявить native или untagged? Потому что непонятно будет, когда вы отправляете один кадр без метки, с прозрачной меткой, и другой кадр с прозрачной меткой вы отправляете. И непонятно, какой кадр к какому вилану вы будете относить, если таких прозрачных виланов у вас два.

Так что только один вилан у вас должен быть без метки. Правило хорошего тона — делать так, чтобы у вас настройка и на одном конце транка, и на другом конце транка была одинаковая, чтобы native виланы или untaget виланы в транке совпадали. Что если вы на одном конце транка говорите, айтишники передаются без метки, то и с другой стороны все кадры, которые приходят без метки, они бы относились к вилану айтишников. Это теория про виланы.