VLAN (часть 2)

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

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

То есть если вы указываете switchport mode access, это фиксирует состояние Аксесс. Если вы указываете на порту switchport access VLAN и дальше какой-то номер VLAN, это ничего не означает, потому что порт может находиться в транке, тогда эта команда в конфигурации будет. А вот при этом, соответственно, применяться она на самом деле не будет. Здесь у нас показан пример, как можно на интерфейсе настроить режим switchport mode access и прописать switchport access VLAN. Но я думаю, что вы с CCNA это примерно помните. Для того, чтобы посмотреть на состояние коммутации на интерфейсе, у нас используется команда showinterface чего-то там switchport. Она покажет много разного интересного, в том числе информацию про коммутацию на порту. Здесь мы можем увидеть следующее значение. Первое. Мы пока посмотрим administrative mode. Это как администратор настроил этот порт. То есть администратор сказал, что этот порт будет в Аксессе.

Значит, вот мы по факту должны быть в Аксессе. Как администратор сказал, так и работает. Administrative mode. Это что администратор сказал? Operational mode как по факту работает? Это как раз два различных свойства интерфейса. Потому что администратор может сказать, что мне все равно, как он будет работать. И по умолчанию как раз используется именно такой режим. То есть мы говорим, что на порту у нас может согласоваться транк, может согласоваться Аксесс. Администратор в принципе не требует какого-то конкретного задания режима. И поэтому operational mode либо Аксесс, либо транк, а administrative mode будет черт его знает, что такое. Дальше. Показывается access mode VLAN. Вот эта вот строчка указывает, в каком VLAN будет обрабатываться каждый приходящий кадр, если он придет на этом порту. Метки на нем не будет. В нем не будет нигде написано, что это кадр 10-го VLAN. Но мы за счет того, что у нас прописано switchport access VLAN 10, будем обрабатывать все приходящие кадры по таблице 10-го VLAN. И в скобочках показывается название этого VLAN.

Что на самом деле очень удобно в ситуации, если у вас этих самых VLAN много. Если VLAN в базе нету, то есть вы прописываете switchport access VLAN 10, и у вас порт находится в абонентском, в аксессовом режиме, но 10-го VLAN в базе нет, в скобочках будет показываться inactive. То есть если вы видите inactive, значит кадры будут обрабатываться по таблице 10-го VLAN, но таблицы 10-го VLAN в базе нету, поэтому все кадры будут дропаться. Никто вам не запрещает прописать switchport access VLAN 10 на порту и не создавать 10-й VLAN в базе. До 12-го IOS включительно switchi автоматически VLAN не создавали, когда вы прописывали switchport access VLAN дальше номер на интерфейсе, и вот этого VLAN не было в базе. То есть они просто тихо принимали эту команду, у вас в скобочках показывалось inactive на команду show interface switchport, и просто коммутация на этом порту не осуществлялась. Актуальное поведение новых свитчей с новыми IOS-ами другое. Если вы задаете команду switchport access VLAN и дальше номер VLAN,

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

Вот если вы 802.1Q будете делать заголовок, то там 4 байта после MAC адресов получатель источника. Если вы ISL делаете, то это другой формат кадра, другое место, куда записывается номер VLAN. И надо указать, соответственно, куда и в каком формате вы это дело пишете. Если вы просто без каких-либо настроек укажете switchport mode trunk, то на порту система не примет у вас эту команду, скажет сначала задайте trunk. И предварительно перед switchport mode trunk надо выполнить команду switchport trunk encapsulation. И дальше либо .1Q, ну тут понятно, 802.1Q, либо ISL, соответственно. Фирменный цисковский стандарт. Если вы указываете ISL-овский trunk, то на порту больше ничего особо делать не нужно. Ну, в смысле, можно, но не обязательно. Если вы задаете 802.1Q-шный trunk, то следует также прописать, какой VLAN будет native. Вы можете использовать команду switchport trunk native VLAN. И дальше вы указываете номер VLAN. Опять же, да, все кадры, которые будут отправляться в этом VLAN,

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

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

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

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

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

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

Заголовок срезается в момент получения кадра на транковом порту. Дальше кадр коммутируется без 802.1Q-тюшного заголовка. Кадр при этом относится к определенному VLAN-у, но момент, в который мы определили, в каком VLAN-е кадр будет обрабатываться, в этот момент заголовок 802.1Q-тюшный становится не нужен, и он отрезается. То есть не путайте, пожалуйста, то, что Switch знает, в каком VLAN-е находится кадр, и то, что там у него есть какой-то заголовок 802.1Q-тюшный, нет, это разные вещи. Как можно проиллюстрировать то, что на самом деле это действительно разные заголовки? Что один заголовок мы отрезаем на входе, а потом другой заголовок мы вешаем на выходе. А вы можете очень легко себе это представить, если у вас есть другой транк, не 802.1Q-тюшный, а ASL-овский. То есть это просто в принципе не получится взять, получить кадр по одному транку, потом его без изменений передать в другой. Поэтому в какой-то момент мы должны будем 802.1Q-тюшную голову отбросить, и Switch делает это в самом логичном месте.

Он отбрасывает 802.1Q-тюшный заголовок на входе, на получение этого кадра на интерфейсе. Как только мы узнали, в каком VLAN-е кадр передавался, все, 802.1Q-тюшный заголовок больше не нужен, он отбрасывается, и кадр дальше обрабатывается, как любой другой кадр. Мы понимаем, в какой таблице его обрабатывать, но это просто самый обычный кадр без каких-либо видов изменений. Поэтому существует 802.1Q-тюшный заголовок только в момент передачи кадра по транковому порту. Он добавляется в момент начала передачи, и в момент получения он отрезается. Так вот, настройки на обоих коммутаторах, на обоих портах, которыми они друг на друга смотрят, естественно, должны быть одинаковые. То есть вы должны будете с одной стороны задать режим работы, и с другой стороны задать режим работы одинаковый. Ну или если у вас будет использоваться автосогласование, вы можете положиться на то, что фирменный цисковский протокол DTP, Dynamic Trunking Protocol, может согласовать вам режим работы транка, но для этого у вас режим работы порта должен быть динамический.

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

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

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

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

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

который скажет, что а я хочу прыгнуть в 50-й VLAN, а в 50-м VLAN у вас, не знаю, какая-нибудь бухгалтерия черная, то, соответственно, пользователь, он каким-либо образом заставив свеч думать, что он действительно имеет отправлять кадры 50-го VLAN, он получит доступ ко всем VLAN в транке, которые будут передаваться между несколькими свечами. Поэтому если вы скажете, что в этом транке ограниченное количество VLAN может быть, то, соответственно, пользователь хоть обуказывается, что он в 50-й VLAN хочет попасть, в этом случае просто кадры ненужных VLAN в транке передаваться не будут. Мне дали в DC кабель, сказали, вот, держи на нем гейтвей и твоя сетка. Я могу их попросить сделать на гейтвей какой-нибудь VLAN, чтобы убрать VLAN-1 с коммутатора. Ну, вы имеете в виду, что они бы в проводе, в котором они вам дают, принимали бы метки 802.1Q-шные?

Ну, можете, наверное. Опять же, все зависит от оборудования. Но, в принципе, если у них там какой-то продвинутый достаточно коммутатор или маршрутизатор стоит, как правило, такие железки, они вполне могут работать с 802.1Q, то есть что циски, что джониперы, и маршрутизаторы, и коммутаторы вполне могут работать с метками 802.1Q. Так, по поводу, значит, VLAN-ов этих самых в транке. Вы должны будете указывать, какие VLAN-ы у вас разрешены в транковом порту, и имейте, пожалуйста, в виду, что это, вот, да, самый популярный способ выстрелить себе в ногу с дробовика. Если вы работаете с коммутаторами, вы указываете команду switchport-tran-collout-vLAN, и дальше вы указываете номера VLAN-ов. И здесь есть страшный макрос. Макрос, который называется ADD. То есть если вы просто пишете в списке номера VLAN-ов, которые вы хотите передавать на порту, эта штука работает, с ней все в порядке,

но рано или поздно вы задалбываетесь с этим списком работать, вы говорите, а вот бы мне как-нибудь сделать так, чтобы добавить номер VLAN-а к существующему списку, и при этом не испортить существующий список. И вот макрос ADD делает ровно это. Вы указываете, что у вас есть allowed VLAN на порту, там 10-20, потом говорите ADD 30. Switchport-tran-co-laut-vLAN ADD 30. Так вот, если вы случайно забудете ADD, то вы затрете весь свой старый список, который у вас был, и, соответственно, вот если вы напишете VLAN просто 30 без ADD, то, соответственно, вот все, что раньше там было сконфигурировано, оно у вас пропадет. Наверное, практически каждый, кто настраивал цисковские свечи, накалывался на эту бомбу замедленного действия и забывал этот самый макросад. Да, ну вот плюсики. Чувствую, что есть уже пострадавшие. Очень неудобный синтаксис. Циска сделала прям максимально неудобную конфигурацию. То есть, да, она хотела, конечно, сделать как лучше, а получилось как всегда.

Вот. Ну, есть и другие макросы. Там есть remove, есть суперподстановки all, которые по умолчанию, что на транке разрешены все VLANы, суперподстановка none, значит, никакие не разрешены, и, соответственно, except – это все, кроме заданных. Я, да, рекомендую вам всегда пользоваться только вручную заданным списком. Можно ли использовать зарезервированные VLANы для native? Не вижу причины. Нет, подожди, тысяч четыре? Нет, нельзя. Тысяч четыре вообще запрещено. То есть, тысяча второй, тысяча тридцать, тысяча четвертый, тысяча пятый VLANы, просто забудьте про них, они вам недоступны, вы ничего с ними сделать не можете. Не можете их назначить на порту, не можете никак с ним отсылаться. Ну, то есть, да, если вы работаете с сетью на оборудовании циска, просто у вас этих номеров нет. Если вы работаете с оборудованием других вендоров, вы можете использовать тысяча второй, тысяча тридцать, тысяча четвертый, тысяча пятый VLANы,

но, соответственно, вы себя сразу ограничиваете в том, что никогда ни при каких условиях циски на этих в этой сети появляться будут не должны. Команду вы примете, но, соответственно, работать эти VLANы не будут. В некоторых случаях даже команда не примется. То есть, вы пытаетесь использовать что-то с этими самыми номерами VLANов, а система говорит, извините, это вот специально особенные VLANы, мы с ними работать не сможем. Для native VLAN, в принципе, это неплохой вариант, если вы укажете, что тысяча четвертый номер будет, ну, потому что native всегда здорово делать такой, который в сети заведомо не появится. Поэтому, если вы скажете, что у вас native будет тысяча четвертый, и действительно команда примется, и ругаться она при этом не будет, то, ну, да, вы получите как раз ожидаемое поведение, что никогда ни при каких обстоятельствах кадры без метки на этом порту ниоткуда не возьмутся, а если даже возьмутся, будут расстреляны на подлете. Это как раз рекомендуемое поведение.

По поводу выключенных VLANов есть даже рекомендация, на самом деле, выключать тот VLAN, который у вас будет native, если вы его делаете из обычного нормального списка VLANов, для того, чтобы никогда ни при каких условиях кадры без метки у вас не коммутировались. Если у вас нет команды VLAN .1Q tag-native, то, соответственно, вот такими вот костылями, что VLAN выключить, использовать заведомо несуществующие, никогда пользователей в этом VLAN не заводить, вот вы можете ограничить возможность атаки на вашу среду коммутации. Так. Команда Show Interface Switchport по-прежнему работает для транков. Соответственно, все кадры, на которых коммутация осуществляется, то есть когда у нас кадры приходят, мы говорим, окей, мы сейчас будем коммутировать этот кадр, мы его отправляем на движок коммутации, который потенциально готов распихать кадры по всем портам, но дальше начинает смотреть на каждом порту, надо ли копию кадра отправлять в каждый конкретный вот этот вот порт.

Это мы видим с помощью строчки Switchport Enable, то есть у нас коммутация на этом порту осуществляется. Administrative Mode – это как администратор сказал работать, мы включили static trunk. Operational Mode – как админ сказал, так и работает. Administrative Trunk Capsulation – как администратор сказал, в каком типе транка работать, ну, в нашем случае 802.1Q. Operational Trunk Capsulation – что по факту работает? Ну, то и работает. Если вы включаете trunk, там автоматически не выключается согласование trunk, и поэтому там работает протокол DTP – Dynamic Trunking Protocol. Ну, соответственно, да. Протокол этот есть, мы про него дальше будем говорить. Access Mode VLAN. Ну, в нашем случае мы видим, что у нас есть команда Switchport Access VLAN 10 на порту, но она не работает, потому что порт работает в trunk. В то же время trunk – native mode VLAN 30, который отсутствует в базе.

Вот здесь мы видим, что была прописана команда Switchport trunk native VLAN 30. Такого VLAN в базе нету, показывается в скобочках inactive. Administrative native VLAN tagging enabled указывает на то, что мы пытаемся отправлять кадры native VLAN все равно с метками. Вот это поведение как раз можно будет встретить с помощью команды VLAN.1Q tag native. Дальше. Trunking VLANs enabled – это вот тот самый прунинг, ручной прунинг. Не обращайте внимания на слово прунинг вот здесь. Вот это для протокола VTP – VLAN Trunking Protocol, который тоже фирменный цисковский, как и DTP. Вот VTP – это еще один протокол. Мы тоже его обязательно будем смотреть в курсе. Ну и команда Show Interface Trunk покажет вам список всех интерфейсов, которые по факту работают в режиме Trunking. Она покажет четыре раздела. В каждом разделе будут перечислены все порты, которые в Trunking работают.

В нашем случае мы видим, что здесь у нас по два порта есть. Gigabit 0.0 и Gigabit 0.1. Gigabit 0.0 является Trunk, потому что на нем включен статический Trunk. Тип инкапсуляции, как админ сказал, так и работает. M802.1Q, NETI FLAN 30. Gigabit 0.1 образовался в Trunk, потому что там работает автосогласование. Вот это вот Desirable – это динамический режим согласования Trunk, и там согласовался ISL-овский Trunk. Если вы видите вот N чего-то там, NISL или N802.1Q, то это автоматически согласованный тип Trunk. DTP умеет согласовывать его самостоятельно. Ну и вот он там согласовал NETI FLAN 1. Напротив каждого VLAN показывается, какие VLAN разрешены, то есть какие Switchport Run Callout VLAN команды были прописаны на порту. Дальше. Среди всех VLAN, которые разрешены на порту, какие активные существуют в базе. Вот мы видим, что 10, 20, 30 прописаны. 10 есть в базе, 20 и 30 нет.

Поэтому здесь только 10. Ну и потом показывается, какие VLAN не заблокированы с Panning 3. Вот в нулевом, в Gigabit 0.0, 10 VLAN не заблокирован, а в Gigabit 0.1 вообще все VLAN заблокированы. Следующая тема у нас будет, ну как не тема, продолжение банкета, да, будет про Voice VLAN. На самом деле штука, которая постоянно у всех вызывает дискомфорт, потому что она немножко нелогичная. Да. Что это такое? Voice VLAN – это режим работы порта, при котором цисковский Switch Catalyst будет на порту отрабатывать кадры двух разных VLAN. Но при этом это будет не транк. В нормальной ситуации, как вы помните, у нас транк будет такой порт считаться, который анализирует приходящие кадры и смотрит на метку VLAN.

И по метке VLAN определяет, куда такой кадр будет посылаться, то есть по какой таблице его обрабатывать. То есть мы этой метке VLAN доверяем, и мы эту метку читаем, и пытаемся определить, на какой виртуальный коммутатор отправит такой кадр. В случае с Voice VLAN это не транк. То есть сама циск эту штуку называет мультивилан порт. VLAN – это такое интересное обозначение, которое будет указывать на то, что вы по факту меткам этим самым верить не будете. У вас есть кадры, которые на порту приходят без метки. Это просто самые обычные кадры, которыми вы подключаете пользовательский компьютер в разрыв через телефон циска. И компьютер отправляет эти кадры просто самые обыкновенные, телефон эти кадры просто дальше самые обыкновенные, фарвардзит, как ни в чем не бывало, и на коммутатор такие пользовательские кадры будут приходить без каких-либо меток. Ну и, соответственно, мы на порту прописываем switchport mode access,

switchport access VLAN, там, допустим, 10, и кадры, которые без метки приходят, мы обрабатываем по таблице 10 VLAN. То есть так же, как в случае с ситуацией, когда мы просто пользователя подключили напрямую в порт. Ну вот, сам телефон, который в разрыв может включаться на таком порту, он должен будет отправлять какие-то кадры, и эти кадры должны будут обрабатываться свечом более приоритетным образом. Какие у нас здесь есть варианты, как сделать так, чтобы кадры телефонные обрабатывались в приоритете? У нас первый вариант есть по-честному классифицировать трафик. То есть мы принимаем кадры, мы смотрим, не IP ли там внутри лежит. Если IP, то, соответственно, смотрим, что внутри лежит. Не UDP ли. Если мы видим UDP, расковыриваем, смотрим номера портов, и дальше видим, что номера портов там, допустим, UDP-шные, четные. И мы говорим, судя по тому, что это UDP-шные, четные порты в определенном диапазоне, это по ходу RTP-шный трафик. Дальше смотрим, заголовок там есть какой-нибудь похожий на RTP? Ну, окей, значит, есть заголовок,

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

будет производиться с помощью наличия 802.1-кьюшного заголовка. Что вы там внутри напишите в 802.1-кьюшном заголовке? По факту пофигу. То есть это просто флажок, который вы вешаете на кадр, и тем самым вы даете понимание свитчу, что этот кадр голосовой. Обычные нормальные кадры бегают без метки, и они так без метки добегают до свитча, а кадры 802.1-кьюшные, которые прибегают на порт свитча, неважно с какой меткой голосовой, неважно с какой меткой VLAN они будут, они будут голосовые. И коммутатор по признаку «это пришло с меткой 802.1-кью» может сказать «Окей, мы понимаем, что это голосовой кадр». Не расковыривая внутри IP ничего, не расковыривая UDP, несмотря на заголовки RTP, мы говорим, что «это пришло от телефона» просто по наличию 802.1-кьюшного заголовка, который нам пользователь не отправляет. Вы можете в случае, если вы хотите использовать voice VLAN,

обрабатывать такие кадры голосовые по отдельной таблице. То есть это довольно частое явление, когда у вас компьютеры сидят в одном VLAN, а вот как бы телефоны сидят в другом VLAN, и кадры, которые они отправляют, обрабатываются по таблице другого VLAN. То есть в этом другом VLAN, например, в нашем случае 20, мы указываем switchport voice VLAN 20. Мы говорим, что, соответственно, телефон будет получать другие IP-шники, не такие же, как абоненты. У них будет там другой шлюз по умолчанию, у них будут другие DHCP-настройки. И это вполне логичная штука, потому что телефон, например, вы должны будете выдать адрес TFTP-сервера. Там опция либо 60, либо, какая там, 121-я. TFTP по имени или TFTP по IP-шнику. Для того, чтобы он оттуда загрузил конфигурацию, для того, чтобы он оттуда загрузил обновление прошивки. Ну, то есть вы обычно компьютерам эти штуки отдавать не хотите. И как раз очень удобно просто сказать, что у нас есть отдельный VLAN с телефони, и в этом VLAN у нас бегает просто специальный,

отдельный выделенный DHCP-сервер для телефонов. Ну, и в обычном VLAN, который не размечен, в нашем случае 10-й аксессовый VLAN, который передается без метки, у нас другие настройки, которые характерны именно для компьютеров. Вот еще раз подчеркну, это не TRUNK. Он выглядит как то, что порт, в котором отправляются некоторые кадры с метками, но при этом мы этим меткам не доверяем. Мы не верим тому, что там внутри написано. Мы говорим, что если что-то по факту пришло с меткой 20-й, то мы эту 20-ю метку прописали в явном виде, что мы ее согласны принимать. Мы, если видим какую-то метку, мы говорим 20-я, окей, это voice VLAN, мы его обрабатываем. Если там будет приходить 30-е, 40-е, 50-е VLAN, неважно какой, мы, соответственно, этой метке верить уже не будем. Это по факту, по поведению, аналогично будет настройки, если бы вы сделали TRUNK-овый порт, и в этом TRUNK-овом порту switchport TRUNK-Allowed VLAN запретили все, кроме одного VLAN-нэйтива

и одного VLAN-для голосовой связи. Ну, то есть, да, если вы такое сделаете, поведение портов не будет отличаться между собой. Но вот если вы делаете аксессовый порт свой с VLAN-ом, то вы там, в принципе, не имеете возможности никакие другие VLAN-ы больше разрешить. Вот только эти два, и все, и больше никакие другие. Конфигурация будет иметь вид. Switchport Access VLAN такой-то, Switchport Voice VLAN другой. Да. Для того, чтобы это все заработало, вы должны будете телефону каким-то образом сообщить, что кадры, которые он будет отправлять, должны будут маркироваться 802.1-Q-шным заголовком, и, соответственно, это будет именно 20-й VLAN. Чаще всего, если говорить про Cisco, вы будете использовать протокол CDP для этого, потому что... Ну, то есть можно это, конечно, в конфигурации выплюнуть в DHCP-настройках и сказать, что дорогие телефоны, все, которые вы находитесь там в голосовом VLAN, пожалуйста, будьте осведомлены,

что нужно использовать 20-й VLAN и помечать его 802.1-Q-шным заголовком. Но проще это сделать по CDP. У вас телефон увидит вот эту конфигурацию, увидит, что Access VLAN 10, а voice VLAN 20, и он, соответственно, будет знать, что все кадры, которые он отправляет в сторону оплинка, должны маркироваться 802.1-Q 20-м VLAN. Вы можете использовать команду switchport access VLAN, допустим, там 10, и switchport voice VLAN вместо циферки указать .1p. В этом случае кадры, которые будут отправляться телефоном, они будут отправляться без указания номера VLAN. Там будет номер VLAN 0. По сути своей это то же самое. Вы говорите, окей, мы кадры телефонные обрабатываем специальным особым образом. Если там есть 802.1-Q заголовок, то это хороший телефонный трафик. Если там нет 802.1-Q заголовка, это, ну, в кавычках, плохой компьютерный трафик. То есть мы не верим тому,

что у нас действительно метка есть. Мы понимаем, что метку проставил телефон, что телефон на вот этом вот порту не будет принимать кадры с 802.1-Q заголовком. Он для этого не предназначен. Но вот, соответственно, все кадры, которые отправляются телефоном, они отправляются либо транзитные кадры без метки, либо кадры, которые сгенерированы самим телефоном с меткой 802.1-Q. Но какой смысл в том, что там указан номер VLAN? А в том, что мы можем не показывать номер VLAN самому телефону. Мы говорим, слушай, присылай просто кадры и не парься по поводу того, что ты по факту в каком-то отдельном широковещательном домене сидишь. У тебя тот же самый широковещательный домен 10. То есть ты точно так же получаешь DHCP настройки. То есть вот этот, например, может узел получить 192.168.10.17, а вот этот вот получит 192.168.10.18. Он в одном и том же VLAN будет сидеть, но, соответственно, кадры телефонные при этом будут помечаться 802.1-Q заголовком. Более того, в 802.1-Q заголовке,

вы помните, есть несколько полей. 81.00, поля Reset Type, тег, как называется, метка EtherType, потом тег ControlInformation, поле, в котором есть номер VLAN, 3 бита поле 802.1-P и 1 битик DiscardEligible. Так вот, если вы проставляете заголовок 802.1-Q, и, соответственно, там 4 байта, 2 из которых 81.00, дальше вот здесь вот 3 битика 802.1-P, 1 битик DiscardEligible, и номер VLAN, который нулевой, 0.00-0.00, вот здесь вот. То, по факту, из всех 32 бит, которые вы в заголовке прописываете, 4 бита только остаются те, которые вы можете редактировать. И в 3 битика 802.1-P вы можете вписать разные приоритеты. Так что ваш свитч может получать кадры,

отправленные телефоном, и телефон может эти кадры размечать по-разному. Он может некоторые кадры отправлять с указанием, это кадры очень важные, а некоторые кадры отправлять с меткой 802.1-P, ну, с частью, заголовка 802.1-Q, и говорить, это кадры менее важные. Например, он может тогда SIP-трафик и RTP-шный трафик разделить по приоритету. Он может сказать, что SIP-трафик, допустим, более важный или менее важный, а, соответственно, вот RTP-шный трафик более важный, потому что там содержится мясо голосовое, которое терять нельзя. Еще раз подчеркну, что в таком сценарии у вас кадры будут отправляться в одном и том же VLAN, просто некоторые из них будут содержать 802.1-Q-шный заголовок, в котором не написан номер VLAN, там будет 0 вместо этого. И кадры будут отрабатываться по факту, не по метке нулевого, не по таблице нулевого VLAN, такой таблицы нету, будут обрабатываться именно по 10 VLAN. Поэтому мы не верим тому, что в этой метке номер VLAN написано.

Мы говорим, что нулевой VLAN это специальный особый случай, когда мы вот этому не верим и обрабатываем кадры по таблице Switchport Access VLAN. Вы можете сказать, что Switch не хочет отдавать никакие кадры с 802.1-Q-шными заголовками, не согласен принимать кадры с 802.1-Q-шными заголовками даже с нулевым VLAN. То есть мы говорим, что все кадры, которые отправляются, должны идти просто самые обычные кадры без каких-либо дополнительных настроек. И в этом случае есть команда Switchport VoiceVLAN Untagged. Эта команда скажет, что кадры обычного абонента отправляются без метки и приходят на Switch без метки. И кадры телефонные тоже приходят на Switch без метки. Штука эта нужна будет для, ну, исключительно редких сценариев вида вы хотите определять наличие телефона по CDP. И вот вы говорите, окей, мы тогда вот по этому CDP будем работать. Если вдруг телефон там по CDP не обнаружен, мы там с этим портом что-то будем делать. Ну, например, порт целиком выключать.

Вот. Ну, редкая штука, да. По факту она относительно бесполезная. И четвертое есть Switchport VoiceVLAN Non. Это означает, что вы со стороны Switch'а не отправляете никакие рекомендации телефону, как он должен работать. И сам телефон должен решить, как он должен работать. То есть Switchport VoiceVLAN Non указывает, что Switch может принимать какие-то кадры, которые будут отправляться телефоном, и телефон должен будет отправлять эти кадры либо с меткой 802.1p, либо без нее. Разница между Untagged и Non заключается в том, что в случае с Untagged'ом Switch явно говорит, не надо использовать метку. А в случае с VoiceVLAN Non Switch ничего не говорит, и телефон сам решает, например, из конфига по DHCP, полученного по TFTP, точнее, что и как он должен обрабатывать. Вот, ну да. То есть вы можете, если вы прописываете Switchport VoiceVLAN Non, заставить как-то телефон

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

Да, то есть это транк, который со стороны маршрутизатора будет принимать много разных VLAN. Когда мы говорим про то, что у нас есть транки на свитчах, ну вот как раз ситуация, когда есть свитч, есть роутер, и они соединены проводом. И у нас на свитче есть несколько разных VLAN, вот, например, VLAN с пользователями, и мы хотим кадры обоих VLAN, то есть всех наших пользователей, отправлять в сторону роутера. Мы их просто можем отправлять, и мы указываем, что одни кадры идут с меткой там 10-го VLAN, другие кадры с меткой 20-го VLAN. Мы со своей стороны кадры отправляем, дальше они отправляются с меткой 802DNQ в сторону роутера. Но эти кадры принадлежат разным широковещательным доменам, и как следствие, для чего мы роутер используем? Для того, чтобы там IP, как правило, запустить поверх этих разных широковещательных доменов. У нас вот здесь вот есть, например, сетка 10.0.10.0.24, а вот здесь сетка 10.0.20.0.24. И вот в такой ситуации

нам нужно как-то сделать так, чтобы роутер принял кадры 10-го VLAN и обработал их в соответствии с тем, что в этом VLAN используется сетка 10.0.10, и принял кадры 20-го VLAN и понял бы, что это кадры из VLAN, в котором используется сетка 10.0.20. То есть нам нужно будет иметь два разных логических интерфейса, которыми мы будем смотреть на два разных широковещательных домена. При этом они все должны смотреть в один физический провод. Делается это с помощью логических субинтерфейсов. Мы, в принципе, уже такое делали на роуте, но не с 802.0.2.0.2.0. А, даже с 802.0.2.0.2.0. Виланами делали. Так что сейчас просто идем повторение материала. Мы говорим, что физический интерфейс у нас должен быть просто в API, no shutdown. Дальше на логических интерфейсах мы говорим, что у нас будет название как у физического интерфейса, но дальше после точки имя субинтерфейса. В нашем случае Gigabit Ethernet 0.0.10. Это номер субинтерфейса

для физического интерфейса Gigabit 0.0. Номер не обязан совпадать с номером Вилана. То есть номер субинтерфейса, номер Вилана – это не связанные вещи. Но удобно, когда они совпадают. И вы командой encapsulation.1q дальше должны будете задать номер Вилана, который используется в этом широковещательном домене. Номер, да, вот в нашем случае вот здесь вот будет 10-й, а здесь будет 20-й. От физического интерфейса требуется, чтобы он просто был создан, чтобы он существовал, чтобы он был в API. Никакие настройки на нем не прописываются. Все кадры, которые приходят на этом физическом интерфейсе, они будут отправляться в один или несколько, ну да, в один логический субинтерфейс. То есть если кадр приходит через физический провод с меткой 10, то мы его отправляем, как будто бы он пришел из логического интерфейса Gigabit 0.0.10. Если кадр приходит с меткой 20, то мы его отправляем в логический интерфейс, который обрабатывает кадры 20-го Вилана,

на котором прописано encapsulation.1q20. Удобно, когда номера Виланов и номера интерфейсов совпадают, но делать это не обязательно. Если вы выключите физический интерфейс, то настройки на нем никакие, естественно, не будут работать, равно как не будут работать и дочерние субинтерфейсы. Поэтому от физического интерфейса требуется, чтобы он просто был в API. Вы можете выключить отдельный субинтерфейс, но вот родительский интерфейс выключать нельзя. Вы, когда выключаете родительский интерфейс, вы выключаете его на уровне физики. Никакие настройки, которые вы прописываете на уровне физического интерфейса, которые не относятся к физическому уровню, они, соответственно, распространяться автоматом на дочерние интерфейсы не будут. То есть, если у вас есть интерфейс, там, Gigabit 0.0, и вы в нем прописываете, там, не знаю, IP-адрес, приоритизацию, какую-нибудь там что-то еще, то это все распространяется только на пакеты, которые обработаны именно самим физическим интерфейсом, не на те пакеты, которые обработаны дочерними интерфейсами, там, типа Gigabit 0.0.1 или Gigabit 0.0.10.

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

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

Ну, например, VLAN 1 или VLAN 10. И вот здесь у нас пользователи другие, которые будут VLAN 20. И, соответственно, между этими VLAN-ами мы можем выполнять коммутацию. То есть, фактически, за каждый вот этот вот самый VLAN, за каждый виртуальный широковещательный домен, у нас будет создан виртуальный коммутатор, в кавычках виртуальная машинка. И вот трафик между интерфейсами, которые принадлежат этой самой виртуальной машинке, у нас коммутируется. Но если мы хотим передавать трафик между интерфейсами, которые принадлежат к разным виртуальным коммутаторам, то нам нужно пропустить такой будет пакет через маршрутизатор, через раутинг-энжин. И вот, например, у нас на гигабите 02-м приходит кадр. Дальше кадр мы относим к первому VLAN. Но по таблице коммутации первого VLAN мы принимаем решение, что этот кадр пришел в наш собственный Mac. И направляем такой кадр на центральный процессор, на движок маршрутизации, раутинг-энжин. Дальше раутинг-энжин говорит, окей, мы получили кадр на свой собственный MAC-адрес. Мы должны его открыть, посмотреть, что внутри лежит, увидеть внутри IP, запустить движок маршрутизации,

прошерстить по таблице маршрутизации, найти выходной интерфейс. И принимаем решение, что в выходной интерфейсе у нас будет так называемый SVI, switch virtual interface, это интерфейс VLAN 2. Мы делаем новый кадр, который отправляем в таблицу коммутации второго VLAN. И дальше по таблице коммутации уже находим, в какой конкретно физический интерфейс отправить кадр на нужный MAC-адрес канального уровня с получателем. То есть либо адрес шлюза, либо адрес конечного получателя. Опять же, по таблице CEF мы это будем делать. Как вы помните, тут есть один процесс, который называется frame rewrite, который будет все это дело немножко усложнять или упрощать одновременно. То есть он будет кадр получать, в нем будет перебивать все свойства и дальше отправлять за один проход. То есть у него не будет прям отдельно коммутация вот здесь, маршрутизация вот здесь, коммутация вот здесь. Он это все за одно движение сделает, за один запрос к таблице CEF. Но нас сейчас эта физика не очень интересует. Мы сейчас на таком упрощенном уровне на пальцах будем этот процесс разбирать.

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

И интерфейс называется интерфейс VLAN 2 Switch Virtual Interface. И дальше кадры уходят из-под нашего собственного MAC на MAC-адрес получателя. Ну, соответственно, это уже будет новый кадр. Здесь у нас какой-то MAC-отправителя, MAC-адрес, допустим, A, идет на наш собственный MAC-адрес B. Здесь у нас MAC-адрес C, наш собственный, идет на MAC-адрес D конечного получателя. То есть это новый кадр, получается. Кадр, который приходит, мы обрабатываем по таблице коммутации, находим, что входящим интерфейсом, точнее, исходящим интерфейсом в таблице коммутации будет наш входящий интерфейс на Routing Engine. И выходной интерфейс на Routing Engine указывает, соответственно, что кадр надо отправить куда-то в сторону таблицы коммутации VLAN 2, который дальше уже кадр отправит в сторону сети назначения. Простой вариант, который предполагает, в общем, минимум усилий со стороны коммутатора. То есть он просто говорит, что у меня не только таблицы коммутации есть одна или несколько, а у меня есть еще виртуальный маршрутизатор. Такую штуку могут делать практически все свечи, которые есть в ЦИСКе.

Вы можете интер-ВLAN Routing включить, и вот как раз оно будет именно это и делать. На некоторых коммутаторах вы можете объявить такую штуку, которая называется Routed Interface. Это интерфейс, точно такой же физический интерфейс, как и все остальные, но вы на нем указываете команду no switchport. То есть если вы на интерфейсе указываете no switchport, этот интерфейс перестает смотреть в какой-нибудь VLAN. То есть это просто обычный интерфейс. На нем нету никаких 800 2.1Q меток, на нем нету Nikola Spanning 3, ничего. То есть вы на нем выключаете коммутацию, вы его рассоединяете с виртуальным коммутатором, и вы говорите, этот коммутатор смотрит напрямую в движок маршрутизации, напрямую в воображаемый роутер. Физически, конечно же, этот интерфейс, простите, он все равно будет смотреть в какой-то VLAN. Но вы этого не увидите. Вы будете видеть, что у вас есть просто интерфейс, который подключен сразу на роутер. На этом интерфейсе есть свой собственный Mac.

У нас вот здесь есть Mac. Здесь вот есть Mac. Вот здесь есть Mac. Ну, соответственно, вот, да, на этом интерфейсе у нас появляется свой собственный Mac, из-под которого можно отправлять, принимать кадры. На этом интерфейсе мы можем повесить IP-шник, потому что на коммутируемых интерфейсах мы не можем повесить IP-адрес, а вот на этом можно. Ну, соответственно, да. Если у вас есть вот этот вот самый интерфейс, который смотрит напрямую на роутер, то вы можете на него повесить IP-адрес и прямо с него отправлять IP-пакеты. Вот как это будет выглядеть. Так, да, случай с SVI, с интерфейсом, который смотрит в коммутируемую среду, в VLAN. Это интерфейс ненастоящий, виртуальный. Он не может быть физически выключен. То есть вы можете на нем сделать команду shutdown, но это будет означать только то, что вы логический виртуальный интерфейс, который у вас от routing engine до таблицы коммутации, соответственно, вот смотрит. Вы его выключаете. Вот команда shutdown, вы говорите, у вас сам VLAN продолжает работать, но перестает в определенный VLAN смотреть воображаемый интерфейс на routing engine.

То, что вы пропишите на интерфейсе no shutdown, не означает, что этот интерфейс автоматически поднимется. Он в app будет переходить только при выполнении ряда условий. Во-первых, если вы указываете, что у вас есть интерфейс VLAN 111, например, то этот интерфейс будет работать только по определению, если у вас есть куда его подключить. То есть если вы говорите, что у вас есть, например, интерфейс VLAN 999, а дальше вы не создаете виртуальный широкопечательный домен 999 VLAN, его нет в базе. Соответственно, и сам интерфейс у вас будет выключен, он будет всегда в дауне, хоть вы там на него обвешаетесь no shutdown. Второй нюанс заключается в том, что если у вас есть виртуальный коммутатор, вы создали виртуальный коммутатор 999 VLAN, присоединили его к интерфейсу VLAN 999, но у вас ни одного порта в этом VLAN нету. То есть ни одного аксессового порта, ни одного транка живого. То есть просто VLAN существует в воздухе, висит, таблица коммутации есть, а ни одного порта в эту таблицу не смотрят.

То в этом случае и интерфейс VLAN у вас тоже будет в дауне. Да. То есть у вас, во-первых, должен быть создан VLAN в базе, во-вторых, должен быть хотя бы один порт, который будет принимать или отправлять кадры этого VLAN. Если это будут аксессовые порты, ну, соответственно, прекрасно. У вас есть аксессовый порт в 999 VLAN, значит и сам VLAN живой. Либо у вас есть транк, на котором соответствующий VLAN помечен как allowed и транк находится в API. Ну, соответственно, тоже у вас будет живой порт, который передает кадры этого VLAN. Плюс дополнение, что если у вас есть кадры, которые... Что если у вас есть порты, которые принадлежат этому VLAN, 999, например, да, то эти порты не должны быть заблокированы Spanning 3. И еще там есть гадкий протокол VTP, вот он должен не запрунить передачу кадров этого VLAN в этом транке. Ну, короче, если говоря, если у вас могут отправляться кадры действительно по этому интерфейсу,

по-честному, кадры определенного VLAN, значит, этот VLAN будет работать. Если у вас нет возможности отправлять на физических портах кадры этого VLAN, то и виртуальный свитч виртуал интерфейс тоже не будет находиться в API. Есть еще одна штука, которая на экзамене будет и которая в книжке будет. Причем в Official Certification Guide она описана абсолютно по-дурацки. Есть такая команда switchport-autostate-exclude. И очень часто почему-то есть популярное заблуждение, что если взять и, соответственно, прописать эту команду, это можно сделать так, чтобы у вас какие-то интерфейсы приводили к тому, чтобы у вас этот интерфейс переходил в app, тогда, когда это не указывает вот эти вот условия. На самом деле, с точностью все дано наоборот. Эта команда указывает, что если у вас есть какой-то физический интерфейс, на котором VLAN существует, и он передается нормально, но вы хотите исключить этот интерфейс из списка разрешенных для поднятия VLAN,

то вы можете сказать на физическом интерфейсе switchport-autostate-exclude, и у вас VLAN будет падать, если ничего, кроме этого интерфейса, не останется живого. То есть, если у вас есть routing engine, он смотрит в VLAN 999, и у вас есть вот тут вот аксессовый порт, здесь вот транковый порт с разрешенным 999 VLAN, и тут еще не знаю, что такое, тоже динамический транк согласован. И вот вы говорите, у нас вот этот вот транк упал, но при этом работает аксессовый порт 999 и динамический транк, в котором 999 VLAN передается. У нас падает аксессовый порт, остается живой транк, в котором 999 VLAN есть, все с ним в порядке. Но вот, соответственно, если у нас, например, VTP возьмет и скажет, а давайте мы здесь заблокируем этот самый 999 VLAN, то у нас VLAN упадет, потому что нет ни одного живого порта. Тут мы поднимаем один из портов, вот, допустим, вот этот вот самый транк,

поднимаем и прописываем на нем switchport-autostate-exclude. И он все равно будет в этом случае восприниматься как дохлый порт, даже если он при этом по факту будет находиться в API. И если у вас ни одного живого порта без autostate-exclude нету на VLAN, то, соответственно, VLAN признается дохлым, и интерфейс, вот этот вот самый интерфейс VLAN 111 падает в down. Так, это что касается switch virtual interface. Он будет менять состояние up-down с задержкой порядка 10 миллисекунд. То есть, если у вас есть ваш multilayer switch, L3 switch, у вас есть 999 VLAN, в котором есть пользователи, и эти пользователи нормально работают и говорят, что вот мы можем отправлять трафик, и, соответственно, у нас идет нормальная цивилизованная работа. И тут падает некоторое количество интерфейсов, которые смотрят в этот 999 VLAN. Соответственно, 999 VLAN сам по себе у нас, может быть, в базе и останется,

но вот этот вот интерфейс SVI упадет в down через 10 миллисекунд после того, как упадет каждый из этих физических проводов. Ну, не каждый, а все упадут после того, как последний сдохнет, вот и SVI-ка тоже сдохнет. Задержка 10 миллисекунд, она достаточно небольшая. Да. Если вы хотите переключить ваш интерфейс в routed режим, то здесь будет следующая штука. Физический интерфейс вы можете на свече перевести в routed режим не на всех платформах. Ну и если вы это сделаете, то вы получите возможность отправлять кадры на routing engine не через какой-то VLAN, а через напрямую связь с космосом. В нормальной ситуации на физические интерфейсы на свече вы не можете повесить IP-шники. То есть вот интерфейс Gigabit 02, просто обычный самый интерфейс. Вы, говорите, пытаетесь IP-адрес повесить, говорите, IP-адрес чего-то там.

Система ругается, говорит, нет такой команды IP-адрес. Есть IP-ад и все, адрес нет. Но если мы указываем no switch port, то после этого у нас все функции коммутации на этом порту отключаются. Мы раньше говорили, что у нас есть маршрутизатор, встроенный в наш свеч. У нас есть несколько VLAN-ов, и трафик между этими VLAN-ами передается через маршрутизатор. И вот мы говорили, у нас есть физический интерфейс, допустим Gigabit 0.2. И трафик проходит через таблицу коммутации, и на SVI-ку Routing Engine доходит. Сейчас мы хотим сделать так, чтобы у нас трафик этого порта приходил сразу на Routing Engine. И мы говорим на нему no switch port, и у нас, соответственно, порт этот подключается напрямую к нашему роутеру. Мы на него можем повесить IP-шник, как на роутер. Вот мы можем сказать команду IP-адрес 10.0.0.1, и она даже примется. И у нас действительно вот здесь вот IP-шник 10.0.0.1 появится. Слышь 24. Есть нюансы. При этом, на самом деле, вы не можете влиять на связи между блоками,

ну именно между самими микросхемами, между чипами на свече. Поэтому, по факту, этот интерфейс физически все равно остается подключенным к движку коммутации. Но просто для него создается отдельный VLAN. Вот здесь вот появляется новый VLAN, в котором никаких других портов нету, кроме этого Gigabit 0.2. И, соответственно, будет вот этот вот порт соединяться с SVI-кой в сторону роутинг-энжена. Просто вот эту вот SVI-ку вы не будете видеть. И сам VLAN тут вы не будете видеть. Но он по факту есть. И при определенных командах вы можете заставить показать в списке, что действительно создается новый VLAN. Действительно, вы не меняете прохождение трафика на самом деле. То есть все равно трафик у вас проходит через таблицу коммутации. Просто это происходит прозрачно для вас. И, соответственно, номера вот этих вот VLAN будут выдаваться из диапазона Extended VLAN. Помните, да, что у нас есть диапазоны с 1 по 1001 VLAN.

Это нормальный регулярный диапазон VLAN. Потом есть 1002-1005. Это зарезервированный диапазон для FDDI и токен ринга. И, соответственно, дальше с 1006 по 4094. Это номера VLAN, в которые Extended Diapason. Так вот, если вы используете вот эти вот самые NoSwitchPort интерфейсы, Routed интерфейсы, то из начала этого диапазона будут выкусываться отдельные номера и будут отдаваться под нужды вот этих вот воображаемых якобы интерфейсов, которые имеют прямую связь с космосом. Можно ли задублировать? Нет, нельзя. Система автоматически будет выбирать номера VLAN, которые будут не заняты. Если вы будете в конфиге прописывать, что вы хотите 1006 VLAN использовать, не проблема. То есть вы должны сначала сказать, что вас интересует 1006 VLAN, создать его в базе. И тогда при выполнении команды NoSwitchPort система автоматически, динамически выберет номер VLAN, который не занят. Но если вы сначала сделаете NoSwitchPort, система скажет,

я выделяю под этот интерфейс 1006 VLAN. А потом вы попытаетесь сделать VLAN 1006. Система скажет, извините, этот номер уже занят. При этом ShowVLAN его показывать не будет. Но вы не сможете его использовать именно потому, что он по факту уже занят. Есть команда ShowVLAN InternalUsage. И вот она покажет, что у вас 1006 VLAN занят под гигабитный интерфейс, гигабит 02. То есть повторно использовать этот номер VLAN у вас уже не получится. Вы можете повлиять на поведение CISC, сказав, что надо забирать номера под вот эти вот самые воображаемые Routed интерфейсы из конца диапазона расширенного. То есть вы можете сказать, что у нас есть команда VLAN InternalAllocationPolicy. И дальше там или descending или ascending. Если вы указываете по умолчанию, то по умолчанию забирается из начала диапазона, это ascending. Если вы указываете descending, то выключаем интерфейс, включаем заново. И видим, что ShowVLAN InternalUsage забрала последний номер VLAN из диапазона,

вот в нашем случае, 4024. Именно поэтому есть рекомендация, когда вы используете CISC-овские свечи, не использовать номера VLAN из начала и конца расширенного диапазона. То есть там с 1500 по 3500 номера можно нормально использовать, никаких проблем. Но вот из начала и из конца это опасно, потому что железка может себя повести не совсем корректно. Так, да. С Routed интерфейсами есть одна беда. Я уже говорил, что если вы делаете честный SVI, то есть вот здесь, вот, да, задержка порядка 10 миллисекунд получается. Если физический порт падает, то и SVI падает тоже очень быстро. Это достаточно важно, потому что если у вас есть физический интерфейс, на котором висит IP-шник, ну или, скажем, логический интерфейс, на котором висит IP-шник, и что-то влияет на поведение этого интерфейса, то чем раньше вы обнаружите неспособность отправлять трафик на этом интерфейсе, тем лучше. У вас тем быстрее сработает протокол динамической маршрутизации, там, условный SPF или EGRP,

и, соответственно, тем быстрее ваша сеть перестроится для нормальной работы. Ну вот, SVI-ки работают действительно быстро. Они 10 миллисекунд дают задержку, и это, в принципе, ну, нормальная задержка. У вас интерфейс физически упал. Она определяет, циско, падение физического интерфейса со срок до 48 миллисекунд. У вас три раза по FastLink пульсу должно пробежаться, по линг-пульсу обычному. И это три раза по 16 миллисекунд. То есть вы потеряли три линг-пульса подряд, задержка в любом случае больше 30 миллисекунд, но меньше, чем 48 миллисекунд. Ну, соответственно, там, условно говоря, можно говорить, что через 50 миллисекунд после аварии вы точно про нее уже знаете. И дополнительно к этому дополнительная задержка на SVI-ки 10 миллисекунд перед тем, как порт упадет в down, и как вы запустите процессы, там, рассылки новой LSA, в OSPF, или апдейты в BGP, или апдейты в EGRP, или там что-то еще. Ну, в общем, задержка в 10 миллисекунд – это мало. А вот на роутер-интерфейсах эта задержка может быть реально большой,

потому что у вас падает физический интерфейс, и дальше интерфейс, который у вас... у вас роутер-интерфейс на роутере будет виден, вот он по факту будет испытывать очень большую задержку. Вы можете увидеть, что если включить команду debug IP routing и посмотреть, что физический линк падает, вот fast.net 0.17 упал, и дальше начинаются... дальше начинаются реакции на него. То есть вот у нас упала физика, и канальный уровень срабатывает только с задержкой в одну секунду. У нас сначала физика line proto 5 updown, упала физика, а потом канальный уровень link 3 updown. Вот link 3 updown – это событие вида «мы больше не можем отправлять кадры». Первое событие – это мы больше не можем отправлять отдельные биты. Эта задержка называется carrier delay. Вы можете ее отредактировать, но по умолчанию она в секунду выставлена на циско-свечах.

И, соответственно, после того, как физический интерфейс упал, все события вида «давайте рассылать уведомление, что у нас произошла какая-то беда», срабатывает только с задержкой в одну секунду. В 18.28.57 секунд физика пропала, ну, link пропал на интерфейсе. В 18.27.58 циско начала чесать пятую точку и начала рассылать апдейты, ну, допустим, в рипе или в чем-то еще, что, ребят, у нас пропала сетка 10.0.1.0, которая коннекта на этом интерфейсе была. При этом, если link появляется на интерфейсе, то то же самое хрень происходит, что физика срабатывает в одно время, а link на этом интерфейсе появляется, ну, то есть канальный уровень на этом интерфейсе появляется через секунду. Carrier delay в одну секунду, он работает в обе стороны. Как то, что если у нас интерфейс поднимается, мы ждем секунду, так то, что если интерфейс гаснет, мы ждем одну секунду. И если вы указываете carrier delay, то вы можете повлиять на эту самую задержку, и вы можете сказать, что при падении физического интерфейса

мы немедленно начинаем реагировать на это, ну, или там с небольшой задержкой, и можно, в принципе, выставить эту задержку даже в ноль. Если вы указываете carrier delay, команду на интерфейсе, дальше указываете msec, и вот здесь вот количество миллисекунд, через которое вы хотите поднять виртуально, ну, поднять канальный уровень на интерфейсе, который вот только что получил первый свой link-пульс. Или в обратную сторону, потеряно 3 подряд link-пульса, через сколько мы хотим определить, что пора выключать канальный уровень. Если вы это делаете, будьте осторожны, потому что у вас может быть так называемый link-флаппинг, когда link-пульсы то проходят, то не проходят, то проходят, то не проходят. Если вы будете менять carrier delay на интерфейсе, если вы будете указывать, что у вас интерфейс то потухнет, то погаснет, в случае, когда link-пульсы то проходят, то нет, вы можете зафлудить всю вашу сетку, но апдейтами, потому что интерфейс поднялся,

пришел первый link-пульс, вы говорите, о, у нас новый интерфейс, давайте запускаем процесс рассылки EGRP апдейтов. Дальше у нас интерфейс упал, мы говорим, о, у нас 3 подряд link-пульсы потерялись, интерфейс действительно упал, давайте отсылать сразу сообщение, что у нас сетка недоступна. И вот вы так будете спамить. Доступно, недоступно, доступно, недоступно. И причем с нулевой задержкой вы это будете делать реально очень быстро. Поэтому задержку эту в ноль прямо совсем выставлять надо с очень большой осторожностью. Ну, в реальности, да, вы захотите, наверное, там миллисекунд 50 хотя бы поставить, чтобы он не прям вот, не прям миллионами сообщений в секунду отсылало сообщение там, что у меня поднялась сетка, у меня упала сетка, у меня поднялась сетка, у меня упала сетка. Чтобы хотя бы он там ну не больше 20 таких сообщений в секунду отправлял. 50 миллисекунд нормальная задержка, на самом деле, вполне имеет смысл ставить ее именно такой. Так, Далее, далее, далее, далее. Если вы включаете carrier delay msec, допустим, там 0,

то вот ровно в тот момент, когда у вас падает физика, у вас падает и канальный уровень тоже. И, соответственно, сразу немедленно начинается реакция на это. Да, вот link up down. Это про физику. И сразу у нас начинают срабатывать события вида там интерфейс упал. Давайте на это реагировать. То, что при этом по факту сообщения на консоль показывается, что канальный уровень упал только спустя секунду, это на самом деле уже никому не интересует. То есть это чисто визуальная задержка. Обработка всех IP событий, она произошла, соответственно, спустя вот этот вот самый carrier delay. Если у вас есть VLAN-ы, и вы строите роутер на палочке, или вы строите сети коммутируемые на VLAN-ах, то, соответственно, вы должны будете иметь следующие штуки в виду. Во-первых, если вы смотрите команду showVLAN или showVLAN-бриф, они не показывают транки.

То есть там в колонке порты, которые несут в себя трафик этого VLAN, они показывают только аксессовые порты. Однако showVLAN-ID и номер VLAN показывает все порты, которые несут в себя трафик этого VLAN, в том числе и транки. На экзамене на это будет вопрос. Дальше. Если вы работаете с каталистами и указываете, что у вас будут какие-то порты no-switch-порт, имейте в виду, что этот порт будет занимать отдельный VLAN. Этот VLAN не виден в базе, но его можно посмотреть командой showVLAN internal usage. Вы можете указать, из какого, из начала или из конца диапазона будут забираться номера VLAN под эту задачу. И еще одна вещь. Если у вас есть роутеры старые, со старыми EOS-ами, то EOS-ы до 12.4, 12.4.15T, могут работать только с VLAN-ами нормального диапазона. То есть вы на роутере со старым EOS-ом вполне возможно не сможете использовать расширенный диапазон.

Соответственно, первый VLAN всегда есть в базе. Со второго по 1001 вам доступны номера нормального диапазона. 1002, 1003, 1004, 1005 служебные. И вот этот вот расширенный диапазон доступен только по факту на сравнительно свежих 12-х EOS-ах. Ну, естественно, все 15-е EOS-ы тоже. Если вы хотите на свечах использовать расширенный диапазон, то вы должны будете переключить VTP в такой режим, который позволяет вам с этими VLAN-ами работать. Потому что по умолчанию протокол VTP служебный, который мы с вами еще не проходили, но в ближайшее время будем проходить, запрещает использование расширенного диапазона VLAN-ов. То есть вот эти вот Extended VLAN-ы в нормальном состоянии VTP вам не дает использовать. Но если вы ему хорошо попросите, его хорошо попросите, его хорошо убедите, то он вам даст это сделать. Так. Ну, давайте теперь про все эти служебные протоколы как раз и поговорим. Про то, как настраиваются служебные протоколы DTP и VTP в CISC-ах.

Первым у нас по списку будет идти протокол DTP, Dynamic Trunking Protocol, с помощью которого два CISC-свеча могут согласовать транки между собой автоматически. В нормальной ситуации мы должны будем все транки прописывать вручную. Это нормальное, естественное, абсолютно вполне разумное поведение. Когда вы говорите, что у нас есть сеть предприятия, что в этой сети предприятий есть какие-то узлы, которые абонентские. И вы знаете, какие порты у вас смотрят на абонентов на свечах. Ну, то есть если мы посмотрим на какой-нибудь аксессовый свитч, у него там на морде будет, условно говоря, 48 абонентских портов и 2 оплинка. Вот на абонентских портах, вы говорите, мы фиксируем свитч-порт Mode Access. Мы знаем, что на этих портах будут обычные юзеры. Мы не хотим от обычных юзеров принимать 802.1Q-шные кадры ни при каких условиях. В то же время порты, которыми мы смотрим на соседние свечи, мы тоже заранее хорошо знаем. И мы, как правило, прописываем на все соседние свечи указание, что эти порты будут в транке. Но вот когда-то давным-давно Cisco выпускала свои свечи.

Она их, как вы помните, купила у компании Crescendo, которая придумала, собственно, концепцию виланов и транков. И вот компания Crescendo не только виланы с транками придумала, но и придумала она также и протокол DTP. Что если два Cisco-слеш-клещендовских свеча соединяются между собой, они по факту там сами транк и согласовывают. И за это отвечал как раз протокол, который назывался DTP – Dynamic Tranking Protocol. Если у вас есть два свеча, которые поддерживают DTP, и они друг друга видят по этому самому протоколу, то они могут согласовать автоматический транк между собой. Когда-то давным-давно они даже это автоматически делали. То есть вы брали между собой два свеча, соединяли патч-кордом, никакие настройки на портах не делали, и они сами, эти самые свечи, начинали друг другу обнаруживать по DTP и сами включать транки друг на друга. Спустя некоторое время внезапно выяснилось, что протокол этот какой-то не очень безопасный, что если вы на всех портах не задаете, какие режимы настройки на этом порту будут,

оставляете все в автомате, то у вас обнаруживаются юзеры гадкие, которые с вами внезапно хотят согласовать транк, хотя на самом деле права никакого на это не имеют. То есть злой пользователь может взять, принести Cisco Switch, воткнуть его в вашу корпоративную сетку вместо своего, допустим, компьютера, компьютер воткнуть в этот же самый свой свеч, который он принесет, и этот свеч согласует с вашим корпоративным свечом транк, и вы как бы пустите его по умолчанию во все виланы, которые у вас там есть. Вряд ли же вы будете оставлять настройки по умолчанию и при этом конфигурировать там, например, списки allowed вилан. Вот. Поэтому протокол DTP, как-то Cisco сказала, что он будет не очень хороший, не очень безопасный, и поэтому он по умолчанию получил другое поведение. На актуальных версиях Cisco, Cisco EOS, DTP автоматически транк не согласует. Если вы берете два свеча, из коробки достаете, соединяете их патч-кортом,

они транк вам не поднимут. Но протокол DTP по-прежнему работает на всех портах по умолчанию. И если с одной стороны придет какой-то сосед, например, старый Cisco Switch, он ожидает, вполне возможно, что у вас две Cisco между собой, транк автоматически согласует. Поэтому DTP на новых свечах, в новых версиях EOS, работает в полудохлом режиме. Если придет старый свеч, он скажет, я с тобой согласен согласовать транк. А если придет новый свеч, он транк автоматически не поднимет. Фактически это бомба замедленного действия, которая только и ждет, чтобы кто-нибудь взял и догадался, что две Cisco, которые соединяются между собой, транк автоматом не согласует. На самом деле не согласует именно потому, что ни одна из них не прикинулась старой Cisco. И если вдруг, соответственно, злоумышленник захочет попасть в какой-то VLAN, к которому он право в норме получать доступ не имеет, он может вполне сказать, а давайте я сделаю вид, что я старая Cisco, что я очень сильно хочу согласовать транк, и действительно у него это получится сделать.

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

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

это будет команда Switchport no negotiate. И тогда на этом порту, если вы фиксируете режим работы транка, DTP у вас выключается. Так. Ну и, соответственно, show interface Switchport вам покажет, вот здесь вот, negotiation of tracking, работает ли DTP или не работает. Если вы оставляете настройки по умолчанию, то у вас на, вот здесь у строчки administrative mode будет не Access, static Access и не транк. Там у вас будет что-то типа desirable, dynamic desirable, точнее, или dynamic auto. Вот Switchport mode dynamic desirable, Switchport mode dynamic haft, это два режима, при которых у вас администратор говорит, а мне все равно, что там будет, пусть DTP сам разбирается, надо ли работать в аксессе или в транке. И два этих режима будут различаться между собой тем, что dynamic desirable активно инициирует согласование транка, а Switchport mode dynamic auto не против того, чтобы транк согласовать с соседом.

При этом оба режима по факту отправляют свои PDA, вот эти самые DTP, и оба режима просто рассказывают, как они настроены. Поэтому, если вдруг вы думаете, что злоумышленник, запустив в AirShark, не увидит, что вы оставили конфигурацию по умолчанию, еще как увидит. То есть вы его прямо обрадуете, вы ему все на блюдечке выложите, что у вас режим работы порта оставлен по умолчанию DTP, DTP mode dynamic auto, вот это Switchport mode dynamic auto, и, соответственно, вот со стороны злоумышленника требуется только одно, это отправить DTP-шный кадр, я хочу с тобой дружить, я либо dynamic desirable, либо Switchport mode trunk, и, соответственно, согласовать с вами trunk. Так что имейте в виду, что вот эта вот штука, она довольно неприятная. То есть вы должны будете знать про такую особенность циска Switch'ей для того, чтобы не попадаться на поднятие транка со стороны ваших пользователей, если они на то не имеют соответствующего права. Так, рекомендации по trunk'ам будут следующие.

Везде выключаете DTP, то есть на статических абонентских портах его просто нету. Switchport mode access убирает поддержку DTP на этом порту. И если вы указываете trunk, то DTP там, в общем, не вреден, но и не полезен. Зачем он вам там нужен? Низачем. Фиксируйте везде жестко, где у вас работает DTP, в смысле, где у вас работают trunk'и, и не позволяйте ни на каких портах, где у вас действительно соседа с trunk'ом быть не должно, этот самый trunk согласовывать. Если вдруг зачем-то вы DTP оставите живым, то, соответственно, у вас для того, чтобы trunk' поднялся, должны выполняться некоторые условия. Первое условие – это одинаковые native VLAN'ы. Если они не совпадают, то у вас DTP не подожжется. Второе условие – это одинаковые так называемые домены VTP. Опять же, про VTP мы не говорили, но сейчас поговорим. Если вы будете иметь разные, скажем, настройки на разных портах trunk'а,

то, соответственно, у вас DTP этот самый trunk' не поднимет. Ну и, наконец, если вы используете allow-at-vlan, то они тоже должны совпадать. Вполне логично, чтобы у вас DTP не поднял какой-то транс, в котором какой-то один свитч на другого смотрит определенным VLAN'ом, а тот в ответ нет. Так. По поводу native VLAN'а ситуация будет там следующая. Я вам говорил про то, что очень небезопасно использовать native VLAN для боевого трафика. Сейчас расскажу, почему. Изначально концепция native VLAN'а предполагала, что у вас между двумя свитчами могут зародиться какие-то пользователи, которые не понимают, что такое 802.1Q. То есть вы говорите, окей, у нас с одной стороны 802.1Q-шный trunk, с другой стороны 802.1Q-шный trunk, и в разрыве между двумя свитчами, которые работают друг в другом в trunk'е, у вас есть юзеры, которые 802.1Q не поддерживают. Это может быть либо свитч без поддержки 802.1Q,

либо толстый желтый как Sial, Hub, неважно что. И в этом вот свитче или Hub'е у вас будут сидеть пользователи. То есть кадры какие-то будут передаваться между вот этим вот свитчом и вот этим вот свитчом, они будут передаваться в виде просто кадров 802.1Q-шных с совложением 81.0.0. Они передаются по проводу, они же все еще остаются 802.3 кадрами. Поэтому транзитные свитчи их просто фарвардят куда попало, и, соответственно, здесь заголовок 802.1Q добавляется, здесь заголовок 802.1Q убирается. Ничего плохого здесь особо не происходит. Но вот этот вот узел, который сидит на том же самом свитче, что и соединяет два порта транк, он получает копии некоторых кадров. И эти копии будут содержать в себе заголовок 802.1Q, который он не понимает. Если он сам захочет отправить какие-то кадры, то он будет отправлять их без 802.1Q-шного заголовка. Ну и, соответственно, эти кадры будут не пониматься 802.1Q-шными портами,

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

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

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

Смысл будет следующим. Если вы оставляете настройки порта по умолчанию, то у вас на порту, на любом порту стоит настройка Dynamic Desirable, Dynamic Auto, простите. Desirable старая конфигурация, Dynamic Auto это новая. То есть, вы согласны поднять транк с кем попало, но при этом вы сами поднимать транк не очень хотите. Вы хотите, чтобы с другой стороны кто-то сказал, что он хочет согласовать транк с вами. То есть, с той стороны, что пришел либо кто-то, что скажет, точно поднимаем транк, потому что я транк, либо сказал, я очень сильно хочу согласовать транк, потому что я Dynamic Desirable. Вот, то есть, вот этот вот атакующий, он приходит и говорит, я работаю в транке, так что давай с тобой поднимать транк. Он поднимает транк и в нормальной ситуации у вас здесь прописана команда switchport access vlan 10.

И вы думаете, что вот если у вас switchport access vlan 10, нормальный пользователь по DTP не согласует транк, поэтому по факту порт обычно работает в транке и, соответственно, все кадры обычно обрабатываются по таблице 10-го вилана. Но тут приходит злоумышленник и говорит, я теперь буду не в 10-ом вилане, а я теперь буду с транком и, соответственно, вот я отправляю кадр с меткой 20-го вилана. И злоумышленник, согласовав с вами транк, отправляет кадры с меткой того, что он хочет попасть в 20-го вилана, и он действительно попадает в 20-го вилана. У вас двусторонняя связность здесь будет вполне. В нормальной ситуации вы ожидаете, что кадры будут работать в 10-ом вилане, а вот злоумышленник взял и прыгнул в 20-й. Атака эта будет называться свитч спуфинг, и с помощью нее вы можете попасть в другой вилан. То есть общее название атак, которое позволяет вам попасть в другой вилан, называется вилан хоппинг. Есть атака именно на native вилан. Первая атака была именно на протокол DTP. Вторая атака – это на native виланы. Она не может быть осуществлена на новых свитчах, но она может быть осуществлена на некоторых старых цисках и на очень многих платформах других вендоров.

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

Вот он может проставить метку 10-го вилана, а после нее проставить еще одну метку 20-го вилана. То есть вы, в принципе, можете соорудить совершенно любой кадр, как злоумышленник. Вы вполне заинтересованы в том, чтобы делать такие кадры, которые будут вызывать у системы какое-то нестандартное поведение. И вот если вы сделаете вместо одной метки две, и вы отправите кадр с наружной меткой, совпадающей с номером вашего собственного вилана, в нашем случае 10-го, то тогда такой кадр приходит на абонентский порт. Дальше абонентский порт говорит, я вижу кадр, который пришел с 802.1-кьюшной меткой, но эта 802.1-кьюшная метка совпадает с номером того вилана, в котором этот порт находится. Поэтому я ее просто выбрасываю, я говорю, да, все честно, там 10-ый вилан, и все содержимое он трактует как MAC Client Data. То есть он все содержимое трактует как содержимое. И дальше он говорит, этот кадр пришел в 10-ом вилане. Соответственно, мы его коммутируем по таблице 10-ого вилана, находим выходной интерфейс, отправляем в транковый порт.

Здесь вилан 10-ый будет native, поэтому новая метка на него не добавляется, и все содержимое, которое есть, оно передается по сети. Но, как я уже говорил, там две метки. Соответственно, свитч не ожидает, что там будет вторая метка. Поэтому, когда он посылает кадр в native вилан, он говорит, я просто посылаю контент, который там пришел. А то, что начинается это все с битов 8100 и дальше еще каких-то битов с номерами виланов, например, 20-го, транзитный свитч не смотрит. И поэтому, когда свитч получателя принимает такой кадр в транке, он говорит, я вижу кадр, который начинается на метку 802.1-кьюшную, я читаю ее и доверяю тому, что там внутри написано. Я вижу, что там написано, что этот кадр 20-го вилана. И он выкоммутирует по таблице именно 20-го вилана. Он отправляет в сторону жертвы в 20-м вилане. Вот эта вот штука, она, конечно, требует очень много совпадений, которые должны будут одновременно произойти. Во-первых, у вас должен быть свитч, который на аксессовом порту согласен принимать кадры, помеченные 802.1-кью.

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

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

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

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

Если у нас есть роутер, раутинг-энжин, то он тоже с вяйками своими подключается как бы к этим виртуальным интерфейсам, к этим виртуальным машинам. У нас получается виртуальная машина, которым одним интерфейсом смотрит на один интерфейс, одним интерфейсом смотрит на раутинг-энжин и то же самое вот там с другим виланом будет происходить. Если у нас есть транк, то этот транк подключается ко всем виланам одновременно. То есть он разветвляется на нескольких частей и он может направлять кадры как в 10 вилан, так и в 20. В таблице коммутации у нас есть указание, что в 10 вилане некоторые кадры могут отправляться в этот ранк и в 20 вилане некоторые кадры могут отправляться в этот ранк. У нас может быть такое, что и в 10 и в 20 вилане будут MAC-адреса в таблице, то есть в самой таблице фильтрации FDB, которые будут указывать в сторону этого самого транковского интерфейса. То есть может быть такое, что мы в 10 вилане видим определенный MAC и в 20 вилане мы видим тот же самый или другой MAC за одним и тем же портом, допустим, Gigabit 0.0.

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

То есть в любом случае на каждый конкретный кадр, который мы получаем, мы смотрим внимательно и говорим, по каким-то признакам мы понимаем, что этот кадр приходит в вилане номер такой-то. И дальше внутри самого свеча этот номер уже никуда не девается. То есть мы его назначили, и дальше мы понимаем, что этот кадр коммутируется по таблице определенного вилана. В нашем случае, допустим, 10-й пришел. Значит, мы его отправляем в виртуальный коммутатор 10-й. Среди прочего это означает, что по 20-му вилана мы его уже не коммутируем. Так, давайте посмотрим на то, как на свечах можно согласовать действительно транк, если использовать протокол DTP. Когда у нас есть свитч, мы помним, что у нас сейчас есть два разных интерфейса с нашего маленького свитчика на центральный Core S. И мы делали лабораторную работу на CDP. И show CDP neighbors нам показывало, что у нас есть два интерфейса, которыми мы смотрим в сторону центрального свитча.

Это Ethernet 0.1 и Ethernet 0.3. Вот мы можем сейчас сделать так, чтобы наш свитч автоматически согласовал транк с соседним свитчом. Мы можем сделать это с помощью указания режима работы порта Dynamic Desirable. Сейчас у нас все порты находятся в Dynamic Auto. Мы ничего нигде не переключали. На CCNA мы делали лабу на включение Dynamic... Пардон, на включение порта в Static Access, Switchport Mode Access и, соответственно, транк. Сейчас мы сделаем Dynamic Desirable. ConfT. Интерфейс Ethernet 0.1. Switchport Mode Dynamic Desirable. Desirable. Вот. Вы тоже у себя можете сделать. Эта команда не вызывает перезагрузку интерфейса. Она автоматически начинает работать. То есть у вас что была настройка работать динамически, что сейчас настройка работает динамически.

Ничего, в общем, особо не изменилось. Но сейчас порт по факту начинает работать в транке. Если посмотреть на то, какая настройка порта по умолчанию, мы можем взять на свитче, посмотреть настройку, например, Ethernet 0.2 интерфейса. Show Run Interface E02. Вот я показываю, там ничего нету. Интерфейс пустой, просто не выключен и ладно. И, соответственно, Show Interface Ethernet 0.2. Switchport. Вот это вот состояние свитча по умолчанию. Коммутация на порту включена. Administrative Mode Dynamic Auto. Мы не против согласовать транк, если сосед придет и захочет транк. Но мы при этом сами не стремимся согласовывать этот самый транк. И Operational Mode, как по факту работает, static access. Это настройка по умолчанию. Я специально на Ethernet 0.1 включил Dynamic Desirable, а на Ethernet 0.2 показываю, что у интерфейс есть switchport. На тех портах, где Dynamic Desirable у нас соседа нету или транка, DTP, соответственно, не согласует транк.

Он падает в static access. И по факту, несмотря на то, что мы никакие команды не вводили, там действительно работает access. Но если вдруг у нас есть интерфейс, на котором кто-то из соседей прописал switchport mode Dynamic Desirable, транк на этом порту согласуется. Вот я могу сейчас на центральном свитче Core S выполнить эту команду. Но я хочу на этом. Show Interfaces. Ethernet 0.1. Тот самый, на котором я прописывал Dynamic Desirable. Switchport. Вот. И здесь мы видим, что у нас Administrative Mode, Dynamic Desirable, то, что я прописал. Активно пытаться согласовать транк. И Operational Mode, что по факту работает, там транк. То есть я со своей стороны воспользовался тем, что со стороны центрального свитча стоит настройка по умолчанию Dynamic Auto. И сказал, я хотел бы согласовать транк. И этот транк согласовал. И я получил доступ ко всем виланам. Транкент, виланс, enables. Все. И я могу получить доступ к абсолютно любому вилану, который прописан на центральном свитче.

У нас на центральном свитче сейчас ничего не прописано. То есть там только первый вилан в базе. И тысяча второй, тысяча третий, тысяча четвертый, тысяча пятый. Но если бы вдруг там были какие-то виланы, например, секретные виланы бухгалтерии, ну, соответственно, я бы сейчас к ним получил доступ. Access Mode вилан. Здесь показано, что он у нас есть. И это вилан по умолчанию первый. Ну, и у нас порт работает не в Access. У нас по факту порт работает в транке. Транк согласовался автоматически с помощью DTP. Вот этот самый Negotiation of Tranking on. И по факту согласовался транк типа ISL. То есть если бы мы хотели использовать 802.1Q, мы должны были бы циске нашей сказать, что транк надо использовать не любой, какой попало, а именно 802.1Q. Если не указано иное, циске используют ISL. Ну, если они поддерживают его. Если хотя бы одна из сторон поддерживает только 802.1Q, то согласуется, конечно, 802.1Q. Ну и если вдруг вы захотите в этом транке что-нибудь поделать, ну или, например, статический транк сделать,

вы можете это сделать командой switchport mode trunk, предварительно указав режим работы транка 802.1Q, командой switchport trunk encapsulation.1Q. Опять же, мы это делали, сейчас уже делать не будем. Хотя, почему бы и не сделать, в принципе. Ладно, не будем. Не будем, так не будем. Так. Далее. Show interfaces trunk. Show interfaces trunk. Покажет те транки, которые согласованы на железке. Вот я вижу, что Ethernet 0.1 у меня автоматически согласовался. Dynamic Desirable настройка на нем действительно есть. Тип инкапсуляции ISL автоматически выбраны. Буковка N означает не go shaded. Status ranking. Ну, все хорошо. Native VLAN первый, его никто не менял. Разрешенные на порту VLANы все. Но пересечение разрешенных на порту VLANов с теми VLANами, которые есть в базе, только первый VLAN. Потому что только первый VLAN есть в базе. Если бы мы сделали какие-то еще VLANы, они бы здесь тоже появились. И Spanning 3 ничего нам не заблокировал из числа тех VLANов, которые есть в базе.

То есть он нам все их разрешил использовать. Если бы мы выполнили эту же самую команду на центральном свече, а, собственно, что? Вот она. То здесь у нас бы вот что получилось. Мы видим, что у нас три порта работают по факту в транке. Режим по умолчанию Dynamic Auto. Здесь его никто не менял. Он такой остался. И Cisco центральная согласовала со всеми подряд транк. То есть кто к ней пришел и сказал, давай с тобой дружить, она сказала, конечно. Почему бы не подружиться с кем попало? Здесь мы видим, что согласованный тип инкапсуляции как раз тоже. Она не против согласовать ASL-овский транк. Native VLAN везде первый. VLAN, которые разрешены в транке, везде все разрешены. VLAN, которые допустимо использовать в каждом транке. То есть пересечение предыдущего блока и базы VLANов. Только первый VLAN. Действительно, на центральном свече мы никакие VLANы не создавали. И вот пересечение спанинг-тришных настроек с...

Не спанинг-тришных настроек, спанинг-тришного дерева с теми VLANами, которые есть в базе, указывает нам на то, что на Ethernet 0.1 мы блокируем передачу, на Ethernet 0.2 и 1.3 не блокируем передачу первого VLAN. И вот так вот. Спасибо. Спасибо. Спасибо.