> >

Протокол VTPv3

Привет. Как и обещал, пишу про VTPv3. Введение Предполагаю, что Вы уже читали статью про VTP 1й и 2й версий. Поэтому в данной статье я буду ссылаться и сравнивать с предыдущей, исходя из этого предположения. Оглавление Краткое описание нововведений в протоколе VTPv3 Включаем VTPv3 Что стало с VTP pruning в VTPv3 Проблема с VTP-паролем – […]

//cdn.atraining.ru/i/at300x300.jpg300300

Привет.

Как и обещал, пишу про VTPv3.

Введение

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

Оглавление

  • Краткое описание нововведений в протоколе VTPv3
  • Включаем VTPv3
  • Что стало с VTP pruning в VTPv3
  • Проблема с VTP-паролем – решение в VTPv3
  • Проблема с добавлением коммутатора в VTP-домен
  • Изменения в операционной работе VTPv3
  • Поддержка Private VLAN

Краткое описание нововведений в протоколе VTPv3

Их будет достаточно, чтобы сказать, что третья версия значительно отличается от второй:

  • Поддержка Private VLAN (как помните, раньше если используются PVLAN, то надо было уходить в VTP transparent).
  • Поддержка полного диапазона (4K) VLAN’ов. Ранее, в силу наследства CatOS, Вы ограничивались 2-1001м. Остальные иметь на устройстве было можно, но вот VTP с ними не работал.
  • Появились настройки VTP на уровне отдельного порта коммутатора, плюс появилась возможность реального выключения VTP, а не просто перевода его в transparent.
  • Теперь пароль VTP хоть как-то защищён.
  • Решена проблема с добавлением нового коммутатора – теперь “случайно” угробить VTP-домен нельзя.
  • Обмен данными между VTP-устройствами переработан и стал более эффективным (данные передаются компактнее и быстрее).
  • VTP поддерживает обмен не одной, а несколькими базами данных. На данный момент реализованы БД VLAN’ов и протокола MST (который 802.1s). Схема расширяема, и VTP теперь можно “научить” синхронизировать между несколькими устройствами нужные типы данных.

Включаем VTPv3

Включается достаточно просто – надо ввести

host(config)#vtp version 3

До этого шага необходимо установить имя VTP-домена, иначе переключиться на 3ю версию не получится. Это делается так же, как в предыдущих версиях:

host(config)#vtp domain VTP3TEST

Протокол совместим с предыдущей версий – то есть, если устройство с VTPv3 найдёт на одном из портов “старого” соседа, то оно сможет нормально общаться с ним. Безусловно, ограничивая часть функционала (например, VTP pruning на VLAN’ах с номерами выше 1001 будет невозможен).

Примечание: Совместим с VTPv2. Совместимость с VTPv1 не поддерживается.

После переключения на 3ю версию мы сможем выбрать режим работы данного устройства. Теперь наш выбор не из 3х, а из 4х вариантов – добавился VTP off. Этот режим будет практически идентичен VTP transparent за исключением того, что устройство вместо ретрансляции VTP-кадров, полученых на транковых портах, будет их просто игнорировать. Плюс этот режим позволяет выключить VTP на отдельном порту, что тоже крайне удобно (например, для повышения уровня access-свичей можно просто выключить VTP на access-портах и отсечь целый класс атак на этот протокол).

Давайте посмотрим, как будут в VTPv3 работать три привычных нам режима.

Режим VTP transparent в VTP3

Как и ранее, коммутатор в режиме transparent будет хранить локальную БД vlan’ов и ни с кем ей не обмениваться.

Примечание: Номер версии БД будет всегда равен нулю.

Все VTP-сообщения на всех портах будут игнорироваться (т.е. не обрабатываться) и будут передаваться далее на все транковые интерфейсы. Заметьте тонкость – проверка на валидность домена (т.е. что имя-пароль должны совпадать) производиться не будет. То есть в случае VTPv3 transparent можно не отдавать пароль VTP-домена на каждый transparent-коммутатор просто для того, чтобы он корректно пропускал сквозь себя трафик VTP-домена. Это важно. Вторая тонкость – трафик VTPv3 будет идти с учётом состояния spanning tree в 1м вилане. То есть если RSTP/STP заблокировал трафик 1го vlan’а в транке, через который потенциально мог бы уйти VTPv3-трафик, то трафик не отправляется.

Режим VTP client в VTP3

Клиент так же, как и раньше, хранит полученные по VTP данные в оперативной памяти и не сохраняет их копию локально. Тонкость – под VTP-данными теперь понимается не только БД виланов, но и другие БД (та же база MST); соответственно, при включении устройство класса VTP client некоторое время находится в сложной ситуации, когда всё, что может синхронизироваться поверх VTP, ещё не пришло. В частности, нет БД vlan’ов и MST предполагает, что есть только default instance, и все vlan’ы находятся в ней. Время этого процесса стараются сократить тем, что VTPv3-клиент при старте сервиса VTP теперь отправляет специальный VTP-кадр вида “хочу конфигурироваться, интим не предлагать”.

Режим VTP server в VTP3

С сервером всё стало гораздо интереснее.

Первое – теперь режим VTP сервер разделяется на два варианта – primary server и secondary server. Вы и ранее могли сделать в VTP-домене несколько серверов, но правила их взаимодействия друг меж другом особой продуманностью не блистали. Теперь Вы можете выделить “основной рабочий” сервер и “один из резервных” серверов. Команда

host(config)#vtp mode server

теперь является устаревшей, но продолжает функционировать и переключать VTP в режим server; но всё же на данный момент надо пользоваться новой командой:

host(config)#vtp mode server vlan

Она явно указывает что стать сервером необходимо для модуля VTP, отвечающего за обмен БД vlan’ов. Вообще, воспринимайте теперь VTP как рамочный транспортный протокол, который умеет синхронизировать различные БД между устройствами канального уровня. Этакий “свичово-кадровый” BGP с местным аналогом address-family.

Выполнив эту команду, Ваше устройство станет “одним из серверов”. Сделать его primary можно командой:

host#vtp primary vlan

Устройство подумает, поищет конфликты (другие устройства VTPv3, которые для подсистемы “БД VLAN’ов” являются primary server), после этого запросит дополнительное подтверждение, и, когда Вы согласитесь, Ваш коммутатор станет primary server для VTPv3 VLAN DB. Понятное дело, primary server для одного из модулей может быть только один в VTPv3-домене (то есть один primary server для БД VLAN и один primary server для БД маппингов MST. это может быть как одно устройство, так и различные).

Примечание: Если Вы не хотите проверку и подтверждение путём нажатия Enter, Вы можете добавить после команды слово force – vtp primary vlan force – и тогда данный коммутатор гарантированно станет primary, распространив эту информацию по всему VTPv3-домену. Предыдущий primary при этом станет обычным, рядовым secondary server.

Схема взаимодействия устройств будет такой:

  • Клиенты и secondary-сервера получают конфигурацию от primary server.
  • Все сервера – и secondary и primary – хранят конфигурацию локально, а не в RAM. В RAM – только клиенты.
  • Изменять данные – т.е. выполнять специфичные для сервера задачи по добавлению/удалению/изменению информации в нужной подсистеме – можно только на primary server.

Теперь про pruning.

Что стало с VTP pruning в VTPv3

Механизм остался тем же, и суть его та же – экономия полосы пропускания транков между коммутаторами путём фильтрации трафика неиспользуемых vlan’ов. Работать будет так же, как и раньше – для VLAN’ов с 2 по 1001й. Влиять будет только на unicast и неизвестный multicast. Это нужно, чтобы не “прунить” трафик, например, STP (который представляет из себя “хорошо известный” мультикастовый трафик на канальном уровне). Включается/выключается prгning так же:

host(config)#vtp pruning

Теперь упомянем давнишнюю проблему VTP – возможность читать пароль в открытом виде.

Проблема с VTP-паролем – решение в VTPv3

Раньше в VTP была проблема – пароль хранился в открытом виде. Его можно было прочитать как командой

host#show vtp password

так и просто – скопировав наружу файл vlan.dat и открыв его.

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

host(config)#vtp password пароль hidden

Команда show vtp password продолжит работать, но выводить будет хэш. Можно, заменив слово hidden на слово secret, вводить пароль сразу в виде хэша (не забудьте, что MD5-хэш – это 128 бит. это, в свою очередь, 16 байт. а они записываются как 16 групп по 2 шестнадцатеричных разряда).

Следующий момент про безопасность – известные потенциальные приключения при добавлении в сеть нового коммутатора.

Проблема с добавлением коммутатора в VTP-домен

Раньше при добавлении уже настроенного коммутатора Вы могли стереть всю VTP-базу в VTP-домене. Просто потому что новый коммутатор мог обладать более старшим номером ревизии (версией БД, по сути). Притом его роль – клиент или сервер – на момент добавления не играла роли, VTPv2-клиент с новой ревизией точно так же мог затереть все остальные VTP-базы на всех устройствах. Теперь всё проще – при получении по VTPv3 новой БД VLAN’ов проверяется не только то, чтобы версия этой БД была старше локальной, но и то, что её отправитель – primary server. Поэтому случайно затереть БД нельзя. Что же, если взять коммутатор, “накрутить” ему номер VTP’шной БД VLAN’ов до значительного числа (бОльшего, чем в VTP-домене), настроить его как primary server и подключить к сети? И от этого подстраховались – подключаемый к домену сервер автоматически станет secondary server.

Что же изменилось в VTPv3 в плане функционала?

Изменения в операционной работе VTPv3

VTPv3 так же, как и его предок, VTPv2, будет отправлять от primary server уведомление с новой версией БД VLAN’ов каждый раз при успешной записи в эту БД. К успешным записям будут относиться операции создания/удаления vlan’ов, а также переименования, изменения параметров (например, смена MTU), и некоторые другие. Плюс, каждые 300 секунд будет рассылаться Summary Advertisement, который так же как в VTPv2 будет дополнительно синхронизировать содержимое VTP на всех устройствах в VTP-домене.

К изменениям в упомянутых операциях можно отнести то, что теперь будет рассылаться информация о всём диапазоне VLAN’ов. Что это значит? Ранее для VTP диапазон допустимых в 802.1Q vlan’ов для обмена между устройствами и vtp prune’инга выглядел так:

  • VLAN 1 – рассылаем, не пруним
  • VLAN 2-1001 – рассылаем, пруним
  • VLAN 1002-1005 – не рассылаем, не пруним
  • VLAN 1006-1023 – не рассылаем, не пруним
  • VLAN 1024-4094 – не рассылаем, не пруним

Теперь он полностью участвует в VTP-обмене.

Поддержка Private VLAN

Я не буду детализовывать саму технологию, предполагая, что с PVLAN Вы знакомы. Суть в том, что ранее, если надо было использовать PVLAN, то на коммутаторе надо было делать VTP transparent, т.к. VTPv2 не умел обмениваться информацией про PVLAN-атрибуты у VLAN’ов. Теперь ситуация поменялась; коммутаторы с VTPv3 могут как обмениваться свойствами всех 4х видов PVLAN – Primary, SecIsolated, SecCommunity, Sec2WayCommunity, так и реализовывать локальные PVLAN – то, что называется PVLAN Edge. То есть теперь Вы сможете, допустим, сделать community-порты в PVLAN, который будет покрывать несколько устройств.

Заключение

Про взаимодействие VTPv3 и MST я напишу в статье про MST, потому что VTP’шного в этой теме минимум, а MST’шного – почти всё.
Если про что-то забыл или объяснил недостаточно подробно – пишите в комментарии, добавлю.

Автор

@
info@atraining.ruAdvanced Training
//cdn.atraining.ru/i/at300x300.jpg300300

Полезные статьи

Возможно, вам будет также интересно почитать другие статьи про VTP на нашей Knowledge Base: