VLAN в Ethernet

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

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

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

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

Это, естественно, проблема с недостаточной безопасностью. Потому что если у вас есть два узла, которые между собой трафиком обмениваться не должны, но по факту могут, то есть риск какой-то утечки данных. У меня был случай в очень далёкой моей практике, когда я ещё работал аникейщиком. Я работал в компании, и в этой компании было там компьютеров 15–20. И там было, естественно, несколько компьютеров в бухгалтерии, и все остальные компьютеры — это были просто обычные пользователи. Ещё был компьютер директора. И все эти компьютеры находились в одной большой плоской сетке. Она была на свитчах построена, все узлы находились в одном широковещательном домене. И, естественно, любой узел теоретически мог отправить кадр любому другому узлу. И в этом широковещательном домене, в этом VLAN, если хотите, работало обнаружение устройств. Можно было, например, открыть сетевое окружение,

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

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

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

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

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

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

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

Поэтому, конечно же, мы будем хотеть бороться с подобными проблемами. И мы будем желать минимизировать количество бродкастов, которые мы отправляем. Каким образом можно от всех этих проблем избавиться? Разделить сеть на сегменты. Мы говорим, что пользователи в разных частях сети будут принадлежать к разным широковещательным доменам, к разным сегментам. И, как следствие, они друг другу кадры отправлять не смогут. И в этом случае, если пользователь сидит в одной сети, то кто-то другой из другой сети, из другого сегмента, доступ к первому получить уже не сможет. Здесь возникает проблема, заключающаяся в том, что строить отдельную сеть из коммутаторов под каждый отдел, под каждый сегмент сети — это не очень здорово. Это дорого, это неудобно. Это неудобно обслуживать. Если мы хотим сегментировать сеть на отделы, именно на какие-то административные единицы, допустим, IT-отдел, HR-отдел, бухгалтерия и прочее,

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

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

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

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

Это важный момент: то, что приходит в модифицированном кадре, содержит некую рекомендацию — обрабатывай меня в таком-то VLAN, и Switch-получатель этой метке следует. Он доверяет этой метке, он читает эту метку, видит, в каком VLAN этот кадр следует обрабатывать, и обрабатывает кадр именно в этом VLAN. Эти самые указания, как именно, в каком именно VLAN обрабатывать кадр, можно встретить разных форматов. Это не какой-то единственный универсальный способ, как реализовать VLAN, как реализовать транковые порты. Их много. В индустрии чаще всего в современном мире пользуются одним, который называется 802.1Q. Но есть и другие. Во-первых, есть фирменный цисковский ISL, который, наверное, исторически самый первый появился, потому что сама идея коммутаторов была придумана в своё время компанией Kalpana, и потом Kalpana же придумала механизм VLAN.

И ISL — это как раз механизм в оригинале калпановский. Но это протокол проприетарный, фирменный. После того, как Cisco его автора выкупила, она начала называть его своим именем — Cisco ISL. И больше других вендоров, которые с этим форматом работали, особо и не было. Кроме Cisco никто этот протокол не продвигал. У этого протокола в своё время были определённые преимущества. Во-первых, по сравнению с ничем другим, потому что в своё время он был единственным протоколом, который такую функцию реализовал. По сравнению с просто обычным Ethernet он позволял в одном проводе мультиплексировать трафик нескольких разных широковещательных доменов. До Cisco, до Kalpana этого вообще никто не делал. Затем он позволял инкапсулировать в один линк, помимо разных широковещательных доменов Ethernet, ещё и трафик Token Ring.

И это было очень круто. Token Ring и FDDI можно было в ISL засунуть. И на тот момент, когда это всё появилось, это было прямо вау, это была крутая фича. В заголовке ISL вы могли указывать номер VLAN. У вас все VLAN были пронумерованы. Номера, которые можно было там использовать, были 15-битовые, но по факту использовать можно было только первую тысячу. 15 бит, в принципе, даёт 32 тысячи разных значений, но использовать можно было только первую тысячу. Номера с 1002 по 1005 были зарезервированы как раз за инкапсуляцией Token Ring в Ethernet, в этот самый ISL-овский. А всё остальное было просто недоступно. При этом, когда вы хотели отправить какой-нибудь кадр — что Ethernet, что Token Ring — в ISL-овский транк, вы должны были обернуть этот кадр вместе со всем заголовком, вместе с содержимым и вместе с чек-суммой, что интересно, в новый кадр.

Натурально брали весь кадр целиком вместе с чек-суммой и оборачивали новым заголовком, новой чек-суммой, и у вас получалось, что кадр, содержащий в себе то, что вы хотели по транку передать, становится больше на 30 байт. 26 байт заголовка и 4 байта новая чек-сумма. Старая при этом тоже остаётся, но она идёт перед новой. Фактически формат ISL-овского кадра совпадает с оригинальным Ethernet. Можно сказать, что очень похоже на Ethernet, но только кадры на 30 байт больше. Так что гипотетически, если вдруг вы отправите ISL-овский кадр свитчу, который ISL не поддерживает, то свитч такой кадр прокоммутировать сможет. Это будут фактически как мультикастовые кадры, которые идут между двумя свитчами. Если вдруг где-то там транзитный свитч будет, который не умеет ISL, он такие кадры прокоммутирует.

Но ISL сегодня использовать смысла никакого особого нет. 26 байт заголовка, 4 байта чек-суммы дополнительные к оригинальному вложению не дают никаких преимуществ по сравнению с протоколом 802.1Q, который работает следующим образом. Вы берёте кадр, который вы хотите передать, и затем добавляете в него не новый заголовок, а новое поле в заголовок. На том месте, где у нормальных кадров будет лежать EtherType или длина, вы добавляете новые 4 байта и туда вкладываете самую разную информацию, которую только можно там положить. Понятно, в 4 байта сильно много всего не положишь, но кое-что положить можно. И 802.1Q делает ровно то же самое, что ISL. Он умеет вкладывать в Ethernet VLAN и Token Ring. Он может быть прокоммутирован транзитными свитчами, которые 802.1Q не поддерживают, но при этом он намного экономнее.

У него overhead 4 байта — это по сравнению с 30 байтами довольно заметная экономия. Был ещё один вариант, как можно взять и в один провод инкапсулировать трафик разных широковещательных доменов. Это был протокол, точнее, инициатива 802.10. Вы могли с использованием определённых механизмов и создать разные VLAN-ы, и зашифровать кадр, и ещё разные другие штуки сделать. Комитет 802.10 пытался понять, каким образом можно модифицировать стандартные кадры Ethernet, чтобы получить всякие разные преимущества и плюшки. Но комитет этот проработал некоторое время, выдвинул ряд инициатив, и после этого, когда эти инициативы не были поддержаны вендорами, тихо сдулся. Поэтому по факту 802.10 транков вы сегодня встретить не сможете. Дальше. Когда у нас есть кадр 802.1Q-шный, мы добавляем между полем MAC-адреса отправителя и тем, что следует после него, дополнительные 4 байта.

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

В 802.1Q это решается с использованием заголовка, который идёт после MAC-адреса отправителя. Первые 2 байта, которые там будут передаваться, — это 0x8100. Они лежат на том месте, где у нормальных кадров Ethernet 2 лежало поле EtherType. И следующие 2 байта — это Tag Control Information, некая служебная информация, которая среди прочего содержит и номер VLAN. Если говорить про 802.1Q, то номер VLAN в 802.1Q будет 12-битовый. Мы их сможем создать 4096 штук. Номер VLAN, состоящий целиком из нулей и из единичек, использовать не принято, поэтому остаются 4094 штуки. И всё остальное, что дальше идёт после этого заголовка, — это оригинальный кадр. У нас сюда вклиниваются 4 байта. Всё, что после MAC-адреса отправителя шло, в модифицированном кадре идёт после этого дополнительного заголовка. И поскольку содержимое кадра у нас изменяется, чек-сумма, естественно, портится.

Поэтому старая чек-сумма выкидывается, а новая добавляется. У таких кадров 802.1Q, естественно, максимальный размер может гипотетически вырасти до значений, которые стандартом считаются неприемлемыми. В нормальном обычном кадре Ethernet может быть поле с данными до 1500 байт размером. 1500 байт поле с данными, плюс 2 байта EtherType, плюс 6 байт MAC-адреса отправителя, плюс 6 байт MAC-адреса получателя, плюс 4 байта чек-суммы — даёт нам максимальный размер нормального немодифицированного кадра 1518 байт. Если вы к кадру максимального размера добавляете ещё 4 байта, то максимальный размер кадра внутри транка вырастает до 1522 байт. Это само собой разумеется, что это так. Дальше. Фактически можно сказать, что кадры, после того как вы модифицируете их, всё ещё остаются кадрами Ethernet. При изменении кадра вы следите за тем, чтобы формат этого кадра всё ещё оставался соответствующим требованиям стандарта.

Поэтому, если вдруг вы добавите внутрь линка между двумя свитчами третий коммутатор, который 802.1Q не поддерживает, он такие кадры прокоммутировать сможет. Это не очень хорошая практика, но обычно это всё работает без проблем. Если только, естественно, не возникнут проблемы с MTU, которые помешают транзитному коммутатору без поддержки 802.1Q такие кадры-переростки обрабатывать. В то же время, почему такое будет возможно? Именно потому, что транзитному коммутатору неинтересно содержимое кадра. Ему интересны MAC-адрес отправителя, MAC-адрес получателя. Всё, что внутри лежит, ему неинтересно. В частности, ему неинтересен EtherType. Соответственно, обычный абонент, когда получает кадр, ожидает в поле EtherType увидеть что-то предсказуемое.

Поэтому, если вдруг обычный абонент получит кадр с EtherType 0x8100, он, скорее всего, не поймёт, что вы ему такое прислали. И ещё один момент заключается вот в чём. Если вы меняете содержимое кадра, то у вас портится чек-сумма. Вы, добавляя метку, старую оригинальную чек-сумму кадра выкидываете, новую добавляете. Метка с указанием номера VLAN, по которому получатель должен коммутировать трафик, добавляется в момент отправки кадра через интерфейс. Она добавляется для указания того, что получатель должен обрабатывать этот кадр по определённой схеме, по определённой таблице. Когда получатель такой кадр принимает, он удаляет эту метку. Иногда не совсем корректно говорят, что метка всё время присутствует, пока мы кадр обрабатываем. Нет. Отдельно у каждого кадра, который мы обрабатываем, есть так называемое свойство VLAN ID.

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

следует обрабатывать этот кадр, и мы восстанавливаем оригинальную чек-сумму. В 16-бит поле Tag Control Information мы можем вписать целую кучу самой разной служебной информации. Самое первое поле — трехбитовое поле, которое называется Priority. Это поле для указания важности вашего кадра в формате 802.1p. Если вы сейчас думаете, какой клёвый механизм, надо срочно им воспользоваться, то нет, вы не можете им просто так воспользоваться, потому что вы написать-то можете рекомендуемый приоритет для вашего кадра, только до тех пор, пока транзитные коммутаторы, которые будут ваш кадр обрабатывать, не будут проинструктированы, на это поле обращать внимание, вы можете писать туда всё, что угодно. Вы можете написать туда число от 0 до 7, и вы можете написать хоть 0, хоть 7, хоть что угодно, но всё равно транзитные коммутаторы, до тех пор, пока не получат инструкцию,

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

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

Но мы можем сказать, что если мы хотим распорядиться каким-то ограниченным ресурсом, то мы можем сказать, что в первую очередь должны обрабатываться кадры с одним приоритетом, а потом, если останется какая-то полоса, мы обрабатываем кадры с другим приоритетом, а потом, если останется какая-то полоса, мы обрабатываем кадры с третьим приоритетом. И если вы настроили свои коммутаторы в определённой логике, настроили своё терминальное оборудование для того, чтобы оно корректно проставляло эти метки, то в этом случае вы можете добиться, например, эффекта, что в случае перегрузки, когда у вас есть 48-портовый свитч с четырьмя аплинками, и все порты гигабитные, и все порты на 100% нагрузке лежат, такого поведения, что голосовые кадры, например, вообще никогда не дропаются. Для них всегда есть ресурс, который не обязательно будет доступен для других кадров. И это можно получить как раз с использованием поля Priority. Вы можете указать, к какому типу трафика будет относиться ваш кадр.

И этих типов трафика можно сделать аж целых 8 штук. Дальше. Ещё один битик называется Canonical Format Identifier. В актуальных версиях его поменяли, он теперь называется Discard Eligible Identifier. Он всегда 0 в Ethernet. И он указывает на то, правильные ли MAC-адреса у вас в этом кадре указаны. Фишка заключается вот в чём. Когда трафик приходит от абонентов, вы его коммутируете. Возможно, вы его коммутируете в транковые порты. В этом случае вы добавляете заголовок 802.1Q. Если вы хотите, вы можете заставить 802.1Q-шный транк нести также кадры токен-ринга, например. В токен-ринговских кадрах тоже есть MAC-адреса. И может быть такое, что у вас некоторые кадры пойдут по транку Ethernet-овские, а некоторые кадры — токен-ринговские. Когда вы будете отправлять Ethernet-овские кадры,

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

Canonical Format Identifier указывает на то, можно ли такие MAC-и лёрнить или нет. Нолик означает, что это Ethernet-овские MAC-и, и лёрнить их можно. Единичка означает, что это MAC-и кривые, например, токен-ринговские, и лёрнить их нельзя. И последнее — это VLAN Identifier, 12 бит, это просто номер вилана. Номер 0 и номер 4095 зарезервированы за служебными задачами 802.1Q. Всё остальное можно использовать. В актуальных версиях Ethernet-а Canonical Format Identifier переименован. Дело в том, что токен-ринга в современных сетях вы уже не увидите никогда и ни за что. Поэтому это поле указывает теперь на возможность управления трафиком в случае перегрузки канала. Как у нас Priority указывает 8 разных типов трафика для указания того, что можем сделать трафик одного класса, трафик другого класса,

можем указать, что у нас есть отдельный голосовой трафик, отдельно видеонаблюдение, отдельно что-нибудь ещё. Но Priority устроен таким образом, что вы можете туда вкладывать совершенно произвольные значения, какие захотите. Можете сказать, что класс номер 0 — это, например, класс для телефонии. Класс номер 1 — это класс для мусорного трафика. Класс номер 2 — это класс для видеоконференц-связи. Никоим образом нет стандартного использования этих видов 802.1p. Есть рекомендованные значения. Чем меньше, тем более важный класс. Но это поведение не совсем предсказуемое получается. Если ваш свитч видит какой-то класс трафика, он не всегда может понять, что с этим классом делать. Discard Eligible Identifier, переименованное поле Canonical Format Identifier, указывает на следующее. Если мы видим Ethernet-кадры, которые просто обычные нормальные кадры, отправленные каким-то узлом, который не знает про то, что поле Canonical Format Identifier переименовали,

он будет указывать, что это просто обычные нормальные кадры Ethernet, он будет проставлять нолик. И в этом случае он не хочет нам сказать ничего специального. Он говорит, что просто отправляет кадры Ethernet, не токен-ринг. В такой ситуации мы не предпринимаем никаких специальных действий. Но если мы в 2019 году видим кадр, у которого отправитель в транковый порт отправил кадр с Canonical Format Identifier единичку, мы понимаем, что единичку он отправил не потому, что он отправил токен-ринг, потому что нету токен-ринга, а потому что он отправил кадр со специальным значением. И этот кадр со специальным значением, Discard Eligible Identifier, выставленный в единичку, будет означать, что этот кадр содержит информацию, которую можно пожертвовать. В случае, если у нас возникает перегрузка, мы можем явно указать, что этот кадр не очень нужный, что в нём содержится информация, которую можно потерять относительно легко, безболезненно.

Если такие кадры потеряются, ничего страшного не произойдёт. Зачем такое самопожертвование нужно? Затем, чтобы другие кадры у вас с большей вероятностью прошли через ваш канал. Другие кадры не помечены готовностью к самопожертвованию, и это означает, что они, возможно, не могут быть потеряны. Понятное дело, что можно настроить полноценный quality of service, можно настроить эти три бита приоритетов, можно прописать, что кадры такого формата теряются так, кадры другого — эдак. Но это просто отдельный битик, который имеет предсказуемое значение: нолик — просто нормальные кадры, единичка — кадры, которые можно потерять. В случае, если у нас возникает перегрузка, если нам надо через гигабитный интерфейс пропустить 2 гигабита трафика, в первую очередь будут отбрасываться кадры, которые отправитель посчитал возможным пожертвовать штатно. Это поведение стандартное, и оно не зависит от приоритетов, которые там проставляются.

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

передаётся только один вилан, и этот вилан будет untagged, и тогда такой порт визуально совершенно никак не будет отличаться от untagged VLAN на абонентском порту. Зачастую на оборудовании других вендоров просто нет такого термина, как access port или trunk port. Есть просто все порты, на которых можно сказать, что у нас есть один untagged VLAN и некоторое количество tagged VLAN. Если у нас tagged VLAN на порту вообще нет, то это access port. Если tagged VLAN на порту появляются, то это по сути транк. Tagged VLAN на порту. Важно то, что untagged VLAN на каждом порту может быть только один. И если вы отправляете кадры этого вилана на порту, они отправляются без метки. И кадры, которые на этом порту приходят без метки, они отправляются в таблицу определённого untagged VLAN. Если говорить про Cisco, то этот единственный VLAN, который вы помечаете как untagged на транковом порту, будет называться специальным словом —

native VLAN. Он по определению всего один. Это тот самый VLAN, который отправляется и принимается без метки на транковом порту.