Настройка VLAN на коммутаторах Cisco

Продолжаем мы с вами курс ASIN D1. В предыдущих модулях мы прошли, как настраивать Ethernet просто на уровне отдельного порта. То есть если у нас есть там устройство, какой-то маршрутизатор, коммутатор, то мы можем на уровне порта Ethernet настроить работу именно вот этого порта. Можем настроить скорость, дуплекс и так далее. И дальше возникает вопрос. Окей, а вот мы устройства покупаем ради чего? Ради того, чтобы они у нас перекладывали данные между разными интерфейсами. Да, каждый конкретный интерфейс может быть настроен, но, соответственно, у нас есть еще отдельная процедура. Это перекладывание данных между интерфейсами. Или, если мы говорим про свечи, это у нас мы называем коммутацией. Более строго, естественно, коммутация — это не перекладывание пакета с одного интерфейса на другой. Это разбрасывание всех пакетов между всеми интерфейсами. Нам пришел пакет, дальше мы пытаемся прикинуться толстым желтым коаксиалом. Мы его разбрасываем на все порты. Но на некоторые порты мы, соответственно, не решаем не разбрасывать некоторые пакеты.

И у нас на то есть несколько причин. Первая причина — мы никогда не разбрасываем копию пакета обратно в тот порт, из которого мы его получили. Вторая причина — мы никогда не разбрасываем пакеты на порты, которые, ну, например, выключены. Очевидная причина. Третье, мы никогда не отбрасываем пакеты, копии пакетов, копии кадров, на те порты, за которыми мы точно знаем, что нет получателя. Например, потому что мы знаем, где сидит получатель. Вот если мы знаем, что он сидит за одним портом, то со всеми остальными портами его точно нету. И еще одна из причин, по которой мы можем не отбрасывать копии кадров на некоторые порты, это если, например, мы знаем, что порт, which we look at, рассматриваем, стоит туда отбрасывать копию кадра или не стоит, он находится в другом Вилане. То есть там нету того Вилана, в который мы хотим отправить кадр. У нас кадр пришел на одном порту, мы его посмотрели, поняли, что этот кадр относится к какому-то Вилану по одному из критериев, либо потому, что этот порт у нас аксессовый,

и тогда просто на нем явно написано, к какому Вилану относятся все кадры, либо этот порт транковый, и тогда из самого кадра мы посмотрели на метку, которая в нем прибежала, и поняли, к какому VLAN он относится. И дальше мы принимаем решение, в какие порты мы копию этого кадра отправляем. Если мы отправляем копию кадра на некий конкретный порт, и этот порт аксессовый, то, значит, аксессовый VLAN должен быть тот самый, которому принадлежит, собственно говоря, кадр. Если вдруг у нас есть некий порт, например, FastEarnet 02, и мы его отнесли к VLAN 17, и к нам пришел кадр в 17 VLAN, то мы можем гипотетически отбросить кадр на этот порт. КОПИУ кадра. А если у нас есть VLAN на порту, не знаю, 34, а кадр пришел с 17 VLAN, то мы, естественно, зафильтруем отправку копии кадра на этом порту, потому что он в другом VLAN, ну, очевидная причина. Вот. И мы сейчас посмотрим, как это все дело настраивается на коммутаторах Cisco Catalyst,

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

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

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

то в заголовке кадра будет написано, опять же, там у нас будет метка, например, 802.1Q. И когда мы эту метку читаем, мы ее выкидываем, но мы ее читаем не просто так, мы сразу назначаем номер Вилана для конкретного кадра и отправляем кадр на коммутацию в Вилане. Если вдруг у нас есть транк, и в этом транке у нас настроен Native VLAN, то кадры, которые будут приходить в транке без метки 802.1Q, они все равно будут получать указания, в каком Вилане эти кадры пришли. То есть это будет как раз использоваться для этого концепция Native VLAN, при которой вы кадры без метки отправляете на коммутацию в режим в конкретный виртуальный коммутатор, в конкретно Вилан. Что за режим Dynamic VLAN? Это древняя некрофильская штука в ЦИСКе. На экзамене по ней может быть ровно один вопрос. Типа, знаете ли вы, что такой режим вообще был? И вы можете сказать, да, что вы знаете, что такой режим был, если я вот про него вам сейчас уже сказал, что он вообще-то был.

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

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

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

То есть у вас, опять же, аналогия с гипервизором, да, что вы не можете создать очень много виртуалок, которые у вас одновременно будут работать на одном сервере, потому что, ну, ресурсы сервера не безграничны. Максимальное количество Виланов в базе будет ограничено, зависит от конкретной платформы. Если мне память не изменяет, например, на самых маленьких простеньких свитчах, типа 2960, вы можете создать до 64 Виланов. То есть вы, в принципе, 65 Вилан просто объявить даже не сможете, и система скажет, что, извините, я споткнулась, дальше не могу. В принципе, это не проблема. Опять же, 2960-я линейка, она типичный access switch, она предназначена для обычных абонентских пользователей. То есть у нее там будет максимум 48 абонентских портов, ну и, допустим, там парочка, четверочка, например, оплинков. То есть больше 52 портов на ней, ну, как бы быть не может обычно. И, соответственно, если у вас есть 48 юзеров, вот они могут быть в 48 разных Виланов. Ну, плюс еще там какое-то Вилан управление, плюс, не знаю, что-то, вот какие-то еще служебные Виланы.

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

потому что showvlan выдает вам большую простыню текста, в которой, ну, в общем, разбираться на самом деле, что там, к чему относятся, не очень может быть интересно. Showvlanbrief показывает коротенько минут на 40, как список всех Виланов, и вот это вот состояние по умолчанию вам показывается, что есть Вилан с номером 1, У него есть имя, default, и поменять его нельзя, он всегда называется default. И в колонке status показывается, всё ли в порядке с этим VLAN, работает ли он, условно говоря, виртуальная машина запущена или не запущена. Вы можете на гипервизоре, например, создать виртуальную машину, но не запускать её. Она у вас есть, место занимает, но при этом по факту не работает. Виртуальный коммутатор тоже можно создать, объявить, что он есть, а по факту он будет выключен. Здесь показывается, что состояние active — это единственное возможное состояние для VLAN 1, потому что выключить его нельзя. Дальше в колонке ports показывается список портов, которые находятся в access-режиме в этом VLAN,

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

Если вы хотите добавить новый виртуальный коммутатор, новый VLAN в базу, то делается это из конфигурационного терминала. Вы указываете команду VLAN 10, например, десятый VLAN хотите создать, указываете VLAN, дальше номер VLAN. Приглашение к вводу изменяется, становится config-vlan. И важный момент. Обычно все команды немедленно применяются, когда мы даём какую-то настройку, оно сразу начинает работать. Переименовали железку — оно сразу переименовалось. Выключили интерфейс — он сразу выключился. VLAN не создаются немедленно. Они создаются тогда, когда вы выходите из контекста настройки конкретного VLAN. Вы создали десятый VLAN, провалились в контекст настройки десятого VLAN, из него надо выйти, и только в этот момент по факту VLAN создастся. До этого создания не происходит. Команду она приняла, но эта команда попала в некую предварительную память, и по факту не сработала. Вышли из контекста — она сработала.

Связано это с тем, что свитчи цисковские, эти Catalyst, сама Cisco в своё время не делала. Это была компания Crescendo, которая сделала свитчи, которая придумала аппаратную архитектуру, которая придумала для них операционную систему CatOS, и потом Cisco просто купила эту компанию. Она пыталась натянуть Cisco IOS на эти свитчи, всё было ничего, сама операционная система натянулась нормально, но работа с VLAN фактически осталась от старой архитектуры Crescendo. И в этой архитектуре сама база VLAN физически хранилась в файлике, и она до сих пор там хранится в некоторых случаях. Поэтому, когда вы указываете, что хотите создать десятый VLAN, вы фактически должны провести запись в файлик, который называется vlan.dat и лежит на флешке. И для того, чтобы слишком часто не проводить запись в этот файлик, чтобы не расходовать лишний раз ресурсы вашей флешки на каждую операцию работы с этим файликом, по факту, когда вы какие-то изменения вносите,

они у вас накапливаются, и в тот момент, когда вы выходите из контекста работы с VLAN, только тогда изменения сбрасываются на флешку. И только в этот момент по факту появляется соответствующий VLAN в базе VLAN. Равным образом, если вы зашли в контекст работы существующего какого-то VLAN, зашли в VLAN 1 или VLAN 10 существующий, VLAN 20 существующий, вы хотите его переименовать, включить, выключить — все эти действия применяются только тогда, когда вы выходите из контекста десятого VLAN или двадцатого VLAN, в каком вы находились. Они изменяются не сразу, они изменяются только тогда, когда вы выходите из контекста. Может быть, это будет из-за команды exit, может быть, вы Ctrl+C нажмёте, может быть, вы перейдёте в настройку другого VLAN, тем самым эффективно выходя из текущего десятого VLAN. Вы набираете VLAN 20, проваливаетесь в настройку двадцатого VLAN, из десятого выходите. Такое можно сделать. И когда вы выходите из контекста настройки конкретного VLAN,

только тогда изменения сбрасываются. Далее. Вы можете выполнить команду show vlan brief и посмотреть, что десятый VLAN создался. По умолчанию все VLAN получают имя — большими буквами VLAN, и дальше четырёхзначное число. Учитывая, что номера VLAN могут быть с первого по 4094, действительно, четырёхзначного числа для этого будет вполне достаточно. Десятый VLAN получил 0010. По умолчанию никакие порты в access-режиме в этом VLAN не присутствуют, поэтому в колонке ports пусто. Но тем не менее VLAN живой, нормальную виртуалку мы создали, она там крутится, только она трафика никакого не получает. Обратите внимание на секретную команду, которая здесь тихо просочилась. Команда show vlan brief вообще-то выполняется из решёточки, она не из конфига выполняется.

И по-хорошему мы здесь, конечно, должны были бы сказать не exit, а, допустим, end, провалиться в обычную решёточку, и дальше уже из решёточки писать show vlan brief. Но есть лайфхак. Если вы хотите, находясь в конфиге, выполнить команду — попинговать кого-то, посмотреть время, или посмотреть список VLAN — то можно воспользоваться макросом do чего-нибудь, и тогда вы фактически выполняете команду из режима настройки. На старых IOS в do не работает вопросик. Если вы точно знаете, что хотите сделать, вы можете написать do show vlan brief, нажать Enter. Справка работать не будет, но тем не менее команда сама выполнится. На новых IOS даже вопросик работает. Так, далее. Если вы хотите удалить VLAN, используется конструкция no vlan 10. Удаление VLAN срабатывает сразу. Здесь неправильно нарисовано. Приглашение будет не config-vlan, а просто config. Если вы хотите другой VLAN создать — VLAN 20, VLAN 30. VLAN можно переименовывать.

Здесь name accounting показывается, что действительно можно дать имя VLAN, и оно будет показываться в колонке name. Очень хорошая идея давать имена VLAN, потому что если у вас их достаточно много, например, больше десяти, рано или поздно вы запутаетесь в том, какой VLAN за что отвечает. Как правило, в предприятии VLAN используются для сегментирования сети на отделы. И вы указываете, что у вас есть VLAN бухгалтерии, VLAN HR, VLAN айтишников, VLAN для управления, VLAN для чего-то ещё. И хорошая практика — давать говорящие имена. Плохо, когда у вас просто имена VLAN 10, VLAN 20, VLAN 30. Можно VLAN выключить. Вряд ли вам это понадобится на CCNA D1, но тем не менее команда shutdown внутри настроек VLAN показывает, что VLAN создан, место занимает, но работать при этом не будет, трафик коммутироваться не будет. И тогда вы можете видеть в списке VLAN, что у него статус active — место занимает, и act/lshut значит, что он выключен, локально выключен командой shutdown. Ещё обратите внимание на хак,

который здесь использован. Если вы находитесь в контексте работы с двадцатым VLAN, у вас приглашение config-vlan, вы даёте какие-то настройки этому VLAN, и дальше вы можете, если захотите, набрать end или exit, и вы выпадете либо в обычную решётку, либо на уровень выше, в контекстный уровень выше. Если бы мы здесь набрали, допустим, exit, то мы бы провалились в глобальный конфиг, и здесь приглашение было бы просто config#. Но если мы хотим, допустим, поработать с двадцатым VLAN, а потом хотим поработать с тридцатым VLAN, то мы можем не набирать exit. Мы можем сразу выполнить настройку VLAN 30, которой, вообще-то, нету в VLAN 20. Справка здесь вам ничего не даст. Справка на эту штуку скажет, что такого нету, и никак не отреагирует. Но система сработает следующим образом. Она посмотрит, что команды VLAN 30 в контексте работы с двадцатым VLAN не существует. Посмотрит на всякий случай в контексте выше, а если там нету, то ещё в контексте выше,

а если ещё нету, то ещё в контексте выше, пока не дойдёт до глобального контекста. Если в каком-то из контекстов она найдёт эту самую команду, то она автоматически, вместо того чтобы сказать вам, что такой команды в двадцатом VLAN нету, выполнит эту команду из контекста выше. Фактически она exit наберёт за вас автоматически. Вы из двадцатого VLAN переходите в глобальный контекст, а потом из него переходите в субконтекст работы с тридцатым VLAN. Приглашение здесь как будто бы не изменяется, но на самом деле оно будет находиться в разных контекстах. Здесь мы находимся в двадцатом VLAN, здесь мы находимся в двадцатом VLAN, а здесь мы уже находимся в тридцатом VLAN. Мы автоматически туда вышли и вошли. Довольно удобная штука, позволяет сэкономить немножко ценных калорий на набирании exit, которые, по сути, не обязательны. Так, далее. Максимальный номер VLAN, который вы можете создать, будет 4094, потому что у нас 12-битные номера VLAN, и 12-битный диапазон даёт нам значение от 0 до 4095.

0 использовать не принято. Это специальная служебная штука, обозначающая «я точно не знаю свой VLAN», и в некоторых случаях мы его будем использовать для таких задач. И равным образом 4095 — тоже специальный служебный случай, мы его использовать не можем. Всё остальное, формально говоря, можно будет использовать. В зависимости от конкретного устройства, конкретной линейки, вы можете столкнуться с тем, что некоторые VLAN вам не дают использовать. Просто по каким-то соображениям некоторые VLAN будут считаться занятыми. В частности, в линейках Cisco вы не можете использовать с 1002 по 1005 VLAN. Это рудименты того, что в Ethernet можно было инкапсулировать Token Ring. Вы брали 802.1Q-шный транк и говорили,

что у нас есть Ethernet-овский транк, и вы в этом транке могли передавать кадры Token Ring. У вас и Ethernet по этому протоколу бегал, и Token Ring. Хотя физика в Ethernet и Token Ring разные, но кадры у них частично были совпадающие. И там специальным был признак, И там специальным был, соответственно, признак, что кадр — это не Ethernet-овский, это токен ринговский, хотя физику мы используем Ethernet, но кадр по факту токен ринг. И для этих токен рингов

было 4 VLAN в цисках выделено. В целях обратной совместимости до сих пор вы не можете использовать эти VLAN-ы 2002-й, 2005-й, потому что если вдруг у вас где-то в сети всё-таки будут свичи, которые будут работать с токен рингом, одновременно Ethernet и токен ринг, то им эти VLAN-ы могут гипотетически понадобиться. Использовать эти VLAN-ы вы не можете, ничего с ними сделать вы не можете. Вы не можете даже как-то задействовать. Если очень хочется, ничего не получится. Более того, некоторые VLAN-ы могут быть заняты даже из других диапазонов. В любом случае со 2 по 1001 вы можете использовать без особых проблем, а из расширенного диапазона с 1006 по 4094 вы должны будете использовать с осторожностью, особенно на цисках. Начать с того, что по умолчанию эти VLAN-ы вы просто не сможете задействовать, система будет ругаться. Но если дать секретную команду, она вам разрешит их использовать именно на цисках, подчеркну. Но она гипотетически

может занимать некоторые из этих VLAN-ов под какие-то свои служебные задачи, по своему усмотрению. Как правило, забираются номера либо из начала этого блока, либо из конца, поэтому там с 1006 по 1100 и с 4000 по 4094 я бы не стал использовать под свои нужды, потому что мало ли вдруг они будут задействованы под служебные задачи, и, соответственно, у вас будет конфликт технологий, ничего хорошего в этом не будет. Поэтому с 1500 по 3500 абсолютно без проблем вы можете использовать под свои задачи. Так, далее. Каждый порт у нас может либо разрешать отправлять кадры с этими метками, с указанием, в каком VLAN-е этот кадр следует обрабатывать, либо не будет разрешать такие метки. Фактически мы либо разрешаем кадры-мутанты, либо не разрешаем. Если мы не разрешаем кадры-мутанты, то мы называем такой порт

аксессовый порт или порт доступа. На порту отправляются только самые обычные кадры, и все они, как правило, относятся к одному и тому же VLAN-у. И мы жёстко указываем на таком порту, к какому VLAN-у следует эти кадры относить. Либо мы разрешаем кадры-мутанты на порту, и тогда такой порт называется транком. Мы, как правило, эти кадры 802.1Q или какие-то другие разрешаем на порту, для того чтобы можно было кадры, которые по этому порту отправляются или принимаются, относить к разным VLAN-ам. Поэтому на аксессовом порту все кадры относятся к одному VLAN-у, на транковом порту кадры могут относиться к разным VLAN-ам. Как правило, эта штука будет характерна для линков между коммутаторами. Если у нас есть два свича, и у нас есть пользователи на одном свиче, в одном VLAN-е, в другом VLAN-е, на другом свиче, в одном VLAN-е, в другом VLAN-е. И, соответственно, нам надо передавать по одному проводу кадры и одного, и другого VLAN-а. И тогда мы говорим, этот кадр передаётся в первом VLAN-е,

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

мы всё равно этот кадр должны будем обработать, мы его направляем на десятый VLAN. Так что не путайте, пожалуйста, одно дело, какую метку вы прописали в дополнительном заголовке, и другое дело, к какому VLAN-у вы кадр отнесли. Это две разные вещи, хотя и похожие друг на друга. В коммутаторе все порты в режиме Access из коробки — верно ли это утверждение или нет, я бы хотел отложить этот вопрос чуть-чуть на потом. В предположении, что вы взяли, принесли коммутатор из магазина, настроили его, не подключали его к каким-то существующим коммутаторам, не включали на нём какие-то хитрые дополнительные технологии, все порты будут по факту работать в static access. Транк, как правило, на современных свичах вы должны включать в явном виде и настраивать его руками. Я специально делаю оговорку здесь, что вы ни к чему существующему

его не подключали, пользователи у вас ничего взломать не пытаются, в такой ситуации, если вы взяли условно новый свич, подключили его к своему собственному компьютеру, вы точно знаете, что там происходит, что ваш компьютер ничего плохого не делает, в этой ситуации все порты у вас будут в static access. Дело в том, что у Cisco есть некоторое количество технологий, такие бомбы замедленного действия. Одна из них — это то, что у вас порт может внезапно перейти в транк без вашего на то ведома. И мы про это отдельно поговорим буквально через 10 минут. Транк, как правило, настраивается между коммутаторами. Эти кадры-мутанты, которые в транке разрешены, они должны каким-то образом появляться в сети, кто-то их должен создать, мутировать. Обычные пользователи не знают про эту дополнительную метку. Когда вы отправляете кадр соседнему свичу,

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

кадров с дополнительными какими-то модификациями, то эти кадры могут быть в разных форматах. Могут быть 802.1Q, могут быть ISL, могут быть 802.10. Причём, если ISL или 802.10, то они все одинаковые, должны быть все модифицированные. А если это 802.1Q стандарт, то эти меточки, 4 байта дополнительные, которые мы с вами вчера изучали, они могут быть или могут не быть. И если их нет, то допустимо их отсутствие только для кадров, которые передаются ровно в одном VLAN-е, который будет называться Native VLAN. Native VLAN существует только для 802.1Q. Для ISL он, соответственно, не применяется. ISL-овский транк, если вы включаете, то там все кадры должны быть мутировавшие. Так. Если вы хотите на Cisco задать режим работы порта, то это делается с помощью команды на интерфейсе switchport mode, и дальше вы указываете тот режим, который вы хотите включить.

Самый простой вариант — это когда у нас есть просто обычный пользователь. Мы говорим, на порту обычного пользователя пользователь может нам присылать только обычные кадры. Никакие мутанты кадров на порту пользователя недопустимы, потому что все кадры, которые просто приходят от обычного пользователя, они заведомо будут относиться к одному и тому же VLAN-у. То, что пользователь захочет, возможно, отправлять какие-то кадры в разных VLAN-ах, нас не сильно интересует. Мы всё равно должны будем обрабатывать все кадры ровно в одном VLAN-е. Поэтому на портах обычных пользователей мы указываем, что у нас порт будет находиться в режиме Access. И мы указываем команду switchport mode access. Если вы такую команду даёте, то у вас всё хорошо. На этом порту всегда будут обрабатываться только самые обычные кадры. Кадры с метками обрабатываться не будут, если мы говорим про Cisco. И это правильная настройка на абонентском порту.

Вы можете также включить команду switchport mode trunk и тем самым в явном виде разрешить отправку мутировавших кадров. И это нормальная команда, если вы включаете её на порту, который смотрит на соседний коммутатор. Если у вас есть два коммутатора, левый и правый, И оба они настраиваются вами, вы точно знаете, какими портами они друг на друга смотрят, то вы вполне можете сказать, на этом порту мы разрешаем отправку и приём кадров мутантов. И на этом порту мы разрешаем отправку и приём кадров мутантов. И вы указываете команду switchport mode trunk. На портах обычных абонентов switchport mode trunk включать не нужно, потому что обычные пользователи кадры-мутанты, во-первых, не хотят присылать обычно, во-вторых, не могут обрабатывать, как правило. Если вы пошлёте кадр формата 802.1Q с этим дополнительным заголовком, обычный пользователь на него посмотрит, скажет, да, я вижу кадр, вроде кадр, у него даже вроде чексумма сходится, но, во-первых, он слишком большой, у него 1522 размер с заголовками.

А во-вторых, у него какое-то странное вложение, 8100, которое непонятно, как обрабатывать. Это не IPv4, это не IPv6, это непонятно что. И обычный пользователь будет ругаться, говорить, что он этот протокол не понимает, и будет такие кадры дропать. Поэтому, чтобы такого не происходило, на обычных абонентов кадры мы посылаем в обычном access режиме, для этого он более чем подходит. Trunk для этого не очень подходит. В какой ситуации мы будем включать транковый порт на узел, который не является соседним коммутатором? Иногда такое бывает нужно, и классический пример — это сервер, на котором крутятся виртуальные машины. У нас есть сервер, на нём крутятся виртуалки, некоторые виртуалки надо отдать в один VLAN, некоторые виртуалки надо отдать в другой VLAN. На сервере мы можем управлять драйверами сетевых карт, мы можем запустить какой-то процесс, который понимает, что такое VLAN. И в этой ситуации мы можем сказать, окей, мы разрешаем на порту свича, который смотрит в сторону сервера, где крутится пачка виртуалок,

отправлять разные кадры разных VLAN. И, соответственно, мы их модифицируем, и сервер поймёт, что мы имеем в виду. Это специальный особый случай, когда у вас есть сервер, на который вы пригоняете транк, на котором приходят мутировавшие кадры, и сервер разбирает эти кадры, он понимает, как их обрабатывать, он говорит, кадры, которые приходят в таком VLAN, мы отправляем на такие виртуалки. Кадры приходят в другом VLAN, мы их отправляем на другие виртуалки. Но на обычных абонентов мы всегда ставим просто обычный access. На соседние свичи мы ставим, как правило, транк. Если мы указываем switchport mode access, то у нас есть какой-то виртуальный коммутатор, на нём запущены те самые виртуальные свичи, и мы говорим, что у нас есть обычные абонентские порты, и этот абонент в 10-м VLAN, этот абонент в 10-м VLAN. Соответственно, мы прописываем жёстко на портах gigabit 0.0, gigabit 0.1, что все кадры, которые приходят или отправляются на этом порту, мы отправляем на коммутацию в 10-й VLAN.

Соответственно, командой будет switchport mode access. Фиксируем режим работы порта. Это важно. Это отдельная команда. Вы её должны в любом случае давать. И отдельно указываем, что кадры, которые будут приходить на этом порту или отправляться на этом порту, они должны находиться в 10-м VLAN, если этот порт работает в режиме access. Две разные команды. Первая указывает режим работы порта, а вторая говорит, если у нас порт в access, то тогда отправляем все кадры только в 10-й VLAN. Это две разные независимые команды. Они работают по-разному и делают разные вещи. Если вы захотите, вы можете, в принципе, гипотетически, опустить команду switchport mode access и написать только switchport access VLAN 10. И в большинстве ситуаций она будет давать точно такой же результат, как если бы вы написали switchport mode access. Если вы просто взяли, принесли новый switch из коробки, воткнули в него абонентов и прописали только switchport access VLAN 10,

она будет работать. Действительно, у вас все кадры будут относиться к 10-му VLAN. Разница в том, что switchport mode access жёстко задаёт режим работы порта. А из коробки, у Cisco, этот режим работы задан не жёстко. И у вас гипотетически порт может внезапно стать транком. Даже если вы прописали команду switchport access VLAN 10, это не означает, что порт у вас всегда будет работать в режиме access. Если злой пользователь захочет вас похакать, он может отправить секретный пакет, и у вас порт станет транком. И тогда эта команда, несмотря на то, что в конфиге она будет, она по факту применяться не будет. Она работает именно так, что если порт работает в access, то VLAN 10. А если не работает, то эта команда ни на что не влияет. Она в конфиге есть, но никак не влияет на результат. Поэтому отдельно включаем switchport mode access и отдельно включаем switchport access VLAN 10. Да, это dynamic mode с предыдущего слайда. Мы его сейчас чуть дальше увидим. На одном порту включаем,

на другом порту включаем. Если у вас много-много коммутаторов, много-много портов на них, то отдельно бегать на все порты и говорить на этом порту две команды, на другом порту две команды, на третьем порту две команды — на каждом порту много этих самых команд придётся вводить на каждом коммутаторе. Задолбаетесь. Есть способ, как схалявить. Если вы хотите сказать, что у вас есть какой-то диапазон портов, на которых надо дать одинаковые настройки, вы можете воспользоваться макросом interface range. Вы указываете interface range, дальше указываете первый порт, на котором надо дать настройки, и через дефис указываете диапазон портов на том же самом модуле. Это читается как все порты на модуле gigabit 0 с номерами со второго по третий. Настраиваем однотипно. На самом деле у вас даже приглашение к вводу будет другое, не config-if будет, а config-if-range. И все команды, которые будете давать,

и switchport mode access, например, здесь, и switchport access VLAN 20, они все попадут во все порты в указанном вами диапазоне. Тут можно даже через запятую сказать, допустим, gigabit 1.0-7. Сначала в этом диапазоне, а потом и в этом тоже, соответственно, будете давать одинаковые настройки. Interface range — она очень удобная, и я рекомендую вам её использовать, если у вас есть много интерфейсов, на которых надо дать одинаковые настройки. В нашем случае мы указываем, что у нас есть два порта, gigabit 0.2 и gigabit 0.3, на которых одной командой мы одновременно забиваем на двух портах switchport mode access. И равным образом одной командой мы на двух портах указываем, что если порт работает в access, то он будет в 20-м VLAN. На Cisco, на свежих Cisco, подчеркну, потому что 2950, например, Cisco — это Cisco очень сильно предыдущих поколений,

там было другое поведение. Если вы указываете switchport mode access, то на таком порту будут обрабатываться только кадры без меток. Если вы указываете switchport mode access, то кадры с метками просто тихо сбрасываются. Вы можете посмотреть, как настроен порт в части коммутации. Команда show interface, дальше название порта, switchport. Здесь нас сейчас будет не всё интересовать. Мы потихоньку разбираем вывод этой команды. В нашем случае — это название интерфейса, оно понятное. Switchport enabled. Это означает, что на этом интерфейсе коммутация в принципе включена. Дело в том, что вы можете выключить коммутацию на интерфейсе и тем самым перевести порт в то, что Cisco называет L3. На обычных коммутируемых портах у вас, например, MAC-адресов нет. Потому что когда у вас есть виртуальный широковещательный домен, коммутатор перекладывает кадры между интерфейсами, ему для этого свои собственные MAC-адреса не нужны. Если у вас интерфейс работает в режиме коммутации,

то своего MAC-адреса у него нет, он ему не нужен. Вы можете выключить коммутацию на интерфейсе и перевести порт в маршрутизируемый режим, и тогда на интерфейсе появляется MAC-адрес, но тогда коммутация на порту выключается. Кадры, которые приходят на этом порту, вы больше никуда не коммутируете. Нормальное состояние, особенно на дешёвых свичах, это как раз то, что коммутация по умолчанию включена. На более мощных свичах, например, на наших лабораторных, вы можете выключить коммутацию на порту, и это приведёт иногда к некоторой пользе. Но про это мы будем говорить на курсе по свитчингу. Дальше. Administrative Mode — как администратор сказал работать. Если вы выключили динамический режим, вы сказали switchport mode access, то вы прибили гвоздями static access на этом интерфейсе. Вы сказали, только так и работает. Operational Mode — как по факту работает. Как сказали, так и работает. Мы потребовали static access, оно по факту static access и есть. Фишка в том, что вы можете сказать,

что вам всё равно, как оно будет работать. И более того, это поведение по умолчанию. Поэтому, когда вы берёте свич из коробки, у него тут кое-что другое. И, соответственно, во второй строчке Operational Mode он показывает, как по факту работает. Если предположить, что вас никто не взламывает, если предположить, что вы достали новый свич из коробки, подключили к нему свой собственный компьютер, то там, скорее всего, static access и будет. Но это «скорее всего», «если предположить» — сами понимаете, IT — это наука точная, это почти как математика. Поэтому там не должно быть этого. Если предположить, там, как сказали, так и должно работать. Если вы настроили static access, то у вас operational mode тоже должен быть static access. И в этой строчке access mode VLAN показывается, в каком VLAN у вас будут обрабатываться все кадры. Эта строчка есть в любом случае, даже если у вас порт не работает

во static access, она применяется, срабатывает только тогда, когда порт по факту находится в access. Показывается номер VLAN и показывается в скобочках его название. Я как раз говорил вам, хорошая идея будет именовать ваши VLAN именно потому, что здесь будет показываться, что за название VLAN вы дали. Вы можете взять, посмотреть быстренько show interface switchport на конкретный порт, и он вам скажет, это порт, который смотрит в VLAN бухгалтерии. Вам не нужно будет их по номерам помнить. Все остальное нас сейчас пока не интересует. Мы через пару слайдов посмотрим на другие режимы, где это будет нас уже больше интересовать. По поводу транков. С транками ситуация следующая. Транк разрешает отправку кадров мутантов и прием кадров мутантов. Мутантов мы плодим для того, чтобы дать соседу понять, в каком VLAN ему следует обрабатывать кадры. Отдельно то, что написано в кадре,

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

а нам надо уже чего-нибудь ему отправить. Поэтому мы не можем просто сказать включи какой-нибудь транк. Надо сказать, какой транк мы жестко требуем, чтобы работал. И поэтому, если у вас поддерживается старый формат ISL, то вы должны будете выполнить команду switchport trunk encapsulation, и чаще всего мы будем задавать 802.1Q, то есть будет формат .1Q. Команда будет switchport trunk encapsulation .1Q. Если у вас поддерживается ISL, вы гипотетически можете задать команду switchport trunk encapsulation ISL, но там будет большой расход полосы пропускания на эти 30 байт заголовка. И я, пожалуй, вам его не рекомендую использовать, тем более что никакой выгоды он на самом деле не дает по сравнению с 802.1Q. Вы просто так будете тратить 30 байт на каждый кадр. А работает он точно так же, как 802.1Q. На всех новых платформах 802.1Q обязательно есть. На оборудовании других вендоров 802.1Q только, никакого ISL,

поэтому смысла использовать сегодня ISL никакого нет. Но тем не менее может быть, что он у вас поддерживается, поэтому может быть такое, что вам обязательно придется задать команду switchport trunk encapsulation .1Q, потому что он у вас гипотетически поддерживается. Если вы включаете режим 802.1Q, то есть используете switchport trunk encapsulation .1Q или не используете, потому что такой команды у вас вовсе нету, потому что у вас только 802.1Q есть, то вы дальше указываете switchport trunk, то, что в заголовке написано, прибиваете жестко режим, что на этом порту транка вам кадры мутанты разрешены, и дальше вы должны будете указать, что делать с кадрами, которые приходят без метки, потому что в 802.1Q транке может быть такое, что кадры придут без метки, это допустимая ситуация. Если кадр приходит неразмеченный,

мы должны все равно его отнести к какому-то VLAN. И ровно один VLAN вы можете пометить, что это будет switchport trunk native VLAN, и дальше какой-то номер. Например, 10. И тогда кадры, которые будут приходить без метки, они будут фактически обрабатываться, как будто в них написано число 10, что кадр пришел в 10 VLAN. Более того, кадры этого VLAN по умолчанию будут отправляться без метки тоже. Смысл этого действия я чуть попозже расскажу. Дело в том, что изначально эти 802.1Q-шные транки предполагалось использовать еще в коаксиальных проводах, в которых у вас могли быть абоненты. Поэтому может быть такое, что у вас есть switch один, есть switch другой, и есть провод между ними. Только это провод не прямой, точка-точка, а провод, в котором еще абоненты сидят. И вы можете застрелиться, потому что вам этим двум товарищам надо обмениваться кадрами-мутантами, и в этом же проводе надо принимать кадры,

которые приходят от обычных абонентов, которые приходят, естественно, без модификации. Поэтому для того, чтобы с ними можно было работать, вы указываете: те кадры, которые предназначены для или приходят от обычных абонентов, вы относите к Native VLAN, а все остальные кадры вы обрабатываете с метками. И обычные абоненты их не понимают, отбрасывают, как unknown protocol drop. Использовать Native VLAN сегодня не рекомендуется, но тем не менее он все равно задается в конфиге, вы должны его узнать в конфиге. Да, я его нарисовал, а на самом деле все было уже нарисовано заранее. Да, концепция Native VLAN нужна была для того, чтобы вы могли в разрыве между двумя устройствами использовать кадры обычных абонентов. Здесь нарисовано, что у нас есть свитч без поддержки 802.1Q. Это точно так же будет работать, если здесь будет просто коаксиал, в котором сидит абонент. Мы не знаем на самом деле,

есть там свитч, нет там свитча, потому что любой свитч пытается максимально эффективно, насколько он может это делать, прикидываться толстым желтым коаксиалом. Поэтому что вы здесь скажете, что у нас коаксиал, в котором сидит абонент, что вы скажете, что у вас там свитч без поддержки 802.1Q, результат один и тот же. Этот абонент отправляет и принимает обычные кадры. Нам нужно будет их обрабатывать, и мы говорим: все, что приходит без метки, это приходит от обычного абонента, и мы обрабатываем его по таблице, допустим, 20-го VLAN, который у нас помечен как native. Мы здесь говорим native 20. И то же самое здесь говорим native 20. Все, что приходит без метки, обрабатывается по таблице 20-го VLAN. Все, что приходит в 20-м VLAN и отправляется в этот провод, оно может дойти до соседнего коммутатора и будет отправляться дальше на 20-й VLAN. И тогда мы должны будем как-то сказать, что это 20-го VLAN. Либо может быть такое, что этот кадр пойдет до обычного абонента.

Если он пойдет до обычного абонента, мы его обязаны отправить без метки. Обычный абонент метки не поймет. Поэтому мы кадры 20-го VLAN отправляем без метки. Это мы делаем потому, что у нас 20-й VLAN прописан как native. А сосед, у которого тоже 20-й VLAN прописан как native, будет обрабатывать кадры без метки по таблице 20-го VLAN. И взаимодействие между всеми узлами 20-го VLAN в этом случае будет возможно. Сегодня native VLAN использовать настоятельно не рекомендуется, потому что на него есть несколько достаточно неприятных атак. Поэтому рекомендация: используйте в качестве native VLAN такой VLAN, в котором у вас никогда ни за что никакие кадры отправляться не будут. Предположим, что у нас есть 10-й VLAN — это HR, 20-й VLAN — IT-шники, 30-й VLAN — бухгалтерия, аккаунтинг. И вы говорите: native VLAN мы прописываем 666. Его в базе нету. Поэтому то, что мы его прописали,

означает, что такие кадры просто никогда не возьмутся нигде. Если бы у нас хотя бы один пользователь относился к 666 VLAN, то тогда кадры бы эти пошли без метки. Но учитывая, что в 666 VLAN пользователей у нас нету и быть не может, соответственно, никакие кадры по факту без метки не пройдут. Более того, ещё неплохой идеей может быть создать этот самый 666 VLAN в базе и выключить его командой shutdown. Или, допустим, даже гипотетически, если у вас много денег, вы можете его не выключать и завести в нём систему обнаружения вторжений. Вы можете сказать: это у нас будет VLAN, так называемый honeypot. И, соответственно, любой трафик, который там возьмётся, он возьмётся только исключительно из-за того, что у нас в этом VLAN заведётся атакующий. И этот самый VLAN-honeypot мы будем отправлять на какую-то систему IDS или IPS. И если вдруг она обнаружит, что там какой-то трафик начинает ходить,

она включает сирену, включает красную лампочку моргающую, и у вас немедленно отряд быстрого реагирования начинает разбираться, что там за трафик и откуда он взялся. Рекомендация — использовать в качестве native VLAN такой номер, который не используется, не задействован, не существует. Может быть, в базе отсутствует, может быть, присутствует, но выключен. Но главное, чтобы в этом VLAN не было пользователей. Чтобы нигде в компании этот номер не использовался, и трафик там никогда бы не завёлся. Как настраивается транк на свичах Cisco? Сначала надо создать VLAN. Отдельно вы указываете, что у вас есть транк, и что в этом транке какие-то VLAN можно обрабатывать. И отдельно — то, что у вас есть виртуальные коммутаторы. Это одно про метки, а другое про коммутацию этих самых виртуальных широковещательных доменов. Смотрите, я почему на это внимание обращаю. У нас есть кадры, которые по транку будут бегать. На картинке 10-й и 20-й VLAN.

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

посчитал оригинальную контрольную сумму. И дальше говорит: я вижу, что мне пришла рекомендация обрабатывать его по таблице 20-го VLAN. И, соответственно, он дальше говорит: я буду сейчас отправлять этот кадр на либо 10-й, либо 20-й VLAN. Но рекомендация была по 20-му, поэтому я его отправляю на 20-й VLAN. В чём загвоздка здесь кроется? В том, что отправитель мог написать здесь любое число. 777. Он говорит: я тебе рекомендую по таблице 777-го VLAN обрабатывать. То, что он рекомендует вам это сделать, то, что он отправляет кадры, в которых написано 777 в метке VLAN, не означает, что у вас такой коммутатор есть. Соответственно, его у вас нет, у вас только 10-й, 20-й, 30-й, 40-й VLAN. Поэтому, если вдруг какой-то кадр — вы посмотрели на него внимательно и приняли решение, что этот кадр должен быть обработан по таблице 777-го VLAN или любого другого, и у вас не создан такой VLAN, с этим кадром вы делаете ровно одно — вы его выбрасываете.

Вы не можете его обработать. Если кадр вы приняли решение отнести к несуществующему VLAN, это проблема этого кадра. Кадр выбрасывается и не обрабатывается дальше. Ровно та же самая история с access-портами. Если у вас есть коммутатор, у него есть абонентские порты. Два порта в 10-м VLAN, два порта в 20-м VLAN. Нормальная ситуация, что вы при этом создаёте 10-й и 20-й VLAN на самом свиче. Если вы 10-й VLAN создали, то трафик 10-го VLAN нормально ходит. Вы принимаете решение, что на access-порту у вас пользователь в 10-м VLAN сидит, кадр, который приходит на порт, обрабатывается по таблице 10-го VLAN и уходит в сторону соседнего порта, который тоже в 10-м VLAN есть. Если вы объявили команду switchport mode access, switchport access VLAN 20 на access-портах, но сам 20-й VLAN при этом не создали, совершенно не факт, что такой кадр будет обработан. К вам приходит кадр, вы говорите: кадр пришёл на порт, на этом порту написано switchport mode access, кадры могут приходить только самые обычные,

всё хорошо, switchport access VLAN 20. Мы говорим, что обычные access-кадры, которые приходят на access-порту, относятся к 20-му VLAN, а дальше вы должны прокоммутировать этот кадр по таблице 20-го VLAN, но вы его заранее не создали, и у вас такого VLAN нет. Что с этим кадром произойдёт? Правильно, он выкинется. Ещё раз подчеркну, отматывая назад: наличие команды switchport mode access, switchport access VLAN 10 не означает, что кадры у вас будут коммутироваться нормально в этом интерфейсе. Они будут нормально коммутироваться, только если вы заранее команду VLAN 10 выполните. Одно действие — создать VLAN, другое действие — зафиксировать на порту режим работы access, и третье — сказать, что если у нас порт находится в access-режиме, то кадры отправляются по таблице 10-го VLAN, который мы создали заранее. На новых цисках может быть такое, что если вы указываете switchport access VLAN чего-то на access-порту и не создаёте VLAN заранее, то оно предупреждает вас, говорит:

слушай, тут, кажется, такого VLAN, которого ты хочешь, нету, и создаёт его за вас. Оно выдаёт предупреждение: ты попросил 777-й VLAN на порту включить, а такого VLAN в базе не было, поэтому я тебя просто уведомляю, что такой VLAN теперь есть, живи с этим как хочешь. На транках такого нету, на транковом порту у нас ничего автоматом не создаётся. Что нужно будет сделать для того, чтобы включить транковый режим? Нужна будет команда switchport mode trunk, она фиксирует режим работы транка, но транки бывают разные, поэтому если у вас поддерживаются и ISL, и 802.1Q, то перед тем, как выполнять команду switchport mode trunk, надо выполнить команду switchport trunk encapsulation dot1Q, иначе switchport mode trunk вам выдаст ошибку. И прибивайте гвоздями native VLAN. Switchport trunk native VLAN 30. По умолчанию на всех транках native VLAN 1, поэтому даже если вдруг вы гипотетически не отследите ситуацию,

что у вас порт стал транком, а он может стать транком, если вы принесли новый свич из магазина, достали, распаковали, включили в сеть — в нормальной ситуации все порты находятся в режиме access, но гипотетически может быть такое, что порт перейдёт в транк, если вы не зафиксировали порт switchport mode access. Даже если вдруг вы это не отследите, даже если вдруг у вас атакующий какой-то завёлся, который заставил порт перейти в транковый режим, всё равно все кадры первого VLAN будут обрабатываться без меток и отправляться они тоже будут без меток. Вы этого не заметите по умолчанию. Поэтому рекомендация — не использовать динамический режим, зажимать жёстко switchport mode access на портах. Далее. Также на портах можно будет сказать, какие VLAN мы будем обрабатывать, и это будет работать следующим образом. У нас есть железный свич, и мы на нём создаём VLAN 10, 20 и 30.

И, соответственно, у нас есть один порт, допустим, второй порт и третий порт. Это всё транковые порты, мы на них разрешили отправку кадров-мутантов, мы на них разрешили приём кадров-мутантов, и мы хотим сказать, что здесь соседний свич может нам присылать кадры и 10-го, и 20-го VLAN. Но при этом мы не хотим, чтобы кадры 30-го VLAN на этом порту вообще появлялись. 30-й VLAN — это специальный, особенно секретный VLAN за бухгалтерией, а на этом порту свич, на котором сидят, не знаю, водители и экспедиторы. И бухгалтерия им вообще никак не нужна. И в этом случае мы можем сказать: на этом порту мы разрешаем обработку только 10-го и 20-го VLAN. И командой будет switchport trunk allowed VLAN 10 и 20. Технически это будет выглядеть как то, что здесь появляется некий анализатор, который смотрит на то, какие метки приходят. Если метки приходят с нужными цифрами,

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

соответственно, трафик от водителей до компьютеров 30-го VLAN пройти не сможет. Они не соединены, видите, никакого соединения между ними нет. Обычный абонентский порт может быть соединён только с одним виртуальным свичом. Транковый порт может быть гипотетически соединён с несколькими разными виртуальными свичами. Если говорить более строго, то каждый коммутатор будет разбрасывать все кадры по всем портам. Но если мы принимаем решение, что некоторый кадр мы отнесли к 10-му VLAN, то мы не будем отправлять копии этого кадра на те порты, которые не подключены к 10-му VLAN. К 10-му VLAN подключен этот access-порт и этот транк. Здесь другой транк, который к 20-му, к 30-му VLAN подключен. И здесь тоже транк, который к 20-му, к 30-му VLAN подключен.

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

Если мы говорим, что на некотором порту можно принимать не все VLAN подряд (а по умолчанию именно так), а только некоторые, то вы можете использовать команду switchport trunk allowed VLAN и дальше указать, какие VLAN вы хотите на порту обрабатывать. Здесь есть два варианта. Первый вариант — просто через запятую или через диапазон, допустим, 10, запятая, и с 20-го по 30-й — все VLAN разрешить на порту. Либо вы можете воспользоваться макросами, и макросы есть: добавить к существующему списку или убрать из существующего списка перечисление нужных вам VLAN. У вас есть, например, транковый порт, и на нём разрешены 10-й, 11-й и 12-й VLAN, и вы хотите к ним добавить ещё 20-й. Вы говорите switchport trunk allowed VLAN add 30. И у вас автоматически к существующему списку добавляется 30-й VLAN. Или то же самое — удалить. Вы говорите: есть сейчас список — 10-й, 11-й,

12-й, 30-й. Вы хотите, чтобы 12-й VLAN из списка убрался. Можно написать в явном виде switchport trunk allowed VLAN 10, 11, 30. Но если у вас достаточно большой список, то вы задолбаетесь это делать вручную. Вы можете сказать switchport trunk allowed VLAN remove 12. Эти макросы с одной стороны довольно удобны, а с другой стороны они очень опасны. Проблема в том, что рано или поздно вы обязательно столкнётесь с ситуацией, если вы часто эту штуку делаете, что вы забудете слово add или remove. И у вас команда «добавь к существующему списку 30-й VLAN» превратится в, сами понимаете, «разрешён только 30-й VLAN». Это замечательный способ выстрелить себе в ногу из дробовика, или даже не в ногу, а сразу в две ноги, сразу в половину туловища, потому что вы теряете управление менеджмент VLAN, и у вас там всё сразу пропадает. Поэтому так делать можно, но с очень большой осторожностью. У Cisco просто неудобно это сделано,

откровенно неудобно. Я бы даже сказал, опасно. Если вы включаете транк, то команда show interface switchport вам даёт много всякой разной полезной информации. Administrative mode — как админ сказал работать. Транк, значит, кадры-мутанты разрешены. Operational mode — что по факту есть. Как админ сказал, так и работает. Мутанты разрешены. Administrative trunk encapsulation. Какой режим работы выбрал для транка администратор? Мы жёстко прибили гвоздями 802.1Q, потому что у нас есть выбор либо ISL, либо 802.1Q. Как по факту работает? Как админ сказал, так и работает. Почему здесь есть выбор между одним и другим вариантом? Между тем, как админ сказал, и как по факту работает? А потому что по умолчанию на всех свичах у нас такой неопределённый режим. Он называется динамический, а по факту это такой режим Шрёдингера. Может быть access, а может быть trunk. Если у вас поддерживается 802.1Q и ISL,

то если вдруг включается такой динамический транк, то он может включиться как ISL-овский, так и 802.1Q-ный. По умолчанию он как раз такой транк Шрёдингера. Он и будет неизвестный по факту даже. То, что там получится, заранее непонятно. И по умолчанию, если вы посмотрите на новый порт, это будет show interface switchport, там будет показываться, что administrative trunk encapsulation — типа само решит. Какая разница, мальчик-девочка — вырастет, само решит. А operational trunk encapsulation — это как раз что по факту получилось. Либо мальчик, либо девочка. Либо ISL, либо 802.1Q. Либо ещё бывает native. То есть транк вообще не согласовался. Negotiation of trunking. Следующая строчка — это про то, будет ли работать автоматическое согласование trunk или нет. Эта штука очень и очень опасная. Она по умолчанию есть на всех портах. И если у вас работает автоматическое согласование trunk,

то гипотетически ваш порт может стать trunk в любой момент. Но если вы ему задали жёстко ручками trunk, то это не страшно, потому что он уже стал trunk. Проблемы это особо не создаёт. А вот если у вас обычный пользовательский порт, и вы забыли на нём ручками прибить режим access, то это действительно может стать проблемой. Потому что пользователь с использованием хитрой техники может заставить switch смотреть на него trunk-овым портом. И, как правило, там будут все-все-все виланы в нём разрешены. Поэтому ваш пользователь, если вы ему сказали, ты будешь водителем, ты получишь по умолчанию доступ только к вилану водителей. Вы на нём взяли и забыли сказать switchport mode access, вы прописали только switchport access вилан водительский. Пользователь говорит, а я сейчас возьму хитрую команду, выполню и заставлю switch на меня смотреть trunk. И он тогда во все-все-все виланы попадает, включая секретные виланы бухгалтерии. Поэтому очень опасная штука, и нужно знать про неё, нужно всегда фиксировать режим работы порта ручками.

Access mode вилан есть, но не работает, потому что порт не находится в access вилане. Trunking native mode вилан. Здесь показывается 30-й вилан и в скобочках inactive. Это значит, что этого вилана нет в базе. Если у вас есть вилан в базе, то показывается его имя. Дефолт для первого вилана или для тех виланов, которые вы создаёте, те имена, которые вы им задаёте ручками, или по умолчанию там вилан и четырёхзначный номер вилана. Но если в скобочках показывается inactive, значит, такого вилана в базе нет. И это одна из техник, которые можно использовать для того, чтобы никогда, ни при каких условиях, этот самый native вилан у вас не задействовался для отправки кадров. Это одна из рекомендаций, которые вы можете встретить. Ещё одна рекомендация может быть то, что вы скажете, не знаю, 666 вилан, который у вас в базе есть, но он будет выключен, команда shutdown, и тогда дайте ему какое-нибудь имя, чтобы было говорящее имя,

чтобы было понятно, что такой вилан не должен использоваться для боевого трафика. Здесь trunking vlans enabled — это то, какие виланы вы разрешили в trunking. Логичное вполне название. Если у вас всё работает хорошо, то вы все абонентские порты должны будете загонять в режим static access, а все транки между коммутаторами, все порты между коммутаторами у вас должны быть в транках. На цисках по умолчанию работает дурацкий протокол DTP, dynamic trunking protocol, который как раз автоматически согласует такое поведение, чтобы абоненты у вас работали в access, а порты между коммутаторами автоматически становились транками. Если на порту вы обнаруживаете соседа с поддержкой DTP, вы со своей стороны можете автоматически включить trunking, если захотите. Эта штука работала, хорошо работала 20 лет назад, 30 лет назад, когда про безопасность никто особо не думал,

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

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

которая выработалась за 20-30 лет, что вы подключаете новую Cisco, она автоматом trunk поднимает. Вы достали старую Cisco, включили новую, и они у вас действительно trunk поднимут. Последние лет 10 поведение по умолчанию совершенно точно уже такое, что DTP работает в таком полудохлом состоянии. Это такая бомба замедленного действия, которая ждёт своего часа, и когда попадётся вам атакующий, который попытается вас взломать через DTP, у него это получится, если вы не зафиксировали режим работы ручками. Включение DTP, если вдруг вы почему-то захотите его использовать, будет осуществляться командой switchport mode dynamic, и дальше один из двух вариантов, либо desirable, либо auto. DTP не надо использовать. Вы должны будете switchport mode access включать на абонентских портах, тем самым автоматически говоря, что не надо там использовать DTP, он там выключается, и никакой trunk автоматически согласовать уже не сможет.

Равным образом, если у вас есть trunk-овые порты, которые смотрят на соседей, DTP там не нужен. Вы ручками прибиваете trunk гвоздями, явно выбираете режим работы этого trunk, явно выбираете, что этот trunk будет работать, DTP там тоже не нужен. В такой ситуации получается, что DTP не нужен вообще. Если вы хотите, вы можете на trunk-овом порту DTP выключить, прямо активно выключить, потому что он вам там не сильно полезен. А если не полезен, нафига там лишние пакеты тратить? Не то чтобы он прямо сильно мешал на trunk-овом порту. Можете выключить, можете не выключать. Если захотите, есть команда switchport nonegotiate, которая его выключает. Режим по умолчанию — это switchport mode dynamic auto на современных цисках. И если у вас есть две циски, которые друг на друга смотрят, они друг на друга смотрят в этом режиме dynamic auto, и они так переглядываются лениво, говорят, мне не надо, тебе тоже не надо, давай не будем trunk поднимать. И вы можете перевести циску в режим dynamic desirable,

и они тогда прямо активно будут хотеть поднять trunk, как это происходило раньше, 20 лет назад. Вы брали циску с dynamic desirable, и с другой стороны, неважно, что было, что поддерживало бы протокол DTP, хоть другой desirable, хоть auto, тогда у вас trunk с обеих сторон поднимался. Зачем нужен DTP на trunk-овом порту в switchport mode trunk? Затем, что если вдруг вы берёте с одной стороны на циске, фиксируете жёстко switchport mode trunk, а с другой стороны просто подтыкаете хоть какую циску в состоянии по умолчанию, где dynamic auto стоит, у вас dynamic auto автоматически становится trunk. С одной стороны включили trunk, а с другой стороны он сам включился. Поведение, на мой взгляд, абсолютно неестественное для современного предприятия, потому что если вы настраиваете сеть предприятия, вы с одной стороны задали режим работы trunk, и с другой тоже задаёте режим работы trunk, и DTP там, опять же, не нужен. Поэтому рекомендация — выключать его на абонентских портах,

а на trunk портах пусть работает, в принципе не сильно мешает, не полезен ничем, мешает тоже вроде ничем, особо не мешает. Рекомендация — выключайте везде DTP, на статических trunk бесполезен, а на абонентских портах прямо откровенно вреден. Поэтому switchport mode access на абонентских портах вы обязательно фиксируете в режиме access. Равным образом не задействованные порты, если у вас просто свободный порт, в который ничего не воткнуто, тоже фиксируйте их в access. Они могут быть не в VLAN, но всё равно дайте команду switchport mode access, чтобы если вдруг туда что-то воткнулось потом, оно бы не попало в какой попало VLAN. Дальше. До своих свитчей ставьте trunk, причём trunk фиксируете в 802.1Q, никакого ISL, и если вы включаете trunk, то, соответственно, фиксируете одинаковые native VLAN, лучше отсутствующие в базе или выключенные командой shutdown, и сделайте так, чтобы у них был одинаковый набор allowed VLAN.

Вы можете быстренько посмотреть команду show interfaces trunk, которая покажет вам список тех интерфейсов, которые у вас по факту организовались в trunk, те, на которых по факту trunk включён. Показывается 4 графы. Первая графа, табличка, здесь нам показывается, что у нас 2 trunk: GigabitEthernet 0/0, GigabitEthernet 0/1. На GigabitEthernet 0/0 мы жёстко пришили его командой switchport mode trunk, поэтому он показывает режим on, это безусловный trunk. Показывается, в каком режиме этот безусловный trunk работает — в 802.1Q, и показывается native VLAN, который у нас используется. Вторая строчка, GigabitEthernet 0/1, которая показывает, что у нас desirable режим, это динамическое согласование trunk, мы переключили порт в desirable, и он у нас действительно согласовал trunk, с той стороны обнаружилась циска и согласовала нам trunk. Encapsulation — если вы видите n-ISL или n-802.1Q,

это автоматически согласованный тип trunk, не просто у нас согласовался trunk автоматически, а ещё и сам тип согласовался автоматически, его не задавал администратор вручную, и на цисках по умолчанию, если у вас поддерживается и ISL, и 802.1Q, и у вас работает DTP, то выбирается автоматически ISL. Дальше вторая графа — это какие VLAN разрешены на порту, switchport trunk allowed VLAN — что вы там написали, то и показывается. Третья графа — пересечение этого множества с тем, какие вы вообще VLAN создали, то, что вы на порту сказали, что можно использовать 10, 20, 30 VLAN, не означает, что по факту трафик 10, 20, 30 VLAN там может ходить, потому что если вы не создали 20-й и 30-й VLAN, то они там ходить и не будут. Поэтому пересечение этого множества с базой VLAN даёт вам этот результат. И для второго порта тоже. По умолчанию

все VLAN разрешены в trunk, и для GigabitEthernet 0/1 мы никакие switchport trunk allowed VLAN не задавали, там динамически согласовался trunk, поэтому скорее всего конфигурация дефолтная, и это действительно дефолтное состояние, что все VLAN в trunk разрешены. Но пересечение всех VLAN с теми VLAN, которые по факту созданы в базе, даёт нам скромненько два VLAN — первый и десятый, потому что только они и созданы. И, наконец, про протокол Spanning Tree мы будем с вами говорить на курсе ICND2, но пересечение третьей графы — первая графа, вторая графа, третья графа и четвёртая графа. Пересечение множества третьей графы с тем, что посчитал Spanning Tree, даёт нам четвёртую графу. Если нам Spanning Tree в GigabitEthernet 0/0 порту, допустим, разрешил использовать 10-й VLAN, то здесь показывается. Если нам здесь, GigabitEthernet 0/1 порт не разрешил использовать ни первый,

ни десятый VLAN, то нам здесь, соответственно, ничего не показывается. Поэтому, VLAN первый и десятый в базе есть. Оба этих VLAN разрешены к использованию в switchport trunk allowed VLAN, но по факту трафик ходить не будет, потому что Spanning Tree нам это всё дело поблокировал. Про Spanning Tree — отдельная история будет на ICND2. Если у нас есть свитчи, то про trunk на свитчах я вам рассказал. Если у вас есть маршрутизатор, то VLAN с ним работать могут на цисках, но немножко специфически. Там не просто уже switchport trunk, там немножко по-другому это выглядит. Дело в том, что если у вас есть свитч, и у этого свитча есть виртуальные свитчи, которые вы создаёте, есть один провод, который вы будете отправлять, и, соответственно, у вас фактически получается, что есть роутер, который подключается к свитчу, рисую роутер, а это у нас свитч,

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

будет обрабатываться не физическим интерфейсом, а логическим интерфейсом, в который мы направим кадры разных Виланов. То есть мы создаем отдельный виртуальный интерфейс 10-го Вилана и отдельный виртуальный интерфейс 20-го Вилана. И вот на вот эти дочерние интерфейсы мы будем назначать IP-адреса, будем назначать всякие политики обработки трафика, будем назначать правила Quality of Service. То есть все будет обрабатываться в вот этих вот отдельных, дочерних так называемых субинтерфейсах. И создаются они следующим образом. Вы просто указываете интерфейс, дальше название физического интерфейса, в нашем случае Gigabit 00, дальше точка и некое число. Вот это вот число — это номер субинтерфейса. Оно не обязано совпадать с номером Вилана, но оно удобно, когда совпадает с номером Вилана, потому что вы имеете меньше шансов запутаться. Отдельно, если у вас номер Вилана 435-й, и отдельно номер субинтерфейса 11-й, ну вот запомнить, где что,

это будет очень тяжело. Поэтому если совпадает номер субинтерфейса и номер Вилана, это удобно, это, соответственно, рекомендуется к использованию. Далее. Мы создаем субинтерфейс Gigabit 00.10. Мы говорим, что в этот субинтерфейс, логический интерфейс, будет попадать не весь трафик, который вообще гипотетически может прийти, а только тот, который приходит с а. 802.1Q-шной меткой, и б. с меткой с 10-м Виланом. encapsulation.1Q10. Приглашение к вводу здесь меняется на конфиг субив. Это вот как раз намекает на то, что вы находитесь в контексте обработки субинтерфейса и там указываете encapsulation.1Q10. В этом же контексте вы назначаете айпишники, в этом же контексте вы делаете, соответственно, все свойства, которые будут применяться для трафика. Еще раз подчеркну, не на физическом интерфейсе. На физическом интерфейсе только на ушатдаун и больше ничего. Вся логика, она должна вот на логическом интерфейсе происходить.

Туда всякие фильтры, аксесс-листы, правила quality of service, вот все туда. И получится, что вот у вас есть один отдельный физический интерфейс, который смотрит 10-й Вилан, и отдельный физический интерфейс, который смотрит 20-й Вилан. Если вам нужно, к примеру, по скорости ограничить трафик 20-го Вилана, вот именно сюда вы должны назначать ограничитель скорости. Если вам нужно на 10-й Вилан ограничитель скорости сделать, значит на 10-й Вилан. Так. Далее. Айпишники тоже, соответственно, тоже именно на дочерние субинтерфейсы. На физику мы ничего не прописываем, только на ушатдаун и больше ничего. Если вы выключите родительский интерфейс, то все выключится, сама физика выключится, естественно, логические субинтерфейсы тоже выключатся. Можно выключить отдельный субинтерфейс, но нельзя выключить физику. Ну, или можно, но она выключит все. Все, что относится к конкретному Вилану, все вы на отдельных субинтерфейсах будете сдавать.

Если вдруг вы работаете с Native Виланом вопреки рекомендациям, то вы можете сделать это двумя способами. Первое. Вы можете, если захотите, на физическом интерфейсе сдать какие-то настройки, типа там айпишники или что-то еще, но это плохая практика, не рекомендуется так делать. Рекомендуется сделать отдельный субинтерфейс и прописать на нем команду encapsulation.1q, дальше номер Вилана, который по факту со стороны свеча задан как Native, и задать ключевое слово Native. Почему рекомендуется делать именно так, а не как-то иначе? Дело в том, что для Native Вилана мы говорим, что у нас кадры Native Вилана могут приниматься без метки или могут отправляться без метки. Но также они могут отправляться и с меткой. То есть если у вас есть пользователи 10-го Вилана и пользователи 20-го Вилана, и есть транк, и мы говорим, в этом транке 10-й Вилан, типа у нас Native, мы со своей стороны можем отправлять кадры 10-го Вилана без метки вообще, или мы можем, в принципе,

отправлять кадры 10-го Вилана с меткой. Гипотетически мы можем это сделать. Поэтому для того, чтобы вот кадры, которые вроде как к Native Вилану относятся, но при этом уходят с меткой этого Вилана, чтобы их обрабатывать, как раз вот эта вот конструкция и будет использоваться. Она будет и кадры без метки ловить, и кадры с меткой 10-го Вилана. Она более правильная, более корректная. Так, давайте мы с вами лабораторную работу на это сделаем в курсе ICD2. То есть я просто обещаю вам, что на этом курсе, на ICD2, у нас точно будет ровно то же самое. То есть все эти слайды, честное слово, они будут повторяться. Только там у нас будет еще и Spanning Tree, поэтому мы сможем пощупать это чуть более детально. Спасибо. Спасибо. Спасибо.