VTP (VLAN Trunking Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:06, 1 февраля 2015.

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

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

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

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

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

  • Клиентский режим. В этом режиме коммутатор принимает и распространяет анонсы VTP, которые относятся к его домену управления (эта тема подробно рассматривается в следующем разделе). С учетом этих анонсов коммутатор вносит изменения в свою конфигурацию виртуальной локальной сети. До тех пор пока коммутатор находится в клиентском режиме, в нем не могут быть непосредственно внесены изменения в конфигурацию виртуальной локальной сети. Поэтому изменения в конфигурацию виртуальной локальной сети коммутатора, находящегося в клиентском режиме, могут быть внесены только с помощью протокола VTP.
  • Серверный режим. В этом режиме коммутатор также принимает и распространяет анонсы VTP, которые относятся к его домену управления, но наряду с этим формирует новые анонсы. Этот режим позволяет модифицировать информацию виртуальной локальной сети непосредственно в самом коммутаторе в том числе добавлять и удалять виртуальные локальные сети из домена управления. Модификация конфигурации VTР домена управления вызывает обновление номера версии конфигурации (а также номера версии базы данных VTP). Такое обновление вынуждает все коммутаторы в домене управления обновить свои конфигурации VTP с учетом новой информации. Как правило, в каждом домене управления должны существовать только один-дна сервера VTP; кроме того, необходимо тщательно контролировать соблюдение прав на модификацию конфигурации этих коммутаторов. В противном случае могут возникнуть ошибки, которые распространятся по всему домену управления. (А если номер версии конфигурации является достаточно большим, исправление таких ошибок может стать дорогостоящим и потребовать много времени. Подобные ситуации и способы их исправления рассматриваются в разделе "Устранение нарушений в работе локальных сетей".)
  • Прозрачный режим. В прозрачном режиме информация VТР перенаправляется, но данные о конфигурации виртуальных локальных сетей, содержащиеся в этих анонсах, игнорируются. В противной режиме разрешается непосредственно вносить изменения в конфигурацию виртуальных локальных сетей в коммутаторе, но такие изменения в конфигурации относятся только к этому локальному коммутатору.

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

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

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

Рис. 1. Пример конфигурации, в которой информация VTP не будет распространяться по одному из домеиов (Lamborghini), поскольку он не является непрерывным.

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

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

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

Версии VTP

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

Рис. 2. Пример конфигурации, в которой информация VTP распространяется должным образом

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

Рис. 3. Существующий по умолчанию поток широкове- щатеяьного трафика для виртуальных локальных сетей VLAN 2 и 3 без применения метода исключения поддеревьев

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

Рис. 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).

Рис. 5. Пример неоптималъного маршрута, сформированного при использовании протокола CST
Рис. 6. Пример оптимального маршрута, сформированного при использовании протокола PVST