VLAN в Cisco IOS

Продолжаем говорить про VLAN, продолжаем вспоминать то, что мы проходили с вами на ICND1, и продолжаем говорить про реализацию VLAN в коммутаторах Cisco. Как уже было подмечено, один коммутатор, на котором реализована функция VLAN, эмулирует несколько широковещательных доменов. Он соединяет много разных доменов коллизий в несколько широковещательных доменов, а не в один широковещательный домен, как это делают большинство неуправляемых коммутаторов. Как именно в Cisco будет реализован этот механизм? Будет реализован он следующим образом. У вас есть так называемая база VLAN. Эта база VLAN — это фактически те самые широковещательные домены, которые вы будете эмулировать. Можно сравнить эту базу VLAN с гипервизором, на котором вы можете запускать виртуальные машины. Вы можете в рамках одного гипервизора создать одну, две, три, пять, десять виртуальных машин.

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

то мы предполагаем, что этот кадр надо обработать на native VLAN, соответственно, по виртуальной машине того VLAN, которому соответствует native VLAN. По умолчанию, когда вы приносите новый коммутатор Cisco из коробки, у вас настроена в базе виртуальная машина первого VLAN, база первого VLAN, и все остальные кадры, которые вы каким-то образом будете получать, если вдруг вы не создадите предварительно какой-то другой VLAN в базе, они не смогут быть обработаны. Если у вас есть свитч, на этом свитче в базе есть только первый VLAN, и вы поднимаете на этом свитче транковый порт, и у вас в этом транковом порту приходит кадр, в котором написано «это кадр 17-го VLAN». Вы говорите «Окей, нам пришла метка 802.1Q с указанием 17-го VLAN, мы эту метку убиваем, дальше мы пытаемся сопоставить VLAN ID этому кадру,

и у нас это не получается сделать, у нас нету коммутатора 17-го VLAN». Поэтому последнее, что мы на этом кадре делаем, мы говорим, у нас VLAN ID этого кадра — 17-й VLAN, 17-го VLAN в базе нету, поэтому такой кадр просто удаляется. Вы можете на коммутаторе запустить несколько разных VLAN в базе, точно так же, как на гипервизоре можно взять и запустить много виртуальных машин, но сильно много запустить не получится. В зависимости от конкретной платформы вы будете ограничены сверху неким лимитом. Если говорить про младшие модели Cisco Catalyst, как правило, на 2960-х свитчах у вас 64 VLAN можно сделать, на чуть более старших моделях — 256 VLAN, на самых жирных толстых свитчах можно все 4000 сделать. В базу VLAN можно посмотреть командой show vlan brief. Если вы хотите её отредактировать,

то в режиме configure terminal, в обычной конфигурации указываем vlan, пробел и номер VLAN. Тем самым создаётся новый VLAN. Фактически изменения применяются не тогда, когда вы вводите команду, а тогда, когда вы выходите из контекста config-vlan. Указали vlan 10, нажали Enter, и в этот момент VLAN ещё не создался. Набрали exit, нажали exit, только в этот момент, по факту, VLAN создался в базе, только в этот момент кадры получили возможность коммутироваться по базе 10-го VLAN. Если вы смотрите show vlan brief, то вы можете увидеть там список портов, которые соответствуют определённому VLAN. Здесь важно, что Cisco показывает в списке портов только порты в access-режиме, те порты, которые по факту работают в access напротив каждого VLAN. И здесь не показываются транки, хотя транки, по идее, точно так же подключены к этому VLAN, как и access-порты. Я сейчас попробую порисовать. Я рисовал это так. Это выглядит как то, что у вас есть железный свитч,

и на нём запущены VLAN 10, 20, 30 и 40. В нашем случае мы создали VLAN 10, плюс ещё у нас был VLAN 1 отдельно. Вот это виртуальная машина VLAN 1. Вот это виртуальная машина VLAN 10, которую мы создали. И у нас есть какие-то железные порты на этом свитче. Там Gi1, 2, 3, 4. Соответственно, Gi1/0/0, Gi1/0/1, Gi1/0/2, Gi1/0/3. Многовато портов получилось. Давайте один сотру. Когда мы говорим, что у нас есть абонентские порты, вот они здесь показаны, что они прямо явно подключены к этому виртуальному широковещательному домену VLAN. Мы можем прямо такую линию провести между физическим портом и виртуальной машиной на нашем коммутаторе. Эти порты физически прямо подключаются

к этой виртуалке. Любой кадр, который приходит на наш физический порт Gigabit 0/0, он будет коммутироваться по базе первого VLAN, потому что этот порт в абонентском режиме, и всё, что приходит на этом порту, всё коммутируется по таблице первого VLAN. С другой стороны, любой другой кадр, который может прокоммутироваться по таблице первого VLAN, он может выйти в этот самый Gigabit 0/0 порт. Но, например, 10-й VLAN к этому порту не подключен. Вот этой линии нет, видите? Я только что пунктиром нарисовал, но её нет. Поэтому таблица 10-го VLAN не может быть использована для отправки кадров в Gigabit 0/0 интерфейс. Если приходит к нам где-нибудь, каким-нибудь образом, кадр, который мы определили как кадр, принадлежащий к 10-му VLAN, он не уйдёт в Gigabit 0/0 порт, потому что этой связи нет. В то же время у нас есть какие-то другие порты,

которые подключены, возможно, к 10-му VLAN. Например, Gigabit 0/2, 0/3, возможно, будут подключены к 10-му VLAN. Они между собой будут обособлены, и трафик с Gigabit 0/3 порта на Gigabit 0/0 порт никогда не будет прокоммутирован. Мы коммутируем трафик только в пределах своего виртуального свитча. Более строго мы можем сказать, что коммутатор, как вы помните, любой коммутатор коммутирует любые кадры на все порты, кроме порта источника. Мы знаем также, что есть дополнительные ограничения. Например, если мы знаем, что у нас в таблице получателей, в таблице MAC-адресов есть MAC-адрес получателя, то мы не коммутируем кадры на все остальные порты. Но есть нюанс. Если у нас появляется несколько виртуальных свитчей, то таблица у нас отдельная на каждый VLAN идёт. Мы говорим, что в случае, если у нас коммутатор поддерживает VLAN, коммутируем кадры на все интерфейсы, кроме некоторых.

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

окей, мы его отправляем на 10-й VLAN. Если вдруг мы другой какой-то кадр получаем, в котором написано, что он должен быть прокоммутирован по таблице 10-го VLAN, окей, не проблема, мы его коммутируем по таблице 10-го VLAN, и затем принимаем решение, куда мы отправляем копию этих кадров. Точнее, в какие порты 10-го VLAN мы копию кадра не отправляем. Естественно, все порты, которые к 10-му VLAN в нашем случае тоже подключены, транки и access-порты, они гипотетически тоже могут быть использованы для доставки трафика в 10-м VLAN. Если вы просто смотрите show vlan brief или просто show vlan, эта команда вам показывает только абонентские порты. Но если вы заказываете show vlan id 10, она вам показывает все порты, которые подключены к этому VLAN. Так, здесь вам не показывают это? Нет, не показывают. Show vlan, только не brief, а show vlan id, например, 10. Она покажет в списке портов

все-все-все порты, включая транки. Далее. Если мы хотим отредактировать базу VLAN, мы можем добавить новый VLAN или удалить существующие VLAN, и делается это с помощью команды vlan чего-то или no vlan чего-то. Когда мы вводим команду vlan чего-то, мы попадаем в субконтекст настройки определённого VLAN, и в этом субконтексте мы можем сделать определённое действие с VLAN. Во-первых, можем его переименовать. В нашем случае — accounting. Должен быть accounting, наверное, но написано accouning, опечатка. Судя по всему, она здесь вкралась изначально. Мы пытаемся дать название VLAN, что это VLAN бухгалтерии. Можно VLAN включить или выключить. Так же, как на железном гипервизоре, вы можете взять одну виртуальную машину и погасить. Она у вас при этом трафик пользователя обрабатывать не будет, но она место занимать будет на диске, она будет какие-то ресурсы, возможно, другие потреблять. Мы закладываемся под то, что виртуалка у нас есть

и гипотетически может быть запущена в любой момент. Если вы захотите выключить VLAN, но при этом оставить его в базе, вы можете это сделать. Команда будет в настройках VLAN — shutdown. И если вы указываете, что у вас определённый VLAN будет выключен, то трафик этого VLAN коммутироваться не будет вообще никак, но при этом VLAN в базе останется. У нас будет показано в колонке статус напротив этого VLAN active/locally shutdown. Что здесь ещё можно сказать? Вы не можете переименовать, вы не можете выключить, и вы не можете вообще что-либо сделать с теми VLAN, которые штатно идут из коробки. VLAN первый, 1002, 1003, 1004, 1005. У них уже есть имена, и у них есть состояние. Первый VLAN всегда есть, он всегда называется default, и он всегда активен, его выключить нельзя. VLAN 1002, 1003, 1004, 1005 — это VLAN для инкапсуляции в Ethernet, FDDI и Token Ring.

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

зарезервированы за этими хитрыми технологиями, которые давным-давно уже остались в прошлом. Поэтому на всякий случай ваш свитч резервирует номера тысяча второй, тысяча третий, тысяча четвёртый, тысяча пятый для такого сценария, когда ему понадобится через себя пропускать транзитный трафик этих самых FDDI и токен-ринга. Он умеет с ними работать, если они упакованы в Ethernet, но он не умеет с ними работать на нативном токен-ринговском уровне. Поэтому он не позволит вам в этот VLAN включить Ethernet-порты: тысяча второй, тысяча третий, тысяча четвёртый, тысяча пятый. Он не позволит вам их выключить, он не позволит вам их переименовать, но он всё время будет держать их рабочими. Эти VLAN-ы место занимают. Если вы посмотрите, там есть такая команда show VTP, она покажет вам, сколько VLAN-ов у вас есть в базе. Она показывает, что эти четыре VLAN-а всегда место занимают и всегда ресурсы отъедают. Но не настолько, чтобы об этом можно было в реальности заботиться. Так. Максимальный номер VLAN-а,

который мы можем запихать в 12-битовое поле — 4095. Но это будет номер, состоящий из всех единичек. Номер, состоящий из всех нулей, и из всех единичек использовать не принято. Это специальный особый случай. И по факту самый большой номер VLAN-а, который вы можете использовать в реальности, это 4094. Есть нюансы, заключающиеся в том, что на цисках вы не все номера можете использовать. Понятное дело, что вы не можете использовать 1002, 1003, 1004, 1005. Плюс на конфигурации из коробки вы не можете использовать и любые другие номера больше, чем 1006. По факту вы можете использовать номера только со второго по 1001. Ну и плюс первый VLAN такой немножко особенный. И если вы захотите использовать дополнительный диапазон VLAN-ов, начиная с 1006, то вы должны будете выполнить секретную команду на цисках, которая отключит поведение,

характерное для древних-древних-древних каталистов, и вместо этого древнего поведения по факту заставит циску вести себя сообразно актуальным потребностям. Вы должны будете либо выключить древний протокол VTP, либо перевести его в современный режим. По умолчанию на всех цисках работает этот самый древний протокол в целях совместимости, что если вдруг вы берёте новую циску и вставляете её в сеть, в которой древние-древние каталисты работают, чтобы они автоматически друг друга обнаружили, автоматически между собой начали передавать правила. Чтобы этого не происходило, вы можете взять и переключить вашу циску в современный режим. Тогда она с древними каталистами дружить по умолчанию не будет, но при этом она позволит вам использовать номера VLAN-ов больше, чем 1001. Есть нюанс, что расширенный диапазон VLAN-ов нельзя выключить. Так же как и 1002, 1003, 1004, 1005 VLAN-ы не можете выключить, система вам не даст это сделать, так же и расширенный диапазон VLAN-ов

тоже не даст. Из этого диапазона циска может под свои нужды откусывать некоторые VLAN-чики либо из начала этого блока, либо из конца. В каталистах это происходит, в некоторых других моделях это происходит, в других линейках, поэтому не рекомендуется брать номера VLAN-ов из начала и из конца блока этих самых расширенных VLAN-ов. Условно говоря, 1006, 1007 — эти номера под риском того, что циска их захочет забрать под свои нужды. Равно как 4094, 4093 — тоже они в зоне риска. Поэтому по факту, если вы хотите использовать номера больше, чем 1000, лучше всего будет не использовать 1002–1005 VLAN-ы никогда. Даже если вы работаете с оборудованием другого вендора, которое не имеет ограничения на эти номера, вдруг вы добавите в какой-то момент циску, и она у вас начнёт пытаться эти VLAN-ы коммутировать, как будто это токен-ринг. Вам с осторожностью следует использовать номера с 1006 по,

например, 1100, равно как с 4000 по 4094, потому что, чёрт его знает, как там циски захотят пооткусывать эти самые блоки под свои нужды. Но всё остальное вы можете использовать без особых проблем. Ну и главное — на циске просто надо будет выключить дурацкий протокол VTP. Да. Каждый из портов, которые у вас есть на цисках, может работать в одном из двух состояний. Либо вы принимаете только обычные кадры, либо вы разрешаете кадры-мутанты на этом порту. Одно из двух. Либо то, либо другое. Вариантов промежуточных нет. На обычных портах, на которых у вас есть обычные пользователи, никогда кадры-мутанты приходить не должны и отправляться абонентам эти кадры-мутанты тоже не должны. Абонент у нас работает с обычными портами. В то же время, если у нас есть соседний свитч, и с этим соседним свитчом мы хотим обмениваться данными разных VLAN-ов, мы можем на этом порту, который смотрит на соседний свитч,

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

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

Мы будем обрабатывать эти кадры по предсказуемым, заранее известным, номерам виланов. Это в курсе по свитчингу нас будет интересовать, например, в случае с телефонией. Вот если у вас есть обычный абонентский порт, но на этом абонентском порту есть IP-телефон. Вот мы можем сказать, что этот порт будет, соответственно, switchport mode access, но трафик телефона разрешается принимать с 802-зинкьюшной меткой для того, чтобы указать, что это телефонные кадры, они более важные, более приоритетные. В этом случае мы говорим, что да, кадры телефона будут приходить с меткой VLAN, а кадры компьютера будут приходить без метки VLAN. Но мы не будем верить тому, что написано в метке VLAN. Мы в любом случае голосовой трафик будем, который с меткой пришел, обрабатывать не по тому VLAN, у которой написано в метке, а по тому, который у нас в конфигурации задан. Поэтому даже если предположить, что у нас есть вот такая вот конфигурация, когда некоторые кадры приходят с 802-зинкьюшными метками, но мы, соответственно,

все равно на этом порту пишем switchport mode access, в этом случае мы такой порт будем называть не транковым портом, а мы его будем называть мультивиланным портом. Но это специфика CISC, что вот она считает транком только такой порт, в котором приходят кадры-мутанты, и мы заглядываем внутрь заголовка кадра-мутанта, видим там VLAN, и по именно этому VLAN коммутируем кадры. Если мы коммутируем кадр по какому-то VLAN, который задан в конфиге, это access-свы порт. Вот обычные абонентские порты, там switchport mode access мы задаем, говорим, что кадры-мутанты на этом порту не разрешены, и дальше мы говорим switchport access VLAN, относим в явном виде указания, к какому VLAN мы относим кадры, приходящие на этом интерфейсе, ну и исходящие с этого интерфейса тоже. Если у вас есть несколько разных интерфейсов, на которых вы должны будете задать один и тот же набор команд, вот это switchport mode access, switchport access VLAN, чего-то, то удобно пользоваться интерфейсом. face range макросом, он на все интерфейсы

в пачке задаст одинаковые настройки. Как посмотреть текущие настройки коммутации на порту? Для этого используется команда showinterface, дальше название интерфейса и switchport. Ну, если у нас аксессовый порт, то есть мы на нем не разрешаем кадры-мутанты, то мы указываем, что на этом порту у нас режим работы static access, мы это сделали командой switchport mode access и operational mode, что по факту получилось. Ну, то, что администратор просил, то и получилось. static access. И вот эта вот строчка указывает на то, в каком VLAN будут обрабатываться кадры, приходящие на этом интерфейсе, к какому VLAN у нас отнесен этот интерфейс в аксессовом режиме. Эта строчка в любом случае будет выводиться в команде showinterface switchport, даже на транковых портах, но она по факту будет применяться только для портов, которые находятся по факту в аксессе. Если у нас есть switchport mode trunk на порту, то, соответственно, мы разрешаем отправлять и принимать кадры мутанты.

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

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

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

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

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

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

вот на этот самый VLAN, который идет без 800-дваденкиюшных заголовков на транковом порту, неприятная атака будет следующая. Смотрите, у нас есть юзер, он будет подключен к вот этому свечу. Этот свеч может быть либо старой циской 2950-й, либо каким-то свечом без указания, как это сказать, без обязательного требования, что на аксессовом порту приходят только кадры-мутанты. Он может быть, например, свечом, у которого помечается untarget VLAN, и при этом нету концепции аксессовых и транковых портов. Очень часто такое оборудование можно будет встретить. И проблема будет в том, что если кадры приходят без указания метки VLAN, они обрабатываются по 10-му VLAN, по таблице 10-го VLAN. Но если кадр приходит с меткой 10-го VLAN, он все равно обрабатывается по той же самой таблице. То есть кадры других VLAN не обрабатываются, но кадры с меткой будут обрабатываться

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

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

он увидит, что это кадр 20-го VLAN. И вот в этом случае у вас получится, что пользователь из 10-го VLAN может отправить кадр пользователю из 20-го VLAN. Если у вас на коммутаторе вот есть такое поведение, что кадры, которые на аксессовом порту приходят, они могут приходить с меткой, меткой своего VLAN. И если этот же VLAN у вас используется в качестве нейтива. Это классическая атака, на самом деле она может показаться вам немножко сложной, но достаточно часто подобное встречается в реальном мире. с точки зрения дизайна у вас есть два свеча, которые связаны между собой транком, и в этом транке у вас есть какой-то нейтив VLAN X. И этот же VLAN X у вас есть для абонентов. Это нормально, да? То есть получается, что, ну, бывает такое, что у нас какие-то VLAN, да, в них сидят пользователи, вот один из этих VLAN-ов мы говорим, а давайте мы сделаем его нейтивом. Вот это вот поведение, а давайте сделаем его нейтивом, оно влечет за собой проблему.

Проблема заключается в том, что если в какой-то момент у вас на свече не будут проверяться вот эти вот заголовки 802.1Q, что они должны отсутствовать на статике Access портах, у вас пользователь сможет провести прыжок в другой VLAN или VLAN-хоппинг. Поэтому, чтобы такого не было, никогда не используйте нейтив VLAN в транковых портах. Если вдруг от вас оборудование требует, чтобы вы указали нейтив VLAN или untagget VLAN или что-то еще на транковом порту, используйте такой номер, которого нету в базе, либо который не коммутируется, либо в котором хотя бы пользователей нет. То есть у вас есть 10 и 20 VLAN, в которых сидят пользователи. Прекрасно. От вас Cisco требует указать нейтив VLAN? Превосходно. Номер VLAN 666 для этих задач больше, чем подойдет. Так, как настраивается транк? Мы указываем switchport mode транк. Если наша Cisco поддерживает и 802.1Q, и ASL, то предварительно мы должны будем указать switchport trank

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

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

они, соответственно, не будут работать на этом транке. Кадр приходит на порту, в нем написана какая-то метка, но если эта метка не соответствует тому, что написано в этом списке, то кадр просто отбрасывается. Если вдруг у вас есть большой список VLAN-ов, с которым вы хотите работать, и вы хотите его отредактировать, например, добавить еще один, то есть макросы. Эти макросы очень опасны. Вы можете сказать, что добавь к существующему списку еще один или несколько VLAN-ов. Вот это switchport trunk allowed VLAN add и дальше чего-нибудь. И есть еще макрос remove. Кажется, что это очень удобно, что у нас есть какой-то длинный список, чтобы его не перенабирать, просто говорим, добавь еще 30-й. По факту, если вы будете пользоваться этим часто, то это не вопрос того, случится это с вами или нет. Вопрос того, только когда случится. Вы рано или поздно забудете добавить added. Соответственно, вы просто наберете switchport trunk allowed VLAN, допустим, 30, и вы весь старый список затрете при этом. То есть у вас вместо 10-го и 20-го

VLAN останется только 30-й. Прекрасный способ потерять управление вашим свечом, через который вы, через транк, который вы настраиваете, потому что вы через этот же транк и подключаетесь к этому свечу удаленно. Команда showinterface switchport, как уже было сказано, выдает тот же самый вид, который показывается и для аксессовых портов, но в administrative mode показывается, как администратор сказал, мы будем работать. Operational mode как по факту работаем? Ну, как попросил, так и работаем. Administrative trunk encapsulation – это режим, в котором администратор попросил, чтобы транк работал. По умолчанию там работает negotiate, типа, попытайся договориться с соседом, в каком режиме мы будем использовать транк, если мы будем с ним договариваться о транке. За это будет отвечать дурацкий протокол DTP – Dynamic Trunking Protocol. Он вредительский, мы про него поговорим чуть дальше, но, тем не менее, да, он по умолчанию работает. И по умолчанию, если вдруг вы захотите,

чтобы он вам согласовал транк, он вам согласует и режим заодно. Но вот по факту, чего у него удалось согласовать, показывается в Operational Trunking Encapsulation. Если бы в административ Trunking Encapsulation было бы negotiate, то вот когда транк согласовался, он здесь показал, что мне удалось согласовать 802.1Q или мне удалось согласовать ISL. Но поскольку администратор именно конкретно здесь жестко прибил гвоздями 802.1Q, то Operational режим тоже, понятное дело, 802.1Q. Negotiation of Trunking дурацкий протокол DTP, который по умолчанию работает на всех интерфейсах. Мы про него сейчас будем говорить отдельно. Команда, не команда, строчка AccessModeVLAN указывает на то, что если вдруг у нас этот порт работает в Аксессовом режиме, то он будет работать в 10-м Вилане. Обратите внимание, эта строчка появляется в результате того, что, не появляется, эта строчка изменяется в результате того, что мы задаем команду SwitchPort AccessVLAN чего-то. Если у нас есть Trunk, у него тоже может быть команда SwitchPort

AccessVLAN чего-то. Она просто работать не будет. Она будет указывать, что вот эта конфигурация AccessModeVLAN у нас будет вот такая, 10-й там Вилан или 20-й. Это указывает на то, что если порт работает в Аксессе, то он будет работать в 10-м Вилане. Но поскольку у нас OperationalModeTrank, то 10-й Вилан просто не переменяется. Trunking NativeModeVLAN это показывает на то, какой NativeVLAN в этом транке мы используем. То есть поскольку это Trunk, она опять же работает. Вы можете прописать NativeVLAN и на Аксессовом порту. SwitchPort Trunk NativeVLAN чего-то. На Аксессовом порту такая команда есть. Она работать не будет в том смысле, что эффекта от нее никакого не будет. Но прописать вы ее можете, она в конфиге будет. И в скобочках показывается напротив каждого из номеров VLAN-ов имя этого VLAN-а, который вы в базе VLAN-ов оставили. Если показывается, допустим, VLAN 0010, это значение имени по умолчанию.

Это вам может помочь понять, про какой VLAN идёт речь. Если вы там сделали бухгалтерия, accounting будет написано. По accounting. Вы сразу поймёте, что это бухгалтерские порты. Если показывается inactive, значит, соответствующего VLAN-а в базе нет. Это прекрасная идея — делать такой VLAN, которого нет в базе, для этих VLAN-ов в транковом порту. Когда мы будем говорить про свитчинг, нас эта штука будет довольно сильно интересовать. Дело в том, что вы можете заставить вашу циску отправлять кадры на эти VLAN-ы с метками тоже, в обязательном порядке. Это отключает концепцию native VLAN-а, и довольно прикольная вещь, рекомендуется к использованию. Это уже на курсе по свитчингу мы разберём. Дальше там идёт про voice VLAN. Это как раз тот самый режим, когда у нас на порту будет два VLAN-а и это будет не транк.

Это будет всё-таки ещё access-порт, потому что 802.1Q-меткам, которые там будут, мы доверять не будем. Мы будем доверять только её наличию или отсутствию. Опять же, это курс по свитчингу. И Trunking VLANs Enabled — это про ручное ограничение VLAN-ов в транке. Мы указываем в явном виде, какие VLAN-ы на порту разрешены. Сейчас у нас у каждого есть по свитчу, и плюс все эти свитчи связаны с центральным свитчом. Давайте сейчас мы с вами настроим VLAN-ы на наших свитчах таким образом, чтобы у нас каждый роутер, который у нас имеется, был бы в отдельном VLAN-е. Чтобы наши роутеры и свитчи были связаны одним-единственным VLAN-ом. А те интерфейсы, которыми наши свитчи соединены между собой, они бы смотрели друг на друга уже транками. Итоговый результат, если вы посмотрите на схему,

как наши свитчи между собой и с другими устройствами соединяются, должен быть примерно следующий. Свитчи с роутерами соединены интерфейсами Ethernet 0/0, и на Ethernet 0/0 нашего свитча должен быть порт в абонентском режиме, в access-режиме. И там должен быть какой-то номер VLAN-а, который будет уникальный именно для этой связки роутер и свитч. И кроме того, наши свитчи смотрят на центральный свитч двумя интерфейсами — Ethernet 0/1 и Ethernet 0/3. Эти интерфейсы должны быть в транковом режиме. Если вдруг вы не запомнили это, не страшно. Сейчас по мере настроек будем все эти вещи реализовывать по мере необходимости. Итак, первое, что мы будем делать — это настраиваем наш интерфейс Ethernet 0/0 на свитче. У нас есть интерфейс, который смотрит на роутер. Мы хотим,

чтобы этот интерфейс был в абонентском режиме, в access-режиме и в отдельном VLAN-е. Для того, чтобы получить искомый результат, нам нужно создать тот самый VLAN, который нам понадобится для работы. Давайте сейчас создадим каждый свой отдельный VLAN. Это будет VLAN 100 плюс номер комплекта. У вас первый и второй комплект. У первого комплекта мы сделаем VLAN 101, у второго комплекта 102, и мой номер комплекта восьмой — я сделаю VLAN 108. conf t и VLAN 108. Когда я набрал команду VLAN 108, вы набрали там VLAN 101, 102, это привело к тому, что в конфигурации мы перешли в субконтекст настройки 108-го VLAN-а, и в принципе здесь, если набрать вопросик, можно увидеть те настройки,

которые мы можем здесь задать. Среди интересного есть настройка имени VLAN-а и настройка включить и выключить, shutdown. Мы сейчас имя настраивать не будем, мы просто посмотрим, что VLAN можно создать, и важно здесь заметить следующее. Пока мы находимся в субконтексте настройки 108-го VLAN-а, этого VLAN-а в базе ещё пока нет. Создастся он только тогда, когда я выйду из этого контекста, когда я наберу exit. Либо я exit наберу, либо я Ctrl+C нажму, либо я выполню какую-то команду, которая переведёт меня в другой контекст. В любом случае, я не увижу VLAN-а в базе до тех пор, пока не выйду из контекста 108-го VLAN-а. Дальше. У нас есть VLAN первый, у нас есть VLAN 108, и мы их создали. Давайте попробуем в 108-й VLAN запихать абонентский порт. И это будет порт как раз Ethernet 0/0, которым наш switch смотрит на наш роутер.

Interface Ethernet 0/0. Указываем, что интерфейс этот находится в абонентском режиме: switchport mode access. Access — вообще, по-хорошему, да. И мы должны будем указать, что не просто порт находится в абонентском режиме, а switchport access VLAN 108. Эти две команды как раз и указывают на то, что мы хотим сделать. Что на абонентском порту мы не разрешаем отправку и приём маркированных кадров, и на абонентском порту мы хотим, чтобы все кадры обрабатывались по таблице 108-го VLAN-а. Это две разные команды, они отвечают за разное. Может быть такое, что эта команда у вас будет на транковом порту. Она просто работать не будет, но она присутствовать в конфиге будет, а эффекта от неё никакого нет. Может быть такое, что у вас на абонентском порту switchport mode access будет присутствовать

команда switchport trunk native VLAN. Опять же, она в конфиге присутствовать будет, но эффекта от неё никакого не будет. Команда switchport mode access как раз указывает, в каком режиме порт по факту должен работать, в каком режиме мы заказываем работу порта. И мы указываем либо switchport mode access, либо switchport mode trunk. Сейчас мы получили следующий режим. Мы сказали, что на интерфейсе В нулевом мы хотим работать в абонентском режиме, чтобы все кадры, которые приходили на интерфейсы, приходили бы без метки, отправлялись бы без метки и обрабатывались бы по таблице 108 VLAN. Давайте посмотрим на вывод команды show VLAN, точнее, show VLAN brief. Она нам сейчас более интересна. Давайте show VLAN я просто наберу, чтобы показать вам, как она выглядит. Если я закажу show VLAN brief, то мне покажут только вот эту часть, а в show VLAN полноценном тут есть ещё всякая дополнительная информация. Информация, конечно, будет полезная, но полезна она будет нам в некоторых

специфических раскладах. Так вот, show VLAN brief, если бы я выполнил, показал бы мне только первую часть, а show VLAN, который я выполнил, показывает мне много всякого, показывает списки VLAN-ов, которые есть в таблице VLAN-ов. Первый VLAN всегда есть, с ним ничего нельзя сделать, он присутствует, и он всегда называется default, он всегда активен. 108-й VLAN, который мы создали, получил имя VLAN 0108, четырёхзначный номер, вполне достаточно для 4094 VLAN-ов. И четыре VLAN-а, которые всегда есть в базе, 1002, 1003, 1004, 1005, они присутствуют, они активны, с ними сделать ничего нельзя, но unsupported намекает нам на то, что наш switch в любом случае с token ring-ом не особо согласен дружить, поэтому завести новый порт в эти номера VLAN-ов нам не получится. И показывается, что в первом VLAN-е у нас находятся три абонентских порта Ethernet 0.1, 0.2, 0.3, а соответственно

в 108-м VLAN-е у нас находится один абонентский порт Ethernet 0.0. Если мы захотим, мы можем посмотреть детально настройки коммутации этого порта. show interface Ethernet 0.0. Не show interface, простите, show interface Ethernet 0.0 switchport. И здесь показывается, что это у нас порт действительно коммутируемый. Administrative mode — как админ сказал работать, сказал в access-е работать. Operational mode — как по факту работаем, как сказал, так и работаем. Administrative trunk encapsulation — negotiate. Говорит, что если вдруг мы будем договариваться, если вдруг мы будем переводить этот порт в транковый режим, то мы будем договариваться о типе этого транка по протоколу DTP, который мы ещё пока с вами не смотрели, но посмотрим обязательно чуть дальше. По умолчанию на Cisco этот DTP работает. Operational trunk encapsulation —

как по факту, какой тип транка будет использоваться? Никакой. Native — это значит, что все кадры идут без метки. Мы отправляем все кадры в одинаковом формате, независимо от того VLAN, в котором они будут находиться. Очень удобно, что это происходит в access-овом режиме, там, где у нас кадры все принадлежат к одному и тому же VLAN, поэтому мы никаким образом не маркируем кадры этого VLAN. Negotiation of Trunking — это как раз тот самый DTP, который на абонентских портах выключается, и очень полезная вещь. Чуть дальше, когда будем говорить про DTP, пройдём почему. Access mode VLAN 108, в скобочках имя VLAN — VLAN 0108. Это, как вы понимаете, указание, что если вдруг мы на этом порту работаем в access-е, то порт будет находиться именно в 108 VLAN. Следующая строчка: если вдруг мы будем работать в Trunk, то native VLAN будет первый. Если вдруг мы захотим, мы можем поменять эту настройку, мы можем сказать на этом порту, на Ethernet 0.0, что следует действительно перевести

switchport Trunk Native VLAN, сказать, какой-то другой VLAN, например 666. Я вам прямо покажу, что это можно сделать. Interface Ethernet 0.0, switchport Trunk Native VLAN 666. Эта команда принимается, она есть в конфиге. Если я сейчас выполню show run interface Ethernet 0.0, конфигурация интерфейса Ethernet 0.0, вот она есть. Эта команда присутствует в конфиге, только она не применяется, потому что порт в Trunk сейчас по факту не работает. И если я заказываю show interface switchport, мне показывается Trunking Native Mode VLAN 666, в скобочках inactive. Такого VLAN нет в базе, и в скобочках показывается намёк на это. Очень удобно: если вдруг вы видите, что у вас на порту

какой-то access VLAN должен быть, и он inactive, значит, либо вы умышленно это сделали, либо вы где-то ошиблись. Это не название VLAN inactive, это именно специальное ключевое слово, обозначающее, что VLAN inactive — нет в базе. Далее. Это всё нас сейчас не интересует. Про Private VLAN будем говорить на курсе по свитчингу. Это сейчас в Trunk-ах разберём. После того, как мы сделали переведение порта Ethernet 0.0 в абонентский режим в 108-й VLAN, давайте настроим Trunk-и и сделаем так, чтобы наши интерфейсы Ethernet 0.1 и 0.3 работали в Trunk-овом режиме, соответственно, передавая, например, все VLAN. При этом мы это сделаем разными способами. Первый способ я вам покажу на интерфейсе Ethernet 0.1,

который штатно предлагается к использованию в 100% случаев. Это способ, когда вы с обеих сторон жёстко фиксируете режим Trunk-а. Соответственно, я сейчас на свитче своём маленьком указываю conf t, interface Ethernet 0.1, и вы тоже у себя делаете. И на этом порту я пытаюсь зафиксировать режим Trunk-а. Кстати, если я попытаюсь сначала сказать «включи мне Trunk», на этом свитче мне сделать это не удастся, потому что этот свитч поддерживает и 802.1Q, и ISL. Поэтому switchport node Trunk выскочит с ошибкой. Система не принимает команду, говорит, что если мы используем настройки по умолчанию, которые предлагают автосогласование типа Trunk'а, то и сам Trunk'а может согласоваться только в результате этого согласования. Если у нас тип Trunk'а не согласовался, мы не можем переключить интерфейс в Trunk'. Интерфейс в Trunk'е может находиться в двух разных типах Trunk'а, либо 802.1Q, либо ISL.

И, соответственно, если мы указываем switchport node Trunk', то предварительно надо указать вместо автосогласования используя жестко заданный тип Trunk', чтобы, когда мы захотим отправить самый первый пакет, в каком-то конкретном формате его отправлять. И поэтому команда switchport Trunk encapsulation Dota 1Q. И вот после этого switchport node Trunk'а уже покатит. Я зафиксировал жестко, что никакого автосогласования типа Trunk'а у нас нету, что Trunk, если будет использоваться, то всегда 802.1Q-шный. И зафиксировал switchport node Trunk', который указывает, что да, Trunk'а у нас нужно использовать, что на этом порту разрешена отправка и прием маркированных кадров, мутантов, у которых есть дополнительное поле в заголовке. Мы на этом поле будем ориентироваться. Если вдруг коммутатор со включенным Trunk'ом принимает кадр, у которого EtherType прописан 8100, то он понимает,

что дальше идет метка VLAN. Если коммутатор принимает кадр и видит, что там в EtherType написано что-то отличное 8100, он этот кадр обрабатывает по таблице на этих VLAN. Так. Я зафиксировал режим Trunk'а. Давайте сделаем крибли-крабли-бумс и на центральном свече выяснится, что все настройки тоже такие же были даны на портах. Но единственное, что номера VLAN'ов надо будет создать. Enable, ConfT, VLAN, и давайте 101, 102 и 108. Вот так вот через запятую и одной командой создаю все три VLAN'а сразу. Ну и выхожу из режима конфигурации, из режима настройки VLAN'а для того, чтобы эти VLAN'ы по факту применились. Вот. Магическим образом выяснится сейчас, что у нас все начинает работать, что действительно на всех транках у нас настройки стали совпадать, и, соответственно,

свечи, которыми мы соединены с центральным свечом, вот через интерфейс Ethernet 01 могут обмениваться макированными кадрами. После того, как мы выполнили все эти команды, можем посмотреть на show interface Ethernet 0.1 switchport. Это тот самый порт, который мы только что включили в режиме транка. Administrative mode. Как админ сказал работать, работать в транке. Operational mode. Как по факту работает, ну, как сказал, так и работает. Administrative транкинг encapsulation.1 Q. Мы сказали show interface, простите, show interface, switchport trunk encapsulation.1 Q. И вот это вот та самая команда, которую мы задали, она фиксирует, что если вдруг мы работаем в транке, то, соответственно, транк может быть только 802.1 Q. Operational trunk encapsulation. Как админ сказал, так и работаем. 802.1 Q.

Вот эта вот штука, negotiation of trunking, означает, что на транковом порту DTP остается работающим. Он там не сильно нужен, но он остается работающим. И дальше, когда будем проходить протокол DTP, вы поймете, почему на самом деле это прикольно, что он остается работать. Ну, с одной стороны прикольно, с другой не очень. Дальше. AccessMode.VLAN. Вот эта вот команда указывает, что если у нас есть порт и работает этот порт в Аксессе, то, соответственно, будет первый VLAN использоваться. Этот порт не работает в Аксессе, поэтому эта команда не срабатывает. Если вдруг я сейчас захочу, я пропишу на интерфейсе Ethernet 01 команду switchport access VLAN 666. Ну, кстати, да, сейчас отдельно расскажу про создание автоматического VLAN. И вот как это будет выглядеть. Show интерфейс Ethernet 01 switchport. Вот.

Вот. Он показывает accessMode VLAN 666. Вот это вот указание на то, что если интерфейс работает в Аксессовом режиме, он будет, соответственно, в 666 VLAN. Но он не находится в Аксессовом режиме, потому что operational mode у нас никоим образом не static access. Это транк. Поэтому здесь вот, вот эта штука, она не работает. И в настройке интерфейса команда, которая висит, она по факту никакой роли не играет. Show run interface Ethernet 01. Вот. Вот эта вот строчка, она в конфиге место занимает, а роль никакой не играет. Поэтому бесполезная строчка, ее можно смело удалить или можно оставить. Она ни за чем не нужна. Очень часто, ну не то чтобы ошибка, очень часто явление, что в конфигурации какой-то порт сначала был в транке, потом в Аксессе, потом снова в транке, потом снова в Аксессе. И у вас может быть такое, что порт транковый, но в нем есть вот эта команда switchport.access.vlan. или интерфейс Аксессовый, а на нем висит там switchport.runc.aloud.vlan.

То есть эти команды, которые относятся к другому режиму, они в конфигурации присутствуют, но они не работают, они просто бесполезный мусор. В конфиге их можно оттуда удалить. В некоторых случаях может быть такое, что конкретный EOS не очень корректно реагирует, если вы указываете одновременно и команды switchport.access.vlan. Такие EOS есть, это известный баг, и, соответственно, лучше, если вы не будете сочетать такие команды между собой, что если у вас интерфейс в Аксессе, то в нем в конфиге есть команды по настройке Аксессового режима и нет команд по настройке танка. Это логично, ну, соответственно, да. Ничего плохого, скорее всего, не будет, если вы смешаете эти команды, если вы просто видите, что интерфейс у вас работает нормально, ну и хорошо. Ну, если есть возможность очистить интерфейс, настройку интерфейса от мусора, очищайте. Так, далее. Я хотел еще вот что показать.

Если вы указываете на свежем EOS на интерфейсе команду switchport.access.vlan и даете номер VLAN, которого не существует в базе, 15-й EOS и свежее автоматически добавляет вам в базу такой VLAN. Это поведение, на мой взгляд, вредительское, то есть я не хотел создавать этот VLAN, я хотел показать вам, что switchport.access.vlan с несуществующим VLAN действительно тоже отработает, но вот он автоматически мне добавил VLAN в базу. На 12-й EOS этого поведения не было, ну и это, мне кажется, более честно, более справедливо. То есть я не против того, чтобы он меня предупреждал, допустим, что такого VLAN нету, но то, что он автоматически VLAN за меня создает, это вот, конечно, вредительство. Ну, если что, можно его удалить, можно его зашатдаунить, то есть это по вашему усмотрению. Так, ну и, соответственно, если у нас есть транковый интерфейс, по умолчанию на нем никакого прунинга не ведется. Вот это вот trunk.vlan.senabled.

Все. Показывает на то, что у нас все VLAN разрешены на этом интерфейсе, что если вдруг приходят какие-то кадры и в этих кадрах указывается метка какого-то VLAN, мы этой метке доверяем безусловно, мы не проверяем, действительно ли такой VLAN может прийти в этом транке, и мы, безусловно, если VLAN создан в базе, то обрабатываем кадр по метке этого VLAN. А в то же время, если VLAN в базе нету, то никоим образом мы не можем обработать те кадры, которые приходят с метками несуществующего VLAN. То есть, если вдруг у нас придет кадр с указанием, не знаю, 777-го VLAN, а VLAN такого в базе у нас нет, то он здесь будет показан, что разрешен, мы его не отбросим на этапе еще получения, но дальше мы скажем, извините, у нас такого VLAN в базе нет, поэтому мы отключаемся. Равным образом, если у нас есть порт в аксессовом режиме, я еще раз покажу конфигурацию, вот у нас есть порт в аксессовом режиме, представьте себе, что здесь switchport mode access прописано. Здесь вот

switchport access VLAN 666, и у нас в конфигурации нету VLAN 666, но VLAN 666. Вот гипотетически такое же может быть, правда? Вот у нас VLAN 666 нету, я вот только что удалил. А в конфигурации прописано, что switchport access VLAN 666. Это означает, что все кадры, которые приходят, они получают метку VLAN ID 666, и они должны обработаться по таблице коммутации 666 VLAN, но такого VLAN в базе нет, поэтому все кадры на этом интерфейсе, они будут отбрасываться. А что еще с ними делать? Так что вот имейте, пожалуйста, в виду, что для того, чтобы все хорошо работало, вам нужно и определить, к какому VLAN кадры относятся, получить метку VLAN ID, и чтобы этот VLAN был в базе, потому что если хотя бы чего-то одного не хватает, то у вас коммутация будет невозможна. так, мы с вами настроили транковый порт, есть замечательная команда showinterface

trunk, можете тоже у себя ее выполнить и посмотреть на то, что действительно тот порт, который мы занесли в режим транка, он здесь появился, напротив каждого порта показывается, почему порт стал транком, в случае, если показывается mode on, это статический транкинг, то есть мы жестко прибили гвоздями switchport mode trunk, показываются типы на капсуляции, 802.1Q, опять же, мы жестко прибили гвоздями именно 802.1Q, чтобы никакого ISL и никакого согласования, статус транкинг, ну, здесь всегда будет транкинг, табличка показывает только транки, и native VLAN показывает тот native VLAN, который у нас есть, опять же, с обеих сторон этот native VLAN должен быть одинаковый, если вдруг у вас в этом транке будет бегать CDP, и если вдруг у вас этот native VLAN будет различаться с обеих сторон, то есть если у вас либо с обеих сторон будет транк, и в этом транке у вас native VLAN не совпадают, либо с обеих сторон у вас будет аксессовый режим, и там не совпадают

аксесс VLAN, либо с одной стороны native VLAN не совпадают с другой аксесс VLAN, если у вас с одной стороны транк, с другой аксесс, CDP у вас будет ругаться, он будет говорить, извините, у вас не совпадение VLAN с обеих сторон. В принципе, ни на что это не повлияет, кроме того, что будет дискомфортно от количества спама на консоли. Сейчас покажу. Conft, интерфейс Ethernet 01, switchport, trunk, native, bilan, не знаю, что, охин. В принципе, команда имеет право на существование, но система нас немедленно предупреждает, что у нас какая-то беда случилась. Так, Spanning 3 тут начал ругаться. Про Spanning 3 сейчас отдельно будем говорить. И вот, CDP. CDP ругается, говорит, у нас не совпадение native, bilan. То есть с нашей стороны задан 108-й bilan, а с другой стороны первый bilan. За счет того, что мы получаем кадры CDP-шные от соседа, он видит, что у соседа native bilan прописан один,

у нас native bilan прописан другой, и, соответственно, здесь он начинает вопить, говорить так нехорошо. Это действительно не очень хорошо. Не то, чтобы это прям могло привести к катастрофическим последствиям, это нехорошо. Поэтому для того, чтобы избежать возможных проблем, не делайте так. Ну или если вдруг делаете, то понимайте, почему вы это делаете, и выключайте CDP. То есть, например, если вдруг вы смотрите на провайдера, и вы хотите, чтобы весь трафик провайдера попадал в ваш bilan, не знаю, 777, и вы хотите, чтобы в этом bilan у вас, например, появился интернет, но вы совершенно не знаете, какой bilan со стороны провайдера прописан, выключайте CDP на этом порту. Это нормально, что вы не отправляете CDP-шные кадры своему провайдеру, и загоняйте его в любой bilan, который захотите. Но внутри предприятия, конечно, у вас на всех транках, на этих bilan с обеих сторон должны будут совпадать. Так, это базовая конфигурация транка. Мы с вами перевели интерфейс в один и в другой режим.

SwitchPort Mode Access, SwitchPort Mode Trunk. Давайте теперь поговорим про промежуточное состояние. И не то, и не другое. По умолчанию на всех портах, на цисках, работает протокол DTP, Dynamic Trunking Protocol. И у этого протокола есть одна задача. Это сделать так, чтобы стало хорошо. Чтобы если у вас порт смотрит на обычного абонента, он бы работал в Access. Если порт смотрит на соседский коммутатор, этот порт бы работал в Trunk. Но задача протокола DTP — это без какой-либо предварительной настройки автоматически перевести порт в соответствующий режим. Чтобы если у вас... Вот есть просто цисковские свечи из коробки, вы его достали, смонтировали в стойку, и он у вас на обычных абонентов согласовал Access, а на соседние свечи согласовал Trunk. А вы ручками вообще не подключались к этому свечу. Вот это типа было бы прикольно. Я даже расскажу, почему бы это было прикольно. Дело в том, что концепция Trunk'ов, она появилась примерно в конце 90-х годов. А в конце...

Простите, в конце 90-го года. Не 90-х, а 90-го. То есть 1990-й год. Управляемыми железки, циски стали примерно в конце 92-го года. И несколько лет железки, циски, они не были управляемы. Они конфигурировались только по протоколу TFTP. То есть железка загружалась, получала стартовый конфиг по TFTP, и дальше с ней ничего нельзя было сделать. Если вы хотели изменить конфигурацию циски, вы должны были перезагрузить. Она новый конфиг по TFTP бы усасывала, и, соответственно, дальше бы работала. То есть у нее не было консоли, и к ней нельзя было подключиться, налетую конфигурацию поменять. Поэтому было бы прикольно, сказали авторы, что мы со своей стороны что-то делаем, а оно само как-то там обнаруживает соседей, настраивается, и без какого-либо вмешательства, без перезагрузок, без TFTP-шного конфига само решает, что ему делать. Ну и, соответственно, DTP — это вот такая вот попытка из начала 90-х автоматизировать работу свеча

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

подключаете на него абоненты. И если вы не знаете, что там есть протокол DTP, вы не знаете, что любой абонент с вами может согласовать транк, просто прикинувшись свечом и сказав, я очень сильно хочу согласовать с тобой транк. И если вы не знаете этого поведения, вы не знаете, что ваш абонент может получить доступ ко всем-всем-всем виланам. Но, соответственно, абонент должен быть злоумышленный, конечно же. Так что вы должны будете знать, что DTP есть, вы должны будете знать, что DTP – вредительский протокол, и вы должны будете его уметь выключать. Единственное, что с ним имеет смысл делать, это выключать. Больше с ним ничего делать не надо. И благо выключение происходит, в общем-то, автоматически. Если мы выключаем, если мы переводим порт в switchport mode access, он там выключается сам. Фишка в том, что если вы его не переводите в switchport mode access, он, в принципе, в аксессии так будет работать. То есть DTP как раз потыкается в соседа, обнаружит, что на нем не обнаружен цисковский свитч, ну и, соответственно, сам переведет порт

в static access. Я сейчас вам покажу. У нас, так, у нас здесь ругается. Давайте мы это отменим. Интерфейс, какой-нибудь showinterface Ethernet 0.3 switchport. Вот по умолчанию, когда порт мы не трогаем, он находится в режиме dynamic auto. И если он с той стороны не находит соседний цисковский свитч, то operational mode получается static access. То есть DTP потыкался палочкой в соседа, не обнаружил там соседа, естественно, не обнаружил там соседний свитч и сказал, ну ладно, тогда этот порт будет в аксессии. И в таком режиме, соответственно, получается, что если мы ничего не делаем, то порты у нас работают в аксессовом режиме. Но есть нюанс. Нюанс заключается в том, что, в общем-то, никто не мешает гадкому соседу с той стороны ответить на запросы DTP и сказать, да, я цисковский свитч, давай с тобой дружить. И тогда у вас DTP согласует с вами транк.

В то же время, если вы возьмете две свежие циски, соедините их в патчкорды между собой, они у вас транк автоматом не поднимут. И это связано с тем, что у DTP есть два разных, ну, два различных режима работы. Первый – это режим desirable. Это тот режим, который изначально был в цисках, режим, который позволял автоматически согласовывать транк, когда у вас было два свитча, которые были соединены между собой проводом. У вас был провод, одна циска, другая циска. Одна циска посмотрела, обнаружила вторую, другая циска обнаружила первую. Они говорят, о, окей, давай согласовывать транк. Обе циски у себя с одной стороны и с другой стороны включают режим транк. Это был режим desirable. Если мы обнаруживаем соседа, то мы прям активно хотим согласовать с ним транк. Авто – это другой режим, который на современных цисках используется по умолчанию. Это режим, когда мы не против согласовать транк с соседом, если он сильно этого хочет. Но если вдруг

у нас есть две циски, которые находятся в режиме авто, то есть с одной стороны авто, с другой стороны авто, одна на другую посмотрит, скажет, тебе надо, другая на первую посмотрит, скажет, тебе надо, и дальше они так пассивно скажут, ну ладно, раз тебе не надо, то и мне вроде тоже не надо согласовывать транк, и они по факту перейдут в режим static access все равно. Вот на наших свитчах у нас есть порт Ethernet как раз 0.3, и вот он, Ethernet 0.3, видите, да, что по умолчанию работает режим Dynamic Auto, и там не согласуется транк. static access показывается, несмотря на то, что вот этот вот порт, он смотрит на соседний свитч. То есть мы здесь видим, что никакого по факту согласования транка не происходит, если у нас порт работает в режиме Dynamic Auto. но в то же время, если мы захотим, мы можем сказать, а давайте транк все-таки согласуем, то есть давайте воспользуемся тем, что DTP умеет согласовывать транки автоматически, и переведем этот порт в режим Dynamic Desirable. И если мы это сделаем,

у нас порт действительно станет транком, ну раз с той стороны свитч, и с другой стороны у свитча такая же настройка Dynamic Auto, ну, соответственно, он ответит на наш запрос, давай согласуем транк, и согласует с нами этот самый транк. Да. Давайте сделаем это. ConvT, interface Ethernet 0.3, switchport, mode, Dynamic Desirable. На CISCе, с другой стороны, на Core S свитче, точно такая настройка, как вот здесь вот. То есть administrative mode, там стоит Dynamic Auto. После того, как мы со своей стороны зафиксировали Dynamic Desirable, с нашей стороны Desirable, с той стороны Auto, маленький свитч приходит на большой, говорит, я очень хочу согласовать транк. Большая говорит, ну ладно, раз хочешь, давай согласуем транк. И у нас порты переходят в транковый режим. Давайте посмотрим на то,

что действительно у нас это получилось сделать. Show interface switchport. Опять же, та же самая команда. Administrative mode, Dynamic Desirable, он только что был Dynamic Auto. а operational mode стал транк, потому что DTP побежал на ту сторону, та сторона сказала, ну ладно, раз тебе надо, давай согласуем транк, и operational mode по факту получился транк. Если вы не знаете, что в нацистках работает по умолчанию протокол DTP, вы абсолютно любому желающему позволяете с вами согласовать транк. Абсолютно любому желающему даете доступ во все ваши виланы, потому что на этом интерфейсе, раз вы не закладывались под существование протокола DTP, то вы не закладывались под ограничение виланов в транке. И поэтому у вас согласовался транк со всеми-всеми виланами. Trunking VLANs Enabled All. Вот. Вы-то думали, что там access, и вы-то, возможно, там прописали команду switchport access VLAN, но этого мало. Надо еще и switchport mode access заводить. Вот.

Ну и, соответственно, administrative trunk encapsulation negotiate. Договорись автоматически, какой режим транка использовать. И operational trunk encapsulation ISL. Два Cisco switch'а договорились о том, какой режим транкинга использовать. Один другому хитро подмигнул и сказал, ну давай, раз ты Cisco и я Cisco, используем фирменный цисковский протокол ISL. И вот они согласовали ISL. Negotiation of Trunking включен. То есть на порту, на котором у нас работает динамическое согласование, работает согласование типа транка и согласование самого факта транка. И show interface trunk покажет, что у нас действительно появилось два транка. Вот здесь вот появляется вместо on статического транка слово desirable, что мы со своей стороны захотели согласовать транк, и с той стороны кто-то был как минимум не против. Может быть, с другой стороны был тоже desirable. То есть два desirable согласуют транк,

desirable и авто согласуют транк. И что еще интересно, если вы фиксируете транк жестко, switchport mode trunk, DTP там остается работать. И, соответственно, если мы с одной стороны фиксируем жестко тип транка и указываем, что switchport mode trunk должен работать, то с другой стороны все автоматически поднимается. На центральном свече, как у нас тут ругательство происходит, enable show interface trunk. С другой стороны, у нас все порты перевелись в транковый режим тоже. Видите, на каждый абонентский комплект у нас по два порта. Ну и у нас автоматическое согласование типа транка, автоматическое согласование самого транка, и первые пачки портов, которые мы использовали, они согласовались в 802.1Q. наши свечи на интерфейсах Ethernet 01 отправили указание, мы жестко работаем в транке, мы жестко работаем в 802.1Q. Но ты, если хочешь,

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

есть несовпадение на эти филаны, и вот это препятствует нормальной работе DTP. То есть, казалось бы, да, где DTP и где на эти филаны, но нет, ну действительно, это становится грустно, и он отказывается согласовывать транк в этом случае. Так, мы с вами еще дальше посмотрим, есть такой протокол VTP, VLAN-транк, это протокол. Вот если там, например, имя домена будет неодинаковое, то DTP тоже от этого погрустнеет и тоже не будет согласовывать транк. При работе с DTP рекомендация, в общем, простая. Выключайте его везде, то есть на абонентском порту DTP просто вреден, потому что вы не хотите с абонентскими портами работать в автоматическом согласовании транка. Абонентский порт мы фиксируем с switchport mode access, тем самым выключая динамическое согласование. А если вы заводите статический транк, то DTP там бесполезен,

потому что если вы, с одной стороны, статический транк прибили гвоздями, то с другой стороны, для вас не будет проблемы прибить его тоже гвоздями. Вот сейчас у меня на центральном свитче просто много портов, на которых я бы должен был прибить гвоздями транк, switchport mode trank и switchport trank encapsulation.21q, мне было лень, и я проманкировал своими обязанностями. Но вообще, по-хорошему, если бы я работал в предприятии, я бы, конечно, не просто с одной стороны сказал switchport mode trank, но и с другой стороны, на соответствующем порту центрального свитча тоже бы сказал switchport mode trank. Поэтому DTP бесполезен в современном мире. Мы не ожидаем, что у нас на каких-то портах внезапно должны заводиться транки. Везде, где транки должны заводиться, мы можем ручками прописать switchport mode trank, поэтому DTP нам не нужен. Настройки на смотрящих друг на друга транках на разных свитчах должны быть одинаковые. В частности, Должен быть одинаковый набор разрешенных виланов, allowed вилан, и одинаковый native вилан.

Лучше будет, если эти native вилан будут отсутствовать в базе или будут выключены командой shutdown. Для того, чтобы на ваш native вилан нельзя было устроить атаку. Show interface trunk я уже показал. Здесь интересно, что будет. У нас будет тут четыре графы. Первая, вторая, третья и четвертая. В первой графе показывается, какие у вас есть транки, в каком режиме они получились транками. Это означает, что это статический транк, desirable, что он автосогласовался. Если в графе encapsulation стоит N чего-то там, то это автосогласованный тип транка, вот это жёстко зафиксированный 802.1Q, а это автосогласованный ISL. И, соответственно, native виланы, здесь с ними всё понятно, native виланы и в Африке native виланы. Вторая графа, первая, вторая, третья и четвертая. Вторая графа показывает, какие виланы на этом транке разрешены. То есть switchport trunk allowed vlan здесь показывает

просто вывод этой команды. Здесь показывает, что на этом 0/0 порту у нас разрешены 10, 20 и 30 виланы. На гигабите 0/1 сработало автосогласование, там никто не задавал команду switchport trunk allowed vlan, и все виланы будут разрешены. С 1 по 4094. Как было сказано, 0 и 4095 использовать не рекомендуется. Или нельзя даже. Дальше. Третья графа показывает пересечение второй графы с тем, какие виланы есть в базе. Если у нас в базе нету никаких виланов, кроме первого и десятого, то из всего множества десятый, двадцатый, тридцатый виланы, которые в транке в принципе разрешены, по факту работать будет только десятый, потому что вилан в базе есть десятый, а двадцатого нет, а тридцатого тоже нет. Равным образом из всего диапазона с 1 по 4094 четыре тысячи виланов, которые в принципе гипотетически на первом порту у нас могут приходить, по факту будут работать тоже только два, первый и десятый.

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

Дальше. Третья графа — это как раз про пересечение множества разрешённых виланов на транке со множеством виланов, которые есть в базе. И четвёртое — это пересечение для каждого порта результата третьей графы с тем, что сказал Spanning Tree. Spanning Tree — это протокол, который умеет блокировать коммутацию, если мы говорим именно про циски, отдельных виланов на отдельных транках. И, соответственно, может быть такое, что у нас, допустим, гигабит 0/0 сказал 10-й вилан, пожалуйста, пропускайте, а вот на гигабите 0/1 он сказал, нет, ни первый, ни десятый вилан мы обрабатывать на этом порту не должны, иначе мы там устроим петлю. И Spanning Tree коммутацию заблокировал, и как следствие в четвёртой графе показывается, что трафик первого и десятого вилана не ходит через четвёртый порт. Это удобная команда для диагностики того, почему трафик определённого вилана не ходит через определённый транк. Это происходит либо потому, что Spanning Tree заблокировал, либо потому, что вилана в базе нет, либо потому, что прунинг,

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

И в этом случае мы должны будем физический интерфейс просто включить, командой no shutdown, а дальше создать отдельный виртуальный интерфейс. Интерфейс с названием физического интерфейса, и дальше точка и некое число. Это номер субинтерфейса, так называемого. Вся эта конструкция будет называться субинтерфейс. В настройках субинтерфейса мы можем давать любые конфигурации, которые нам нравятся. Можем IP-адреса вешать, можем вешать access-листы, можем вешать политики quality of service. Всё что угодно можем делать, но есть нюанс. Для того, чтобы трафик попадал в субинтерфейс, приходит кадр 10 вилана. Мы должны будем сказать, что трафик 10 вилана попадает именно в субинтерфейс 10. Если рядышком идёт кадр 20 вилана, мы должны будем сделать так, чтобы он попал в субинтерфейс 20. Физически всё это будет приходить на родительский интерфейс, который гигабит 0/0. Но мы укажем, что если у нас есть субинтерфейс, который заканчивается на точка 10, то в этот интерфейс попадает трафик,

который маркирован 802.1Q 10 заголовком. Encapsulation dot1Q 10. Вот эта десятка — это номер субинтерфейса, а вот эта десятка — это номер вилана. Они могут не совпадать, но если они совпадают, это просто удобно. Вы не запутаетесь, когда у вас номер вилана, допустим, 666, а номер субинтерфейса 153. Если они везде у вас одинаковые, то это удобно, это комфортно. И я рекомендую вам, если у вас есть такая возможность, делать всегда именно так, чтобы номер субинтерфейса и номер вилана совпадали. И тогда сразу глазками будет видно по номеру интерфейса, трафик какого вилана он ловит. Давайте попробуем с вами аналогичную конструкцию соорудить. У нас сейчас есть интерфейс, который смотрит на свитч. И в этом интерфейсе у нас используется 100-какой-то-там вилан в аксессовом режиме. Сейчас мы переведём этот интерфейс в транк, и на этом интерфейсе скажем, что будет разрешена отправка двух виланов. Первого и вот этого самого 100-какого-то-там.

Так, центральный свитч. У меня тут ругается что-то, но ничего страшного. Вот он роутер. У меня диалог начальной настройки, нужно будет от него отказаться. Но пока он там отказывается, я могу продолжить настройку свитча. Итак, enable, show run interface Ethernet 0/0. Это интерфейс, который сейчас у нас есть на нашем свитче, смотрит в сторону роутера. Интерфейс сейчас находится в аксессовом режиме. И, соответственно, у нас сейчас на этом интерфейсе указана команда switchport access VLAN 108, что означает, что весь трафик, который проходит через интерфейс, коммутируется по 108-му вилану. И мусорная команда switchport trunk native VLAN 666. Давайте переведём этот порт в транковый режим и укажем, что у нас есть два вилана, которые мы согласны отправлять в этот порт. Configure terminal. Interface Ethernet 0/0. Соответственно, switchport trunk encapsulation dot1Q.

Это на свитче делается, без этого не заработает. Если мы хотим зафиксировать, что у нас порт будет в транке, мы должны указать, в каком транке. Switchport mode trunk. Перевели порт в транковый режим. И switchport trunk allowed VLAN. Первый и 108-й в моём случае. У вас первый и 102-й, первый и 101-й, там какой-то. Show run interface Ethernet 0/0. Вот такой результат должен получиться. Порт работает в транке. Разрешённый набор виланов в транке — 1 и 108-й. Тип транка 802.1Q. И, соответственно, native VLAN у нас остался, вы можете у себя прописать. Пропишите её, пожалуйста. Главное, не сделайте первый VLAN, потому что нам будет важно, чтобы native VLAN был отличным от первого.

Если вы поставите 666, это будет прекрасно. Главное, чтобы такого VLAN в базе не было, или он был выключен. И соответственно. Switchport access VLAN 108, тоже команда, которая в конфиге была, она осталась, она никуда не делась. Она не применяется, потому что порт не в аксессе. Но тем не менее в конфиге она есть. Вы можете в конфиге на интерфейсе держать и команды аксессового режима, и команды транкового режима. Просто применяться в каждое конкретное время будут только команды из нужного режима. Опять же, вы можете использовать динамическое согласование. И допустим, если у вас вдруг это зачем-то будет нужно, вы можете сказать, что пусть мы согласуем транк, если у нас транк согласуется, то мы держим такие конфигурации транка. А если транк не согласуется, то мы держим такие конфигурации аксессового порта. Мало кому это нужно, но мало ли вдруг вам когда-то пригодится. Что я со своей стороны сделал на интерфейсе Ethernet 0/0? И думаю, что вы тоже уже сделали. Перевел порт в транк и сказал, что в этом транке будут бегать два VLAN. Первый и 108.

На стороне роутера сейчас надо будет сделать ответные действия. Enable. Conf t. Так. Интерфейс Ethernet 0/0, которым роутер смотрит на switch. Его надо как минимум не выключить. Если он будет выключен, то на уровне физики ничего передаваться не будет, и это будет, конечно, не то, чего мы хотим. Дальше. После того как мы зафиксировали, что порт работает, больше ничего с родительским интерфейсом делать не нужно. От него нужно, чтобы он был не выключен. Но мы для отлова трафика разных VLAN-ов создаем субинтерфейсы. Интерфейс Ethernet 0/0.1. Такой же, как физический интерфейс, но через точку добавляем единичку. Это интерфейс для отлова трафика первого VLAN-а. Указываем encapsulation dot1Q 1.

В этот интерфейс будет ловиться трафик первого VLAN-а, и система нам ругается, говорит, что у нас на этом интерфейсе дуплекс не соответствует. Как-то печально. Duplex full. Он сможет так? Не сможет. А так? А так сможет. Так. Возвращаемся в настройку субинтерфейса. И на субинтерфейсе у нас уже прописан encapsulation dot1Q 1. На этом интерфейсе мы можем прописать IP-адреса. Давайте пропишем IP-шник и скажем, что у нас на этом интерфейсе висит IP-адрес. IP-адрес 192.168.0. Номер комплекта. У меня восьмой. 255.255.255.0. И на этом интерфейсе у нас уже есть команда encapsulation dot1Q. Если бы её не было,

то при попытке повесить IP-шник система бы сказала, надо сначала задать тип инкапсуляции. То есть какой трафик через этот интерфейс будет обрабатываться. Все кадры, которые по родительскому Ethernet 0/0 интерфейсу приходят с меткой первого VLAN-а, они отправляются в субинтерфейс Ethernet 0/0.1. Рядышком мы можем сделать другой интерфейс. Интерфейс Ethernet 0/0.108. Это, как вы догадываетесь, будет интерфейс для отлова трафика 108 VLAN-а. Опять же, нужно будет encapsulation dot1Q задать с указанием 108 VLAN-а. И здесь тоже можно повесить какой-нибудь IP-шник. Давайте какой-нибудь повесим. В принципе, неважно какой, потому что у каждого из нас VLAN будет разный, и это соответственно будут разные сети. Например, можем сделать 192.168.номер_комплекта.1. Без разницы, какой он будет,

всё равно это ни на что особо не повлияет. И получается, что у нас на роутере есть два интерфейса, на которых висят IP-адреса. Появление IP-адреса на интерфейсе порождает connected маршрут. И у нас сейчас есть один интерфейс, который смотрит в первый VLAN с IP-шником 192.168.0.что-то. И интерфейс, который смотрит в какой-то другой VLAN с адресом каким-то другим. Show IP route. Вот два интерфейса, два connected маршрута. Такой маршрут и другой маршрут. И по идее мы сейчас даже должны иметь возможность друг друга пинговать. Ping 192.168.0.1. Первый комплект пингается, не пингается? Пока не пингается. Делайте у себя аналогичные настройки. Ethernet 0/0 надо включить. Ethernet 0/0.1 — надо на него повесить

IP-шник 192.168.0. Ваш комплект. Так, пока не пингается. Так, проверяем, может быть, на что-то повлияло. Нет, пока нет. Нет. Тоже пока нет. Давайте проверим. Может, я где-то ошибся. Show run interface Ethernet 0/0. Физический интерфейс. Нет, он работает. Смотрите, он автоматически добавляет на первый VLAN слово native. Эта штука native означает, что трафик и маркированный первым VLAN-ом, и не маркированный ничем отправляется в этот самый Ethernet 0/0.1 интерфейс. А трафик первого VLAN отправляется соответственно без метки.

Наши свитчи настроены таким образом, чтобы native VLAN ловить не в... Не в... Как называется-то? Не в первом VLAN. Не маркированные кадры они отправляют в 666 VLAN. По крайней мере, мой свитч. Давайте мы сделаем это правильно. Давайте мы сделаем так, чтобы у нас на стороне свитча здесь была команда, которая указывала native VLAN, не существующий. Там, 666. А со стороны роутера мы скажем, что первый VLAN native быть не должен. Cisco считает, что если у нас есть 802.1Q-шный транк, то там всегда должен быть какой-то VLAN native. И это поведение, когда она первый VLAN автоматически обзывает native, оно в нашем случае немножко вредительское. И для того чтобы его победить, нам нужно какой-то другой интерфейс объявить как получатель native трафика, который будет не маркированный. Давайте мы это сделаем.

Интерфейс Ethernet 0/0.666. Encapsulation dot1Q 666 native. Эта команда скажет, что в этот интерфейс будет приходить как трафик, который маркирован 666, так и трафик, который приходит без метки. И метка native автоматически в этом случае с Ethernet 0/0.1 уберётся. Проверяем, что интерфейс Ethernet 0/0.1 потерял этот самый native, зато у нас появился этот прекрасный товарищ, который собирает трафик, который приходит без метки. И если всё сделано правильно, то сейчас у нас должно заработать. Здесь моя ошибка была. Первый IP-шник пингается, второй... Второй пока нет, но сейчас запингается. Ещё разочек.

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

И соответственно, если мы используем с одной стороны свитч, с другой роутер, то на роутерах DTP не поддерживается. Поэтому мы всё должны делать с обеих сторон руками. Среди прочего, надо native VLAN руками задавать. Так. Прописали транки на маршрутизаторах. Если у нас есть субинтерфейсы, то они каждый имеют своё собственное состояние. Можно выключить отдельный субинтерфейс, и тем самым в таблице маршрутизации у вас connected маршрут пропадёт. Но есть нюанс. Если вы выключите физический родительский интерфейс, то у вас все дочерние интерфейсы, естественно, тоже погаснут. Если вы на физике не отправляете нолики-единички, то понятное дело, что там работать ничего не будет. Если вы хотите, чтобы у вас какие-то настройки применялись к отдельному VLAN, то их надо задавать на соответствующих субинтерфейсах. К родительскому интерфейсу, как правило, вам вообще ничего не нужно делать. Не нужно туда вообще лезть, за исключением команды shutdown или no shutdown.

Если вы хотите задать какие-то настройки по access-листам, по скорости, по чему угодно, по шейпингу трафика, по анализу трафика, по отслеживанию его, по firewall, это всё делается в субинтерфейсах. После того как мы создали субинтерфейсы, дальше мы работаем с ними как с нормальным полноценным интерфейсом, который смотрит в нужную нам среду. Если вы делаете native VLAN какой-то, то вы можете создать отдельный субинтерфейс и в него трафик этим самым native отбирать. То же самое, что мы сейчас только что сделали. Есть старая рекомендация использовать настройки родительского интерфейса. Если вы хотите, вы можете в принципе это сделать, вы можете сказать, что у вас есть родительский интерфейс, в который отбирается трафик без метки. И на него повесить IP-шник, и там всякие разные другие вещи делать. Это работает не очень стабильно, поэтому в современном мире, если вдруг вы делаете конфигурацию

транка на роутере, она ещё называется роутер на палочке, router on a stick, предполагается, что в современном мире вы всегда делаете отдельный субинтерфейс для каждого отдельного VLAN в транке. И давайте быстренько расскажу про VTP. VTP — это древний протокол, древнючий-древнючий. Опять же, нужный был тогда, когда у Cisco IOS ещё не было конфигурации. Точнее, конфигурация была, но она загружалась через TFTP, вы не могли её проадминить с консольки, вы не могли ничего ввести с клавиатуры, вы должны были перезагрузить целиком железку и подгрузить на неё конфиг в текстовом файлике для того, чтобы она начала как-то работать. И если у вас была какая-то большая-большая сеть, в которую вы плодили VLAN, для того чтобы обрабатывать трафик определённого VLAN, вам надо в базе VLAN создать на каждом коммутаторе этот VLAN.

Потому что иначе, если у вас есть цепочка коммутаторов, первый коммутатор, который смотрит на второй коммутатор, который смотрит на третий, который смотрит на четвёртый. Вы здесь создали 101-й VLAN, потом здесь надо создать 101-й VLAN, здесь надо создать 101-й VLAN, здесь надо создать 101-й VLAN. И только после этого компьютер, который находится в 101-м VLAN-е с одной стороны, и компьютер, который находится в 101-м VLAN-е с другой стороны, смогут вести взаимодействие между собой. До тех пор пока вы этого не сделали, пока вы не создали VLAN на всех транзитных свитчах, трафик не ходит. И на старых IOS-ах, которые совсем-совсем древние, до 92-го года были, как уже было сказано, нельзя было настраивать эти железки без TFTP, без перезагрузки устройства полной. Поэтому, если вы хотели создать здесь 101-й VLAN, здесь 101-й VLAN, здесь 101-й VLAN, вы их должны были перезагрузить. По-любому. И у вас пока перезагружается этот свитч, пока перезагружается этот свитч, пока перезагружается этот. Это дикий объём работы. Раз. И дикое время недоступности

сети — два. И на лету так особо не поперезагружаешь железки. Вам захотелось нового VLAN? А что бы нам не сделать нового VLAN? А давайте поперезагружаем всю сетку так ради смеха. Неудобно и, главное, вызывает лютое беспокойство со стороны пользователей. Cisco предложила, точнее, это ещё не Cisco предложила, это компания Crescendo, которую потом Cisco купила, предложила фирменный протокол, который назывался VTP. VLAN Trunking Protocol. И этот протокол заключался вот в чём. Вы могли на одном свитче создать VLAN каким-то образом. А дальше он автоматически разлетался по всем остальным свитчам без необходимости их конфигурировать. На старых, древних свитчах это было очень круто. Потому что действительно, вы только один свитч настроили, перезагрузили, а все остальные свитчи перезагружать не надо. Это же круто. Но на новых свитчах это неудобно использовать, потому что первый протокол, который у Cisco получился, VTP первой версии, равно как и второй версии на самом деле,

они имеют очень большие проблемы с безопасностью. Так же, как и DTP. Они включены по умолчанию. VTP включён по умолчанию. И точно так же, как и DTP, он, мягко говоря, нехорошо себя ведёт тем, что он максимально скрывает своё поведение. Если вы просто взяли новую Cisco, воткнули её в сеть, она никоим образом не показывает, что VTP на ней есть. Если вы не знаете, что такой протокол существует, если вы не знаете, что он в полудохлом состоянии активирован на любой железке, то фактически это бомба замедленного действия, которая только ждёт того, чтобы её проадминили. И соответственно, если вдруг каким-то образом что-то пойдёт не по плану, то VTP вам может удалить всю базу VLAN-ов. Он может её переколбасить по своему усмотрению, просто потому что может. Поэтому мы в большинстве ситуаций, если не хотим использовать протокол VTP, хотим его выключить. Выключается он либо командой VTP mode off, либо VTP mode transparent. Но лучше VTP mode transparent использовать.

И эта команда фактически отключает действия протокола VTP. Как следствие, у вас база VLAN-ов немножко изменяет своё местоположение. На старых свитчах, которые обменивались данными о VLAN-ах с помощью протокола VTP, был специальный отдельный файлик, который назывался не NVRAM, а flash:vlan.dat. И соответственно, flash:vlan.dat — это файлик, в котором хранилась база VLAN-ов, и фактически протокол VTP обменивался этим файликом. Как только изменения в базу VLAN-ов происходили, файлик обновлялся, и дальше он на все остальные железки раскидывался именно в виде файлика. Смысл протокола VTP заключался в том, что он позволял обновлять базу VLAN-ов без перезагрузки устройства, но работал он исключительно по транковым портам. Смысл в этом вполне конкретный был: если у вас есть фирменные цисковские свитчи, они автоматически согласуют между собой транки с помощью DTP,

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

Роутер. И вот он, свитчик. Enable. Conf t. Давайте сделаем VLAN 777. Обычно, когда мы применяем команду, когда нажимаем Enter, она сразу применяется, сразу работает. Но здесь do show vlan brief. Эта команда не отработала. Мы видим, что VLAN 777 на свитче не появился. Но как нам сделать, чтобы он появился? Достаточно выйти. Мы выходим из этого контекста VLAN 777, снова выполняем команду show vlan brief, и вот он, VLAN 777. Операция записи внутрь файла произошла только тогда, когда мы вышли из контекста VLAN-а. Делается это специально для того, чтобы если мы зашли в субконтекст настройки VLAN-а, переименовали, включили, выключили, чтобы все эти действия сбросить на флешку одним скопом, чтобы прошла одна операция записи,

а не 3 или 4. И как следствие получается, что если вы не знаете про это поведение файлика vlan.dat, то вы можете оказаться в ситуации, когда выполнили команду vlan 777, и остались в этом контексте и думаете, что у вас VLAN создался. Честно сказать, я сам в такой ситуации несколько раз оказывался, что вроде выполнил, нажал Enter, думаю, что у меня всё хорошо, лезу проверять — не работает. Думаю, что за фигня. Проверяю, ещё раз пишу vlan 777, повторно ничего не работает, потому что я всё по-прежнему остаюсь в том же самом контексте config-vlan 777. Я только после этого вспоминаю, что да, надо выйти из контекста, и тогда всё будет хорошо. Но если вы указываете VTP mode transparent, то у вас база VLAN-ов переезжает. VTP mode transparent. Система предупреждает, что она изменяет режим работы VTP, и соответственно, сейчас все изменения,

которые мы будем вносить в базу VLAN-ов, они будут вноситься не в файлик vlan.dat, они будут вноситься напрямую в конфигурацию. Вы можете взять и посмотреть, что если у вас VTP находится в файловом режиме, то есть VTP mode transparent вы команду не вводили, то у вас в конфигурации, в show run, вообще нет никаких указаний про VLAN-ы. Давайте я верну, как было. No VTP mode transparent. Посмотрим, так отработает. И я здесь указываю do show run | include vlan. И здесь, как вы видите, вообще про VLAN ничего нет. Весь конфиг, который содержит слово VLAN. И здесь вообще нигде нет указаний про то, какие VLAN-ы созданы. Этот 777 VLAN отсутствует в конфиге. И связано это с тем, что действительно 777 VLAN хранится в отдельном файлике vlan.dat.

Но если мы указываем VTP mode transparent, то у нас появляется строчечка VLAN. Те самые VLAN-ы, которые раньше хранились в файлике, они теперь переезжают в конфигурацию. Это удобно, потому что если у вас есть свитчик, в котором VTP не выключен, то соответственно у вас получается по факту конфигурация этого свитча хранится в двух местах. Первое место — это startup-config или running-config, как хотите, а второе место — это тот самый файлик flash:vlan.dat. Если вы выключаете VTP, у вас вся конфигурация находится в одном месте и позволяет вам бэкапить конфигурацию, позволяет вам сбрасывать конфигурацию быстро и эффективно одной командой просто по удалению startup-config. Ещё раз хотел бы напомнить, что команда show vlan, которая здесь есть, show vlan brief, она показывает только абонентские порты. Здесь, например, нам показывают,

что Ethernet 0/2 есть в первом VLAN-е, но больше нигде никаких портов нет. Связано это с тем, что все наши остальные порты находятся в транке. Ethernet 0/0 — это транк, который смотрит на наш роутер, а Ethernet 0/1 и 0/3 — транк, который смотрит на центральный свитч. А Ethernet 0/2 действительно работает в access, и вот он в первом VLAN-е находится. Переводите на всех своих свитчах VTP в transparent режим, кроме случая, когда вы знаете, что VTP у вас используется в вашей конфигурации. Если вы знаете, что VTP у вас не работает, что никто его не настраивал, то выключаете его. vtp-мон-транспорент, и это будет, скорее всего, позитивно. Но если вы вдруг узнаете, что vtp у вас используется в продакшне, то есть он у вас настроен, у вас в конфигурации, есть какие-то следы vtp, и do show run include vtp, покажет вам, что что-то кроме vtp-мон-транспорента у вас в конфигурации есть. Например, прописан vtp-домейн-нейм,

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