VTP

Следующий модуль, посвященный коммутации, будет посвящен протоколу VTP. Протокол этот вендорский, цисковский. Соответственно, расшифровывается как VLAN Trunking Protocol. И хотя название у него не очень говорящие, нужен он для того, чтобы реплицировать базы VLAN на соседних свечах циска. Более точно на коммутаторах Catalyst. По умолчанию этот протокол работает, но находится в таком полувыключенном состоянии. Он готов, если что, подложить вам свинью в любой момент и включиться. Так же, как протокол DTP по умолчанию. Вроде как он и не работает, а вроде как и есть. Если DTP вам позволит согласовать Trunk в любой момент с любым свечом и пустить атакующего, который знает про такую любопытную особенность циска свечей в любой VLAN, то VTP позволяет любому желающему, у которого есть определенные, скажем, достаточно небольшие права,

среплицировать базу VLAN вашу с ним, а его, соответственно, с вашей. То есть он позволяет сделать так, чтобы ваша база VLAN стала немножко другой. VTP изначально был придуман для того, чтобы вы на одном свече в вашей корпоративной сети могли создать какой-то VLAN, и он бы автоматически разбежался на все остальные свечи. Идея была красивая, но, соответственно, с безопасностью тогда, когда все это дело придумывалось, было крайне не очень. То есть это все, на самом деле, времена, когда появились первые коммутаторы с VLAN. Если вы все еще помните, это компания Crescendo, которая потом циска купила. И, соответственно, да, VTP – протокол примерно начала 90-х годов. Про безопасность тогда не говорили вообще. То есть то, что кто-то может взять и испортить базу VLAN. Да как такое вообще можно подумать? Вот в такой вот логике VTP создавался. Ну и сегодня, понятное дело, такая логика уже не совсем работает. Поэтому часто можно встретить рекомендацию выключать VTP вообще совсем целиком.

И действительно, эта рекомендация работает в 100% случаев. Если он выключен, то взломать его уже не получится. Но, в принципе, протокол не самый плохой. И если уметь его готовить, то можно его приготовить так, чтобы он действительно реплицировал ваши базы VLAN на соседних свечах и при этом не создавал угрозу для безопасности. Для того, чтобы его использовать, нужно использовать актуальную третью версию. Третья версия поддерживается с 12.2 EOS. Не 12.2 просто, а 12.2 52. То есть это практически один из самых последних 12 EOS на свечах. Фактически можно сказать, что третья версия есть только на 15 EOS, потому что количество EOS в 12, где VTP есть третья версия, около нулевое. Но если у вас 15 EOS, то третья VTP там есть. И он там, в принципе, вполне неплохо себя чувствует. Первые две версии, соответственно, версия 1 и версия 2, они очень похожи друг на друга и они очень сильно небезопасны.

То есть первая версия, она появилась в 93-м году. Во второй версии придумали всякие косметические улучшения, как можно реплицировать базу немножко более хитро. Там появился токен ринг, то есть можно было реплицировать токен ринг с кевиланы. Там можно было включить трансляцию непонятных VTP-шных кадров, которые приходили вам от какого-то свеча, который был более новый, более модный, гипотетически. На одном свече у вас работает типа старый EOS, который не знает какие-то дополнительные плюшки, которые можно было бы положить в VTP на более новом свече. И более новый посылает VTP-шное сообщение и указывает там чего-то непонятное. Вот первая версия говорила, это то, что приходит непонятное, надо просто выкинуть. Во второй версии, если вы видели VTP-шный кадр, который содержит что-то непонятное, то вы могли такое непонятное передать дальше. Сами бы вы с ним ничего не сделали, но при этом вы все равно бы транслировали такое непонятное дальше. И другие свечи, которые, возможно, понимали бы это непонятное,

они бы, соответственно, смогли бы из этого непонятного извлечь пользу. Вот. Но по большому счету первая и вторая версии, они абсолютно идентичны. Третья версия – это фактически новый протокол, то есть это уже не улучшенная первая версия, как было со второй, а это прям совсем все новое. Он устроен абсолютно иначе. Поведение у него будет похоже на первую и вторую версию, но формат сообщений там абсолютно другой, концепции все другие. И поэтому изучать мы будем с вами все три версии, но при этом будем понимать, что работать по факту, если и придется с каким-то VTP, то только с третьим. Для того, чтобы понять, как работает VTP, нам нужно будет вспомнить, откуда вообще пошла линейка Catalyst. То есть это свечи, которые изначально CISCO сама не разрабатывала. Она купила целиком компанию Crescendo вместе с их линейкой Catalyst. И как следствие она просто переклеила шильдики. Из-за этого архитектура каталистовских свечей устроена следующим образом.

База виланов хранится в файлике VLAN.DAT. На флешке здесь неправильно написано. Не RAM VLAN.DAT, а Flash VLAN.DAT. И соответственно там хранится база виланов, и там же хранится на самом деле настройки VTP. Вы можете переопределить хранение VTP-шной базы, указать, где конкретно VTP должен хранить свою базу, командой VTP-файл. Но по умолчанию да, она хранится в VLAN.DAT. Этот файлик позволяет хранить только 10-битные номера виланов. То есть позволяет хранить только виланы с 1 по 1005 на самом деле. Extended виланы он хранить не может. И соответственно, если вы храните виланы в этом файлике, то вы ограничены только первой тысячой одним виланом для своих нужд. Вы можете указать, что вы на самом деле храните виланы не в этом файлике,

а в running.config или в startup.config. Для этого вам нужно будет прямо выключить VTP, либо указав, что VTP должен работать как-то в совсем дохлом состоянии, либо не должен работать вовсе. Тогда у вас база виланов будет переезжать в startup.config. Но сам файлик вилан.DAT при этом с диска не удаляется. Если вы потом сотрете startup.config, то сам файлик там будет лежать на месте. Железка перезагрузится без startup.config. Посмотрите на то, что этот файлик есть и увидят, что база виланов у вас все еще присутствует. Поэтому, если вы берете каталистовский свитч и хотите его продать кому-нибудь, или купили вы с рук бэушный каталистовский свитч и хотите поставить свою сеть, имейте, пожалуйста, в виду, что недостаточно на каталистовском свитче удалить startup.config файлик, для того, чтобы сбросить конфигурацию. Часть конфигурации, вот в части виланов, например, в части VTP, в части виланов, хранится в файлике вилан.DAT.

И его надо тоже удалять. Как можно с VTP работать? Для того, чтобы VTP мог реплицировать базу виланов, вы должны будете задать некоторые базовые настройки. По умолчанию на всех свитчах настройки VTP устроены таким образом, что VTP не может работать. Он не может работать, если ему не задать имя домена, и это имя домена по умолчанию пустое. То есть оно задано в пустую строчку null, и вы можете его поменять. Для того, чтобы его поменять, используется команда VTP domain и дальше название домена. Когда вы это делаете в первый раз, у вас пробегает сообщение, VTP domain name изменилось, было null, стало какое-то, которое вы задаете. И, соответственно, VTP у вас включается и начинает рассылать VTP-шные свои сообщения. До того, как вы задаете доменное имя, у вас сообщения VTP-шные не рассылаются.

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

и вы не знали про то, что VTP у вас на самом деле живет. Вот. И потом кто-то где-то на каком-то из свечей взял и ввел доменное имя VTP, соответственно, у вас VTP везде массово включился с одним и тем же доменным именем, и вся база VLAN среплицировалась с того свеча. Так что если где-то какие-то VLAN были созданы, то они у вас затрутся. И вообще разговаривать, вот как вы продают нам Е serve le VTP, иRISADASgoose, допустим, то Вы их не Effects, то Южноигрелку о том, А. Вующих domain вы можете сказать, что это же ожидает цида, кап 있다 уже всегда emblemается приземлBecause в iPhone Gold Report. У меня есть ли об этом helm成果, в этом각-instruction exerc VRC, Так, да, прошу прощения, в какой-то момент у нас получается отвалился просто микрофон, и я все это время говорил в пустоту.

Так вот, если вы не настроили доменное имя, вы сидите с нулем, и кто-то в сети поменяет доменное имя и начнет рассылать VTP-шные сообщения, то все коммутаторы в сети, у которых доменное имя было пустое, они заимствуют VTP-шный домен, они начинают в VTP участвовать, и они начинают реплицировать базу VLAN с тем, кто это самое доменное имя рассылает. То есть, если вдруг у вас были какие-то свечи, на которых VTP был не настроен, но база VLAN какая-то на каждом свече была, и эта база VLAN была не одинаковая, то в какой-то момент мы можем включить VTP на одном свече, и он автоматически включает VTP на всех остальных свечах и автоматически разливает свою базу VLAN на все остальные свечи. Поэтому таким образом можно потерять базу VLAN, если она раньше была не одинаковая, то после включения VTP она станет уже одинаковой. Вот. VTP, соответственно, позволяет нам посмотреть, как он настроен. Есть команда showVTPStatus, которая покажет доменное имя текущее.

Оно может быть либо пустое, либо не пустое. Если мы задали его команде VTPDomain, или если пробежала какая-то VTP-шная ПДУ-шка с указанием доменного имени соседа, то у вас будет показано, с каким доменным именем VTP запущен. Ну и плюс показывается, какая версия прямо сейчас запущена. Там синтаксис команды showVTPStatus немножко различается от EOS к EOS. На старых EOS он немножко по-другому выглядит, но смысл там плюс-минус километра везде одинаковый. Вот VTP version capable и VTP version running показывает то, соответственно, какие версии поддерживаются. Здесь на этом EOS поддерживается с первую по третью. И какая сейчас прямо версия VTP запущена? Версия номер один. Это поведение как раз по умолчанию. Ну и VTP у нас умеет реплицировать базу VLAN. Он на самом деле умеет много чего реплицировать. Но в частности он умеет реплицировать и базу VLAN. И в базе VLAN вот у нас прямо сейчас пять VLAN. Я даже знаю, какие это VLAN.

Это VLAN 1, 1001, 1002, 1003 и, как вы уже догадываетесь, 1002, 1003, 1004, 1005. То есть это VDI и token ring в VLAN. Если мы возьмем и включим в VTP, соответственно, на каком-то свече, то он начнет рассылать указания, как он настроен. И все свечи, у которых VTP, соответственно, VLAN будут приниматься, вот они свою базу VLAN будут заменять соседней базой из приходящих сообщений. Можно будет немножко защититься от этого, указав, что репликация будет возможна только в ситуации, когда наши сообщения будут подписаны правильным паролем. По сети сам пароль не передается. Передается хэш от пароля и содержимого каждого конкретного пакета. То есть там не то, чтобы прям уж совсем ужас в части безопасности,

но все равно пароль там защищает только от ситуации вида сосед прям какой-то злобный злоумышленник взял нам что-то и прислал. Можно задать этот пароль командой VTP password cisco. Ну, VTP password, дальше пароль. И можно его посмотреть плейн-текстом. Show VTP password покажет этот самый пароль. По сети передается только хэш, так что если вы имеете доступ к командной строке, то вы можете посмотреть сам пароль. Если вы просто перехватываете пакет, то вы пароль не увидите. Если вы работаете в VTP третьей версии, то VTP-шный пароль можно создать с ключом hidden. И тогда вы не можете посмотреть оригинальный пароль, но вы можете посмотреть только хэш от него. Show VTP password вам покажет от него только хэш. Ну вот как здесь показано. VTP password, дальше мы показываем cisco и hidden. И хэш пароля будет вот такой кривой. Есть, правда, нюанс заключающийся в том, что в определенных ситуациях вам нужно будет иметь плейн-текстовый пароль.

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

базу виланов другого свеча, то это определяется просто на основании номера ревизии. Вы на одном свече взяли, добавили новый вилан в базу, или удалили новый старый вилан, или переименовали вилан, и у вас номер ревизии на новом свече увеличился на единичку. И дальше в этих самых summary advertisement вы начинаете рассказывать про то, что у вас база виланов более новая, более свежая. И все ваши соседи, видя такие summary advertisement, понимают, что у вас база виланов более новая, и, соответственно, надо у вас попросить какие-то изменения, которые произошли у них, которые они сами не видят. Вы можете такие изменения разослать внепланово. Если вдруг вы добавляете какой-то вилан в базу, то вы отсылаете сразу сообщение subset advertisement. То есть вы рассказываете про то, что в вашей базе произошли изменения, и вы отсылаете базу целиком. Summary advertisement рассказывает только про номер ревизии, про то, что у вас произошли изменения. А subset advertisement рассказывает про саму базу.

То есть, естественно, subset advertisement, он больше по размеру, чем summary. Если вдруг вы только включились, и вы, скажем, обнаружили, что есть какой-то свеч, который присылает summary advertisement с номером ревизии большим, чем ваш, то вы можете отправить advertisement request и получить в ответ subset advertisement. То есть вы говорите, я вижу, что у меня номер ревизии 18, при этом в summary advertisement приходит номер ревизии 19, то есть у соседа есть более свежая база. Вы говорите, пришли мне, пожалуйста, номер 19, и сосед присылает subset advertisement с базой вилана номер 19. Базу виланов 18 вы свою выкидываете, заменяете ее на 19 базу, которая пришла из соседа. И последний тип сообщения – это VTP join. Оно будет нужно для механизма VTP pruning. Когда будем говорить про pruning, я про него расскажу. Так, как будет VTP работать?

Работает VTP только по транковым портам. Это означает, что если у вас… Так, мультик сейчас немножко рановато. VTP работает только по транковым портам, поэтому если вдруг у вас происходят какие-то изменения в сети, это автоматически все-таки не разбегается вообще в любом случае. То есть какой-то злоумышленник, который добавил новый свич в сетку и собирается по VTP рассказать всем остальным свичам, что теперь в базе виланов только один вилан номер один, вот по умолчанию в VTP этого сделать вам не позволит. Ну, злоумышленнику не позволит. Но это не позволит он сделать только если злоумышленник не смог согласовать с вами транк. А если злоумышленник все-таки смог согласовать с вами транк, Например, потому что вы забыли про протокол DTP, и DTP позволил злоумышленнику на лету поднять транк, согласовав его параметры с вами. Вот в этом случае, скорее всего, вы забыли также протокол VTP, и тогда злоумышленник сможет вам и перебить базу виланов тоже. То есть DTP и VTP – это два протокола, каждый из которых является бомбой замедленного действия, разоботанного разложенными граблями.

Но DTP позволяет кому угодно устроить атаку, а VTP позволяет при условии, что атака на DTP была возможна, сделать еще более страшную и ужасную вещь. VTP будет работать по транковым портам, он по транковым портам будет подсылать вот эти сообщения – summary advertisement, subset advertisement и advertisement request. И, соответственно, если вдруг у нас есть свечи, которые непротиворечиво настроены, то есть у них совпадает имя домена и у них совпадает пароль, ну или хэш от пакета и пароля, то, соответственно, база виланов, которая есть на свече с более старой ревизией, просто выкидывается и заменяется база виланов на более новой ревизией. Пример тот, который у нас есть на экране, это как раз такой мультик. На одном из свечей у нас происходит обновление, то есть администратор туда зашел, внес какие-то изменения, номер ревизии увеличился, пошли суммарки в сторону соседей, что номер ревизии 10-й у нас есть, те сказали, у нас 9-й, пришли 10-й.

Начинается вилан адвертайзмент, субсид адвертайзмент рассылаться на соседние свечи, дальше они уже рассказывают, у нас 10-й субсид адвертайзмент, и соседи, которые принимают такие сообщения, уже начинают с них запрашивать изменения, которые происходят. Ну вот, рано или поздно, да, все свечи в итоге получат более новую версию базы, старую, при этом они, естественно, выкинут. Ну, учитывая, что в сети с ненастроенным VTP достаточно на одном свече просто включить доменное имя, и все свечи автоматически включат виланы, и все свечи автоматически начнут реплицировать базу виланов, ну, да, то есть получается, что надежность у этого механизма достаточно слабенькая. Вероятность того, что атакующий при соблюдении каких-то элементарных норм безопасности возьмет и согласует, с кем попала транк, и согласует взаимодействие по VTP и сотрет базу виланов, на самом деле не очень большая.

Если вы хотя бы что-то знаете про протокол DTP, то вы, скорее всего, на всех портах, где может образоваться атакующий, запретите возможность устроить транк. Поэтому в VTP проблема основная не в том, что злобный хакер придет и вас похакает. В VTP основная проблема в том, что если вдруг у вас администратор возьмет и вставит в топологию свеч, свеч, у которого доменное имя будет совпадать и у которого пароль, возможно, тоже будет совпадать. Например, потому что этот свеч когда-то был в продакшене, и он был настроен на использование того же доменного имени, того же пароля. Номер ревизии у него почему-то был больше. Например, потому что вы в какой-то момент взяли все свечи из продакшена, вывели, положили на склад. Дальше с теми же конфигурациями сделали новые свечи. У них база Виланов начала ввести свой номер ревизии снова с другого числа. Ну, с единицы она начинается. И дальше вы со склада взяли новый, в кавычках, новый, на самом деле, старый свеч,

у которого номер ревизии был еще со старой нумерацией, оно было там больше. И вот вы вставили в сеть. И VTP в такой ситуации разошлет указание. У вас тут у всех номер ревизии, например, 9, а у меня номер ревизии 109. И, соответственно, вы должны все сейчас стереть свою базу Виланов и заменить эту базу Виланов моей 109. Ну, то есть, вот такой вот свеч, флешбек из прошлого возвращается, и у него номер ревизии, если будет больше, то, соответственно, он затрет вам базу Виланов, актуальную, новую. Проверяется только номера ревизии. То есть, 10-я ревизия однозначно больше, чем 9-я, и однозначно лучше. 9-ю выкидываем целиком, 10-ю заменяем ее, ставим на ее место. Может очевидно быть такое, что вы... Пардон, да, возвращаясь на один слайд назад. Может быть такое, что вы в двух местах одновременно внесете изменения. То есть, у нас была, например, везде 10-я ревизия.

Вы взяли на одном свече, сделали 11-ю ревизию, добавили новый Вилан, и на другом свече добавили Вилан, но уже другой. То есть, здесь вы добавили Вилан, допустим, там, не знаю, Вилан, ну, пусть 11-й будет, а здесь сделали Вилан 11-й. И номер ревизий у вас, соответственно, здесь изменился, стал 11-й в обоих случаях. Вот база Виланов 11-й ревизии тут и база Виланов 11-й ревизии здесь. Это две разные базы. И, соответственно, они начинают рассылаться. Этот рассказывает, что у меня есть ревизия 11-я, этот рассказывает, что у меня есть ревизия 11-я. Вот этот вот свитч только одну 11-ю ревизию примет. Допустим, он вот эту вот базу скопирует к себе, а вторую, соответственно, не скопирует. В этом случае на центральном свитче будет 11-й Вилан, но не будет 111-го. И у вас получится, что если два свитча одновременно сделали изменения в своей базе, то эти изменения по факту не среплицируются на все остальные свитчи. Кто-то получит информацию от одной базы 11-го ревизии,

кто-то получит изменения другой 11-й ревизии, но это будут две разные ревизии. Для того, чтобы немножко защититься от такой проблемы, в VTP были придуманы так называемые роли, режимы работы VTP. Соответственно, каждому свитчу вы можете назначить его возможность или, скажем, право редактировать базу Виланов. Это не про то, что там VTP будет какой-то другой. Это про то, что администратор, который будет заходить на свитч, при соблюдении определенных, скажем, при соблюдении определенных правил, не должен будет редактировать базу Виланов. Соответственно, режимы работы у VTP будет 4. Будет режим работы сервер. Это неограниченные права администратора по редактированию базы. То есть мы можем отредактировать базу, можем увеличить номер ревизии, можем отредактировать параметры VTP, можем... Соответственно, что можем сделать?

Можем включить VTP, выключить VTP. То есть, что хотим, то и делаем. Если мы на свитче указываем VTP-мод сервер, то в этом случае, да, администратор может редактировать базу Виланов. Плюс к тому, естественно, что мы, мы, получая VTP-шные сообщения на сервере, естественно, дальше их передаем без каких-либо сложностей. То есть мы получаем сообщение с указанием номер ревизии большего, чем наш. Мы говорим окей. Соответственно, мы, если сосед присылает номер ревизии больше, чем наш, мы говорим, наша база плохая, у соседа база хорошая, мы свою базу выкидываем, новую базу забираем. И дальше начинаем рассказывать про это своим соседям. То есть сервер — это не про то, что мы внутри VTP как-то начинаем иначе работать. Сервер — это про то, что мы можем редактировать базу Виланов. Логично представить, dass вы, как администратор сети, сделаете так, чтобы у вас серверов в сети был только один. То есть вы говорите, что у вас есть там 4 свитча в топологии, или 10 свитчей в топологии, или 100 свитчей в топологии, они между собой как-то связаны.

И вот вы говорите, у нас есть один свитч, который мы объявляем сервером, а все остальные свитчи, которые у вас в топологии есть, мы сервером не объявляем. мы их переводим в какой-то другой режим. И тогда только на одном свече база Виланов будет редактируема. То есть прямо в консоли вы можете редактировать базу Виланов. На всех остальных свечах вы говорите, у них будет роль другая, клиент. И, соответственно, на этих клиентских свечах вы базу Виланов просто тупо редактировать не можете. Вы заходите в консоль, вы пытаетесь создать номер Виланы, переименовать Вилан, удалить Вилана, что угодно сделать, и вам система выдает ошибку, говорит, извините, вы клиент, вы не можете редактировать базу Виланов, если вы клиент. Клиент только не имеет права редактировать базу VTP или настройки VTP Но при этом клиент точно так же работает, как и сервер То есть он, принимая номер ревизии больше, чем у него, выкидывает свою базу Забирает у соседа ту базу, которая с большим номером ревизии И дальше начинает рассылать ее своим соседям Разница клиента и сервера заключается только в праве редактировать базу VLAN

То есть в консоли на сервере можно зайти и поправить базу VLAN В консоли клиента нельзя зайти и поправить базу VLAN При этом может быть такое, что сервер обновит базу клиенту И может быть такое, что клиент обновит базу серверу Никаких проблем нету, потому что при работе VTP в самих сообщениях нигде не указывается, какая роль у этого узла Клиент или сервер одинаково свечи себя ведут, одинаково заменяют на соседских свечах базу VLAN В более новой ревизии Сервер и клиент это про то, как VTP работает Соответственно, в обоих случаях VTP работает хорошо Но в случае с сервером мы можем редактировать локальную базу VLAN на свече А в случае с клиентом мы можем только принимать сообщения от соседей И обновлять свою базу VLAN тем, что соседи нам прислали Вот, ну да Есть еще два режима Это режимы Transparent и Off Transparent говорит, что у нас VTP фактически выключается

То есть свеч не участвует в VTP, не синхронизирует базу VLAN Но при этом Transparent разрешает транзитные сообщения VTP То есть если у нас есть какой-то свеч Давайте сейчас сотру со слайда все свои каракули Если у нас есть свеч, например, сервер Он подключен к свечу Transparent и он подключен к клиенту То сообщения VTP от сервера к Transparent будут просто транзитно фарвардиться в сторону клиента Как будто бы это были сообщения, которые просто транзитный свеч Ну, как любой мультикаст, который он видит, он просто дальше пересылает Мультикаст там будет идти, как понятно, на традиционный мультикастовый Mac Цисковский 010000C, ccc, ccc, ccc Вот Еще один режим будет называться Off Если вы выключаете VTP с помощью транспорта Вы фарвардинг транзитных сообщений разрешаете Если вы выключаете VTP с помощью VTP в моде Off

То вы точно так же выключаете VTP VTP-шные сообщения не влияют на базу VLAN Витп-шные сообщения, кроме того, не фарвардятся дальше То есть, если вы принимаете какое-то сообщение на одном порту VTP-шное То Switch анализирует это сообщение и дальше его не фарвардят VTP-модов есть не на всех платформах То есть, если у вас есть какой-то старый iOS с, например, отсутствием поддержки VTP-3 версии То там VTP-off может не быть Вот Но если у вас новый iOS, новая железка, то VTP-off там есть И он не зависит от номера версии VTP, которая у вас запущена в данный момент Если у вас железка новая, то вы можете VTP-off включить в любой версии Разница между transparent и off заключается в том, что фарвардинг транзитных сообщений В случае с off выключен, в случае с transparent включен То есть, transparent вы просто целиком выключаете обработчик VTP В off вы, хотя кажется, что off это прям как-то совсем выключили, а транспорт как-то не совсем

На самом деле, off он более, скажем, более внимательно смотрит на транзитный трафик Если он видит в транзитном трафике VTP, он такие кадры пристреливает Так, в чем проблема будет с VTP? Я уже на самом деле говорил, что если вдруг у нас в какой-то момент на двух свечах Одновременно изменится база VLAN, то все свечи по факту получат только одну копию изменений То есть, в любом случае, допустим, у нас была девятая ревизия Мы на двух свечах отредактировали базу У нас номер ревизии вырос на единичку, стал десятым номером и на одном свече, и на другом И, соответственно, все остальные свечи, которые были, у нас они получили только одну версию десятой ревизии Вот, например, здесь мы добавили десятый VLAN, здесь добавили двадцатый VLAN Два разных VLAN Потом отправили указание, что мы знаем номер ревизии десять И там, и там у нас номер ревизии вырос на единичку Здесь говорим десятый и номер ревизии, и тут номер десятой ревизии

Соответственно, все остальные свечи говорят, мы видим десятую ревизию Что с одной стороны, что с другой стороны, видим, это одна и та же ревизия Нам достаточно любой свеч попросить прислать нам десятый номер ревизии Для того, чтобы у нас стало хорошо Мы отправляем запрос на то, чтобы нам прислали десятую ревизию И получаем только какую-то одну вариацию десятой ревизии Ну и получится, да, что два свеча знают про десятый VLAN, один свеч знает про двадцатый VLAN Дальше, например, может произойти такое, что на вот этом вот свече мы еще добавили там тридцатый VLAN У нас снова новые изменения, номер ревизии 11 Рассылаем сообщение вот этому свечу, говорим, что у нас одиннадцатый номер ревизии Он затирает свою базу VLAN всерьез, что мы видим ambassador, который у нас есть 20 и 30 VLAN, а 10-го уже нет И рассылает эти изменения на соседние свечи Он раньше знал про 10 VLAN, но не про 20 VLAN Сейчас он 10 VLAN перестает знать, и знает 20 и 30 VLAN То есть таким образом можно потерять базу виланов, если вы в сети позволяете появиться свечу, у которого будут такие же имя, домены и пароль, как у вас, или хотя бы просто какое-то имя, домены, если у вас имя домена нулевое.

Но у него будет, соответственно, больше номер ревизии, и это означает, что если вдруг у вас в сети внезапно возьмется свеч, например, из старых запасов, он может вам обновить базу виланов настолько, что сотрет вообще все. Это будет крайне неприятно, что у вас раньше база виланов была, а теперь перестала быть, или, скажем, вернулась на несколько лет назад. Поэтому от такого стоит защищаться. Защищаться от этого можно, в общем, только очень простым способом. Каждый раз, когда вы отправляете какой-то свеч на склад, обнулять его конфигурацию, в частности, стирать файл xviland.daz. То есть там хранится настройка VTP, там, в частности, хранится номер ревизии. Дальше. Если мы работаем с VTP первой и второй версией, то вы должны будете убедиться, что VTP-сервер у вас только один. Но вам никто не запрещает иметь несколько VTP-серверов в пределах вашей сети. Более того, по умолчанию все свечи VTP-сервера, все свечи позволяют редактировать базу виланов.

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

VTP-мод-клайент в принципе не позволяет вам редактировать базу виланов, а VTP-мод-сервер позволяет вам редактировать базу виланов только если вы так называемый primary-сервер. А primary-сервер это будет один свитч, и VTP 3 версии контролирует, что он всего только один. То есть это такой верховный сервер. Базу виланов можно редактировать только на этом самом primary-сервере. В чем тогда разница между просто сервером и клиентом, если у нас есть еще primary-сервер? А дело в том, что вот этот вот самый primary-сервер, он будет выбираться среди всех обычных серверов. И, соответственно, вы, когда указываете VTP-мод-клайент, вы говорите, этот свитч вообще даже не подлежит возможности когда-либо иметь право редактировать базу виланов. Соответственно, по умолчанию у вас все свитчи имеют роль сервер, и вы среди этих всех свитчей выбираете один primary-сервер с помощью традиционной демократической процедуры выборов. В VTP третьей версии есть сообщение, которое позволяет установить, ну, своего рода соседские отношения.

То есть каждый свитч знает, какие еще VTP-шные свитчи есть в топологии. И вы, зная, какие другие свитчи есть в топологии, начинаете рассылать им сообщение, не против ли они, чтобы вы стали primary-сервером. Вот. Учитывая, что вы знаете список всех соседей, учитывая, что вы задаете всем вопрос, не хотите ли вы сказать что-то по поводу моего становления primary-сервером, то получается, да, что если никто не против, то вы primary-сервером становитесь. VTP третьей версии будет реплицировать не только базу виланов, но и разное другое. В частности, из коробки сегодняшние циски позволяют редактировать базу виланов и базу MST. Помните у нас в конфигурации MST там инстансы есть и привязки виланов. И надо, чтобы они обязательно на всех свитчах были одинаковые, иначе у нас MST не подружится. Только вот VTP третьей версии позволяет нам реплицировать именно базу MST, для того, чтобы на одном свитче можно было создать инстанс, а на другом свитче этот инстанс сам появился.

Очень клевая вещь. Вот, соответственно, да, VTP третьей версии позволяет ее сделать. И, кроме того, VTP третьей версии позволяет расширять функциональность за счет других, назовем это адресных семейств, хотя это не адресные семейства, конечно, других баз, которые тоже можно будет реплицировать. И вот unknown – это как раз то, что в дальнейшем возможно появится, но пока еще не появилось. VTP может передавать непонятные сообщения дальше, если мы говорим про третью версию. И эти сообщения могут содержать в себе базу чего-то прям совсем другого. Не про то, что неизвестные виланы с неизвестными свойствами, а прям совсем что-то неизвестное. Если вы хотите сделать ваш свитч primary сервером, то это будет команда не из конфига, а из глобального язык-зак режима VTP primary. И вы указываете VTP primary, за какую фичу вы хотите стать. То есть фича – это как раз набор того, чего можно реплицировать.

Можно реплицировать виланы, тогда будет VTP primary VLAN, либо VTP primary MST, вы будете primary сервером за роль репликации MST конфигураций. И вот если вы заказываете, что вы должны стать primary сервером за роль VTP VLAN, то ваш свитч начинает отпрашивать соседей, не против ли они, чтобы вы стали primary сервером за базу VLAN. Соседи не возражают, и система вам говорит, что да, у нас все хорошо, у нас не обнаружены никаких конфликтующих устройств, действительно ли нужно становиться primary сервером. Вы подтверждаете это, система говорит, окей, наш свитч стал primary сервером за базу VLAN. Как можно опросить соседей и вообще выяснить, какая у них роль, что у них вообще чего? Есть команда showVTP devices, которая покажет всех-всех-всех соседей. Она на лету строит список актуальных соседей, поэтому там не то, что какая-то табличка есть, которая прямо всегда на готове.

Она на лету всех соседей опрашивает, и показывается, что вот у нас есть сосед, который поддерживает репликацию базы VLAN. У него база имеет ревизию 1. Праймеры сервером он считает вот этот вот свитч. Сам он при этом вот такой вот, и у него есть хостнейм свитч 2. То есть это сообщение, которых в VTP 1 и 2 версии в принципе не было, которое позволяет нам установить соседские отношения или узнать про то, как зовут соседний свитч, какой у него хостнейм. Ну и поэтому да, VTP 3 он устроен существенно иначе по сравнению с VTP 1 и 2 версией. Так, если мы говорим, что у нас есть VTP, который умеет реплицировать базу VLAN, то есть это поддерживается во всех версиях VTP 1, 2 и 3 версии. Более того, она включена по умолчанию. Если у нас VTP работает, то вот репликация у нас автоматически происходит. То реплицируются списки VLAN и реплицируются их свойства.

То есть реплицируется состояние Active. Если у нас VLAN какой-то в активном состоянии, включен, то мы это состояние реплицируем на все остальные свитчи. Реплицируется состояние Suspended. То есть если вдруг мы заходим в редактирование базы VLAN, говорим вот, заходим в VLAN 10 и говорим State Suspended, то мы тем самым как бы ставим виртуальную машину на паузу. Она, фарвард трафик уже больше не будет. Но при этом она как бы остается, ресурс употребляет. И вот это вот состояние Suspended реплицируется в VTP. Как вы помните, там есть еще shutdown. Это прям выключить виртуальную машину. Вот shutdown не реплицируется. То есть если вы видите в базе VLAN'ов LShut, то это значит, что это вот локально на вашей системе выключен VLAN, но на остальных свитчах этот VLAN продолжает работать. А вот Suspended, если вы на одном свитче Suspendите VLAN на Primary Server, то вот это вот состояние Suspend'd разбегается на все остальные свитчи. Дальше.

VTP 1, 2, 3 версии может реплицировать флаг Remote Span. То есть мы про Switchport Analyzer, про мониторинг еще пока не говорили, но обязательно поговорим. Вот там флаг этот самый Remote Span для VLAN'а можно будет тоже реплицировать. И если вы работаете с VTP 3 версией, то можно будет реплицировать также и структуру Private VLAN. Так, да. Если у нас есть Primary Server, вот мы взяли, отредактировали базу VLAN'ов. Мы сказали, что 10 VLAN у нас имеет какое-то имя, имеет какой-то вот статус, состояние Suspend'd. Вот отредактировали базу и смотрим на любом свитче Show VLAN и дальше мы видим, что VLAN такой в базе появился с именем тем самым, который у нас есть. То есть на всех свитчах разбегается этот VLAN, на всех свитчах указывается его имя, и на всех VLAN, на всех VLANах реплицируется его статус Active или Suspend'd.

Если вы будете, соответственно, редактировать, пытаться редактировать базу VLAN'ов на свитче, который не является Primary Server в VTP 3 за фичу VLAN. То есть вы пытаетесь на другом каком-то свитче отредактировать базу VLAN'ов, пишете VLAN 20, и система ругается. Она говорит, я не буду принимать эту команду. VTP VLAN Configuration not allowed when devices not the primary server for VLAN database. То есть система не принимает редактирование VLAN'ов просто на уровне консоли. Она по-прежнему будет реплицировать базу VLAN'ов. То есть если вдруг придет номер ревизии больше, чем у нас, она нашу базу выкинет на мороз, а новую базу примет и заменит ей старую. Но при этом редактирование базы VLAN'ов локальное вам будет недоступно. Равным образом недоступно будет редактирование базы VLAN'ов, если вы VTP Mode Client. То есть вы пытаетесь зайти в редактирование базы, и система говорит, я не буду этого делать. То есть мы зад pearl'ов Hobbit цифровать на

Клиент и сервер это не про то, кто кому базу затереть может. Клиент и сервер это про то, кто может редактировать локальную базу, кто не может редактировать локальную базу. Так. Для следующей темы нам понадобится вспомнить четвертый тип сообщений, помимо summary, advertisement, subset, advertisement и request, которые мы рассмотрели уже. Четвертый тип сообщений – VTP join. Это сообщение нужно для работы механизма, который называется VTP pruning. Он по умолчанию выключен, но тем не менее можно его включить. И этот механизм позволит немножко сократить количество так называемого бум-трафика. Broadcastного, multicastного и unknown-unicastного. Если у нас есть какие-то порты, в которых можно передавать трафик какого-то VLAN, то в эти порты у нас по умолчанию бум-трафик, соответственно, будет отправляться.

Может быть с метками, может быть без меток, не суть, важно. Но по умолчанию он разбегается по всем портам. Если у нас есть какие-то абонентские свечи, на которых нет портов определенного VLAN, то мы можем сделать так, чтобы бум-трафик за этот VLAN не отправлялся в сторону свечей. Дело в том, что если у нас есть VTP, то мы, как правило, на всех транках разрешаем все VLAN. А вот это VLAN, но у нас вот здесь, на этом свече, есть все VLAN, но пользователи есть только в VLAN и в WIP 10, 20. Сuyu. На этом свече есть все VLAN, но пользователи тоже есть только в 10, 20. В VLAN. Сuyu. На этом свече, опять же, все VLAN есть в базе, но пользователи есть только в 20 и 30. То есть VTP нам реплицирует базу виланов, но VTP говорит, что на всех свитчах у нас есть виланы 10, 20, 30, 40. По факту пользователи, конечно, не на любом свитче, не в любом вилане будут.

Поэтому на самом деле нет смысла вот на этот свитч присылать браткастовый трафик 30-го вилана. Там просто тупо нету пользователей в этом вилане. И как можно бороться с браткастовым трафиком ненужных виланов, которые будут приходить на ваш транковый порт? Можно будет использовать как раз механизм, который называется VTP пронинг, который действует очень просто. Если вы включаете этот самый пронинг, то вы заказываете список нужных вам виланов. То есть вы отправляете join и говорите, какие виланы по факту вам нужны. И тогда, если вы не заказали трафик определенного вилана, вот бум трафик этого вилана, то вам отправляется трафик только тех виланов, которые вы заказали. То есть трафик ненужных вам виланов не отправляется. Вот как это выглядит. У нас есть свитч с абонентами в 10 и 20 вилане из 4 виланов, которые вообще в принципе везде есть. 10, 20, 30, 40. Вы заказываете, отправляете сообщение join и говорите, что меня интересуют 10 и 20 виланы.

Соответственно, здесь join идут. Заказывается тоже 10 и 20. Здесь заказывается 20 и 30. Здесь заказывается, соответственно, 30 и 40. То есть те свитчи, которые включили пронинг, они отправляют список виланов, которые им нужны. Если вы не отправили сообщение join, то отправляются broadcast, unicast и multi-cast и trafic за все виланы. Если вы отправили сообщение join, то тогда broadcast, unicast и multi-cast и trafic отправляется только за те виланы, которые вы в явном виде попросили. То есть, на самом деле, более правильно это сообщение рассчитывать, расценивать не как сообщение «присылай мне трафик этих виланов», а «не присылай мне ничего другого, кроме того, что я явно не попросил». Если вы не отправляете такое сообщение, то вы ничего в явном виде не просите не отправлять. Если вы это сообщение «join» отправляете, то вы говорите «отправляй мне только вот это, все остальное не отправляй».

Поэтому, если вы ничего не отправляете, вообще join не отправляете, VTP-прунинг не включаете, то вам отправляется вообще все. Если вы включаете прунинг и отправляете join, то тогда вы тем самым говорите «все остальное, кроме того, что я не попросил, присылать мне не надо». Ну и, например, вот у нас есть свитч, на котором есть 20-й вилан. У него тут пользователь в 20-м вилане сидит, этот пользователь начинает отправлять браткастовый трафик в 20-м вилане. В этом транке у нас 20-й вилан бегает, соответственно, 20-й вилан передает браткастовый трафик дальше на центральный свитч. И 20-й вилан у нас, соответственно, есть во всех транках. Если бы мы не включили прунинг, то он бы должен разбежаться, был бы на все-все-все порты. Но за счет того, что мы прунинг повключали, вот, например, вот этот вот свитч, он сказал, «У меня пользователей 20-го вилана в принципе нету, поэтому я отправляю сообщение join только за 30-й и 40-й виланы. Поэтому, пожалуйста, 20-й вилан мне не присылай». И на этот свитч 20-й вилан не уйдет.

Хотя в транке у нас все порты, все виланы разрешены. Но по факту 20-й вилан туда коммутироваться не будет. 20-й вилан для бум-трафика. Вот этот вот свитч не заказал 40-й вилан и 10-й вилан, но 20-й вилан он заказал. Он мне говорит, есть пользователь 20-го вилана, поэтому браткастовый трафик 20-го вилана приходить ему будет. Здесь тоже заказали 20-й вилан, поэтому браткастовый трафик 20-го вилана тоже будет приходить. Такой простенький механизм, который позволяет немножко сократить количество браткастового трафика в тех виланах, в тех транках, где по факту нет пользователей этого вилана. Join, да, шлют аксесс-свитчи. Ну, join шлют все свитчи, на которых вы включаете этот механизм. Но больше всего этот механизм нужен именно на аксесс-свитчах. Понятное дело, что вы, в принципе, гипотетически можете включить его вообще на всех свитчах. Тогда, если у вас есть какой-то порт, в котором есть хотя бы один пользователь этого вилана,

вот вы будете отправлять join за этот вилан. В каких случаях отправляются join? Первое. Если у вас есть абонентские порты с этим виланом. Второе. Есть транки, в которых вы получили join от соседнего VTP. То есть, вот вопрос, как определяется список вилан для join на основе чего. Ну, вот два правила. Первое правило. Если есть абонентские порты в этом вилане. И второе. Если у вас есть живой транк, в котором был получен join от какого-то другого свитча. То есть, вам свитч один прислал сообщение, давай мне присылай 20-й вилан. Значит, вы говорите, если вдруг кто-то мне будет присылать 20-й вилан, браткаст твой трафик, я вот ему должен буду это отправлять. И вы поэтому сами в другие транки отправляете сообщение join, что вас браткаст 20-го вилана интересует. Так. Включается очень просто. Причем, что интересно, включается не в конфиге.

Команда будет VTP Pruning в глобальном режиме, в exec mode. Дело в том, что это, опять же, тяжелое наследие времен платформы Crescendo, где конфигурация виланов и конфигурация VTP выполнялась не из конфига, а отдельно. Поэтому VTP Pruning включается тоже отдельно. Ну и после того, как вы его включили, никаких специальных настроек делать не надо. Он сам определяет списки виланов и сам отправляет сообщение join. Далее, далее, далее, далее. Про MST. MST позволяет тоже реплицировать базу, но уже не базу виланов, а базу инстансов MST и привязок виланов к ним. Для того, чтобы использовать репликацию таблицы MST, вам потребуется VTP только третьей версии. То есть VTP первой и второй версии реплицируют только базу виланов, VTP третьей версии реплицируют что угодно. Ну вот, например, MST конфиги. И вы указываете, что вы хотите стать сервером за фичу MST.

Указываете VTP mode server MST. На всех свечах, которые у вас должны реплицировать базу MST конфигураций, вы указываете VTP mode server MST, VTP mode client MST. Ну, то есть вы участвуете в фиче MST. Понятно, что сервер и клиент ведут себя точно так же, как и для фичи виланов. То есть на клиенте, в принципе, нельзя редактировать список инстансов. На сервере можно редактировать список инстансов, но, соответственно, вы должны стать предварительно primary server. И primary server становится, опять же, VTP, primary и дальше название фичи MST. Опять же, после того, как вы это сделаете, система начинает опрашивать список всех соседей. Когда не обнаруживает соседей, которые против того, чтобы вы стали primary server, она говорит, что окей, действительно ли продолжить. И если вы соглашаетесь, указывает на то, что у нас primary server за фичу MST. Была получена роль. Также VTP с девайса будут отображать, что у вас появился новый сосед,

новое соседство по VTP третьей версии для фичи MST. И показывается, соответственно, кого сосед считает primary server за эту фичу и кто он. В нашем случае мы видим, что у соседа switch 2 MAC адрес AABBCC00001 и primary server за фичу VLAN он считает самого себя, а primary server за фичу другую MST сосед считает нас. Так, как выглядит работа, репликация MST в VTP третьей версии? У нас есть switch 1. Он, соответственно, сейчас не имеет никакой конфигурации MST. У него название домена MST пустое, номер ревизии пустой. Инстанс только дефолтный, к которому привязаны вообще все VLAN с 1 по 4094. И, соответственно, show VTP статус показывает, что вот это вот configuration revision это для фичи VLAN, а соответственно вот это вот для фичи MST.

И видно, что VTP ничего пока не среплицировал, номер ревизии имеет тот же самый 0, что и вот здесь. Ой, пардон, пардон, это разные 0. Да, вру, вру, вру. Вот это номер ревизии 0, это не тот же самый номер ревизии, что вот здесь. Это разные 0. Дальше. На каком-то другом свече мы указываем, что у нас есть база конфигурации MST, Spanning 3 MST Configuration. Здесь заносим что-то вот свое. Обращаю внимание на то, что номер ревизии мы внутри конфига MST выставляем, и это номер ревизии для MST. То есть это MST-шная ревизия. И потом мы начинаем реплицировать эту конфигурацию MST. И, соответственно, на другом свече, который в VTP, третьей версии у нас, реплицирует MST-шная конфигурация, мы увидим, что эта 99-я ревизия, вот эта 99-я ревизия, вот эта 99-я ревизия, она прибежала. То есть то, что раньше здесь был 0, соответственно, оно стало 99-й. И появляется у нас здесь новый инстанс с двумя VLAN-ами, со 100 VLAN-ами,

с этого по 200-й. Ну, то есть конфигурация, очевидно, стала уже различаться. То, что мы на одном свече поменяли, прибежало на другой свеч. При этом configuration revision, вот эта вот ревизия, это ревизия VTP-шная. И вот эта, соответственно, VTP-шная ревизия. Смысл примерно похожий у VTP-шных ревизий и у MST-шных ревизий. Но это две разные ревизии, две разные сущности. VTP-шная ревизия влияет на то, кто кому перезапишет базу, а вот эта вот ревизия нужна для того, чтобы просто хэши не сходились. Так, давайте попробуем это дело понастраивать. То есть у нас сейчас как раз есть MST. Мы можем включить VTP-3 версии и для VLAN-ов, и для, как называется, и для MST, и срепенсировать тем самым базу и того и другого. Давайте попробуем настроить MST. Я сейчас предлагаю настроить MST, не MST, простите, а VTP-3 версии. И я начну конфигурацию с центрального свеча.

Соответственно, вы можете пока ничего не делать. Я пока настрою центральный свеч, а потом мы все вместе настроим уже свечи, которые дополнительные. Поскольку мы хотим реплицировать и базу VLAN-ов, и базу MST, то я сейчас не буду показывать то, что включение VTP в версии 1 или 2 автоматически включает VTP на всех остальных свечах. Я думаю, что вы можете просто мне поверить, а потом когда-нибудь самостоятельно проверить это в лабораторной среде. Но просто поверите, что это так. Если на одном свече у нас есть транк до другого свеча, и на одном свече мы указываем, что VTP первой и второй версии без пароля получает какое-то доменное имя, то все остальные свечи, которые точно так же без доменного имени, без пароля будут получать эти VTP-шные бодушки, они будут просто заимствовать настройки, и они будут автоматически включаться в тот же самый домен VTP. Но я указываю, что у меня VTP должен работать третьей версии. Так, а, ну да, он заставляет меня включить все-таки VTP-доменное имя.

VTP-моди. Так, VTP-домейн. Network.education. Видимо, придется мне показать, да, что от того, что я включил доменное имя VTP по умолчанию, да, VTP по умолчанию работает VTP первой версии, вот то, что я попытался в третью версию переключить, он мне не дал, говорит, нельзя. Если доменного имя нет, то нельзя. Ну и, соответственно, на всех остальных свечах у нас VTP заимствовал это доменное имя. Show VTP status. Должно показать. Вот оно, Network.education. Я это не менял на этом свече, оно само хапнуло. Соответственно, вот показывается, что Configuration.revision у нас единичка, и количество VLAN на этом свече 13. Если я сейчас на центральном свече сделаю какой-то номер VLAN, VLAN, не знаю, тысячный. Вот этот VLAN автоматически разбежится на все остальные свечи,

и Show VTP status покажется, что количество VLAN у нас увеличилось на единичку, и ревизия увеличилась тоже на единичку. И Show VLAN brief. Вот он, тысячный VLAN создался. Равным образом, если я сейчас на центральном свече возьму и переменую этот VLAN, Name Network Education VLAN, то, соответственно, на остальных свечах это автоматически тоже разлетится. Я на маленьком свече ничего не делаю, вообще ничего не делал, просто сижу, никого не трогаю, примус подчиняю, ко мне прибегают новые VLAN. Старые VLAN, которые были, у меня автоматически стираются. Но, соответственно, да. Если вдруг вы сейчас попытаетесь отредактировать свою базу VLAN, то эти изменения могут разлететься на все остальные свечи. Но если вы вдвоем пытаетесь отредактировать базу VLAN одновременно, абсолютно синхронно, то, соответственно, от кого-то из вас эти изменения просто не пройдут.

Номер ревизии увеличится у обоих на единичку. Был одинаковый номер ревизии, стал тоже одинаковый. У кого из вас более правильная ревизия с номером, например, 3, у того, кто создал VLAN, там, 301 или у 302, непонятно. Сравнивается база только по номеру ревизии. Вот. Поэтому мы хотим переключить VTP сразу в третью версию. Указываем VTP версию. Кстати, любопытный нюанс. Сейчас я покажу, раз уж начали это делать. VTP по умолчанию работает в первой версии. То есть из коробки, когда достаешь цисковский свеч, вот если есть транк, который смотрит на соседний свеч, если соседний свеч присылает сообщение, я работаю в домене вот таком, то это доменное имя автоматически хапается и автоматически свеч включается в домен VTP. Но версия первая, она, соответственно, вот из коробки работает и она позволяет нам реплицировать базу VLAN, просто вот ничего не делая.

Но, если я переключаю VTP во вторую версию, это тоже автоматически разлетается. То есть вот на центральном свече я переключил, на маленьком свече, вот у меня VTP версия работала первая. Show VTP status, вот она автоматически переключается в VTP второй версии. Мы для этого ничего не делали, оно само. Но VTP третья версия автоматически не хапается. То есть я сейчас все-таки возвращаюсь к оригинальному сценарию. VTP version version 3. То есть я переключаю VTP в третью версию. Конфигурация старого VTP, обнаруженная в файлике, VTP заимствуется под новую. И, соответственно, это не влияет на то, что у нас автоматически все свечи, которые подключены к этому свечу, тоже становятся третьей версией. Вот они видели, да, раньше, что разбегались изменения мгновенно. Сейчас он по-прежнему продолжает работать в VTP второй версии. То есть дружба по VTP третьей версии автоматическая не происходит.

Я указываю VTP версии 3 на центральном свече. Я указываю, что у меня центральный свеч должен быть VTP в моде сервер VLAN. Ну, система ругается, что уже и так сервера за VLAN. И MST тоже. Указываю, что VTP мод сервер для фич и VLAN и MST. В принципе, если бы я захотел, я мог бы сказать, что у меня есть вот 4 разных режима, которые я могу настроить. И каждый из этих режимов настраивается независимо для каждой фичи. Ну, вот для VLAN и для MST я указал, что я хочу быть сервером. И, в принципе, гипотетически нам этого достаточно для того, чтобы установить взаимодействие. Выхожу из конфига и становлюсь private сервером. Exit. Так, ой, что-то я такое нажал.

Так. Ну, ладно. Так, exit. VTP. Primary. VLAN. Система немножко тупит. Спрашивает у соседей, которые, возможно, только что появились, не против ли того, чтобы этот свитч стал главным за базу VLAN. И система вот потихонечку запрашивает праймер сервера, не обнаруживает никого. И, окей, я захватил роль праймера сервера за базу VLAN. Равным образом за базу MST захватываю. Так. Система немножко потупила, немножко покозлила и захватил роль за базу MST. Show VTP status. Show VTP status. Покажет нам про каждую фичу, что наша система о себе думает.

VTP запущена с версии 3, доменное имя Network Education. VTP для фичи VLAN работает с ролью Primary Server. То есть мы настроили, что это сервер, и потом захватили роль Primary Server. У нас 14 VLAN, причем из них 0 Extended VLAN. Отличительная особенность VTP третьей версии, он позволяет работать с Extended VLAN. VTP первой и второй версии не позволяют вам редактировать базу VLAN, не позволяют создать VLAN Extended, если у вас включен VTP в режиме отличного транспорента. Если вы хотите работать с расширенными VLAN, вы либо обязаны перевести VTP mode транспорент, либо вы можете включить VTP третьей версии, и тогда VTP позволит вам работать с расширенными VLAN. Для фичи Primary Server, для фичи VLAN, простите, у нас показывается Configuration Revision Единичка. И вот такой вот хэш будет посылаться в исходящих пакетах,

которые за фичу VLAN наш сервер будет отправлять своим соседям. С учетом имеющейся базы, с учетом определенного количества VLAN, которые у нас есть в базе, их имен и всего остального. Этот дайджест очень удобно использовать для того, чтобы сравнивать как раз между собой базу на одинаковость на соседних свечах. Если у нас есть подозрение на то, что два свеча независимо друг от друга изменили свои конфигурации, и у нас есть такой Brain Split, когда один свеч думает, что у него одна редакция определенной ревизии, а другой свеч понимает, что у него другая редакция той же самой ревизии, то вот можно сравнить как раз их хэши. И хэши должны будут совпадать. Но если не совпадают, значит у нас как раз Brain Split. Номер ревизии одинаковый, хэши разные, криминал, криминал. Ну и за фичей MST то же самое показывается. Configuration Revision Единичка. И опять же, кто Prime Reserver и Digest. Show Spalding Tree MST Configuration.

Вот показывает, что сейчас у нас инстансы созданы и номер ревизии. Здесь вот единичка, вот этот вот номер ревизии, и вот эта единичка Configuration Revision MST, это разные ревизии. Вот эта ревизия MST, это ревизия VTP. Теперь давайте попробуем настроить наши маленькие свечи. Вот сейчас повторяйте, пожалуйста, за мной. Как бы мне это сделать, чтобы это пропало? Что-то я не знаю, как это убрать. Так. Ой, что-то я очень сильно неправильно делаю. Да. Повторяйте за мной. Conft. Доменное имя у нас уже настроено правильно, оно разбегалось еще тогда, когда VTP был второй версией, поэтому от нас сейчас потребуется переключить VTP в третью версию просто. VTP версию 3.

Опять же, когда мы включаем VTP в третьей версии, он обнаруживает старую базу второго VTP, перезаписывает ее, и сейчас у нас по идее VTP должен будет реплицировать свои настройки с всеми остальными свечами. Давайте посмотрим show VTP status, что нам покажет. Покажется, что у нас мы включили VTP третьей версии, но мы оставили рабочие только пока фичу VLAN, которая работала из коробки. И показывается, кто у нас primary server. Primary server называется switch. Давайте его переименую, что ли. Conft hostname switch. Витч. Кстати, я не знаю, как быстро разбегается информация про primary server. Скорее всего, не очень часто. Дальше показывается ID-шник primary server. Мы уже, кстати, знаем, что вот этот вот MAC-адрес — это центральный switch.

И показывается, что остальные фичи мы пока не включали. Вы можете у себя тоже попробовать включить фичу VLAN и заодно включите фичу MST. Conft. И укажите VTP моде. И дальше вы указываете какую-то роль, либо клиент, либо сервер. Давайте клиент для разнообразия. И фича MST. Раньше MST у нас для фичи, в смысле, VTP для фичи MST работал в режиме transparent. Сейчас он работает в режиме клиент. Так, вот он клиент. Primary server у нас называется switch для фичи MST. Опять же, primary server MAC-адрес мы его хорошо видим. И configuration revision наконец-то показывается, что ревизия имеет номер один. Если я сейчас внесу какие-то изменения в настройки MST, то у нас, по идее, эти изменения автоматически реплицируются на соседние свечи, что очень удобно при работе с MST. Потому что там вручную вносить все изменения

ну задолбающийся. Особенно, если вы делаете новые инстансы или новые VLAN к нему привязываете, или даже доменное имя захотите поменять, вот это становится действительно тяжело. Сейчас у нас show spanning 3 MST configuration показывает, что доменное имя Network Education, номер ревизии 1, и есть 5 инстансов, дефолтный и 4 кастомных. Давайте я сейчас добавлю на центральном свече какой-нибудь, не знаю, либо instance, либо к VLANу, допустим, 8 привяжу еще один, в смысле к instance 8 привяжу еще один VLAN. ConfT, spanning 3 MST configuration, instance 8, VLAN 108, 208, ну не знаю, 308. И ревизия 2. Давайте не 2, а даже 222. Прям много, чтобы было, чтобы это глазками отличалось.

Номер ревизии MST и номер ревизии фичи MST в VTP. Выхожу, применяю конфигурацию. Exit show VTP status. Вот раньше у меня был номер ревизии 1 на фиче MST, а теперь у меня произошли изменения, номер ревизии стал 2. И дайджест, то есть хэш от того, что я рассылаю, начинается на 9а. Раньше на маленьком свече у меня фича MST показывала номер ревизии 1, и соответственно дайджест начинался на 2f. Сейчас show VTP status показывает 9а. То есть то, что и должно быть, прибегают изменения, и показывает, что да, действительно у нас что-то произошло. Ну, соответственно, можно посмотреть, show VTP status, show Sparning 3 MST configuration, действительно 308 VLAN добавился к 8 инстансу. То есть мы на одном свече поправили конфигурацию MST, и эти изменения автоматически разбежались на все свечи. Рядышком можно же и VLAN поправить. То есть мы 308 VLAN в базе не имели.

Если бы у нас на центральном свече добавился этот VLAN, и мы добавили бы этот VLAN к 8 инстансу, он бы автоматически разбежался на все остальные свечи. То есть было бы очень удобно. Если просто 308 добавить, да, в 108 и 208 затрутся. То есть это не switchport run-callowed VLAN. Это все по-честному, надо ручками писать. Если вдруг вы захотите захватить какую-нибудь роль Primary Server, то вы должны будете использовать команду VTP Primary и, соответственно, должны будете указать, какую роль вы хотите захватить. Либо MST, либо VLAN. Ну, да, каждый раз, когда у нас происходят какие-то изменения, когда кто-то захватывает роль, все остальные свечи в топологии должны будут узнать про то, что произошли эти изменения. И когда вы становитесь Primary Server, вы можете редактировать эту базу. То есть если вы имеете роль сервера и вы захватываете роль сервера,

Prime Server, то вы получаете возможность редактирования базы VLAN. Я вот предполагаю, что сейчас мой свеч не является Prime Server, например, за фичу VLAN. Поэтому если я сейчас возьму и попытаюсь отредактировать на моем маленьком свече базу VLAN. Например, VLAN 10 создам, система скажет, извините, не могу. Ну и на центральном тоже не могу. Show VTP статус. Да. Вот показывается, что у нас есть роль просто сервера, который может поучаствовать в выборах основного сервера, праймера сервера. И, соответственно, здесь в фиче MST у нас VTP Mode Client. Очень удобная вещь VTP третьей версии. Его имеет смысл защищать паролем дополнительно. То есть, чтобы злоумышленники, которые вдруг к вам приходили бы и говорили бы, что они хотят стать Prime Server и хотят отредактировать вам базу, чтобы это не вызвало бы

внезапно негативных последствий в виде потери всех VLAN. Давайте попробуем сейчас это и сделать. То есть, сделать так, чтобы наши свечи, придаваемые VTP-шные сообщения, бы подписывали паролем. И, соответственно, у нас конфигурация будет иметь вид VTP Password. Ну, давайте, не знаю, Cisco сделаем. Так, ну и здесь тоже. Conf-t VTP Password Cisco. И теперь все сообщения, которые мы будем отправлять, будут подписываться этим самым паролем. VTP третьей версии позволяет хранить пароль как plaintextом, так и в зашифрованном виде. Если бы мы сказали VTP Password Hidden, Cisco Hidden, ну, то тогда бы в конфиге этот пароль plaintextом не хранился. А так, show VTP Password. Вот оно plaintextом его показывает. Ну что,

вот такой вот замечательный протокольчик, очень удобный при правильном приготовлении. То есть, если вы знаете про пароли, если вы знаете про то, что надо защищать ваши транки, и если вы знаете про VTP третьей версии, где только один сервер может быть primary сервером, то, ну, для, вот, например, репликации и базы VLAN-ов, и таблицы MST, это прям вот безумно удобная штука, рекомендую к использованию, но, опять же, да, при условии, что вы все сделали правильно. Если вы не уверены в себе, не уверены, что вы его можете правильно приготовить, лучше переключать все в VTP Mode Transparent для всех фич, и просто ручками все настраивать. Это куда более надежная, куда более подконтрольная штука. На сегодня все. Спасибо за внимание. И пока-пока. Продолжение следует... Продолжение следует...