Vtp что это такое

Vtp что это такое

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

VLAN Trunking Protocol (VTP) — проприетарный протокол компании Cisco Systems, предназначенный для создания, удаления и переименования VLANов на сетевых устройствах. Передавать информацию о том, какой порт находится в каком VLANе, он не может.

Аналогичный свободный протокол: GVRP

Содержание

[править] Описание протокола

[править] Версии протокола

Версия 3 VTP доступна:

[править] Сообщения VTP

[править] Режимы работы протокола

На коммутаторе VTP может работать в трёх режимах:

В версии 3 VTP добавился новый режим работы и изменились некоторые режимы работы, по сравнению с предыдущими версиями:

[править] Диапазоны VLAN

[править] VLAN database

Сервера VTP должны иметь возможность сохранять информацию, полученную в обновлениях VTP от других серверов, без участия администратора. Для этого в коммутаторах Cisco под управлением IOS используется VLAN database. Это отдельный файл, который хранится во флеш и называется vlan.dat.

При обнулении конфигурации коммутатора, VLAN database не затрагивается, поэтому зачастую получается, что информация о VLAN и настройках VTP сохраняется после обнуления и перезагрузки коммутатора. Для того чтобы удалить VLAN database необходимо удалить файл vlan.dat.

Можно изменить название файла в котором хранится VLAN database:

[править] Настройка VTP на коммутаторах Cisco

[править] Настройка VTP версии 2

Имя VTP-домена (от 1 до 32 символов):

Настройка пароля, который будет использоваться для аутентификации в VTP-домене (от 1 до 32 символов):

Настройка второй версии протокола VTP:

Настройка режима VTP:

[править] Настройка VTP версии 3

Версия 3 VTP доступна:

Имя VTP-домена (от 1 до 32 символов):

Настройка пароля, который будет использоваться для аутентификации в VTP-домене (от 1 до 32 символов):

Настройка версии протокола VTP:

Если настроены VLAN расширенного (extended) диапазона, переводить VTP обратно в версию 2 или 1 из третьей запрещается.

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Протокол VTP

Передача информации о VLAN

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Для начала вспомним что же такое VLAN. VLAN – это Virtual Local Area Network, что дословно переводится как “виртуальная локальная сеть”. При создании VLAN’а хосты физической сети, объединенные общей функцией, выделяются в логическую виртуальную сеть, при этом их физическое местонахождение не имеет значения. Обычно VLAN настраивается на сетевом коммутаторе, по средствам добавления портов, за которыми находятся хосты подлежащие объединению, в группу. Выглядит это примерно так:

На слайде приведен случай, когда на коммутаторе настроено два VLAN’a. Порты с 1 по 3 принадлежат VLAN’у 10, а порты с 6 по 8 находятся во VLAN’е 20.

Команды, которые вводил администратор для такой конфигурации, примерно такие:

Как видите набор команд довольно простой, но администратор вводил их на единственном коммутаторе. Хосты реальных VLAN’ов могут быть рассредоточены по сети и находиться за разными устройствами, как показано на рисунке:

Как видно из рисунка хосты принадлежащие VLAN 10 рассредоточены по сети, они находятся как за коммутатором 1 так и за коммутатором 3. Для того, чтобы они могли корректно взаимодействовать, администратору вручную придется создавать VLAN на каждом устройстве и добавлять в них порты. Реальные сети могут содержать ещё больше VLAN сетей и каждую необходимо прописать вручную, в следствие чего растет вероятность допущения ошибок в конфигурации, которая может привести перекрестному соединению и многочисленным несогласованностям.

Для того чтобы исключить вероятность таких ошибок и был разработан протокол VTP, который позволяет устройствам автоматически делиться информацией о настроенных на них VLAN’ах и самостоятельно вносить изменения в конфигурацию.

Режимы работы VTP

VTP коммутатор имеет два режима работы:

В этом режиме можно создавать новые и вносить изменения в существующие VLAN’ы.

Коммутатор будет обновлять свою базу VLAN’ов и сохранять информацию о настройках во Flashпамяти в файле vlan.dat.

Генерирует и передает сообщения как от других коммутаторов, работающих в режиме сервера, так и от клиентов

Коммутатор в этом режиме будет передавать информацию о VLAN’ах полученную от других коммутаторов и синхронизировать свою базу VLANпри получении VTPобновлений. Настройки нельзя будет поменять через командную строку такого устройства. 3) Transparent

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

Типы сообщений VTP

В VTPсуществует три типа сообщений:

Представляет из себя запрос от клиента к серверу на оповещение SummaryAdvertisement

Данное сообщение по умолчанию сервер отправляет каждые 5 минут или сразу же после изменения конфигурации.

Отправляется сразу же после изменения конфигурации VLAN, а также после запроса на оповещение.

Стоит отметить, что VTPкоммутатор, который получает информацию о новых VLAN’ах, внесет ее в свою конфигурацию только в том случае, если сообщение пришло от коммутатора с большим номером ревизии.

Номер ревизии это некий идентификатор “свежести” базы VLAN. Коммутатор воспринимает базу с наивысшим номером ревизии как самую “свежую” и вносит изменения в свою конфигурацию.

Протокол VTPявляется проприетарным, т.е закрытым. Он сильно облегчает жизнь администраторам, работающим с оборудованием Cisco.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Источник

Тренинг Cisco 200-125 CCNA v3.0. День 35. Динамический протокол транкинга DTP

Сегодня мы рассмотрим динамический протокол транкинга DTP и VTP – протокол транкинга VLAN. Как я говорил на последнем уроке, мы будем следовать темам экзамена ICND2 в том порядке, в котором они приведены на сайте Cisco.

В прошлый раз мы рассмотрели пункт 1.1, а сегодня рассмотрим 1.2 – настройка, проверка и неполадки соединений сетевых коммутаторов: добавление и удаление VLAN из транка и протоколы DTP и VTP версии 1 и 2.

Все порты свитча «из коробки» по умолчанию настроены на использование режима Dynamic Auto протокола DTP. Это означает, что при соединении двух портов разных свитчей между ними автоматически включается транк, если один из портов находится в режиме trunk или desirable. Если порты обоих свитчей находятся в режиме Dynamic Auto, транк не образуется.

Таким образом, все зависит от настройки режимов работы каждого из 2 свитчей. Для удобства понимания я сделал таблицу возможных комбинаций режимов DTP двух свитчей. Вы видите, что если оба свитча используют Dynamic Auto, то они не образуют транк, а останутся в режиме Access. Поэтому если вы хотите, чтобы между двумя свитчами был создан транк, то должны запрограммировать хотя бы один из свитчей на режим Trunk, или же запрограммировать транк-порт на использование режима Dynamic Desirable. Как видно из таблицы, каждый из портов свитча может находиться в одном из 4-х режимов: Access, Dynamic Auto, Dynamic Desirable или Trunk.

Если оба порта настроены на Access, соединенные свитчи будут использовать режим Access. Если один порт настроен на Dynamic Auto, а другой на Access, оба будут работать в режиме Access. Если один порт работает в режиме Access, а другой в режиме Trunk, соединить свитчи не получится, поэтому такую комбинацию режимов нельзя использовать.

Итак, для работы транкинга необходимо, чтобы один из портов свитчей был запрограммирован на Trunk, а другой – на Trunk, Dynamic Auto или Dynamic Desirable. Транк образуется также в случае, если оба порта настроены на Dynamic Desirable.

Разница между Dynamic Desirable и Dynamic Auto заключается в том, что в первом режиме порт сам инициирует транк, отсылая DTP-фреймы порту второго свитча. Во втором режиме порт свитча ждет, пока кто-либо не начнем с ним общаться, и если порты обоих свитчей настроены на Dynamic Auto, между ними никогда не образуется транк. В случае Dynamic Desirable имеется обратная ситуация – если оба порта настроены на этот режим, между ними обязательно образуется транк.

Я советую вам запомнить эту таблицу, так как она поможет вам правильно настроить свитчи, соединенные друг с другом. Давайте рассмотрим этот аспект в программе Packet Tracer. Я последовательно соединил вместе 3 свитча и сейчас отображу на экране окна консолей CLI для каждого из этих устройств.

Если я введу команду show int trunk, мы не увидим никакого транка, что совершенно естественно при отсутствии необходимых настроек, так как все свитчи настроены на режим Dynamic Auto. Если я попрошу показать параметры интерфейса f0/1 среднего свитча, вы увидите, что в режиме административных настроек значится параметр dynamic auto.

Аналогичные настройки имеются у третьего и первого свитчей – у них также порт f0/1 находится в режиме dynamic auto. Если вы помните таблицу, для транкинга все порты должны находиться в режиме trunk либо один из портов должен быть в режиме Dynamic Desirable.

Давайте зайдем в настройки первого свитча SW0 и настроим порт f0/1. После ввода команды switchport mode система выдаст подсказки возможных параметров режима: access, dynamic или trunk. Я использую команду switchport mode dynamic desirable, при этом вы можете заметить, как транк-порт f0/1 второго свитча после ввода этой команды сначала перешел в состояние down, а затем, после получения фрейма DTP первого свитча перешел в состояние up.

Если теперь в консоли CLI свитча SW1 ввести команду show int trunk, мы увидим, что порт f0/1 находится в состоянии транкинга. Я ввожу ту же команду в консоли свитча SW1 и вижу ту же информацию, то есть теперь между свитчами SW0 и SW1 установлен транк. При этом порт первого свитча находится в режиме desirable, а порт второго – в режиме auto.

Между вторым и третьим свитчем связь отсутствует, поэтому я перехожу в настройки третьего свитча и ввожу команду switchport mode dynamic desirable. Вы видите, что во втором свитче произошли те же смены состояния down-up, только теперь они касаются порта f0/2, к которому подсоединен 3 свитч. Теперь второй свитч имеет два транка: один на интерфейсе f0/1, второй на f0/2. Это можно увидеть, если использовать команду show int trunk.

Оба порта второго свитча находятся в состоянии auto, то есть для транкинга с соседними свитчами необходимо, чтобы их порты были в режиме trunk или desirable, потому что в этом случае существует всего 2 режима для установки транка. С помощью таблицы вы всегда можете настроить порты свитчей таким образом, чтобы организовать между ними транк. Вот в чем заключается суть использования динамического протокола транкинга DTP.

Давайте приступим к рассмотрению протокола транкинга VLAN, или VTP. Этот протокол обеспечивает синхронизацию баз данных VLAN разных сетевых устройств, осуществляя перенос обновленной базы VLAN с одного устройства на другое. Вернемся к нашей схеме из 3-х свитчей. VTP может работать в 3-х режимах: server, client и transparent. VTP v3 имеет ещё один режим под названием Off, однако в тематике экзамена Cisco рассматривается только VTP первой и второй версий.

Режим Server используется для создания новых VLAN, удаления или изменения сетей через командную строку свитча. В режиме клиента никаких операций над VLAN совершить нельзя, в этом режиме происходит только обновление базы данных VLAN с сервера. Режим transparent действует так, как будто бы протокол VTP отключен, то есть свитч не выдает собственных сообщений VTP, но передает обновления от других свитчей – если обновление поступило на один из портов свитча, он пропускает его через себя и отправляет дальше по сети через другой порт. В прозрачном режиме свитч просто служит передатчиком чужих сообщений, не обновляя собственную базу данных VLAN.
На этом слайде вы видите команды настроек протокола VTP, вводимые в режиме глобальной конфигурации. Первой командой можно изменить используемую версию протокола. Вторая команда выбирает режим работы VTP.

Вы видите версию протокола VTP – вторая, максимальное число поддерживаемых VLAN — 255, количество существующих VLAN – 5 и режим работы VLAN – сервер. Всё это параметры по умолчанию. Мы уже обсуждали VTP на уроке «День 30», так что если вы что-то забыли, можете вернуться и пересмотреть это видео ещё раз.

Для того, чтобы увидеть базу данных VLAN, я ввожу команду show vlan brief. Здесь показаны VLAN1 и VLAN1002-1005. К первой сети по умолчанию подключены все свободные интерфейсы свитча – 23 порта Fast Ethernet и 2 порта Gigabit Ethernet, остальные 4 VLAN не поддерживаются. Базы данных VLAN двух других свитчей выглядят точно так же, за исключением того, что у SW1 свободными для VLAN остались не 23, а 22 порта Fast Ethernet, так как f0/1 и f0/2 заняты под транки. Еще раз напомню то, о чем говорилось на уроке «День 30» — протокол VTP поддерживает только обновление баз данных VLAN.

Если я настрою несколько портов на работу с сетями VLAN с командами switchport access и switchport mode access VLAN10, VLAN20 или VLAN30, конфигурация этих портов не будет реплицирована с помощью VTP, потому что VTP обновляет только базу данных VLAN.
Так, если один из портов SW1 будет настроен на работу с VLAN20, но этой сети не будет в базе данных VLAN, то порт будет отключен. В свою очередь, обновление баз данных происходит только при использовании протокола VTP.

C помощью команды show vtp status я вижу, что все 3 свитча сейчас находятся в режиме server. Я переведу средний свитч SW1 в прозрачный режим командой vtp mode transparent, а третий свитч SW2 – в режим клиента командой vtp mode client.

Теперь я попробую поменять заданное доменное имя, для чего зайду в настройки SW0 и наберу команду vtp domain NetworKing. Как видим, на этот раз обновления не произошло – имя домена VTP на третьем свитче осталось прежним. Дело в том, что такое обновление доменного имени происходит всего 1 раз, когда меняется домен по умолчанию. Если после этого доменное имя VTP меняется ещё раз, на остальных свитчах его потребуется поменять вручную.

Сейчас я создам в консоли CLI первого свитча новую сеть VLAN100 и назову её именем IMRAN. Она появилась в базе данных VLAN первого свитча, но не появилась в базе данных третьего свитча, потому что это разные домены. Запомните, что обновление базы данных VLAN происходит только в том случае, если оба свитча имеют одинаковый домен, либо, как я показал ранее, новое доменное имя устанавливается вместо имени по умолчанию.

Я захожу в настройки 3 свитча и последовательно ввожу команды vtp mode и vtp domain NetworKing. Обратите внимание, что ввод имени чувствителен к регистру, поэтому написание имени домена должно полностью совпадать для обоих свитчей. Сейчас я снова перевожу SW2 в режим клиента с помощью команды vtp mode client. Давайте глянем, что произойдёт. Как видите, теперь, при совпадении имени домена, база данных SW2 обновилась и в ней появилась новая сеть VLAN100 IMRAN, причем эти изменения никак не отразились на среднем свитче, потому что он находится в режиме transparent.

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

Следующее, что мы рассмотрим – это VTP pruning, или «обрезка» неиспользуемых VLAN. Если у вас в сети имеется 100 устройств, использующих протокол VTP, то обновление базы данных VLAN одного устройства автоматически будет реплицировано на остальных 99 устройствах. Однако не все эти устройства имеют упомянутые в обновлении сети VLAN, поэтому информация о них может быть не нужна.

\

Раcсылка обновлений базы данных VLAN устройствам, использующим VTP, означает, что все порты всех устройств получат информацию о добавленных, удаленных и измененных VLAN, к которым они могут не иметь никакого отношения. При этом сеть забивается лишним трафиком. Чтобы этого не происходило, используется концепция «обрезки» VTP. Для того, чтобы включить на свитче режим «обрезки» неактуальных VLAN, используется команда vtp pruning. После этого свитчи будут автоматически сообщать друг другу о том, какие VLAN они фактически используют, тем самым предупреждая соседей, что им не нужно присылать обновления сетей, которые к ним не подсоединены.

Например, если SW2 не имеет никаких портов VLAN10, то ему не нужно, чтобы SW1 присылал ему трафик для этой сети. В то же время свитч SW1 нуждается в трафике VLAN10, потому что один из его портов подсоединен к этой сети, просто ему не нужно отсылать этот трафик свитчу SW2.
Поэтому, если SW2 использует режим vtp pruning, он сообщает SW1: «пожалуйста, не присылайте мне трафик для VLAN10, потому что эта сеть ко мне не подсоединена и не один из моих портов не настроен на работу с этой сетью». Вот что дает использование команды vtp pruning.

Существует ещё один способ фильтрации трафика для конкретного интерфейса. Он позволяет настроить порт на транк с конкретной сетью VLAN. Недостатком такого способа является необходимость ручной настройки каждого порта транка, которому потребуется указать, какие VLAN разрешены, а какие запрещены. Для этого используется последовательность 3-х команд. Первая указывает интерфейс, которого касаются эти ограничения, вторая превращает этот интерфейс в транк-порт, а третья — switchport trunk allowed vlan — показывает, какая VLAN разрешена на данном порту: все, ни одной, добавляемая VLAN или удаляемая VLAN.

В зависимости от конкретной ситуации вы выбираете, что использовать: VTP pruning или Trunk allowed. Некоторые организации предпочитают не пользоваться VTP по соображениям безопасности, поэтому выбирают ручную настройку транкинга. Так как команда vtp pruning не работает в Packet Tracer, я покажу её в эмуляторе GNS3.

Если вы зайдете в настройки SW2 и введете команду vtp pruning, система тут же сообщит, что данный режим включен: Pruning switched on, то есть «обрезка» VLAN включается всего одной командой.

Если набрать команду show vtp status, мы увидим, что режим vtp pruning разрешен.

Если вы настраиваете этот режим на свитче-сервере, то заходите в его настройки и вводите команду vtp pruning. Это значит, что подключенные к серверу устройства станут автоматически использовать vtp pruning, чтобы минимизировать трафик транкинга для неактуальных VLAN.

Если вы не хотите использовать этот режим, то должны войти в конкретный интерфейс, например, e0/0, и затем набрать команду switchport trunk allowed vlan. Система выдаст вам подсказки возможных параметров этой команды:

— WORD — номер VLAN, которая будет разрешена на данном интерфейсе в режиме транка;
— add — VLAN, которую нужно добавить в список базы данных VLAN;
— all — разрешить все VLAN;
— except — разрешить все VLAN, кроме указанных;
— none – запретить все VLAN;
— remove – удалить VLAN из списка базы данных VLAN.

Например, если у нас разрешен транк для VLAN10 и мы хотим разрешить его для сети VLAN20, то нужно ввести команду switchport trunk allowed vlan add 20.

Я хочу показать вам ещё кое-что, поэтому использую команду show interface trunk. Обратите внимание, что по умолчанию для транка были разрешены все VLAN 1-1005, а теперь к ним добавилась еще и VLAN10.

Если я использую команду switchport trunk allowed vlan add 20 и снова попрошу показать статус транкинга, мы увидим, что теперь для транка разрешены две сети – VLAN10 и VLAN20.

При этом никакой другой трафик, кроме предназначенного для указанных сетей, не сможет проходить через этот транк. Разрешив трафик только для VLAN 10 и VLAN 20, мы запретили трафик для всех других VLAN. Вот как можно вручную настроить параметры транкинга для конкретной VLAN на конкретном интерфейсе свитча.

Обратите внимание, что до конца дня 17 ноября 2017 года у нас на сайте действует 90% скидка на стоимость скачивания лабораторной работы по данной теме.

Благодарю за внимание и до встречи на следующем видеоуроке!

Источник

Основы компьютерных сетей. Тема №6. Понятие VLAN, Trunk и протоколы VTP и DTP

P.S. Возможно, со временем список дополнится.

Мы пока не будем затрагивать маршрутизаторы и разные подсети. Допустим все узлы находятся в одной подсети.

Сразу приведу список IP-адресов:

Кто хочет увидеть это в виде анимации, открывайте спойлер (там показан ping от PC1 до PC5).

Красиво да? Мы в прошлых статьях уже не раз говорили о работе протокола ARP, но это было еще в прошлом году, поэтому вкратце объясню. Так как PC1 не знает MAC-адрес (или адрес канального уровня) PC2, то он отправляет в разведку ARP, чтобы тот ему сообщил. Он приходит на коммутатор, откуда ретранслируется на все активные порты, то есть к PC2 и на центральный коммутатор. Из центрального коммутатора вылетит на соседние коммутаторы и так далее, пока не дойдет до всех. Вот такой не маленький трафик вызвало одно ARP-сообщение. Его получили все участники сети. Большой и не нужный трафик — это первая проблема. Вторая проблема — это безопасность. Думаю, заметили, что сообщение дошло даже до бухгалтерии, компьютеры которой вообще не участвовали в этом. Любой злоумышленник, подключившись к любому из коммутаторов, будет иметь доступ ко всей сети. В принципе сети раньше так и работали. Компьютеры находились в одной канальной среде и разделялись только при помощи маршрутизаторов. Но время шло и нужно было решать эту проблему на канальном уровне. Cisco, как пионер, придумала свой протокол, который тегировал кадры и определял принадлежность к определенной канальной среде. Назывался он ISL (Inter-Switch Link). Идея эта понравилась всем и IEEE решили разработать аналогичный открытый стандарт. Стандарт получил название 802.1q. Получил он огромное распространение и Cisco решила тоже перейти на него.
И вот как раз технология VLAN основывается на работе протокола 802.1q. Давайте уже начнем говорить про нее.

В 3-ей части я показал, как выглядит ethernet-кадр. Посмотрите на него и освежите в памяти. Вот так выглядит не тегированный кадр.

Теперь взглянем на тегированный.

Как видим, отличие в том, что появляется некий Тег. Это то, что нам и интересно. Копнем глубже. Состоит он из 4-х частей.

1) TPID (англ. Tag Protocol ID) или Идентификатор тегированного протокола — состоит из 2-х байт и для VLAN всегда равен 0x8100.
2) PCP (англ. Priority Code Point) или значение приоритета — состоит из 3-х бит. Используется для приоритезации трафика. Крутые и бородатые сисадмины знают, как правильно им управлять и оперирует им, когда в сети гуляет разный трафик (голос, видео, данные и т.д.)
3) CFI (англ. Canonical Format Indicator) или индикатор каноничного формата — простое поле, состоящее из одного бита. Если стоит 0, то это стандартный формат MAC-адреса.
4) VID (англ. VLAN ID) или идентификатор VLAN — состоит из 12 бит и показывает, в каком VLAN находится кадр.

Хочу заострить внимание на том, что тегирование кадров осуществляется между сетевыми устройствами (коммутаторы, маршрутизаторы и т.д.), а между конечным узлом (компьютер, ноутбук) и сетевым устройством кадры не тегируются. Поэтому порт сетевого устройства может находиться в 2-х состояниях: access или trunk.

Набираю команду show vlan.

Выстраиваются несколько таблиц. Нам по сути важна только самая первая. Теперь покажу как ее читать.

1 столбец — это номер VLAN. Здесь изначально присутствует номер 1 — это стандартный VLAN, который изначально есть на каждом коммутаторе. Он выполняет еще одну функцию, о которой чуть ниже напишу. Также присутствуют зарезервированные с 1002-1005. Это для других канальных сред, которые вряд ли сейчас используются. Удалить их тоже нельзя.

При удалении Cisco выводит сообщение, что этот VLAN удалить нельзя. Поэтому живем и эти 4 VLANа не трогаем.

2 столбец — это имя VLAN. При создании VLAN, вы можете на свое усмотрение придумывать им осмысленные имена, чтобы потом их идентифицировать. Тут уже есть default, fddi-default, token-ring-default, fddinet-default, trnet-default.

3 столбец — статус. Здесь показывается в каком состоянии находится VLAN. На данный момент VLAN 1 или default в состоянии active, а 4 следующих act/unsup (хоть и активные, но не поддерживаются).

4 столбец — порты. Здесь показано к каким VLAN-ам принадлежат порты. Сейчас, когда мы еще ничего не трогали, они находятся в default.

Приступаем к настройке коммутаторов. Правилом хорошего тона будет дать коммутаторам осмысленные имена. Чем и займемся. Привожу команду.

Остальные настраиваются аналогично, поэтому покажу обновленную схему топологии.

Начнем настройку с коммутатора SW1. Для начала создадим VLAN на коммутаторе.

VLAN создан. Теперь переходим к портам. Интерфейс FastEthernet0/1 смотрит на PC1, а FastEthernet0/2 на PC2. Как говорилось ранее, кадры между ними должны передаваться не тегированными, поэтому переведем их в состояние Access.

Так как оба порта закрепляются под одинаковым VLAN-ом, то их еще можно было настроить группой.

Настроили access порты. Теперь настроим trunk между SW1 и CentrSW.

Сразу видим, что порт перенастроился. В принципе для работы этого достаточно. Но с точки зрения безопасности разрешать для передачи нужно только те VLAN, которые действительно нужны. Приступим.

Без этой команды передаваться будут все имеющиеся VLAN. Посмотрим, как изменилась таблица командой show vlan.

Появился 2-ой VLAN с именем Dir-ya и видим принадлежащие ему порты fa0/1 и fa0/2.

Чтобы вывести только верхнюю таблицу, можно воспользоваться командой show vlan brief.

Можно еще укоротить вывод, если указать определенный ID VLANа.

Вся информациях о VLAN хранится в flash памяти в файле vlan.dat.

Как вы заметили, ни в одной из команд, нет информации о trunk. Ее можно посмотреть другой командой show interfaces trunk.

Здесь есть информация и о trunk портах, и о том какие VLAN они передают. Еще тут есть столбец Native vlan. Это как раз тот трафик, который не должен тегироваться. Если на коммутатор приходит не тегированный кадр, то он автоматически причисляется к Native Vlan (по умолчанию и в нашем случае это VLAN 1). Native VLAN можно, а многие говорят, что нужно менять в целях безопасности. Для этого в режиме настройки транкового порта нужно применить команду — switchport trunk native vlan X, где X — номер присваиваемого VLAN. В этой топологии мы менять не будем, но знать, как это делать полезно.

Осталось настроить остальные устройства.

CentrSW:
Центральный коммутатор является связующим звеном, а значит он должен знать обо всех VLAN-ах. Поэтому сначала создаем их, а потом переводим все интерфейсы в транковый режим.

Не забываем сохранять конфиг. Команда copy running-config startup-config.

Обратите внимание на то, что мы подняли и настроили VLAN, но адресацию узлов оставили такой же. То есть, фактически все узлы в одной подсети, но разделены VLAN-ами. Так делать нельзя. Каждому VLAN надо выделять отдельную подсеть. Я это сделал исключительно в учебных целях. Если бы каждый отдел сидел в своей подсети, то они бы априори были ограничены, так как коммутатор не умеет маршрутизировать трафик из одной подсети в другую (плюс это уже ограничение на сетевом уровне). А нам нужно ограничить отделы на канальном уровне.
Снова отправляю ping с PC1 к PC3.

Идет в ход ARP, который нам и нужен сейчас. Откроем его.

Пока что ничего нового. ARP инкапсулирован в ethernet.

Кадр прилетает на коммутатор и тегируется. Теперь там не обычный ethernet, а 802.1q. Добавились поля, о которых я писал ранее. Это TPID, который равен 8100 и показывающий, что это 802.1q. И TCI, которое объединяет 3 поля PCP, CFI и VID. Число, которое в этом поле — это номер VLAN. Двигаемся дальше.

После тега он отправляет кадр на PC2 (т.к. он в том же VLAN) и на центральный коммутатор по транковому порту.

Так как жестко не было прописано какие типы VLAN пропускать по каким портам, то он отправит на оба коммутатора. И вот здесь коммутаторы, увидев номер VLAN, понимают, что устройств с таким VLAN-ом у них нет и смело его отбрасывают.

PC1 ожидает ответ, который так и не приходит. Можно под спойлером посмотреть в виде анимации.

Теперь следующая ситуация. В состав дирекции нанимают еще одного человека, но в кабинете дирекции нет места и на время просят разместить человека в отделе бухгалтерии. Решаем эту проблему.

Подключили компьютер к порту FastEthernet 0/3 коммутатора и присвою IP-адрес 192.168.1.8/24.
Теперь настрою коммутатор SW2. Так как компьютер должен находиться во 2-ом VLAN, о котором коммутатор не знает, то создам его на коммутаторе.

Дальше настраиваем порт FastEthernet 0/3, который смотрит на PC7.

И последнее — настроить транковый порт.

Чтобы кадры ходили красиво, подкорректирую центральный коммутатор CentrSW.

Время проверки. Отправляю ping с PC1 на PC7.

И вот он приходит на SW2. Открываем и видим, что он еще тегированный. Но следующим узлом стоит компьютер и тег надо снимать. Нажимаем на «Outbound PDU Details», чтобы посмотреть в каком виде кадр вылетит из коммутатора.

И действительно. Коммутатор отправит кадр в «чистом» виде, то есть без тегов.

Доходит ARP до PC7. Открываем его и убеждаемся, что кадр не тегированный PC7 узнал себя и отправляет ответ.

Открываем кадр на коммутаторе и видим, что на отправку он уйдет тегированным. Дальше кадр будет путешествовать тем же путем, что и пришел.

ARP доходит до PC1, о чем свидетельствует галочка на конверте. Теперь ему известен MAC-адрес и он пускает в ход ICMP.

Открываем пакет на коммутаторе и наблюдаем такую же картину. На канальном уровне кадр тегируется коммутатором. Так будет с каждым сообщением.

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

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

Раз подсети определены, то сразу адресуем узлы.

Осталось настроить маршрутизатор, и я открываю его CLI. По традиции дам осмысленное имя.

Далее переходим к настройке интерфейсов.

Теперь внимание! Мы включили интерфейс, но не повесили на него IP-адрес. Дело в том, что от физического интерфейса (fastethernet 0/0) нужен только линк или канал. Роль шлюзов будут выполнять виртуальные интерфейсы или сабинтерфейсы (англ. subinterface). На данный момент 3 типа VLAN. Значит и сабинтерфейсов будет 3. Приступаем к настройке.

Маршрутизатор настроен. Переходим к центральному коммутатору и настроим на нем транковый порт, чтобы он пропускал тегированные кадры на маршрутизатор.

Конфигурация закончена и переходим к практике. Отправляю ping с PC1 на PC6 (то есть на 192.168.3.3).

PC1 понятия не имеет, кто такой PC6 или 192.168.3.3, но знает, что они находятся в разных подсетях (как он это понимает описано в предыдущей статье). Поэтому он отправит сообщение через основной шлюз, адрес которого указан в его настройках. И хоть PC1 знает IP-адрес основного шлюза, для полного счастья не хватает MAC-адреса. И он пускает в ход ARP.

Обратите внимание. Как только кадр прибывает на CentrSW, коммутатор не рассылает его кому попало. Он рассылает только на те порты, где разрешен пропуск 2-го VLAN. То есть на маршрутизатор и на SW2 (там есть пользователь, сидящий во 2-ом VLAN).

Маршрутизатор узнает себя и отправляет ответ (показан стрелочкой). И обратите внимание на нижний кадр. Когда SW2 получил ARP от центрального коммутатора, он аналогично не стал рассылать его на все компьютеры, а отправил только PC7, который сидит во 2-ом VLAN. Но PC7 его отбрасывает, так как он не для него. Смотрим дальше.

ARP дошел до PC1. Теперь ему все известно и можно отправлять ICMP. Еще раз обращу внимание на то, что в качестве MAC-адреса назначения (канальный уровень), будет адрес маршрутизатора, а в качестве IP-адреса назначения (сетевой уровень), адрес PC6.

Доходит ICMP до маршрутизатора. Он смотрит в свою таблицу и понимает, что не знает никого под адресом 192.168.3.3. Отбрасывает прибывший ICMP и пускает разведать ARP.

PC6 узнает себя и отправляет ответ.

Доходит до маршрутизатора ответ и он добавляет запись в своей таблице. Посмотреть таблицу ARP можно командой show arp.

Двигаемся дальше. PC1 недоволен, что ему никто не отвечает и отправляет следующее ICMP-сообщение.

Первый пакет затерялся (в результате работы ARP), а второй дошел без проблем.
Кому интересно увидеть в анимации, добро пожаловать под спойлер.

Итак. Мы добились того, что если узлы находятся в одной подсети и в одном VLAN, то ходить они будут напрямую через коммутаторы. В случае, когда нужно передать сообщение в другую подсеть и VLAN, то передавать будут через роутер Gateway, который осуществляет «межвлановую» маршрутизацию. Данная топология получила название «router on a stick» или «роутер на палочке». Как вы поняли она очень удобна. Мы создали 3 виртуальных интерфейса и по одному проводу гоняли разные тегированные кадры. Без использования сабинтерфейсов и VLAN-ов, пришлось бы для каждой подсети задействовать отдельный физический интерфейс, что совсем не выгодно.

Кстати очень хорошо этот вопрос разобран в этом видео (видео идет около 3-х часов, поэтому ссылка с привязкой именно к тому моменту времени). Если после прочтения и просмотра видео захочется добить все собственными руками, прикладываю ссылку на скачивание.

Разобрались с VLAN-ами и переходим к одному из протоколов, работающего с ним.
DTP (англ. Dynamic Trunking Protocol) или на русском динамический транковый протокол — проприетарный протокол компании Cisco, служащий для реализации trunk режима между коммутаторами. Хотя в зависимости от состояния, они могут согласоваться и в режим access.

В DTP есть 4 режима: Dynamic auto, Dynamic desirable, Trunk, Access. Рассмотрим как они согласуются.

То есть левая колонка это 1-ое устройство, а верхняя строка 2-ое устройство. По-умолчанию коммутаторы находятся в режиме «dynamic auto». Если посмотреть таблицу сопоставления, то два коммутатора в режиме «dynamic auto» согласуются в режим «access». Давайте это и проверим. Создаю я новую лабораторную работу и добавлю 2 коммутатора.

Соединять их пока не буду. Мне надо убедиться, что оба коммутатора в режиме «dynamic auto». Проверять буду командой show interfaces switchport.

Результат этой команды очень большой, поэтому я его обрезал и выделил интересующие пункты. Начнем с Administrative Mode. Эта строка показывает, в каком из 4-режимов работает данный порт на коммутаторе. Убеждаемся, что на обоих коммутаторах порты в режиме «Dynamic auto». А строка Operational Mode показывает, в каком режиме работы они согласовали работу. Мы пока их не соединяли, поэтому они в состоянии «down».

Сразу дам вам хороший совет. При тестировании какого либо протокола, пользуйтесь фильтрами. Отключайте показ работы всех ненужных вам протоколов.

Перевожу CPT в режим simulation и отфильтрую все протоколы, кроме DTP.

Думаю здесь все понятно. Соединяю коммутаторы кабелем и, при поднятии линков, один из коммутаторов генерирует DTP-сообщение.

Открываю и вижу, что это DTP инкапсулированный в Ethernet-кадр. Отправляет он его на мультикастовый адрес «0100.0ccc.cccc», который относится к протоколам DTP, VTP, CDP.
И обращу внимание на 2 поля в заголовке DTP.

1) DTP Type — сюда отправляющий вставляет предложение. То есть в какой режим он хочет согласоваться. В нашем случае он предлагает согласовать «access».
2) Neighbor MAC-address — в это поле он записывает MAC-адрес своего порта.

Отправляет он и ждет реакции от соседа.

Доходит до SW1 сообщение и он генерирует ответный. Где также согласует режим «access», вставляет свой MAC-адрес и отправляет в путь до SW2.

Успешно доходит DTP. По идее они должны были согласоваться в режиме «access». Проверю.

Как и предполагалось, согласовались они в режим «access».
Кто то говорит, что технология удобная и пользуется ею. Но я крайне не рекомендую использовать этот протокол в своей сети. Рекомендую это не только я, и сейчас объясню почему. Смысл в том, что этот протокол открывает большую дыру в безопасности. Я открою лабораторку, в которой разбиралась работа «Router on a stick» и добавлю туда еще один коммутатор.

Теперь зайду в настройки нового коммутатора и жестко пропишу на порту работу в режиме trunk.

Соединяю их и смотрю, как они согласовались.

Все верно. Режимы «dynamic auto» и «trunk» согласуются в режим trunk. Теперь ждем, когда кто- то начнет проявлять активность. Допустим PC1 решил кому то отправить сообщение. Формирует ARP и выпускает в сеть.

Пропустим его путь до того момента, когда он попадет на SW2.

И вот самое интересное.

Но здесь настройки порта пустые. Ввожу show interfaces switchport и проматываю до fa0/4.

А вот здесь видим, что согласован trunk. Не всегда show running-config дает исчерпывающую информацию. Поэтому запоминайте и другие команды.

Думаю понятно почему нельзя доверять этому протоколу. Он вроде облегчает жизнь, но в то же время может создать огромную проблему. Поэтому полагайтесь на ручной метод. При настройке сразу же обозначьте себе какие порты будут работать в режиме trunk, а какие в access. И самое главное — всегда отключайте согласование. Чтобы коммутаторы не пытались ни с кем согласоваться. Делается это командой «switchport nonegotiate».

Переходим к следующему протоколу.

VTP (англ. VLAN Trunking Protocol) — проприетарный протокол компании Cisco, служащий для обмена информацией о VLAN-ах.

Представьте ситуацию, что у вас 40 коммутаторов и 70 VLAN-ов. По хорошему нужно вручную на каждом коммутаторе их создать и прописать на каких trunk-ых портах разрешать передачу. Дело это муторное и долгое. Поэтому эту задачу может взвалить на себя VTP. Вы создаете VLAN на одном коммутаторе, а все остальные синхронизируются с его базой. Взгляните на следующую топологию.

Здесь присутствуют 4 коммутатора. Один из них является VTP-сервером, а 3 остальных клиентами. Те VLAN, которые будут созданы на сервере, автоматически синхронизируются на клиентах. Объясню как работает VTP и что он умеет.

Итак. VTP может создавать, изменять и удалять VLAN. Каждое такое действие влечет к тому, что увеличивается номер ревизии (каждое действие увеличивает номер на +1). После он рассылает объявления, где указан номер ревизии. Клиенты, получившие это объявление, сравнивают свой номер ревизии с пришедшим. И если пришедший номер выше, они синхронизируют свою базу с ней. В противном случае объявление игнорируется.

Но это еще не все. У VTP есть роли. По-умолчанию все коммутаторы работают в роли сервера. Расскажу про них.

Начитались теории и переходим к практике. Проверим, что центральный коммутатор в режиме Server. Вводим команду show vtp status.

Видим, что VTP Operating Mode: Server. Также можно заметить, что версия VTP 2-ая. К сожалению, в CPT 3-ья версия не поддерживается. Версия ревизии нулевая.
Теперь настроим нижние коммутаторы.

Видим сообщение, что устройство перешло в клиентский режим. Остальные настраиваются точно также.

Чтобы устройства смогли обмениваться объявлениями, они должны находиться в одном домене. Причем тут есть особенность. Если устройство (в режиме Server или Client) не состоит ни в одном домене, то при первом полученном объявлении, перейдет в объявленный домен. Если же клиент состоит в каком то домене, то принимать объявления от других доменов не будет. Откроем SW1 и убедимся, что он не состоит ни в одном домене.

Убеждаемся, что тут пусто.

Теперь переходим центральному коммутатору и переведем его в домен.

Видим сообщение, что он перевелся в домен cisadmin.ru.
Проверим статус.

И действительно. Имя домена изменилось. Обратите внимание, что номер ревизии пока что нулевой. Он изменится, как только мы создадим на нем VLAN. Но перед созданием надо перевести симулятор в режим simulation, чтобы посмотреть как он сгенерирует объявления. Создаем 20-ый VLAN и видим следующую картинку.

Как только создан VLAN и увеличился номер ревизии, сервер генерирует объявления. У него их два. Сначала откроем тот, что левее. Это объявление называется «Summary Advertisement» или на русском «сводное объявление». Это объявление генерируется коммутатором раз в 5 минут, где он рассказывает о имени домена и текущей ревизии. Смотрим как выглядит.

В Ethernet-кадре обратите внимание на Destination MAC-адрес. Он такой же, как и выше, когда генерировался DTP. То есть, в нашем случае на него отреагируют только те, у кого запущен VTP. Теперь посмотрим на следующее поле.

Здесь как раз вся информация. Пройдусь по самым важным полям.

Думаю здесь понятно. Отдельный заголовок для каждого типа VLAN. Список настолько длинный, что не поместился в экран. Но они точно такие, за исключением названий. Заморачивать голову, что означает каждый код не буду. Да и в CPT они тут больше условность.
Смотрим, что происходит дальше.

Получают клиенты объявления. Видят, что номер ревизии выше, чем у них и синхронизируют базу. И отправляют сообщение серверу о том, что база VLAN-ов изменилась.

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

И тут в сеть мы добавляем новый коммутатор. У него нет новых VLAN-ов, кроме стандартных и он не состоит ни в одном VTP-домене, но подкручен номер ревизии.

И перед тем как его воткнуть в сеть, переводим порт в режим trunk.

Теперь переключаю CPT в «Simulation Mode» и отфильтровываю все, кроме VTP. Подключаюсь и смотрю, что происходит.

Через какое то время до NewSW доходит VTP сообщение, откуда он узнает, что в сети есть VTP-домен «cisadmin.ru». Так как он не состоял до этого в другом домене, он автоматически в него переходит. Проверим.

Теперь он в том же домене, но с номером ревизии выше. Он формирует VTP-сообщение, где рассказывает об этом.

Первым под раздачу попадет SW1.

Заметьте, что на SW1 приходят сразу 2 VTP-сообщения (от NewSW и от CentrSW). В сообщении от NewSW он видит, что номер ревизии выше, чем его и синхронизирует свою базу. А вот сообщение от CentrSW для него уже устарело, и он отбрасывает его. Проверим, что изменилось на SW1.

Обновился номер ревизии и, что самое интересное, база VLAN. Теперь она пустая. Смотрим дальше.

Обратите внимание. До сервера доходит VTP-сообщение, где номер ревизии выше, чем у него. Он понимает, что сеть изменилась и надо под нее подстроиться. Проверим конфигурацию.

Конфигурация центрального сервера изменилась и теперь он будет вещать именно ее.
А теперь представьте, что у нас не один VLAN, а сотни. Вот таким простым способом можно положить сеть. Конечно домен может быть запаролен и злоумышленнику будет тяжелее нанести вред. А представьте ситуацию, что у вас сломался коммутатор и срочно надо его заменить. Вы или ваш коллега бежите на склад за старым коммутатором и забываете проверить номер ревизии. Он оказывается выше чем у остальных. Что произойдет дальше, вы уже видели. Поэтому я рекомендую не использовать этот протокол. Особенно в больших корпоративных сетях. Если используете VTP 3-ей версии, то смело переводите коммутаторы в режим «Off». Если же используется 2-ая версия, то переводите в режим «Transparent».

Кому интересно посмотреть это в виде анимации, открывайте спойлер.

Источник