VLAN (часть 1)

Так, мы постепенно начинаем мясо. И это мясо будет касаться именно уже процедуры коммутации. Все, что мы сейчас обсуждали, оно было так или иначе связано с просто всякими клевыми штуками, которые встречаются в коммутируемых сетях. Но нигде слово коммутация у нас особо не всплывало, потому что, ну да, есть CF, есть TK, ну и фиг с ними. Есть всякие по E, есть там, что у нас еще на свечах бывает, да? Ну, какие-то просто фичи самих свечей. А вот процедура коммутации, она все-таки уже имеет отношение напрямую к нашему курсу. И мы сейчас будем повторять то, что мы проходили на ICND1 и немножко на ICND2. Давайте вспоминать. Сначала, когда Ethernet появился, никаких коммутаторов, никакой процедуры коммутации не было. Ethernet в оригинале это протокол связи для узлов, которые находятся рядом друг с другом, и они все соединены одним большим проводом.

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

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

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

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

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

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

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

И, соответственно, получится сделать так, чтобы у нас некоторые провода могли перекладывать кадры между собой, и некоторые другие провода могли перекладывать кадры между собой, а вот между ними кадры бы не перекладывались. Это дальнейшее развитие идеологии вообще появления коммутаторов. Когда коммутаторы появились, они сначала перекладывали кадры только в одном широковещательном домене. Но в 93-м году появляется компания… Сейчас скажу, как называлась. И компанию Calpana, и компанию Crescendo, которая придумала VLAN, потом купила Cisco, поэтому в итоге это все технологии, которые мы сегодня знаем как Cisco. И сами свечи, 1989 год Calpana и Crescendo, это 1993 год, все куплено в итоге Cisco. И Cisco свечи Catalyst, мы сегодня знаем, как они, как то, что Cisco свечи, на самом деле это не Cisco, на самом деле это другая компания, которая Cisco купила вместе с их свечами, вместе с их протоколами. И вот они эту идею расширили, что у нас не один виртуальный провод, а несколько разных виртуальных проводов, и кадры из разных физических проводов коммутируются по каким-то разным соображениям, разным таблицам.

Технология получила название VLAN, виртуальная локальная сеть. По большому счету, любой коммутатор у вас будет работать с VLAN, с виртуальной локальной сетью. Вот просто у вас есть коммутатор, который объединяет несколько физических проводов в один виртуальный широкопрещательный домен, это уже VLAN, просто один. Но если у вас несколько этих виртуальных широкопрещательных доменов, то вот мы говорим, у нас тогда будет некоторое количество VLAN, может быть один, может быть два, может быть десять, может быть сто. И фактически, да, это просто расширение идеи перекладывания кадров между проводами по каким-то простым критериям. Если мы говорим про Cisco свечи, то Cisco свечи будут работать с VLAN, пронумерованными от 1 до 4094. Это 2 в 12 степени минус 1. И вы в каждом виртуальном широкопрещательном домене будете иметь свою отдельную таблицу. Ну, она привычно называется таблица коммутации, вообще она, конечно, таблица фильтрации.

Вот это вот самое FDB. FDB будет отдельная своя для каждого широкопрещательного домена, для каждого VLAN. Обычно на железке поддерживается меньшее количество этих самых таблиц. То есть вы не можете сказать, давайте мы сделаем все 4094 таблицы на одном свече. Просто у вас, опять же, не хватит памяти под это дело. И даже 4000 не сможете сделать, и 2000 не сможете сделать. Как правило, максимально поддерживаемое количество, оно будет сильно меньше. Будет зависеть от конкретной платформы. Если говорить про, например, 2960 или железки, то там, как правило, можно сделать 64 виртуальных коммутаторов, виртуальных вот этих вот таблиц FDB. И тем самым, соответственно, вот создать 64 VLAN. Когда мы на коммутаторе, который поддерживает VLAN, указываем, что кадры, которые приходят на наш свеч, относятся к разным VLAN. Мы должны будем сказать, что у нас у каждого, в кавычках, VLAN есть своя таблица коммутации.

И, соответственно, мы должны будем создать эти самые виртуальные таблицы коммутации, чтобы потом кадры на них направлять. Если вы заранее не создадите соответствующую таблицу коммутации, соответствующий, ну, назовем это виртуальный коммутатор, то кадры этого VLAN обрабатываться не смогут. Мне очень нравится идея представлять физический свеч как гипервизор, на котором крутятся виртуальные машины. И, соответственно, у вас есть гипервизор, на нем вы создаете виртуалки, в этих виртуалок не можете создать, сколько влезет, потому что у вас ресурсов не хватит. Но даже если создадите, вы запустить их одновременно не сможете. Ну, то есть на гипервизоре у вас может быть 10, 20, 30, 50 виртуалок, но не 4000. И, соответственно, у вас эти самые виртуалки создаются, работают, и когда приходит какой-то конкретный кадр, мы его можем направить на обработку каждой конкретной виртуальной машины. Но мы должны будем явно в виде определить, что кадр пришел, и его надо отправить именно на 17-ю виртуальную машину, а не на какую-нибудь еще.

Если вы получаете какой-то кадр, и в нем по каким-то критериям вы понимаете, что надо его обработать именно с помощью виртуальной машины номер 17, а виртуалку такую вы не сделали, то есть у вас нет такой виртуальной машины, но по каким-то критериям вы понимаете, что должна его обрабатывать именно 17-я виртуальная машина, ну, значит, вы ничего не сделаете, потому что надо обработать 17-й, а 17-й нет. Значит, выкидываем его. В CISC посмотреть список VLAN, список созданных виртуальных таблиц коммутации можно с помощью команды showvlanbrief Ну или showvlan просто, а brief это просто укорачивает ее вывод, потому что showvlan показывает много всякого ненужного барахла Показывается колонка VLAN, показывается имя VLAN Очень рекомендую вам задавать имена, потому что когда у вас большая сеть, никогда не строите большие L2-сети Но если у вас большая зарнета сеть, много коммутаторов, то рано или поздно вы запутаетесь, где какой VLAN вы создали и зачем

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

Попадаете в субконтекст настройки VLAN Дальше внутри этого контекста вы можете делать какие-то действия Можете дать название, можете включить, выключить Изменить тип VLAN и после чего команда exit выходите из режима настройки VLAN Учитывая, что концепцию VLAN CISCO купила у компании Crescendo вместе со свитчами Catalyst До сих пор можно будет увидеть следы той самой платформы Crescendo Это файлик VLAN.dat, в котором хранятся все VLAN И для того, чтобы не слишком часто уродовать флешку, на которой лежит этот файлик По факту изменения в этом файлике применяются только тогда, когда вы выходите из контекста настройки VLAN То есть, если вы заходите в него команды VLAN 10 Вот в самом файлике VLAN.dat новый VLAN не создается И, соответственно, если вы даете какие-то изменения Переименовываете VLAN или что-то еще Эти изменения не сбрасываются на диск и не применяются до тех пор, пока вы не выйдете из режима редактирования 10 VLAN

Если вы выходите командой exit или переходите в контекст редактирования другого VLAN То ваш VLAN, в котором вы находились, сбрасывается на диск И, начиная с этого момента, изменения по факту применяются Вот Здесь видно, что мы добавили 10 VLAN, никак его не именовали И он у нас действительно применился, что VLAN-бриф показывает, что добавилась новая строчка VLAN 0010 Четырехзначный номер VLAN, который справа приклеен к слову VLAN Учитывая, что номера четырехзначные В смысле, с единицы по 4094 Ну, то есть, вполне этих четырех цифр всегда будет заведомо хватать Ну и никакие порты в него автоматом не добавляются Нацистские номера VLAN в 1002, 1003, 1004 и 1005 Зарезервированы под нужды инкапсуляции в 802.1Q кадров токен ринга и в DDI Соответственно, вы эти номера VLAN использовать не можете Потому что, если где-нибудь у вас в сети возникнет свитч, который инкапсулирует такие токен ринг в Ethernet, в 802.1Q

То, соответственно, вы должны будете эти номера использовать, потому что они жестко прибиты гвоздями На старых железках вы не могли их поменять И на новых железках вы тоже не можете их поменять Именно в целях совместимости со старым железом Что если вдруг где-то у вас появляются кадры 1002 VLAN Это всегда гарантированно FDDI, утопленный в Ethernet В нормальной ситуации вы номера такие использовать сами не можете никак То есть, вы не можете обратиться к этим VLAN, вы не можете выключить эти VLAN Они просто зарезервированы и всегда есть Первый VLAN тоже всегда зарезервирован, тоже всегда есть Вы тоже не можете ничего с ним сделать, не можете выключить, не можете переименовать Все остальное вы можете переименовать, но есть ограничения Без дополнительных костылей, связанных с протоколом VTP Вы можете работать только с первой тысячи VLAN С второго по тысяче первой То есть, эти VLAN можно переименовывать, можно добавлять, можно удалять Делать с ними все, что угодно Номера с тысячи шестого и выше вы можете использовать только при соблюдении определенных условий

Когда будем говорить про VTP, там это дело обсудим С каждым VLAN можно будет делать всякие разные вещи Можно его удалить Командой noVLAN10, например, удалить десятый VLAN Можно его переименовать Вот у нас здесь, например, мы заходим в контекст редактирования 20-го VLAN И переименовываем его, даем ему имя accounting Или можно так называемый локально выключить обработку этого VLAN Пример с виртуальными машинами как раз показывает, что это такое Виртуальную машину вы можете взять и выключить Она у вас как бы есть, место на диске занимает Но при этом она не работает и трафика не обслуживает Поэтому вот он, если вы скажете shutdown В конфигурации VLAN останется Но трафик этого VLAN через вашу железку ходить не будет Если вы закажете show VLAN brief То вот такие выключенные VLAN будут показываться active slash lshot lshot это locally shutdown То есть вы его на именно этой железке выключили

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

Либо вы можете сказать, что все, что приходит на определенном порту Независимо от того, что там было написано Будет относиться к определенному VLAN Оба подхода, в принципе, существуют Но чаще всего применяется второй вариант Когда вы просто говорите, что все, что приходит на порту Все относится к VLAN, допустим, 17 Это просто, это быстро, это удобно и это надежно На некоторых свечах вы можете использовать фичу, которая называется Cisco Dynamic VLAN Это очень старая вещь, то есть на новых свечах ее нету А да, есть на свечах под управлением операционной системы KTOS Это предшественник Cisco EOS для каталистовских свечей То есть 6-тонники, 4-тонники Вот там на KTOS вы могли включить фичу, которая называлась Membership Policy Server, VMPS И, соответственно, этот сервер хранил в себе привязки Привязки маков к VLAN Если трафик приходил, кадр приходил из-под какого-то конкретного мака

То вот этот самый VMPS сервер раздавал на свечи базы Какой мак в каком VLAN сидит И кадры, которые приходили на порту Вот они анализировались на то, какой мак там пришел И, соответственно, VLAN назначались по мак-адресам Вот, кадры приходили самые обычные Но вы смотрели, от кого они пришли И внутри себя понимали Ага, этот кадр пришел от Пети Он будет в VLAN 12 Этот кадр пришел от Сережи Он будет в VLAN 15 Понятное дело, что это зло Потому что мак-адрес от правителя Менять можно как нечего делать Когда-то давным-давно это было не очень актуально Потому что, во-первых, это было физически сложно сделать А во-вторых, ну просто вопросы безопасности так остро не стояли Но как только вопросы безопасности, да, стали вставать всерьез Эту фичу перестали использовать вообще Поэтому сейчас она осталась только в экзаменах ЦИСКе Что когда-то давным-давно существовала такая вещь По факту в 100% случаев в современных сетях Мак-адреса у вас не могут быть надежным источником информации о том, кто это пришел

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

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

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

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

Я сейчас сознательно не использую слово метка, но вот измененный формат, мы говорим, что у нас есть какие-то кадры, которые передаются по проводу. Они могут быть нормальные кадры, которые приходят от абонентов, или видоизмененные кадры, которые передаются с указанием номера вилана. Вот это вот вы можете взять и посмотреть в Airshark, например. То есть взять, запустить снифер и посмотреть, что там кадры передаются. У них действительно есть что-то, что их отличает от обычных нормальных кадров. Кадры, которые передаются вот здесь и которые передаются вот здесь – это разные форматы кадров сами по себе. И в этих кадрах, вот в этих вот кадрах, есть действительно что-то новенькое. В этом чем-то новеньком написан номер вилана. И второй момент – то, что мы получаем какие-то кадры по любому проводу, неважно какому. Мы получаем их по абонентскому проводу или по проводу между двумя свитчами. Мы принимаем эти кадры, неважно какого формата они будут, мы этот кадр относим к одному или другому вилану. То есть в случае, если это абонентский порт, мы это делаем, как правило, по самому порту.

Мы говорим – все, что на порту пришло, все относится к одному и тому же вилану. Если мы говорим, что этот кадр приходит модифицированный с указанием номера вилана, мы говорим – окей, мы верим тому, что там написано, и мы кадр относим к 224-му Вилану, потому что в нем написано, что он передается в 224-му Вилане, и мы этому верим. То есть, понимаете, да? Одно из этих явлений – это то, что внутри в самом кадре написано, а другое из этих явлений – это то, что Switch воспринимает этот кадр как относящийся к одному или другому Вилану. Я сейчас сознательно не использую термин «метка». Связано это с тем, что в русскоязычной литературе один и тот же термин «метка» используется для обозначения обоих этих механизмов. И то, к какому Вилану коммутатор относят кадры, и то, что написано внутри заголовков, передающихся по сети кадров. Поэтому давайте постараемся не использовать термин «метка» в ближайшее время, а потом вы просто сами будете понимать, какую конкретную метку имеет в виду собеседник,

если вдруг он будет вам говорить про какую-то метку. Скорее всего, с очень большой вероятностью, он будет говорить про метку, которая вот здесь передается. Так, дальше. Обещал не использовать слово «метка», но ладно. Не читайте здесь. Если у нас есть какие-то кадры, и мы должны в них добавить указания про то, в каком Вилане они передаются. То есть, есть у нас кадр, который пришел от абонента, это просто обычный Ethernet кадр, там никакого поля с Виланами нету. Но нам нужно, если мы передаем этот кадр соседнему свечу, добавить указания про номер Вилана. Вот есть несколько способов добавить информацию про Вилан в кадр. Первый вариант – это Cisco ESL, InterSwitchLink. Это вы берете кадр, который пришел от абонента, и заворачиваете его в новый заголовок. Вот. У вас получается новый кадр, у него новый заголовок, у него новый трейлер.

У каждого кадра Ethernet есть, соответственно, вложение заголовок и чек-сума. То есть, вот у оригинального кадра заголовок и чек-сума. И у нового кадра новый заголовок и новая чек-сума. И, соответственно, заголовок новый будет 26 байт, а чек-сума будет 4 байта. Ну, чек-сума там обычная Ethernet. Вот. И, соответственно, в заголовке там нужно будет посмотреть на содержимое этого заголовка. Он очень будет похож на Ethernet. Там внутри будет первый 6 байт, очень похожий на мультикастовый MAC-адрес получателя. Дальше следующий 6 байт – это MAC-адрес источника, это MAC-адрес того свеча, который отправил такой кадр. Ну, и, соответственно, дальше там всякое разное вложение идет с указанием на то, чего внутри передается, какого оно характера и все остальное. И, среди прочего, там будет 15-битовый номер Вилана. Из этих 15 бит вы по факту можете сделать 32 768 разных Виланов. Но договорились не использовать такое количество Виланов, договорились использовать первую тысячу.

То есть, с единицы по тысяча пятой. Последние четыре из них отведены под нужды инкапсуляции FDDI и токен ринга. Поэтому, по факту, вам доступны будут с первого по тысяча первой Виланы под свои собственные нужды. По факту, поле с номером Виланы 15-битное. Но из этих 15 бит, да, вы меньше 10 бит можете использовать. Дальше. Понятное дело, что в случае с инкапсуляцией ASL у вас большой overhead, то есть большие накладные расходы, потому что каждый кадр увеличивается на 30 байт. Ну и получается, что кадры, которые вы могли отправлять, у них до 1500 байт вложения, плюс 18 байт заголовки и чек-сумма. Вот, это оригинальный кадр, который мог отправить отправитель. И плюс к этому еще 30 байт дополнительных накладных расходов. То есть, получалось, что такие кадры могли быть до 1548 байт общим размером. Это много. То есть, по сравнению с нагрузкой в 1500 байт, 50 байт накладных расходов, ну, прям, скажем, дофига.

Плюс к этому надо еще прибавить интерфрейм спейс, плюс там еще преамбула. Ну, короче, да, то есть, ASL стандарт не очень заботился о сохранении полосы пропускания. Ну и он, естественно, был фирменный и проритарный. Cisco пыталась его продавать другим вендорам, но те как-то не очень возбудились и не стали его покупать. Поэтому этот стандарт сегодня, в общем-то, на 99% мертв. Некоторые Cisco его по-прежнему еще поддерживают. Они стараются согласовать этот интерсвичлинг между собой. Если вдруг вы говорите, давайте две Cisco, согласуйте между собой какой-нибудь стандарт автоматом. И вот многие железки все еще поддерживают его и даже пытаются выбрать по умолчанию. Но самые новые устройства уже ASL не поддерживают. Если вы там те же Nexus возьмете, там уже никакого ASL не будет. Дальше. Другой мертвый стандарт – это 802.10. Вообще он говорил про то, что если вы берете какой-то кадр, в него можно добавить информацию о номере Вилана.

Но вообще это был стандарт про то, как зашифровать кадр. И вот если бы он в свое время продвинулся как-то вперед, то, возможно, мы бы использовали его. Но стандарт этот официально признали мертвым. И поэтому сегодня мы его нигде вообще не увидим. От него есть кое-какие следы в наших эмуляторах. Но сказать, что надо использовать этот стандарт для того, чтобы пересылать кадры в этом формате, мы уже не можем. Поэтому, да, все, приехали. Ну и тот стандарт, который сегодня используется – 802.1Q. Произносится как 802.1Q. 802.1Q. То есть вот этот вот dot1Q. Это вот как раз оно и есть – 802.1Q. Эта штука добавляет новое поле в заголовок. Добавляет новое поле 4-байтовое. Поэтому overhead там достаточно маленький. И, в общем, это единственный способ сегодня по факту передавать информацию о том, в каком Вилане кадр должен трактоваться с соседом-получателем. Формат этих кадров будет очень простой.

Если вы помните, у нас есть оригинальные кадры из Rnet 2. И когда у нас какой-то отправитель отправляет какой-то кадр, он посылает сначала преамбулу нолики-единички. Потом MAC-адрес получателя. Потом MAC-адрес источника. Потом, что внутри лежит или длину. Здесь нам не важно, что это будет. То есть мы в любой трактовке можем добавить метку 802.1Q к этому кадру. То есть если даже он думал, что здесь вот длина, значит от данных дальше будет откушено какое-то количество бит под заголовки LCSNAP. И дальше идут полезные данные. Сразу после EtherType. Минимум этих данных 46 байт для того, чтобы соблюсти ограничение на минимальный размер кадра, включая получателя-отправителя и чек-суму в 64 байта. Ну и соответственно максимум 1500 байт это просто случайно выбранное значение, при котором чек-суму CRC32 дает нам хорошие варианты при соблюдении определенного качества работы сети BitRowRate.

1500 байт, максимальный размер кадра, дает нам очень большую вероятность обнаружить ошибку в случае, если она произойдет. Причем не одну ошибку, а несколько ошибок, которые возможно случатся в одном и том же кадре. Вот это вот 1500 байт выбрано таким образом, чтобы обнаружить в одном кадре до трех ошибок. Если вдруг у нас случится три изменения отдельных битов, то CRC32 соответственно этот момент пропалит и скажет, что у нас такое произошло. Четыре уже не пропалит, но три даже неплохо. Дальше. Мы можем сказать, что если мы хотим добавить 802.1 киевшный заголовок, мы можем добавить его после MAC адреса отправителя. То есть мы говорим, вот мы эту часть отрезаем, делаем ее вот здесь. Дальше. Вот эту часть мы берем и ставим ее вот здесь. А в разрыве между ними мы вставляем... Ой, пардон, неправильно нарисовал. Вот она будет вот такая вот.

И в разрыве мы вставляем 4-байтовое поле 802.1 киев. В этом поле будет три подполя. Первое поле 2-байтовое, которое называется Tag Protocol Identifier. И там принято вписывать 8100. 8100. Фактически получается, что у вас кадр, который изначально был, он добавляется в него, вот это вот самое 4-байтовое поле. И это 4-байтовое поле добавляется на то место, где у нормальных кадров первые 2 байта это EtherType, и дальше следующие 2 байта это кусочек с данными. То есть можно взять и протрактовать полученный кадр как кадр обычный нормальный Ethernet, у которого просто EtherType 8100. Вот. Если коммутатор принимает какой-то кадр на порту, и он согласен читать 802.1 киевшные метки, он у каждого кадра проверяет вот этот вот самый EtherType. Если он там видит 8100, он говорит, я вижу, что это кадр с 802.1 киевшной меткой. Если он берет EtherType, пытается читать и видит там что-то другое, он говорит, это оригинальный кадр, который я должен протруковать как-то иначе, то есть не пытаться читать вот эти вот самые 4-байта.

Дальше. Tag Control Information. Это вот здесь вот 2 байта, там будет 2 подполя. Это будет... Сейчас, на следующем слайде нету. Есть. Давайте тогда чуть попозже расскажу. Потом идет оригинальный EtherType, который все равно никто уже не читает. Транзитному коммутатору, в принципе, вот то, что здесь лежит, неинтересно. Он проверяет то, что вот здесь лежит, то есть на самом деле это одно и то же поле, но он смотрит, не 81 или 00 там. Если там не 81 00, то что вот здесь вот лежало, 0800, к примеру, IPv4, и уезжает оно направо. В принципе, это уже неинтересно. Транзитному коммутатору важно, чтобы вот здесь не было 81 00 или чтобы оно там было. После чего у нас выясняется, что когда мы добавили вот эти вот 4-байта, у нас испортилась оригинальная чек-сума, поэтому стандарчик суммы выбрасывается, новый добавляется. Ну и получается, да, что кадр такой увеличивается в размере на 4-байта.

Вы не должны будете, если вы работаете с цисками, увеличивать МТУ на интерфейсах или увеличивать систему МТУ, если вы используете транки 802.1 кивошные. Циска сама сохраняет максимальный размер вложения в Ethernet в 1500 байд для того, чтобы, соответственно, кадры, которые будут увеличены на 4-байта в размере, нормально проходили по сети. Да, с 802.1 кивошными кадрами у нас получается следующее. Размер PolyMAC Client Data по факту вырастает до 1504 байт. Это означает, что у вас есть 1500 байт оригинального вложения и еще 4 байта того вложения, которое дорисовали вы. Вот этот вот самый EtherType и Tag Control Information. Формат у полученного кадра будет фактически как у обычного кадра Ethernet, если у того будет EtherType 8100. Если у вас будет почему-то коммутатор один с поддержкой 802.1 кивошный, другой с поддержкой 802.1 кивошный,

и третий в разливе между ними без поддержки 802.1 кивошный. То есть вот этот вот 1 кивошный, этот вот 1 кивошный, а этот, соответственно, нет. И вот они вот так вот в гирлянду между собой соединены. Такой транзитный коммутатор прокоммутирует такие кадры без проблем. Но единственное, что его может смутить, это размер кадра, который вырастет до 1518 байт плюс 4 байт, 1522. Если его это не смутит, то он такие кадры прокоммутирует. Если у вас будет обычный абонент, и вы на него внезапно будете отправлять 802.1 кивошные кадры, обычный абонент посмотрит на то, что внутри лежит, увидит там 8100 и скажет, я вообще не понимаю, что это такое. И выкинет его, и скажет, а non-protocol drop. Так, то, что чексума при добавлении метки портится, это печально. То есть вы должны будете, когда получаете оригинальный кадр, выкинуть оригинальную чексуму и добавить новую, которая будет отражать то, что вы добавили. Но потом, когда кадр будет получен соседом, и он уберет эту метку, он срежет ее и получит оригинальное содержимое,

он оригинальную чексуму тоже восстановит. Поэтому то, что вы выкидываете оригинальную чексуму, проблем не добавляет. Эта чексума по определению избыточная, и, соответственно, можно будет, если вы точно получили кадр без искажений, восстановить ее без особых проблем. И по поводу поля Tag Control Information, там, соответственно, будет вот что лежать. Во-первых, там есть поле, которое называется Priority Code Point. Это поле для указания качества обслуживания, которое вы хотите для этого кадра заказать. Соответственно, это поле заполняется в соответствии с рекомендациями 802.1p. 802.1p – это не самостоятельный стандарт, это, скажем, набор рекомендаций, который был выпущен для указания этого самого качества обслуживания. Иногда будет называться Class of Service, COS, то есть не QoS, Quality of Service, а Class of Service. И в 3-бита можно вписать аж целых 8 разных значений. Обычно эти поля никто не читает.

И, соответственно, если никто их не читает, то принято туда вписывать 0, 0, 0. 3-битика, ну, то есть значение 0. Если вдруг кто-то будет их читать, то, соответственно, он будет их читать в определенной логике, и он будет доверять тем меткам, которые приходят в этом поле, и он будет предполагать, что эти поля заполнены в правильной логике. Поэтому нет смысла говорить, давайте я сейчас на кадрах, которые в интернет отправляются, в сторону моего провайдера поставлю там семерку. Совершенно не факт, что ваш провайдер, а, не будет игнорировать это поле, и, б, что он будет семерку обрабатывать именно максимально приоритетным образом. 802.1.p предписывает использовать, ну, чем больше, тем лучше, как правило, там есть одно исключение, но тем не менее, да, вот чем больше, тем лучше. Семерка, по идее, должна быть самый приоритетный трафик. Но там, если меня память не изменяет, семерка – это Network Control, то есть самый-самый-самый важный трафик – это сеть управления. Если у вас есть какие-то протоколы, которые позволяют в сети оставаться связной,

тот же самый какой-нибудь OSPF, Телнет в конце концов, да, то есть то, что используется для того, чтобы сеть вообще продолжала функционировать. Это самые важные протоколы, и у них будет максимальный приоритет. Потом будет… Забыл уже. Вот же ж. Пятерка – голос, четверка – видео, трешка, если мне память не изменяет… Ладно, давайте не буду врать, потом покажу. Так, дальше. Три бита под поле Priority Code Point, одно же Class of Service. Один битик, который раньше, до 2011 года, назывался Canonical Format Identifier. И там указывалось нолик, если это был нормальный кадр из Орнета, и единичка, если вы брали токен-ринговский кадр и упаковывали его в 802.1Q.

Ну, токен-ринговый FDI. То есть внутри лежало вложение не Ethernet-овское, и маки, которые у вас передавались в кадре, они тоже были не Ethernet-овские. Вот в этом случае вы проставляли единичку, если вы действительно вкладывали какие-то кривые кадры в Ethernet. И коммутатор получателя понимал, что на приходящие кадры не надо запускать процедуру MacLearning, не надо делать разные другие вещи, надо вообще трактовать этот кадр как какой-то особенный. Нолик в Ethernet-е и единица в не Ethernet-е. И поэтому поле называется по-дурацки, оно должно было называться, вообще-то говоря, как-то типа неканоничный формат Identifier, а не то, что каноничный. Потому что флаги у нас обычно, когда единица, значит да, а когда нолик, значит нет. Но вот здесь наоборот. В 2011 году индустрия сказала, ребят, токен ринг помер уже лет 20 как. Поэтому давайте-ка мы переименуем это поле и будем его использовать в какой-то другой логике.

Если вдруг кто-то будет использовать это поле в логике canonical формата Identifier, он с вероятностью единицы будет ставить в это поле нолик, потому что он будет Ethernet-овский. Вероятность того, что там будут появляться токен ринговские кадры, она нулевая. Вот. Но если кто-то в 2011 или позже году будет проставлять единичку в это поле, он будет иметь в виду нечто другое. Не то, что это не Ethernet, а что-то совсем иначе. И соответственно в 2011 году, 802.1Q 2011 года стандарт сказал, это поле мы переименовываем в Drop Eligible Indicator, DE. Если вдруг отправитель ставит там единичку в этом поле, это означает, что он хочет, чтобы эти кадры в случае перегрузки выбрасывались первыми. В чем смысл? В том, что вы можете сказать, что вот если у вас есть 8 различных классов обслуживания в поле Priority Code Point, это хорошо.

Но если у нас есть возможность сделать 16 фактически разных классов обслуживания в рамках Ethernet, это будет еще лучше. Поэтому фактически это будет расширением поля Priority Code Point. Если кто-то заказывает там нолик, черт его знает, в какой он логике это делает, поэтому это просто нормальный трафик Ethernet. А вот если он выставляет единичку, то это будет Drop Eligible Indicator, и в этом случае такие кадры в случае перегрузки будут отбрасываться первыми, то есть мы добавляем новый класс обслуживания для каждого Priority Code Point, типа кадры с меньшей вероятностью доставки до получателя. А зачем это нужно? Как раз в случае, если с перегрузкой мы что-то отправляем, у нас есть возможность пометить кадры как важные и неважные. Важные это там, где мы ставим нолик, единичку, значит, что там чуть менее важные, чем в нормальных важных кадрах будет передаваться что-то. И такие кадры будут отбрасываться в случае перегрузки первыми. Ну и оставшиеся 12 бит – это, собственно, номер Вилана. И как раз 12 бит дает нам 4096 разных значений.

Традиционно номер 0 и номер 4095 зарезервированы под хитрые служебные нужды. Оставшиеся 4094 номера Вилана даются вам для растерзания. На каждом порту вы можете передавать кадры с меткой или без метки. То есть, если мы используем 8002.1Q, то мы можем сказать, мы можем добавлять в кадры, исходящие на нашем порту, какие-то вот эти вот самые 8002.1Q-шные заголовки, или можем не добавлять. Если мы отправляем кадр и не добавляем в него указания, в каком Вилане мы его передаем, то такие кадры мы будем называть untagget. То есть, кадры без метки. Мы такие кадры будем всегда передавать на портах доступа. То есть, если мы будем смотреть на обычные абонентские порты, то там все кадры передаются без 8002.1Q-шных заголовков, они все будут untagget. И, соответственно, на портах доступа у нас кадры, как правило, все относятся к одному единственному Вилану. Мы этот Вилан обычно называем абонентским Виланом,

что в нем у нас юзер сидит, и вот мы ему кадры отправляем самые обычные. И все кадры, которые от него приходят, они тоже будут самые обычные. Поэтому мы говорим, на обычном абонентском порту все кадры, которые мы отправляемся, будут untagget, и все кадры будут относиться к одному и тому же Вилану. Отправляться и приниматься в одном Вилане. Если у нас есть 8002.1Q-шный порт, то есть trunk, то в этом случае кадры могут передаваться как с указанием заголовка 8002.1Q, так и без указания заголовка 8002.1Q. И тогда каждый Вилан, который мы разрешаем отправлять в этот самый порт, мы будем называть либо tagget, либо untagget. Untagget может быть только один. То есть если мы какие-то кадры в порт до соседнего свеча передаем без метки, то мы договариваемся, что только кадры одного Вилана могут передаваться без метки. Ну и, соответственно, все кадры, которые будут приниматься без метки, они будут относиться только к одному единственному вот этому вот самому Вилану. В терминологии CSC эта штука будет называться native VLAN. В терминологии других вендоров она просто называется untagget VLAN.

То есть есть у нас коммутатор, у него есть какой-то порт. Вот. И, соответственно, вот порт. И на нем может передаваться кадры 10, 20 и 30 Виланов. Вот мы 10 Вилан говорим untagget. И, соответственно, кадры 10 Вилана передаются без метки, 20 и 30 сметка. Если кадры какие-то приходят с меткой 20 или 30 или даже 10 Вилана, они отправляются на коммутацию по таблице соответствующего 10, 20 или 30 Вилана. Если кадр приходит без метки, он отправляется на таблицу коммутации 10 Вилана, потому что именно этот Вилан у нас untagget. То же самое история с native VLAN. То есть просто то же самое, по сути, только переименованное. Если у нас есть какие-то кадры, отправляющиеся без метки, то это кадры могут быть только native VLAN. И если кадры какие-то приходят к нам, то это тоже кадры всегда только native VLAN и никакого другого. В подавляющем большинстве платформ вы не можете повесить несколько untagget VLAN на один транк.

То есть если вы попытаетесь сказать, что у вас есть второй untagget VLAN, то система скажет сначала удали первый. Если мы говорим про ASL-овские транки, то там допустимы только кадры размеченные. То есть вы, если помечаете транк ASL, то вы не можете отправлять в этом порту ничего, кроме ASL-овских кадров. Там такой концепции, как native VLAN, просто нет. По поводу слова транк, я, кажется, его забыл сказать. Транк – это тот порт, которым мы отправляем кадры нескольких VLAN. При этом из этого определения есть несколько исключений. Самое заметное, наверное, voice VLAN. Если вдруг вы используете такую штуку, как voice VLAN, то кадры одного VLAN у вас будут отправляться без метки, другого одного тоже VLAN у вас будут отправляться с меткой. Но этот порт все равно не будет считаться транком, он будет считаться аксессовым. Ну, просто это исключение, фактически фирменное цисковское исключение из правила.

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

Да, если мы используем 802.1Q-шные транки, то на них можно настроить Native VLAN, и в таком транке тогда можно будет отправлять одновременно и кадры размечены, и кадры не размечены. Для переключения режима работы порта есть команда switchport, mode и дальше либо access, либо trunk. Если вы указываете switchport mode access, то вы запрещаете обрабатывать модифицированные 802.1Q-шные кадры на этом порту, и все кадры, которые будут приходить или уходить, они будут относиться к определенному VLAN, который вы должны будете отдельно прописать. По умолчанию на всех портах у нас используется аксессовый режим VLAN 1. Ну и, соответственно, trunk. Если вы указываете switchport mode trunk, то вы указываете безусловный trunking, что у вас Cisco должна отправлять кадры с модифицированным заголовком, и вы должны будете сказать, каким именно заголовком кадры вы будете отправлять. Потому что если вдруг у вас Cisco умеет и ISL, и 802.1Q, то в этой ситуации, если вы захотите какой-то кадр отправить,

вы должны будете понимать, какой именно формат использовать. Вы не можете одновременно каждый кадр заворачивать и так, и так. Вот если вы переключаете порт, безусловно, в trunk, то вы должны будете предварительно указать, какой тип trunk вы поддерживаете. Ну и видно, что здесь есть еще другие возможные варианты. Это, во-первых, dynamic всякие режимы, во-вторых, private VLAN режимы, мы их дальше будем смотреть, и, в-третьих, туннели .1Q, это так называемый Q&Q, когда вы несколько меток 802.1Q на один кадр будете навешивать. Ну, вот из всего перечисленного только Q&Q мы в курсе не рассматриваем. Это такая сугубо провайдерская фича. Все остальное у нас будет. Я предлагаю на сегодня завершить нашей студии и продолжить завтра, потому что дальше у нас начинается мясо, связанное именно с работой на циске, и нам пригодится свежая голова. Так что на сегодня все. Спасибо за внимание и пока-пока.