vlan trunking что это

Vlan trunking что это

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

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 из третьей запрещается.

Источник

Безопасность. Начало 09. VLAN и Trunking

В данном материале будет использоваться данная схема:

Пример настройки VLAN:

Trunking

Предположим, что PC1 отсылает broadcast frame. SW1 принимает broadcast frame и должен его отправить через транк: для этого SW1 добавляет к фрейму tag, в котором содержится информация что данный фрейм из VLAN 10. SW2 увидит этот таг, уберёт его из фрейма, и отправит данный broadcast frame на все порты в VLAN10.

Пример настройки trunk:

Native VLAN on a Trunk

Что будет, если в порт транка прибежит untagged frame? Коммутатор такой фрейм примет и поместит его в Native VLAN.
По умолчанию Native VLAN есть VLAN 1.

Inter-VLAN Routing

Inter-VLAN Routing осуществляется устройством 3-го уровня, т.е. роутером.
Подключение к VLAN-ам можно производить на физ уровне, т.е. к роутеру будут подключено столько проводов, сколько у нас есть ВЛАН-ов.

Также можно и на роутере поднять транк, что позволит осуществлять маршрутизацию при подключенном одном проводе:
SW1

Spanning-Tree

Алгоритм работы STP:

При выборах для STP используется следующий механизм приоритетов:
1. Lowest root bridge ID
2. Lowest root path cost to root bridge
3. Lowest sender bridge ID
4. Lowest sender port ID

Таблица стоимостей

Проверка STP

show spanning-tree vlan 10

В примере приведён нерутовый коммутатор.
Как видно, один из портов рутовый. остальные в состоянии Designated.
На всех указанных портах активирован STP, поэтому для каждого сегмента проводятся выборы.

По умолчанию STP включён, и для каждого VLAN существует отдельная STP instance.

STP и новые порты

Если к порту подключить линк, STP не даст этому линку тут же подняться: прежде чем полноценно заработать, порт должен пройти несколько states:
■ Disabled—Ports that are administratively shut down by the network administrator,
or by the system because of a fault condition, are in the Disabled state. This state is
special and is not part of the normal STP progression for a port.

■ Blocking—After a port initializes, it begins in the Blocking state so that no bridging
loops can form. Instead, a port is allowed to receive only BPDUs
so that the switch can hear from other neighboring switches.
Ports that are put into standby mode to remove a bridging loop enter the Blocking state.

■ Listening (15 sec)— The port is allowed to receive and send BPDUs so that it can actively participate in the
Spanning Tree topology process. Here, the port finally is allowed to become a root
port or designated port because the switch can advertise the port by sending BPDUs
to other switches. If the port loses its root port or designated port status, it returns to
the Blocking state.

■ Learning (15 sec)—After a period of time called the Forward Delay in the Listening state,
the port is allowed to move into the Learning state. The port still sends and receives
BPDUs as before. In addition, the switch now can learn new MAC addresses to add to
its address table. This gives the port an extra period of silent participation and allows
the switch to assemble at least some address information. The port cannot yet send
any data frames, however.

■ Forwarding—After another Forward Delay period of time in the Learning state, the
port is allowed to move into the Forwarding state. The port now can send and receive
data frames, collect MAC addresses in its address table, and send and receive BPDUs.
The port is now a fully functioning switch port within the spanning-tree topology.

Безусловно, подобное поведение порта вызывает задержку на 30-50сек, и это вызывает неудобства при подключении клиентов-не-коммутаторов:
— Использование Portfast
— Включение более быстрого Rapid Spanning Tree (802.1w) вместо традиционного STP (802.1D).

Layer 2 Security

Настройка портов «в лоб»

Злоумышленник может воспользоваться DTP, и перевести порт в транк: тогда он получит доступ ко всем ВЛАН-ам и получит возможность провести атаку “VLAN hopping”.

В данном примере мы указали для портов режим работы «в лоб» + также принудительно отключили DTP.

BPDU Guard

BPDU Guard очень часто используется вместе с Portfast и позволяет дизаблить порт в случае получения на него BPDU.

В данном конфиге при подключении к порту другого коммутатора порт залочится. Если вернуть всё обратно, порт восстановится через 300секунд.

Проверка:
show interface fa0/2 status
show errdisable recovery

Root Guard

Наш коммутатор может быть подключён к другим коммутаторам, неуправляемым нами. Root Guard позволяет исключить перевыборы рута от данного порта.

Port security

Port security позволяет контролировать, сколько MAC-адресов могут жить на данном порту.
Это защищает от атаки CAM table overflow attack: вредоносное приложение на стороне клиента рассылает тысячи фреймов от разных MAC. У коммутатора переполняется CAM table, в результате чего коммутатор начинает форвардить все фреймы на все порты и злоумышленник получает возможность сниферить трафик.

Проверка:
show port-security

CDP и LLDP

Проверка:
show cdp
show lldp

DHCP Snooping

Т.о. мы доверяем лишь портам fa0/1 и fa0/5, остальным портам доверия нет. Это означает что DHCP сервер сможет раздавать адреса только с портов, которым есть доверие.

Dynamic ARP Inspection

Для начала давайте рассмотрим, что такое ARP spoofing attack

Когда Host A хочет что-то передать на Host B, он делает broadcast ARP request. ARP request запрашивает MAC адрес, ассоциированный с нужным IP адресом.
Когда коммутатор и Host B получают данный броадкаст, они просматривают свой ARP cache и отвечают на запрос.

DAI перехватывает, логирует и запрещает ARP packets с неправильными IP-to-MAC address bindings.
Валидность биндингов DAI определяет через таблицу DHCP snooping binding database.
Здесь также есть понятие Trusted и Untrusted Interfaces: в первом случае ARP пакет пропускается всегда, во втором случае пропускается только после проверки на валидность.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

VTP (VLAN Trunking Protocol)

Протокол формирования магистральных каналов виртуальной локальной сети (VTP) представляет собой удобное дополнение к средствам управления виртуальными локальными сетями. Он позволяет автоматически присваивать определения виртуальных локальных сетей сразу нескольким коммутаторам в сети. Чтобы полностью оценить удобство этого дополнения, представьте себя на месте сетевого администратора в крупной неоднородной сети. Предположим, что в этой сети имеется 500 коммутаторов и определено свыше 100 виртуальных локальных сетей. Для того чтобы виртуальные локальные сети обменивались данными по магистральным каналам в соответствии с их определениями, номера виртуальных локальных сетей должны быть одинаковыми во всех коммутаторах, участвующих в их формировании на предприятии. К тому же необходимо следить за тем, для чего предназначены те или иные виртуальные локальные сети, и учитывать, что «эта сеть — для исполнительного руководства, а эта — для простых служащих» и т.д. Даже сами эти (довольно типичные) характеристики позволяют понять, какие сложности связаны с настройкой конфигурации виртуальных локальных сетей в подобной крупной сети. Достаточно представить себе, что произойдет если пользовательский порт будет помещен не в ту виртуальную локальную сеть, в какую требуется, поскольку кто-то по ошибке ввел параметр VLAN 151 вместо VLAN 115?

Для оказания помощи в решении этой проблемы программное обеспечение протокола VTP даст возможность автоматически ввести в действие определения виртуальных локальных сетей от имени сетевого администратора, что позволяет задать на одном коммутаторе имена и номера виртуальных локальных сетей, а затем распространить эти данные по всему предприятию. Следует отметить, что программное обеспечение VTP не распространяет по всем коммутаторам информацию о принадлежности устройств к виртуальной локальной сети (поскольку в большинстве сетей это могло бы привести к разрушительным последствиям); на другие коммутаторы передаются только определения (имя, номер и другая основная информация).

Для достижения такой цели программное обеспечение VTP вначале (после ввода протокола VTP в действие) анонсирует информацию о конфигурации виртуальной локальной сети через все магистральные порты. Таким образом соседние коммутаторы получают данные о наличии в топологии виртуальных локальных сетей и об их конфигурации. Затем эти коммутаторы распространяют информацию о виртуальных локальных сетях по подключенным к ним коммутаторам и т.д. Подробное изучение этого процесса требует освоения некоторых новых тем: режимы VTP, домены VTР, версии VTP и исключение фрагментов древовидной структуры VTP.

Содержание

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

Программное обеспечение VTP может функцинонировать в коммутаторе в одном из трех режимов: клиентском, серверном и прозрачном. Эти режимы описаны ниже.

Домены управления VTP

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

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

Но если в конфигурацию будет введен канал между коммутаторами Countach и Diablo, как показано на рис. 2, связь между всеми коммутаторами домена VTP будет обеспечена.

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

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

Версии VTP

Протокол VTP имеет две версии, которые могут использоваться в сети: версия 1 н версия 2. Эти версии, безусловно, полностью несовместимы и при вводе обеих этих версий в действие одновременно в одной н той же сети наступит хаос. (Возможно, что последствия не будут столь драматичными, но все равно следует соблюдать осторожность.) В версию 2 протокола VTP просто включены некоторые дополнительные средства, отсутствующие в версии 1, но только два из них действительно имеют важное значение для большинства сетей: поддержка виртуальных локальных спей Token Ring и многодоыениого прозрачного режима.

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

В версии 1 протокола VTP предусмотрено, что коммутаторы, функционирующие в прозрачном режиме, распространяют информацию VTP, только если домен управления в анонсе VTP совпадает с их собственным. Иными словами, если коммутатор,действующий в прозрачном режиме, относится к домену Corp VTP и получить анонс для домена Org, то он не передает этот анонс другим коммутаторам. С другой стороны,в версии 2 протокола VTP все анонсы VTP распространяются независимо от домена.

Как правило, проще настроить все коммутаторы па использование версии 2, но при условии, что она поддерживается всеми коммутаторами.

Исключение поддеревьев VTP

Наконец отметим, что в протокол VTP включено весьма важное усовершенствование, известное под названием исключение поддеревьев VTP, которое позволяет программному обеспечению VTP автоматически определять, какие виртуальные локальные сети представлены на данном конкретном коммутаторе, и удалять (или исключать) ненужный широковещательный трафик, направленный из таких коммутаторов. Например, как показано на рис.3, на коммутаторе Tama представлены только виртуальные локальные сети VLAN 1 и VLAN 4, но по умолчанию на него также поступает весь широковещательный трафик для сетей VLAN 2 и 3. Если бы исключение поддеревьев VTP было разрешено, то широковещательный трафик для виртуальных локальных сетей VLAN 2 и 3 был бы заблокирован, иными словами, не направлен по магистральному соединению с коммутатором Tama, поскольку эти виртуальные локальные сети на нем не представлены.

Очевидно, что это усовершенствование приводит к существенному сокращению широковещательного трафика в таких сетях, где на каждом коммутаторе представлены не все виртуальные локальные сети (пример подобной сети приведен на рис.4),поскольку оно позволяет более четко обозначить пределы распространения широковещательного трафика.

Особенности использования протокола STP в виртуальной локальной сети

При организации работы виртуальных локальных сетей необходимо решить еще одну задачу — обеспечить их применение в сочетании со средствами протокола SТР. В сетевой среде, основанной на использовании виртуальных локальных сетей, как и в любой другой коммутируемой сети, могут присутствовать избыточные каналы и возникать циклы, поэтому должен применяться протокол STP, Но при этом обнаруживаются определенные сложности, связанные с тем, что при использовании виртуальных локальных сетей программное обеспечение STP фактически вынуждено учитывать наличие множества разных широковещательных доменов (соответствующих каждой виртуальной локальной сети Для настройки функциональных средств STP в сетевой среде, основанной на использование виртуальных локальных сетей, предусмотрены три метода: CST (Common Spanning Tree — протокол формирования общего распределенного связующего дерева),PVST и PVST+ (Per VLAN Spanning Tree Plus — расширенный протокол формирования отдельного распределенного связуюшего дерева для каждой виртуальной локальной сети).

Протокол CST применяется в сочетании с протоколом 802.1q организации IEEE и предусматривает просто создание единого распределенного связующего дерева для всей коммутационной инфраструктуры независимо от количества подддерживаемых виртуальных локальных сетей. Для всей физической сети формируется единая топология STP; при этом все виртуальные локальные сети вынуждены использовать эту топологию. Преимуществом этого метода является то, что в процессе определения топологии SТР коммутаторы затрачивают минимальные ресурсы. Существует единственный корневой мост STP, поэтому перестройка структуры STP требует лишь небольших затрат ресурсов. Недостатком этого метода является то, что для всех виртуальных локальных сетей должна использоваться одна и та же топология (как правило характеризующаяся гигантскими размерами). Б результате повышается вероятность того, что выбранные маршруты будут не оптимальны, как показано на рис.5. Кроме того, в крупной физической сети может также потребоваться значительное время на формирование окончательного варианта топологии.

Протокол PVST применяется в сочетании с протоколом ISL компании Cisco. В нем предусмотрено использование отдельной топологии STP для каждой виртуальной локальной сети. Преимуществом этого метода является то, что он обеспечивает выбор оптимальных маршрутов (как показано на рис. 6) и позволяет свести к минимуму продолжительность окончательного формирования, распределенного связующего дерева. Но он имеет также определенные недостатки, связанные с тем, что приходится использовать множество корневых мостов STP, формировать несколько топологий STP и передавать отдельные фреймы BPDU для каждой топологии, что приводит к повышению затрат ресурсов коммутатора и пропускной способности.

Протокол PVST+ представляет собой усовершенствование протокола PVST и обеспечивает функциональную совместимость между сетью CST и PVST. По сути, программное обеспечение PVST+ отображает распределенные связующие деревья PVST на распределенное связующее дерево CST, создавал своего рола «шлюз обмена данными по магистральному каналу». Но применение этого метода может приводить к созданию некоторых «странных» топологий STP, поэтому обычно гораздо проще и эффективнее придерживаться протокола PVST, если применяется ISL (или CST, при использовании протокола 802.1q).

Источник

Vlan trunking что это

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

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

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

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

У нас 3 отдела: дирекция, бухгалтерия, отдел кадров. У каждого отдела свой коммутатор и соединены они через центральный верхний. И вот PC1 отправляет ping на компьютер PC2.

Работа сети в одном широковещательном домене

Красиво да? Мы в прошлых статьях уже не раз говорили о работе протокола 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.

Сейчас я покажу это на практике. Открываю ту же лабу. Картинку повторять не буду, а сразу открою коммутатор и посмотрю, что у него с VLAN. Набираю команду 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. Посмотрим, как изменилась таблица командой 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.

Пока что весь путь аналогичен предыдущему. Но вот с этого момента (с картинки ниже) центральный коммутатор примет другое решение. Он получает кадр и видит, что тот протегирован 2-ым VLAN-ом. Значит отправлять его надо только туда, где это разрешено, то есть на порт fa0/2.

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

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

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

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

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

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

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

Вот в принципе самое популярное применение VLAN-ов. Независимо от физического расположения, можно логически объединять узлы в группы, там самым изолируя их от других. Очень удобно, когда сотрудники физически работают в разных местах, но должны быть объединены. И конечно с точки зрения безопасности 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-сообщение.

На этот раз 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 есть роли. По-умолчанию все коммутаторы работают в роли сервера. Расскажу про них.

Это все, что касается VTP версии 2. В VTP 3-ей версии добавилась еще одна роль — VTP Off. Он не передает никакие объявления. В остальном работа аналогична режиму Transparent.

Начитались теории и переходим к практике. Проверим, что центральный коммутатор в режиме 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. Теперь посмотрим на следующее поле.

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

Теперь посмотрим на следующее генерируемое сообщение (то, что справа). Оно называется «Subset Advertisement» или «подробное объявление». Это такая подробная информация о каждом передаваемом VLAN.

Думаю здесь понятно. Отдельный заголовок для каждого типа 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».

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

Для желающих поработать с этой лабораторкой, прикладываю ссылку.

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

Источник