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

Привет.

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

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

Изучение данного протокола то добавляется фирмой Cisco в треки CCNA Routing and Switching и CCNP Routing and Switching, то убирается – поэтому у нас он дополнительно изучается как на курсах Cisco ICND2 3.0 и Cisco SWITCH 2.0, так и в составе трека Advanced CCNA и в части углублённых вопросов – в отдельном занятии трека Advanced CCNP.

Поэтому имеет смысл разово изучить VTP, чтобы разобраться что и как.

Оглавление

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

Зачем нужен VTP

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

Протокол VTP помогает упрощать операции с VLAN’ами в организации – добавление, удаление, изменение параметров, а также оптимизирует сетевой трафик, благодаря наличию функции vtp pruning. VTP современной версии – третьей – ещё и помогает жить протоколу MST (который 802.1s), плюс исправляет древние проблемы с безопасностью у VTP первой и второй версий.

Логическая модель работы VTP

Cisco VTP объединяет физически напрямую подключённые друг к другу коммутаторы (т.е. не через роутер или другой свич, не поддерживающий VTP) в именованные области, называемые доменами VTP. В одной организации таких доменов может быть несколько, главное – чтобы они непосредственно не контачили друг с другом, т.к. процедура междоменного взаимодействия не проработана. Предполагается, что VTP используется в “классической” кампусной сети, где много коммутаторов и есть задача “чтобы можно было подключить абонента в нужный VLAN на любом коммутаторе”. У современных сетей такая конструкция встречается всё реже и реже, она вытесняется L3-связями у distribution-коммутаторов и другими моделями взаимодействия, которые обеспечивают большую гибкость и скорость передачи данных по внутренней сети благодаря уходу от L2-доменов со Spanning Tree на топологии с L3-связями и ECMP.

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

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

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

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

А далее – уже данные самого протокола VTP, относящиеся к одному из типов VTP-сообщений. Это могут быть:

• Код 0x01 – Анонс-оглавление (Summary advertisement);
• Код 0x02 – Данные для анонса (Subset advertisement);
• Код 0x03 – Запрос на повторную информацию (Advertisement request);
• Код 0x04 – Данные для pruning (VTP join message);

Замечу, что про 802.1Q можно почитать в статье про 802.1Q и 802.1ad или посмотреть на нашем YouTube вебинар из серии Advanced CCNA про типы транкинга.

Так вот, далее.

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

Роли устройств в домене VTP

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

• VTP Server – те, на которых можно создавать новые VLAN’ы, удалять старые, изменять существующие – в общем те, где можно полноценно изменять всю базу VLAN’ов. Устройства с Read+Write доступом к vlan database, говоря иначе.
• VTP Client – те коммутаторы, которые будут получать по сети анонсы от других VTP-устройств и не будут иметь возможности локально исправлять информацию (устройства с Read-only доступом).
• Те, кто во всём этом участвовать не хочет и хочет иметь свою, локальную базу VLAN’ов и свободно их настраивать – “прозрачные” для VTP коммутаторы. Их роль будет называться VTP Transparent.
• Отдельно и только в VTPv3 – те, кто во всём этом участвовать не хочет и не собирается передавать на другие порты полученные по транкам 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 – в NVRAM.

Обратите внимание на следующие два важных момента. Первый – то, что название домена является 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.