Привет.
Как и обещал в предыдущей статье, пишу про VTPv3. Предполагаю, что вы её уже прочитали и всё знаете про VTP 1й и 2й версий. Поэтому в данном тексте буду исходить из этого предположения.
Оглавление
- Краткое описание нововведений в протоколе VTPv3
- Включаем VTPv3
- Что стало с VTP pruning в VTPv3
- Проблема с VTP-паролем – решение в VTPv3
- Проблема с добавлением коммутатора в VTP-домен
- Изменения в операционной работе VTPv3
- Поддержка Private VLAN
- VTPv3 и MST 802.1s
Начнём.
Краткое описание нововведений в протоколе VTPv3
Их будет достаточно, чтобы сказать, что третья версия значительно отличается от второй:
- Поддержка Private VLAN (раньше, если на коммутаторе используются PVLAN, то если и использовать VTP, то только режим VTP Transparent).
- Поддержка полного диапазона (всех 4094) VLAN’ов. Ранее, в силу наследства CatOS с 10ти битовыми рудиментами, техническое ограничение предполагало работу с VLAN в диапазоне номеров от 2 до 1001. Первый VLAN всегда есть и поэтому факт его наличия передавать на другие устройства Cisco не надо, VLANы с 1002 по 1005 зарезервированы для некрофункций, связанных с транзитом Token Ring / FDDI, а оставшийся до 1023 VLAN “хвостик” имеет свои специфичные применения. Остальные VLANы (с номерами от 1023) иметь на устройстве при VTPv1-v2 было можно, но вот VTP с ними не работал – а теперь может.
- Появилась настройка VTP на уровне отдельного порта коммутатора.
- Появилась возможность реального выключения VTP, а не просто перевода его в transparent mode.
- Теперь пароль VTP стал хоть как-то более-менее защищён.
- Решена проблема с добавлением нового коммутатора – теперь “случайно” угробить VTP-домен нельзя.
- Появились подвиды роли server – у VTP теперь есть просто server и primary server.
- Обмен данными между VTP-устройствами переработан и стал более эффективным (данные передаются компактнее и, следовательно, быстрее).
- VTPv3 стал модульным и поддерживает обмен не одной, а несколькими базами данных. На данный момент реализованы модули БД VLAN’ов и протокола MST (который 802.1s). Схема расширяема, и VTP теперь можно “научить” синхронизировать между несколькими устройствами нужные типы данных.
Разберёмся последовательно – начнём со включения.
Включаем VTPv3
Первым делом – включаем поддержку 802.1t; впрочем, на современных моделях она включена по умолчанию и её не получится выключить даже вручную. Без включения формата расширенного system-id VTPv3 работать не будет. Команда стандартная:
host(config)#spanning-tree extend system-id
После переключаем на третью версию VTP так же, как переключались на вторую с первой – надо ввести:
host(config)#vtp version 3
До этого шага необходимо установить имя VTP-домена, иначе переключиться на 3ю версию не получится. Это делается так же, как в предыдущих версиях:
host(config)#vtp domain ATRAINING
Протокол совместим с предыдущей версией, второй – то есть, если устройство с VTPv3 найдёт на одном из портов “старого” соседа, то оно сможет нормально общаться с ним. Безусловно, ограничивая часть функционала (например, VTP pruning на VLAN’ах с номерами выше 1001 будет невозможен). Совместимость с VTPv1 не поддерживается.
Фактически общение VTPv3-устройства с VTPv2 будет состоять в том, что VTPv3-устройство будет отправлять на интерфейс, смотрящий на VTPv2-устройство, сразу 2 экземпляра VTP-кадров с данными – в формате VTPv3 и в устаревшем VTPv2. Это будет делаться для работоспособности сценария “Два VTPv3-устройства обмениваются своими данными через промежуточные VTPv2-устройства, которые не понимают нового формата, но понимают, что это VTP-кадры и передают их дальше”. То есть иметь в одной сети и VTPv3 и VTPv2 устройства не очень выгодно с точки зрения трафика – всё будет банально дублироваться в двух вариантах.
После переключения на третью версию мы сможем выбрать режим работы нашего устройства. Теперь выбор будет не из 3х, а из 4х вариантов – добавился VTP Off. Этот режим будет практически идентичен VTP Transparent за исключением того, что устройство вместо ретрансляции VTP-кадров, полученых на транковых портах, будет их просто игнорировать.
Помимо выключения VTP на устройстве целиком можно будет выключить VTP на отдельном порту, что тоже крайне удобно (например, для повышения уровня безопасности access-свичей можно просто выключить VTP на access-портах и отсечь целый класс атак на этот протокол). Для этого переключаться в VTP Off не нужно, нужно лишь перейти на третью версию протокола.
Про VTP Off особо много и не скажешь – поэтому давайте теперь посмотрим, как в VTPv3 будут работать три привычных нам режима.
Режим VTP Transparent в VTP3
Как и ранее, коммутатор в режиме transparent будет хранить локальную БД vlan’ов и ни с кем ей не обмениваться.
Файл vlan.dat в этом сценарии не используется, просто хранится. Если такой коммутатор спросить про номер ревизии БД – то можно узнать, что он будет всегда равен нулю.
Все VTP-кадры на всех транковых портах в этом режиме будут игнорироваться (т.е. не обрабатываться) и будут передаваться далее на все транковые интерфейсы. Заметьте тонкость – проверка на валидность домена (т.е. что имя-пароль должны совпадать) производиться не будет. То есть в случае VTPv3 Transparent можно не отдавать пароль VTP-домена на каждый transparent-коммутатор просто для того, чтобы он корректно пропускал сквозь себя трафик VTP-домена. Это важно. Вторая тонкость – трафик VTPv3 будет идти с учётом состояния spanning tree в 1м вилане. То есть если RSTP/STP/PVST+/PVRST+ заблокировал трафик 1го vlan’а в данном конкретном интерфейсе, через который потенциально мог бы уйти VTPv3-трафик, то трафик не отправляется.
Режим VTP Client в VTP3
Клиент так же, как и раньше, хранит полученные по VTP данные в оперативной памяти и не сохраняет их копию локально. Тонкость – под VTP-данными теперь понимается не только БД виланов, но и другие БД (та же база MST); соответственно, при включении устройство класса VTP Client некоторое время находится в сложной ситуации, когда всё, что может синхронизироваться поверх VTP, ещё не пришло. В частности, нет БД vlan’ов и протокол MST 802.1s логично предполагает, что на данный момент есть только 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 (который представляет из себя “хорошо известный” мультикастовый трафик на канальном уровне). Включается/выключается pruning так же:
host(config)#vtp pruning
Теперь упомянем давнишнюю проблему VTP – возможность читать пароль в открытом виде.
Проблема с VTP-паролем – решение в VTPv3
Раньше в VTP была проблема – пароль хранился в открытом виде. Его можно было прочитать как командой
host#show vtp password
так и просто – скопировав наружу файл vlan.dat и открыв его. Задавался пароль просто:
host(config)#vtp password atrainingpw
Более того, при конфигурировании пароль выводился в явном виде – например, при выполнении вышеуказанной команды выведется что-то вида:
Setting device VLAN database password to atrainingpw.
Это – дополнительная уязвимость; ведь получается, что пароль видит не только тот, кто обладает правами по конфигурированию, но и тот, кто например читает логи. То есть в определённом сценарии аудитор, обладающий только правами “анализ журналов событий” может увидеть среди информации об операциях конфигурирования пароль VTP-домена. Который, в свою очередь, может совпадать с другими паролями или навести на мысль о схеме формирования паролей.
Теперь ситуация поменялась. Вы можете задать пароль так, что он будет храниться уже в виде 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-обмене.
