> >

Протокол VTP v1/2 – реализация и настройка

Привет. Введение Протокол VTP является одним из самых известных вендорских протоколов, занимающихся L2-задачами, знание которых нужно по многим причинам – по крайней мере, чтобы понимать, что реально приобретается с поддержкой этого протокола, а что – нет. Это необходимо для ухода от крайностей как вида “раз цисковский протокол, то без него / его поддержки жить нельзя […]

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

Привет.

Введение

Протокол VTP является одним из самых известных вендорских протоколов, занимающихся L2-задачами, знание которых нужно по многим причинам – по крайней мере, чтобы понимать, что реально приобретается с поддержкой этого протокола, а что – нет. Это необходимо для ухода от крайностей как вида “раз цисковский протокол, то без него / его поддержки жить нельзя в принципе, надо сразу удавиться”, так и “раз его не смогло разработать опенсорсное коммунити, то это не нужный протокол”.

История протокола VTP достаточно продолжительна – первый раз он появляется в CatOS 2.1 (это Cisco Catalyst 2900 и 5000), после чего слегка модернизируется до второй версии и живёт очень долго. Третья версия, в которой реально много полезных изменений, вышла несколько лет назад, но до сих пор не поддерживается на многих устройствах начального уровня. Однако это не обозначает, что её не нужно изучать.

Оглавление

  • Зачем нужен VTP
  • Как технически реализован VTP
  • Как работает протокол VTP
  • VTP pruning – что это?
  • Базовая настройка протокола VTP
  • Расширенная настройка протокола VTP
  • Типовые ошибки настройки VTP
  • Ситуация с добавлением нового коммутатора в существующую VTP-инфраструктуру
  • Протокол VTPv3

Зачем нужен VTP

Ключевое назначение протокола VTP – это обмен коммутаторов специфической базой данных с информацией о VLAN’ах. В данном процессе могут участвовать и маршрутизаторы, в случае, если у них установлена специальная карта, являющаяся мини-коммутатором (т.н. switchboard – например, достопочтимая NM-16ESW, благодаря которой и dynamips иногда за коммутатор сойдёт). VTP помогает упрощать операции с VLAN’ами в организации – добавление, удаление, изменение параметров, а также оптимизирует трафик, благодаря наличию функции vtp pruning. VTP новой версии – 3й – ещё и помогает жить протоколу MST (который 802.1s), плюс исправляет древние проблемы VTP версий 1 и 2.

Протокол VTP объединяет физически подключённые друг к другу коммутаторы (т.е. не через роутер или даже через другой свич, но не поддерживающий VTP) в именованные области, называемые доменами VTP. В одной организации таких доменов может быть несколько, главное – чтобы они непосредственно не контачили друг с другом.

Как технически реализован протокол VTP

Технологически протокол VTP реализован как SNAP-вложение в кадры ISL или 802.1Q. Работать может на 802.3 (Ethernet) и 802.5 (Token Ring).

Примечание: Может работать и поверх 802.10 и LANE, но, надеюсь, эта некрофилия Вас не коснётся.

Нужно отметить, что служебные данные VTP вкладываются не сразу в кадр 802.3, а после транкового заголовка. Выглядит это так:

  • Обычный заголовок 802.3 (Destination MAC, Source MAC, тип вложения – например, в случае 802.1Q это будет 0x8100)
  • Субзаголовок LLC-уровня (это “верхний” подуровень канального уровня – кто проходил CCNA, тот знает, что у уровней модели OSI бывают подуровни, и в случае VTP это как раз хорошо заметно), содержащий код 0xAA 0xAA, обзначающий, что далее идёт SNAP-вложение.
  • Субзаголовок SNAP – Subnetwork Access Protocol, показывающий, что будет разделение на субпротоколы канального уровня, а не сразу обработка уйдёт на сетевой уровень – в нашем случае несёт уже конкретную информацию, что вложен будет протокол, идентифицируемый как Cisco’вский протокол VTP.

А далее – уже данные самого протокола VTP, относящиеся к одному из типов сообщений – VTP summary advertisement, VTP subset advertisement, VTP advertisement request, VTP join message.

Примечание: Про 802.1Q можно почитать в статье про 802.1Q и 802.1ad

Весь трафик VTP идёт на специальный мультикастовый MAC-адрес вида 01-00-0C-CC-CC-CC. Так как на этот же адрес, допустим, идёт и трафик протокола CDP, тоже цисковского, то используется схема разделения по SNAP-типу – для CDP он выбран 0x2000, для VTP – 0x2003. Этакое мультиплексирование канального уровня.

Примечание: После таких вендорских MAC-адресов становится ещё более понятно, почему Cisco пользуется в России популярностью. Если бы D-link догадался выпустить серию устройств с кодом АМР или ЕКХ…

Как логически реализован протокол VTP

На логическом уровне протокол достаточно прост. Все коммутаторы делятся на три вида или роли:

  • VTP-сервера (те, на которых можно создавать новые VLAN’ы, удалять старые, изменять существующие – в общем те, где можно полноценно изменять всю базу VLAN’ов). Устройства с Read+Write доступом, говоря иначе.
  • VTP-клиенты – те коммутаторы, которые будут получать по сети анонсы от VTP-серверов и не иметь возможности локально исправлять информацию (устройства с Read only доступом).
  • Те, кто во всём этом участвовать не хочет, и хочет иметь свою, локальную базу VLAN’ов и свободно их настраивать – “прозрачные” для VTP коммутаторы, называемые VTP Transparent.
  • Отдельно – те, кто во всём этом участвовать не хочет, и не собирается передавать на другие порты полученные по транкам VTP-кадры – VTP Off.

Понятное дело, что в сети желательно иметь хотя бы 1 VTP-сервер, а если коммутатор один, то имеет смысл включить его сразу в режим VTP transparent. Этот режим удобен тем, что коммутатор, работающий в нём, в случае, если принимает кадр протокола VTP на любом порту, сразу передаёт этот кадр на все остальные транковые порты – т.е. просто ретранслирует этот кадр, не обрабатывая его. Этим (переключением в vtp transparent mode) заранее ликвидируется потенциальная возможность, что какой-то другой коммутатор повлияет на конфигурацию данного.

Примечание: Как понятно, это всё – только на портах в режиме транка.

Хранение информации о VLAN’ах и их настройках

В разных ролях VTP это реализовано различными способами:

  • Коммутатор с ролью VTP Server будет хранить настройки в файле vlan.dat на указанном устройстве хранения (один из flash’ей устройства)
  • Коммутатор с ролью VTP Transparent или VTP Off будет хранить настройки в конфигурации (это config.text, или, говоря проще, NVRAM)
  • Коммутатор с ролью VTP Client будет хранить настройки в оперативной памяти (их не будет видно в конфигурации или на flash)

Домены VTP

Домены VTP, как уже указано выше – это подмножества непосредственно подключенных друг к другу коммутаторов.

Для идентификации принадлежности устройства к домену VTP используется сравнение названия домена и хэша пароля (безусловно, не друг с другом, а между устройствами – т.е. оба этих параметра должны совпадать, чтобы VTP-устройства могли корректно общаться). Название домена VTP – это текстовая строка длиной до 32 байт (в случае, если название короче, оно добивается нулями – zero-padding), пароль – тоже текстовая строка, в чистом виде в сети не передающаяся, хранящаяся в случае работы устройства в роли VTP Server в файле vlan.dat, а в случае работы в режиме VTP Transparent – в config.text

Обратите внимание на следующие два важных момента. Первый – то, что название домена является case-sensitive, потому что строки сравниваются побайтово. Поэтому коммутаторы из домена Domain и из домена DOMAIN работать друг с другом не будут. Второй – работа с паролем. В кадрах передаётся хэш пароля, а не хэш кадра. Поэтому этот пароль нужен только для идентификации принадлежности к домену и никак не подтверждает целостность сообщения VTP. Его можно просто разово заснифить и добавлять в VTP-сообщения для придания им “легитимности”.

Примечание: Также для успешной связи двух коммутаторов необходимо, чтобы у них были одинаковые версии протокола VTP. Что, в общем-то, логично.

Примечание: Даже если Вы не используете протокол VTP как таковой по его основной задаче – синхронизации базы VLAN’ов, то Вам желательно, чтобы коммутаторы обладали одинаковыми настройками VTP в части имени домена. Причина – протокол динамического согласования транков – DTP – отправляет в ходе процедуры анонса имя VTP-домена, и в случае, если имя не совпадает, согласование не происходит. Т.е. два коммутатора, “смотрящие” друг на друга портами в режиме dynamic auto, в случае разных VTP-доменов просто не смогут согласовать транк. Решений будет несколько – отключить автосогласование (switchport mode trunk), отключить DTP (switchport nonegotiate), или всё ж выставить одинаковые имена доменов.

Что же передают друг другу коммутаторы, обладающие ролями VTP Client и VTP Server?

Как работает протокол VTP

Протокол VTP в основном занимается полезной вещью – он передаёт базу данных VLAN между устройствами. Делает он это в следующих случаях:

  • Если Вы изменили базу данных VLAN’ов на устройстве с ролью VTP Server (т.е. провели успешную запись – не важно, какую – добавили VLAN, удалили VLAN, переименовали VLAN), то изменение будет передано немедленно после проведения записи.
  • Если после последней успешной записи (см. выше) прошло 300 секунд.

Примечание: В случае, если у Вас коммутатор, записи в VLAN database идут сразу же – т.е. создали Вы VLAN, допустим – сразу разошлось уведомление. Если маршрутизатор со свичкартой – то Вы вначале вносите изменения “пачкой”, а после выполняете команду APPLY, и только когда она успешно применится, будет разослан анонс.

VTP версий 1 и 2 передаёт только данные по VLAN’ам с номерами от 1 до 1005. Увы, наследие страшных времён, CatOS, десятибитовые номера vlan’ов, чугунные игрушки, соображения совместимости и прочие причины. Зато в VTPv3 это успешно решено и обмен данными про VLAN’ы охватывает весь диапазон – от 1 до 4094.

Заметьте, что хоть стартовым инициатором рассылки VTP может быть только устройство с ролью VTP Server, но пересылать обновление могут любые коммутаторы – т.е. устройству с ролью VTP Client совсем необязательно быть непосредственно подключённому к VTP Server. Клиент, получив от сервера рассылку с новой версией базы данных VLAN’ов, передаст её на все другие транковые порты, за которыми опять же могут быть другие VTP Client’ы и VTP Transparent, и так – до упора. Ограничения стандарта 802.1D на максимальный диаметр “поля” коммутаторов здесь не действуют.

Итак, обновление базы данных – штука достаточно несложная. Вы – VTP Server, на Вас обновлена БД vlan’ов, Вы разослали во все транковые порты анонс, все коммутаторы, поддерживающие VTP, его прочитали, и, если они VTP Client или VTP Server, то применили к себе и отправили дальше, а если VTP Transparent – то не применили к себе, но отправили дальше. Как же определяется, какая база данных актуальнее? При помощи системы версий.

У каждой базы vlan’ов будет своя версия. В случае, если устройством получено обновление, которое старше по номеру, чем имеющаяся БД, то имеющаяся БД заменяется новой. Целиком, без всяких join/merge.

Также весьма полезной функцией VTP будет являться т.н. pruning:

VTP Pruning

Задача этой функции проста – каждый коммутатор будет “считать” фактически используемые VLAN’ы, и в случае, когда по VTP приходит неиспользуемый VLAN, уведомлять соседа, что этот трафик не имеет смысла присылать. Под этот механизм будут подпадать только первые 1000 VLAN’ов, исключая самый первый (т.е. pruning работает только для VLAN’ов с номерами от 2 до 1001). Более того, под pruning будет подпадать только уникастовый и неизвестный мультикастовый трафик, поэтому, к примеру, BPDU протоколов семейства STP фильтроваться не будут.

Т.е. допустим, у нас есть два коммутатора – A и B. Коммутатор A имеет роль VTP Server, а B – VTP Client. Между ними – транковый канал, 802.1Q. На коммутаторе B включен vtp pruning.
Допустим, на коммутаторе A в базу VLAN добавлены VLAN 10 и VLAN 20. Соответственно, коммутатор A уведомит по протоколу VTP своего соседа – B – о новой ревизии базы VLAN’ов. Сосед B добавит эти VLAN’ы в базу и теперь, когда подключенный к коммутатору A клиент, например, передаст броадкаст в VLAN’е 10, этот броадкаст дойдёт и до коммутатора B. Невзирая на то, что у коммутатора B может вообще не быть ни одного порта и интерфейса в VLAN 10, а также не быть других транков (т.е. трафик 10го VLAN’а коммутатору B совсем не нужен). Вот в данном случае механизм pruning сможет сэкономить полосу пропускания канала между коммутаторами A и B просто не отправляя трафик неиспользуемого VLAN’а коммутатору B.

Как же всё это будет настраиваться?

Базовая настройка протокола VTP

Первым делом – нарисуйте топологию сети, в которой собираетесь применять протокол VTP. Посмотрите, какие версии протокола поддерживаются устройствами (обычно везде есть VTPv2). Выберите устройство, которое будет сервером (ему не надо быть каким-то особо быстрым, это не STP, специфической нагрузки на VTP Server нет, ему лишь желательно обладать максимальным uptime). Если не хотите использовать VTP (например, из соображений безопасности) – тогда просто переведите все устройства в режим VTP Transparent (либо off, если поддерживается оборудованием и ОС).

Настройка имени домена VTP

host(config)#vtp domain имя_домена

Стереть имя домена штатно нельзя, только сменить. Т.е. если стартово заменили дефолтное значение, которое NULL, на своё, то всё.

Примечание: Ну, конечно, не “всё” совсем. Перезагрузите устройство, зайдите в rommon, сотрите файл vlan.dat, и всё ОК – настройки VTP у держателя роли VTP Server хранятся там, поэтому он всё сразу “забудет”.

Настройка пароля VTP

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

Пароль можно сбросить на пустой, если ввести команду no vtp password. Запомните, пароль VTP хранится небезопасно (у VTP Server – в файле vlan.dat, у VTP Transparent – в NVRAM), поэтому если пользуетесь VTP, делайте такой пароль, который более нигде не дублируется, т.к. получить пароль VTP – относительно несложно. Всё, от чего защищает этот пароль – это, например, случайное добавление в сеть неправильно настроенного коммутатора и последующие проблемы. Пароль VTP не защищает передаваемую между коммутаторами информацию.

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

host(config)#vtp version версия
На момент написания статьи версии были от 1й до 3й.

Настройка VTP pruning

Включение выполняется командой:

host(config)#vtp pruning

а выключение –

host(config)#no vtp pruning

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

host(config)#vtp mode режим

Где режим – это server, client, transparent или off. Режим off получится поставить только на устройствах, поддерживающих VTPv3; на коммутаторах, которые поддерживают только VTPv1 и VTPv2 отключить протокол нельзя.

Расширенная настройка протокола VTP

Настройка дополнительных полезных опций VTP

Коммутатор, находящийся в режиме vtp server, как уже упоминалось выше, хранит информацию на флэше. Если потенциальных мест хранения несколько, то нужное можно указать в явном виде, командой

host(config)#vtp file имя_файловой_системы

Понятное дело, для vtp client и vtp transparent это не имеет особого смысла.
Также имеется возможность упростить траблшутинг, указав в явном виде интерфейс, с которого будет браться IP-адрес, пишущийся в результатах вывода команды show vtp status. То есть это влияет на выбор того адреса, который будет указываться в у клиентов в строчке вида

Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00

Примечание: Если в выводе команды show vtp status ниже этой строчки есть что-то вида Local updater ID is 0.0.0.0 (no valid interface found), то на устройстве нет рабочих IPv4-интерфейсов, и данная команда не имеет смысла – надо вначале сделать хотя бы один интерфейс, с которого можно будет забрать IP-адрес для идентификации VTP-устройства.

Делаться это будет такой командой:

host(config)#vtp interface интерфейс

Где интерфейс – это, например, loopback 0.

Устранение неисправностей (troubleshooting) протокола VTP

Неисправностей в VTP может быть очень, очень много. Давайте перечислим основные из них. Запомните эти лица, может пригодиться в дальнейшем.

Проверяем каналы между коммутаторами

  • Проверьте физическую доступность интерфейсов
  • Проверьте корректность режима дуплекса и скорости
  • Проверьте, что корректно согласовался транк
  • Проверьте, совпадают ли native vlan’ы

Проверяем настройки VTP

  • Участвующие коммутаторы должны быть непосредствено подключены друг к другу
  • Должен быть хотя бы один VTP Server
  • Версии VTP, а также имя домена и пароль должны быть идентичны у всех устройств

Теперь чуть подробнее об известном артефакте поведения протокола VTP

Проблема добавления нового коммутатора

Как Вам уже известно, новый коммутатор при добавлении делает следующее – он слушает трафик VTP и при получении первого же advertisement берёт из него настройки (имя домена и пароль). Также известно, что дефолтная настройка коммутатора – это режим VTP Server (т.е. когда Вы достаёте коммутатор из коробки, Вы сразу можете на нём создавать VLAN’ы, в случае VTP Client это было бы невозможно).

Соответственно, возможна неприятная ситуация. Состоит она в том, что можно взять коммутатор, заранее его сконфигурировать, внеся больше изменений, чем есть сейчас в инфраструктурном VTP, задать правильные параметры домена и подключить к сети. Тогда коммутатор своей базой затрёт существующую. Почему так произойдёт и как это может быть? Рассмотрим подробнее.

Вы покупаете новый коммутатор и вводите его в эксплуатацию. Отдельно от других, которые работают в VTP. Ну, вот так сложилось – допустим, в филиале организации его ставите, где он не является непосредственно подключенным к другим коммутаторам. ОК, начинаете с ним работать. Работаете интенсивно – добавляете на него vlan’ы, удаляете их, переименовываете. Каждое действие плюсует единицу к revision number. Вдруг через некоторое время возникает ситуация – филиал закрывается. Коммутатор перевозят в основной офис и Вы подключаете его к другим. И тут выясняется следующее. У данного коммутатора ревизия числовО выше, чем у местного VTP Server. Имя домена и пароль совпадают. Как только транк поднимается, новый коммутатор выстреливает advertisement, который начинают слушать все остальные коммутаторы и ретранслировать дальше. Это штатный функционал – Вы не можете ограничить получение VTP-данных только от одного, “правильного” сервера. Соответственно, эта волна накрывает все коммутаторы в режиме Client и тот, который в Server. Это тоже штатное поведение – VTP Server, получив VTP-данные с бОльшим номером ревизии, чем у себя, перезаписывает свою базу. И всё, Вы имеете большие проблемы – вместо Вашей базы VLAN’ов у Вас на всех коммутаторах та, которая была в филиале.

Чтобы избежать этого, можно поступить по-разному. Например, не делать у этого коммутатора имя домена и пароль, как в основной VTP-сети. Но можно и проще – ведь чтобы этого всего не произошло, надо просто сбросить номер ревизии. Для этого достаточно переименовать домен у коммутатора в какое-нибудь временное название и после вернуть назад. Ревизия сбросится. После не забудьте включить режим VTP Client.

Примечание: Как понятно, именно из-за этой ситуации использование VTP в production-сети с высоким уровнем безопасности является нежелательным. Злоумышленник может провести достаточно простую атаку – ему хватит доступа к транковому порту и возможности отправить, допустим, vtp-уведомление о том, что пришла база с версией 10000 и одним vlan’ом, и всё – вся VTP-инфраструктура примет это как нормальное положение вещей и остальные vlan’ы пропадут. Поэтому в безопасных сетях все коммутаторы работают в VTP transparent, где такая ситуация невозможна в принципе.

Протокол VTPv3

Третья версия протокола принесла множество изменений и нововведений. Например:

Поддержка полного диапазона VID в 802.1Q

Протоколы VTP первой и второй версии поддерживали только первую тысячу VLAN’ов. VTPv3 работает со всем диапазоном, от 1 до 4094го.

Поддержка Private VLAN

Если Вы использовали private vlan (т.е. назначали порты как promiscuous / isolated / community и определяли их в отдельные группы), то Вы знаете, что VTP не работал с этим механизмом. Третья версия работает.

Поддержка 802.1s (MST)

Теперь через VTP можно обмениваться данными не только БД vlan’ов, но и базу маппингов MST, что значительно упрощает конфигурирование 802.1s

Настраиваем VTPv3

Первое, что нужно сделать, чтобы включить поддержку VTPv3 – задать имя vtp-домена в явном виде. В предыдущих версиях протокола это было не нужно – коммутатор стартово обладал именем vtp-домена “NULL” и менял его на другое, получив первое VTP-сообщение. Теперь же до включения протокола VTPv3 Вы должны задать не-дефолтное имя VTP домена в явном виде. Команда, впрочем та же – host(config)#vtp domain имя_vtp_домена.

Второе – надо включить поддержку 802.1t, называемого чаще extended system-id. Соответствие данному стандарту будет подразумевать, что в параметре BID во всех BPDU будет не два поля – приоритет и Base MAC, а три – приоритет, VLAN ID и Base MAC. То есть, если без 802.1t на приоритет отдавалось 16 бит, то после его включения формат bridge ID (BID) будет выглядеть так:

  • 4 бита на приоритет
  • 12 бит на VLAN ID
  • 48 бит на Base MAC

Про этот стандарт и его основное применение (в протоколах семейства Spanning Tree), думается, лучше написать отдельно, а для нас будет достаточно то, что он меняет формат BID и что его надо включать, чтобы можно было переключиться в VTPv3. Включается поддержка 802.1t командой host(config)#spanning-tree extend system-id.

После этого уже можно переключаться – host(config)#vtp version 3. Убедиться, что переключение произошло, можно сделав host#show vtp status и увидев в первых строчках такое:

VTP Version capable : 1 to 3
VTP version running : 3

Ну, а подробно разобрать VTPv3 придётся в отдельной статье – иначе эта превратится в мини-книжку.

Вот, кстати, ссылка на неё: Протокол VTPv3.

Автор

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

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

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