Протокол VTPv3 - реалізація та налаштування
Cisco VTPv3 - нововведення, робота з Private VLAN та MST 802.1s
Як і обіцяв у попередній статті, пишу про 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, а VLAN "хвостик", що залишився до 1023, має свої специфічні застосування. Решта 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 пристрої не дуже вигідно з точки зору трафіку - все буде банально дублюватися в двох варіантах.
Після перемикання на третю версію ми зможемо вибрати режим роботи пристрою. Тепер вибір буде не з трьох, а з чотирьох варіантів - додався 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
Виконавши цю команду, пристрій стане одним із серверів. Зробити його 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 так само:
Проблема з VTP-паролем – рішення у VTPv3
Раніше у VTP була проблема – пароль зберігався у відкритому вигляді. Його можна було прочитати як командою
host#show vtp password
так і просто – скопіювавши назовні файл vlan.dat та відкривши його. Задавався пароль просто:
host(config)#vtp password atrainingpw
Більше того, при конфігуруванні пароль виводився в явному вигляді - наприклад, при виконанні вищезгаданої команди виведеться щось таке:
Налаштування пристрою 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-обміні.
Підтримка Private VLAN
Я не деталізуватиму саму технологію, припускаючи, що з PVLAN Ви знайомі. Суть у цьому, що, якщо треба було використовувати PVLAN, то комутаторі треба було робити VTP transparent, т.к. VTPv2 не вмів обмінюватися інформацією про PVLAN-атрибути у VLAN'ів. Тепер ситуація змінилася; комутатори з VTPv3 можуть як обмінюватися властивостями всіх 4-х видів PVLAN – Primary, SecIsolated, SecCommunity, Sec2WayCommunity, і реалізовувати локальні PVLAN – те, що називається PVLAN Edge. Тобто тепер Ви зможете, скажімо, зробити community-порти в PVLAN, який покриватиме кілька пристроїв.
Висновок
Можливо, вам буде цікаво почитати інші статті про VTP на нашій Knowledge Base
- Протокол VTP v1/2 – реалізація та налаштування