Настройка IEEE 802-совместимой коммутации: часть 1

Продолжаем мы с вами говорить про настройку наших провайдерских железок. Мы с вами по-прежнему читаем курс из PNGN, то есть базовое взаимодействие в провайдерских сетях. И, как уже говорилось, в провайдерских сетях в основном используется взаимодействие сетевых устройств на основе одного из двух протоколов. Чаще всего мы говорим либо про взаимодействие в Ethernet-сетях или Ethernet-подобных сетях с использованием формата кадра 802, либо мы говорим, что неважно, в каком кадре оно приходит, мы терминируем на каналном уровне взаимодействия и дальше уже передаем пакеты между разными интерфейсами в соответствии с требованием протокола IP. Это более правильный сценарий, по большому счету, если мы говорим про IP как протокол, который создан специально для взаимодействия между разными канальными средами, естественно, IP использовать более правильно. Протокол более гибкий, протокол более, скажем, адаптированный под перекладывание данных между разными интерфейсами. Он изначально под это был заточен.

Ethernet изначально не был заточен под перекладывание данных между интерфейсами. Как следствие, формат кадра для перекладывания данных между интерфейсами неудобный. Коммутация в Ethernet появилась позже, чем придуман сам протокол, и, соответственно, она придумана там как дополнительный накладной механизм, который там появился в воле случая, по большому счету. Тем не менее, коммутаторы на основе вот этой логики коммутации 802-х протоколов, они достаточно дешевые. Поэтому в реальных сетях можно встретить и настоящие IP-шные устройства, которые умеют работать с IP-пакетами, и более дешевые коммутаторы на основе Ethernet, которые коммутируют кадры в соответствии с логикой вида. Разбрасываем копии кадров на все порты, кроме тех, куда они надо. Давайте поговорим про то, как настраиваются устройства на основе операционных систем EOS, EOS XE, EOS XR, если мы хотим работать с кадрами Ethernet. Начнем с самого очевидного, самого простого. Если у нас есть интерфейс, этот интерфейс чаще всего бывает мультискоростной.

Если у нас есть интерфейс медный, у него может, например, быть скорость поддерживаться 10 Мбит в секунду, 100 Мбит в секунду, 1000 Мбит в секунду. Обычно на интерфейсах там пишут 10 на 100 на 1000. Это не выбор скорости, хотя на слайде написано слово Speed, которое означает скорость. На самом деле это не скорость, это выбор одного из нескольких поддерживаемых стандартов. Интерфейс у вас может работать либо в стандарте 10 BST, либо в стандарте 100 BST, либо в стандарте 1000 BST. Вот он в этом случае будет 10 на 100 на 1000. Вы не можете сказать, а давайте у меня будет интерфейс Ethernet работать на скорости 539 Мбит в секунду. Не бывает такого стандарта, который работает на скорости 539 Мбит в секунду. Вот есть три стандарта, которые поддерживают ваш интерфейс, ваш чип. Один, другой или третий. Вы можете выбрать только один, второй или третий стандарт. Не более того. Кроме того, есть автосогласование, когда у вас чип может на лету принять решение, какой стандарт он будет использовать. Понятное дело, одновременно два стандарта использовать нельзя. То есть ваш чип должен принять решение, работаем там на гигабите,

и дальше с этого момента он работает на гигабите. Если ему надо переключиться на другой стандарт, он должен выключиться и включиться уже в новом режиме. Если у вас с обеих сторон есть узлы, которые поддерживают автоматический выбор стандарта, то вы можете использовать так называемое автосогласование. согласование. Если у вас с обеих сторон есть устройства, которые поддерживают автосогласование, они могут на лету рассказать, какие стандарты поддерживают они и, соответственно, выбрать наиболее скоростной стандарт из тех, которые и тот, и другой узел поддерживают. Если у нас два роутера с видным патчкордом, вот они согласуют максимально скоростной стандарт, если поддерживают согласование ООО. Кроме того, некоторые стандарты допускают работу либо в дуплексном режиме, в полно-дуплексном режиме, если хотите. Это механизм, при котором у нас отключается проверка на коллизии CSMACD и, соответственно, у нас одновременно возможна отправка и прием данных в обе стороны. И есть полноценный режим, который

халст-дуплексный, когда у нас включена проверка на коллизии, то есть у нас интерфейс не может одновременно отправлять и принимать данные. Если вдруг у нас случается одновременно отправка и прием данных, то объявляется ситуация с коллизией и кадр пытается переотправиться, тот кадр, который вызвал коллизию. В нормальных современных сетях следует везде использовать фул-дуплекс и, соответственно, везде таким образом отключать возможность даже согласования халл-дуплекса. Но есть нюанс. Если вы фиксируете жестко на оборудовании CSKA и скорость, и дуплекс, то у вас выключается автосогласование. А если у вас выключается автосогласование, то две железки, которые друг на друга смотрят без автосогласования, они могут работать некорректно. Для того, чтобы все работало корректно, у вас и стандарт, и режим дуплекса с обеих сторон должен быть одинаковый. Рекомендуется для того, чтобы все было заведомо одинаково, не зажимать вручную эти режимы. То есть рекомендованное поведение — это

оставить все в автомате. У вас автоматически все согласуется, автоматически роутеры или там свечи или что-то еще устройство Ethernet выберут максимально поддерживаемый стандарт по скорости и равно максимально хороший режим дуплекса в любом случае. Если говорить про оборудование на основе операционных систем Cisco IOS или IOS XE, то в этом случае в синтаксис, я думаю, что вам с CCNA должен быть знаком, как это настраивается. У нас есть в настройке интерфейса команда Speed и дальше там либо Speed 10, либо Speed 100, Speed 1000 или Speed Auto. Auto — это включить автосогласование. Если вы включаете автосогласование, то понятно, что все хорошо начинает работать. Если вы включаете какой-то конкретный режим, то есть говорите Speed, например, там 1000, то вы тем самым фиксируете, что ваш интерфейс работает только на скорости в 1 гигабит в секунду. Если вы зажимаете и скорость, и дуплекс в каком-то режиме, то автосогласование у вас отключается вообще совсем целиком.

Сосед, который будет с вами в одном проводе находиться, он не сможет угадать, в каком режиме вы работаете. То есть он не сможет, используя автосогласование, это сделать. У него есть другие механизмы, которые могут помочь ему в некоторых ситуациях угадать, в каком режиме надо работать, но это будут уже такие просто попытки ткнуть пальцем в небо. Это не будет какой-то надежный механизм, на который можно будет опираться. Поэтому в реальных сетях оставляем все в автомате. Далее. Если мы хотим в iOS XR настроить все то же самое, то есть мы хотим выбрать режим скорости, ну, стандарта фактически, или дуплекса, то, в общем, те же самые команды у нас есть, но есть небольшой нюанс. Нету команды авто. То есть если мы хотим зажать скорость какую-то конкретную, говорим там speed 1000, то это выставляет режим работы интерфейса 1000 BST. Если мы хотим, чтобы работало все в автомате, мы убираем это no speed 1000, и в этом случае поведение интерфейса

возвращается в состояние по умолчанию, и это более логично, что у вас в состоянии по умолчанию это автосогласование. То же самое и с дуплексом. Если у вас стоит настройка дуплекса, то вы выставляете жестко либо speed, в смысле, дуплекс half, либо дуплекс full. Если вы хотите вернуться в автомат, no duplex full, no duplex half. Если мы хотим настроить канальный уровень, то есть настроить взаимодействие в пределах одного провода в случае, если у нас там может быть много узлов в одном проводе. Понятное дело, что это все было актуально достаточно давно, сейчас это уже не так интересно. Но иногда все-таки бывает нужно настроить MAC-адрес на роутере, чтобы у нас роутер получил какой-то конкретный MAC. Чаще всего это как раз клиентам бывает нужно, чтобы клиент на сторону провайдера смотрел всегда с одним и тем же MAC-ом. Заменили устройство, а вот чтобы MAC типа не поменялся. Ну, иногда и провайдер будет нужно, чтобы на клиентов MAC-адрес смотрел тот же самый. Если вы берете, меняете железку, чтобы MAC-адрес там не поменялся. Ну, редко, но бывает нужно. Если мы в настройках iOS XE или iOS обычного делаем это, то мы указываем в настройке интерфейса

команду MAC-адрес и дальше в привычном синтаксисе три двухбайтовые группы, разделенных точками, шестнадцатиричные, задаем MAC. Если хотим назначить размер кадра, который может отправляться или приниматься через этот интерфейс, то делается это командой MTU на роутере. Подчеркну, мы сейчас говорим про роутеры. Есть нюанс, заключающийся в том, что команда MTU в цисках обычных или в цисках XE, она кривая и косая. Кривая и косая она по одной простой причине. Нету такого термина, как MTU в изернете. Иногда это называется MTU в изернете, иногда это называется L2-MTU, и все это на самом деле в выдумке. Не бывает такой вещи, как MTU в изернете. В изернете есть размер кадра. Размер кадра ограничен по стандарту 1518 байтами. Сюда не включается преамбул, но сюда включается destination адрес, soros адрес, что внутри лежит изернета, изертайп, простите, какие-то данные, которые более правильно было бы назвать

MAC client data и 4 байта frame check sequence. Вот эта вот вся колбаса по стандарту не может превышать 1518 байт. С учетом того, что заголовки занимают 14 байт и checksum занимают 4 байта, соответственно, поле с данными не может превышать 1500 байт в норме. Если вы задаете на обычном эусе команду MTU на интерфейсе, не IPMTU, а просто MTU, то вы указываете там размер того, что вкладывается после изертайпа. То есть вот эта вот штука называется MAC client data. И вы указываете размер поля MAC client data в кадре изернет, максимальный размер, который поддерживает ваш роутер на этом интерфейсе. Понятное дело, что кроме этого размера есть еще другие вот эти вот всякие поля, 14 байт заголовков, 4 байточки суммы, которые у любого кадра обязательно есть, их надо будет отправлять при передаче данных. Но вот эта вот команда их выносит как бы за скобки. То есть вы указываете размер поля с данными, там 1500, например, штатное поведение, 1500.

И неявно предполагается, что плюс 14 байт заголовков вот этих вот, как минимум, еще в любом случае будут передаваться. Зачем сделана такая странная вещь? Затем, что если вдруг вы будете использовать кадры с какими-то дополнительными 802-ми заголовками, как, например, 802.1Q или 800, или там ASL тоже, в принципе, да, берем кадр полезный, который у нас есть, и заворачиваем его в новый ASL на заголовок. То мы вот этот вот кадр, конечно же, берем. В нем есть какие-то данные полезные, которые мы хотим передавать. И дальше мы оборачиваем этот кадр каким-то дополнительными заголовками. Чтобы не писать, какого размера будут эти дополнительные заголовки, CISC сказала, давайте мы избавим наших администраторов от необходимости высчитывать эти заголовки автоматически, ручную. Сделаем все автоматически. Мы указываем максимальный размер вложения, а вот то, что там плюс дополнительные заголовки какие-то есть, типа CISC сама посчитает. Изначально идея была красивая, но оказалось, что CISC не всегда умеет читать все заголовки, которые есть в кадрах, которые мы хотим пересылать по интерфейсу.

Например, если мы хотим использовать QNQ, когда у нас два, а 800, 2.1.q, что у нас заголовка идет, CISC начинает с этим не справляться. Она говорит, когда у нас есть кадр, у него есть destination адрес, у него есть source адрес, у него есть, что внутри лежит. Это 88A8, если мы используем там 802.1.ad, ну или QNQ, будет 2 81 нулевые метки. Потом там номер VLAN внешнего, S VLAN. Потом вторая метка 8100. Потом, соответственно, там client VLAN. И, соответственно, потом идет данные, data и чек сумма. Вот в этом случае, если у нас есть кадр с двумя метками 802.1, Q или 802.1.ad, вот это вот первая метка сервисная, вот это вторая метка клиентская. В этом случае, с точки зрения интерфейса, который будет пересылать эти данные, вот эта штука будет заголовком Ethernet, а вот эта штука будет клиентскими данными. То есть клиентская метка, получается,

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

мы должны будем добавить эти самые 4 байта. Поэтому в этом случае, если у нас есть интерфейс, по которому мы хотим отправлять кадры с двумя метками 802.1Q, мы должны будем сказать МТУ 1504. Это нелогично, но это вот такая вот настройка, что Cisco одну метку посчитать смогла, а вторую метку мы должны будем воспринимать как содержимое кадра, которое пересылается по сети, и, соответственно, размер этого кадра у нас вырастает на 4 байта. В iOS XR эту штуку как бы рассмотрели и сказали, ну мы поняли как бы ошибку, потому что не все заголовки Cisco может самостоятельно посчитать, какие-то заголовки может, какие-то не может, там, допустим, MPLS не может, 802.1Q дополнительные метки не может, там, если что-то еще будет, тоже не может. Поэтому давайте уйдем от этой схемы, давайте сделаем так, чтобы мы указывали максимальный размер кадра, который мы будем передавать, вместе со всеми заголовками. То есть мы указываем MTU в iOS XR не в той же логике, что в iOS XE.

Это важно. В обычном iOS мы указываем размер поля с данными плюс заголовки, которые Cisco посчитать не может самостоятельно. В iOS XR мы указываем MTU весь размер кадра, который будет передаваться вместе с заголовками, со всеми, всеми, всеми. Cisco уже сама там ничего не добавляет. То есть если мы хотим передать самый маленький кадр, мы указываем размер кадра 64 байта. Если мы хотим передать кадр стандартного размера, то есть поведение по умолчанию будет MTU 1518. Если мы хотим передавать кадры с одной 802.1 кьюшной меткой, 1522. Хотим передавать кадры с двумя 802.1 кьюшными метками, 1526 и так далее. То есть это поведение у iOS обычного и iOS XR различается. Если хотим задать macadres, задается он точно так же, как и в обычном iOS по большому счету. То есть там никаких новостей нету. Тоже команда macadres. И немножко там другой формат подсказки идет, что типа сначала мы вводим какое-то число, потом точку, а потом после ввода точки можно будет отдельную справку заказать.

И там тоже типа следующие два байта macadres тоже типа можно будет смотреть. На экзамене наверняка будет вопрос на тему вот этого термина в кавычках MTU канального уровня. Это не MTU, потому что термин MTU есть только в протоколе IP. В Ethernet термина MTU нету, есть размер кадра, есть размер macline data. Так вот, в случае с iOS обычным или iOS XE мы сдаем размер polymacline data, а в случае с iOS XR мы сдаем размер кадра целиком. Без преамбулы, но с чексомный. Если у нас есть коммутатор, то на коммутаторах, на самом деле, сейчас вернусь на предыдущий слайд, на коммутаторах нацистковских по-разному задается MTU. В некоторых случаях мы будем задавать его так же, как на роутерах. В некоторых случаях есть команда глобального конфига. Это максимальный размер кадра, который коммутатор, в принципе, способен коммутировать. Здесь, к сожалению, я, по-моему, забыл этот слайд добавить, но тем не менее, там одна простая команда system.mtu или system.mtu.jamba. То есть вы указываете размер кадра.

Опять же, на iOS обычном мы указываем размер содержимого macline data. System.mtu.1500 дает нам возможность обрабатывать просто обычные кадры. Если мы хотим обрабатывать кадры, которые содержат дополнительную метку 802.mq, то, в принципе, Cisco сама умеет считать, что там необходимо добавить, поэтому никакую дополнительную команду не нужно выполнять. Если мы хотим добавлять дополнительную метку 802.1.q, чтобы у нас получилось там две 802.1.q метки, то MTU надо поднимать самостоятельно. Вы указываете system.mtu.1500.4. Есть нюанс, который system.mtu, как бы, не совсем очевидный. System.mtu работает на 100-мегабитных интерфейсах. На гигабитных нужно использовать опцию system.mtu.jamba. То есть там две настройки. System.mtu обычная. System.mtu обычная. И, соответственно, system.mtu.jamba. mtu.jamba. Вот. System.mtu.jamba – это для гигабитных

и более высокоскоростных интерфейсов. Это не для jamba фреймов. Это для jamba интерфейсов. Есть еще такая штука, как system.mtu alternate. Если вы на железке попробуете справку вызвать, после system.mtu нажмете вопросик. Она скажет, что есть опция просто везде число, есть опция jamba число, и есть опция alternate. На некоторых свечах эта штука поддерживается. Вы можете на всех интерфейсах сделать MTU нормальный, а на некоторых кривой. Но обычно это не нужно. Обычно на свечах везде включается просто поддержка больших кадров и все. Если вы не зададите MTU повышенной, хотя будете использовать кадры переростки, у вас где-то в транзите кадры такие будут теряться. То есть как это будет выглядеть? У вас есть свитч, допустим, абонентский, на нем сидят юзеры, и вы хотите использовать Q&Q на нем. Вот здесь у вас есть транк, с которым вы обмениваетесь данными с клиентом с использованием 800.2.1.q. И дальше вы хотите передавать данные наружу, и вы хотите использовать Q&Q.

И, соответственно, на неком транзитном свитче вы передаете дальше данные на некий ролл, который у вас сидит там, условно говоря, в ядре. Вот здесь у вас тоже Q&Q поддерживается, и, соответственно, у вас транзитный свитч пропускает через себя кадры, фактически просто помеченные сервисной меткой, там, Q&Q, не знаю, 123. Просто вы в этом случае принимаете кадры с меткой 123 и пересылаете их дальше с меткой 123. Но в этом случае кадры, которые вот здесь вот этот транзитный свитч будет обрабатывать, это будет фактически просто обычные кадры. Просто они будут больше на 4 байта. И, соответственно, на нем надо будет как раз не забыть добавить опцию System.2 или System.2Jumbo. Скорее всего, System.2Jumbo. Если вы этого не сделаете, то абонент, отправляя вам кадры, не помеченные 800.2.1.q. заголовком, вот здесь, вот, он будет видеть, что такие кадры нормально доходят. А если он будет отправлять кадры, помеченные 800.2.1.q. заголовком, то тогда в этом случае кадры будут отправляться

только если у них размер не превосходит, там, 1496 байт. Вот, по содержимому. Так что классическая ошибка провайдерская. Если вы включаете где-то Q&Q, на всех-всех-всех-всех транзитных железках надо будет убедиться, что вот System.2 у вас достаточно большая для того, чтобы такие кадры пропускать через себя. Если нет, будет на трассировке, это хорошо видно, что кадры большого размера где-то будут проваливаться. И там 1496 байт проходит нормально, 1500 не проходит. Ну, значит, где-то кто-то накосячил. Если еще говорим мы про свитчи, то свитчи чаще всего на провайдерских сетях стоят где-то очень близко к абонентам. Это железки, у которых портов много, которые самые дешевые. И, соответственно, вот у нас есть свитч, который смотрит на абонента, и это мы называем такую штуку абонентский свитч. Если вы используете свитчи, которые просто тупо самые дешевые, в этом случае эти свитчи будут предназначены для сетей предприятия. В сетях предприятия мы используем логику коммутации вида,

каждый с каждым может взаимодействовать, чтобы там можно было, не знаю, принтеры пошарить, по папочкам пошариться. Ну, то есть это в сети предприятия является нормой. У провайдера не является нормой взаимодействия между обычными абонентами напрямую. Поэтому, если вы используете метроэзернет свитчи, на которых вот прям в буквке написано ME, если говорим мы про циску, то это специальные отдельные линейки, не обычные каталисты, а вот именно метроэзернет свитчи. На них точно такой же iOS, на них точно такие же интерфейсы, то есть они визуально точно такие же. Но iOS у них немножко различается, и вы можете на уровне интерфейса сказать, что это за интерфейс, куда он смотрит, на обычного абонента или на вашу сеть. То есть это, грубо говоря, ваш апплинк. Метроэзернет, метроэзернет форум предусматривает три, ну, более строго два режима работы порта, User Network Interface и Network Node Interface. Uni — это значит, порт смотрит напрямую на абонента, NNI — это порт, который смотрит на другую вашу собственную железку.

Порт, который смотрит на вашу собственную железку, он доверенный, то есть коммутация от этого порта будет разрешена куда угодно. А вот порт Uni, он не совсем доверенный, у вас не разрешается коммутация между Uni портами по умолчанию. То есть у вас есть свитч абонентский, у вас есть апплинк один-второй, и у вас есть куча абонентских портов. Все абонентские порты по умолчанию Uni, все порты-ауплинки по умолчанию NNI. Коммутация между NNI портами работает, коммутация между NNI и Uni портами работает, коммутация между Uni-портами не работает. Просто, ну, как бы, для того, чтобы пользователи напрямую между собой трафик не передавали, чтобы можно было передать трафик до вашего браса, если это необходимо, а потом уже от браса вернуть трафик до другого абонента, чтобы трафик, который идет между пользователями, проходил через ваш биллинг, чтобы вы его видели, могли проинспектировать, посчитать и так далее. Вот. На юни-портах по умолчанию выключена коммутация между юни-портами. Можно будет сделать так, чтобы в некоторых случаях

это было допустимо. То есть вы можете фактически юни воспринимать как protected port на каталистах, если вы знаете, что это такое. Или isolated VLAN. На каталистах, если мы говорим про private VLAN. Можно включить community VLAN. Если вы хотите, опять же, работать с private VLAN, вы можете взять и сказать, что у нас есть, да, как бы private VLAN, но у нас есть два типа абонентов. Часть абонентов не может друг на друга ходить, а часть может. И вот в этом случае там те абоненты, которые могут в пределах private VLAN друг на друга ходить, называются дочерний community VLAN. То же самое можно сделать и с юни-портами. Но это как бы отдельная тема. Обычно этого никто не делает. На юни-портах выключены служебные протоколы. То есть учитывая, что провайдерские свечи, как правило, не хотят обмениваться никакими служебными данными с клиентами, они нужны только для фарвардинга боевого трафика. Там выключены CDP, то есть Spanning 3, LLDP, LADS, Pag. То есть там все выключено. Транки по умолчанию с этими узлами не поднимаются.

То есть, ну да, там все вот это вот не работает. Это не работает штатно, и это как механизм защиты, и вполне логичный механизм защиты на метроизорнатных свечах, соответственно, провайдерами любимого. Что вы, в принципе, можете все это сделать вручную? Можете. Но не хотите. У вас по умолчанию на метроизорнатных свечах уже и так все это выключено. Если вы используете NNE-порты, то там все включено по умолчанию, так же, как на каталистах. То есть NNE-порты – это вот то, что обычная нормальная свеча, на которой мы проходим на CCNA. Если вы хотите, вы можете порт перевести в Enhanced режим. То есть вы говорите, что порт у вас по-прежнему юзерский, но вот у нас некоторые абоненты есть. Вот это не просто Uniport будет, а Eni-порт, Enhanced Network Interface. Вы в этом случае все равно запрещаете коммутацию между ENI-портами и другими ENI или другими UNI, то есть так же, как в случае с UNI-юни-коммуникацией, это невозможно. Но вы при этом на Enhanced порту

включаете протоколы Spanning 3, LDP, WAC, PAK, что там еще. Вы не можете включить на ENI-порту Spanning 3, то есть он просто там выключен. Его нельзя включить. Но, тем не менее, можно будет опознать, допустим, что вы подключили к этому порту какую-то железку, не знаю, телефон. Условно. Вот. Так. Переключается, ну, в настройки интерфейса командой port type чего-нибудь. По умолчанию на MetroEthernet свечах, я еще раз напомню, как правило, все эти железки, они уже давным-давно, и до все. Но, тем не менее, они все еще встречаются в проведерских сетях. По умолчанию пользовательские порты, вот которых на коммутаторах обычно много, они все UNI. А, соответственно, uplink порты, которых на коммутаторах обычно мало, они все UNI. Если вы хотите, вы можете пользовательский порт перенести в другой режим, сказать, что у нас вот есть там FastEthernet 0.1. Этот порт, как бы он, да, действительно,

он на морде, как бы считается одним из пользовательских портов, но мы туда воткнули какой-нибудь, не знаю, маленький, мелкий какой-то свеч. Мы хотим, чтобы там на этом порту работал транк, мы хотим, чтобы на этом порту работала коммутация, как еще не бывало, вот, и мы в этом случае переводим порт в network node interface режим. Если мы хотим настроить транк на двух свечах, то в этом случае мы должны будем на порту сказать команду switchport.no.trunk. Если на свече поддерживаются несколько режимов инкапсуляции, то есть либо 802.1q, либо ASL, предварительно нужно выполнить команду switchport.trunk.incapsulation.1q. и далее, если вы хотите использовать вдруг почему-то native.vlan, то вы можете его зажать командой switchport.trunk.nate.vlan. Не нужно использовать native.vlan никогда. То есть если у вас есть трафик какой-то, который бегает в определенных виланах, вы должны будете убедиться, что native.vlan у вас не содержит боевого трафика, что в нем нет

никогда пользователей. Вот эту команду switchport.trunk.nate.vlan нужно будет делать не для того, чтобы пометить, какой вилан у вас будет передаваться без метки. А для того, чтобы сказать, что у вас случайно никакой боевой вилан не передается без метки. Чтобы вы вот этот самый native.vlan поставили в такой вот номер вилана, который у вас просто не используется. Либо его вообще нет в базе, либо он выключен командой shutdown. Ну то есть чтобы просто в принципе никогда никакой трафик по вашему транковому порту не ходил без метки. Есть еще, кстати, классная команда. Она будет буквально на следующем слайде. Она в глобальном конфиге выполняет... В смысле конфиг. В глобальном конфиге выполняется vlan.1q.tagnative. Делает она не только то, что написано. То есть vlan.1q.tagnative, во-первых, отправляет даже кадры native вилана на транках с меткой 802.1q. Она помимо этого, если кадр приходит на транковому порту

без метки на 802.1q.tagnative, она его просто выкидывает. То есть она говорит, что во всех случаях, если мы используем эту команду, на всех транках можно передавать только размеченные кадры. Нельзя отправлять кадры с native инсуляцией. Очень хорошая команда. Рекомендуется к использованию. То есть в принципе, если вы объявили, что у вас на каком-то порту работает транк, на этом порту все кадры обязаны быть размечены 802.1q.tagnative. Так. Если мы хотим со стороны маршрутизатора поймать трафик из транка, в какой ситуации это будет нам нужно? У нас есть маршрутизатор, который смотрит на свитч, и на этом свитче у нас есть пачка абонентов. Вот часть абонентов находится в одном вилане, часть в другом вилане, часть в третьем вилане. И мы хотим все три вилана обслужить на одном и том же маршрутизаторе. В этом случае мы должны будем создать субинтерфейсы. И эти субинтерфейсы на CISC и на EOS XE создаются, в принципе, привычным нам CISC-ный образом. Мы указываем, что у нас есть родительский интерфейс,

на котором единственное, что требуется сделать, это сказать no shutdown. Дальше на дочерних субинтерфейсах, которые мы создаем, мы указываем команду encapsulation. Дальше указываем тип инкапсуляции и номер вилана. Если вдруг у нас есть какой-то трафик, который бегает неразмеченным, его тоже нужно будет отловить в субинтерфейсе. То есть мы ничего не делаем на родительском интерфейсе, там нет IP-адреса, там нет никаких настроек. Все настройки мы даем на дочерних субинтерфейсах. В этом случае неразмеченный трафик мы будем ловить в субинтерфейсе, который ловит на этих вилан. По умолчанию не видно этого, но на самом деле это так. Весь неразмеченный трафик относится к первому вилану. То есть как бы неявно предполагается, что у вас есть субинтерфейс, соответствующий первому вилану, и весь трафик первого вилана идет без разметки. Если вы хотите сказать, что трафик, который идет без разметки, должен относиться к другому вилану, вы должны будете создать отдельный субинтерфейс и сказать encapsulation.1q, номер native вилана, и дальше указать ключевое слово native.

Этого не видно, но если вы сделаете субинтерфейс отдельный, в котором скажете encapsulation.1q1, у вас это слово native добавится автоматом. То есть если вы хотите, чтобы у вас native вилана был какой-то другой, вы должны будете создать для этого другого native вилана отдельный субинтерфейс, указать номер этого отдельного native вилана и указать ключевое слово native. Тогда первый вилан перестанет native быть. В iOS XR примерно похожая штука. Есть небольшой бардак, заключающийся в том, что разные версии iOS XR будут иметь разные синтаксисы, настройки субинтерфейсов для 802.1q. Проблема будет в том, что в старых версиях, в старых версиях операционной системы Cisco и iOS XR используется команда отдельная. .1q, вилан, и дальше указывайте номер вилана. Или .1q, native вилан, дальше указывайте номер. Ну, в принципе, как бы не то, чтобы какая-то отдельная прям концепция была,

но просто немножко не похоже на то, как это было в обычных Cisco. В новом синтаксисе, в новых операционных системах, в новых версиях iOS XR, точнее, синтаксис привычный. Тоже вы создаете субинтерфейс, точно так же он выглядит, точно так же на родительском интерфейсе никаких настроек нет, все делается на дочерних субинтерфейсах. И вы указываете номер субинтерфейса, и указываете encapsulation, .1q, и дальше число. Если вы хотите, вы можете сделать указание, что какой-то субинтерфейс будет использоваться как native. И вы в этом случае делаете encapsulation, .1q, дальше номер вилана, и через запятую ставите untarget. Есть нюанс, который заключается в том, что не во всех версиях, даже новых, операционной системы Cisco и OS XR вот этот синтаксис работает. В некоторых линейках оборудования настройка untarget native вилана будет осуществляться только через вот эту вот штуку. В некоторых линейках есть другой синтаксис, типа encapsulation untarget.

Ну, то есть, к сожалению, есть бардак в части настройки native вилана на сабах в XR, поэтому просто надо будет, если вы будете работать с конкретной железкой, посмотреть по документации, как делается это на ней. Ну, вот, как бы классический синтаксис, который Cisco использует в большинстве литератур, это вот такой вот. В принципе, концепция по созданию транков и субинтерфейсов, ну, вот она в iOS, обычном iOS XR примерно одинаковая. Если мы хотим назначить на свече транк-кукушку, то есть Q&Q, в этом случае мы должны будем сделать следующую вещь. У нас есть, на самом деле, два разных варианта, как можно это сделать. Можно сделать чистый Q&Q в том виде, в котором мы придумали Cisco, когда мы просто на кадре навешиваем две метки. Одну внутреннюю метку клиентскую, client tag, другую сервисную метку, нашу собственную, по которой, собственно, идет коммутация. Вот если мы говорим, что у нас используется именно классический Q&Q, то это проприетарный Cisco-вский вариант,

при котором используются два заголовка, возможно, с 8100, капсуляция, возможно, с какой-то другой. Если вы хотите использовать Q&Q с инкапсуляцией, с типом Ethertype 88.8, пожалуйста, никто вам не запрещает это сделать. Ну, то есть, вот в нашем случае мы можем сказать, что вот клиенты нам отправляют кадры с указанием Ethertype 8100, мы дальше отправляем эти кадры с инкапсуляцией 88.8. Пожалуйста, никаких проблем можно так сделать. Но все равно это как бы расценивается как 802.1Q-шный кадр, который будет передаваться вот здесь, вот с меткой 802.1Q. Значит, ну, с двумя метками. В нашем случае у нас есть какой-то вот абонент, который подключен на левом свече, который, ну, не знаю, который мы хотим коммутировать по 10-й таблице, по 10-му Вилану, и абонент этот же имеет другую точку присутствия у нас, подключен к другой точке присутствия,

и, соответственно, вот мы хотим трафик этого клиента передавать по вот этому нашему транку с указанием метки Вилана 10-го. Равным образом у нас рядышком есть другой клиент, который точно на тех же самых точках присутствия есть, но он должен будет коммутироваться по отдельной таблице, по таблице 20-го Вилана. При этом каждый из этих клиентов хочет использовать свои 802.1Q-шные заголовки для того, чтобы указывать, куда там кому чего можно будет передавать. То есть вот когда у нас используется, например, внутренний клиентский 10-й Вилан для взаимодействия между вот этими вот товарищами, то есть у нас трафик должен между ними ходить только вот так. То, что другой клиент использует точно такой же 10-й Вилан для своего взаимодействия, не означает, что трафик между десятыми Виланами разных клиентов должен будет ходить. То есть мы в этом случае на кадры будем навешивать свою какую-то собственную метку, и у нас трафик вот этого клиентского 10-го Вилана и вот этого клиентского 10-го Вилана, а равные каких-то других абонентов, которые, допустим, в нашей сети 10-го Вилана помечаются, путаться при этом не должен.

Равным образом, если здесь, не знаю, 20-й Вилан, здесь тоже 20-й Вилан, то трафик, между вот этими двумя клиентами тоже должен ходить, а со всеми остальными клиентами 20-го Вилана, которые, возможно, в нашей сети тоже есть, но только они какие-то другие, это все не должно путаться. То есть клиент у нас один, и вот его Виланы мы должны будем сохранить, его метки Виланов. Если у нас есть другой какой-то клиент, его метка Виланов, мы должны будем сохранить тоже и не перепутать кадры разных клиентов между собой. Поэтому мы навешиваем отдельные метки, так называемые сервисные метки, и в них проставляем свои номера Виланов, которые на клиентские уже никак не ориентируются. Вот на трафик первого абонента мы навешиваем свою сервисную метку с 10-м Виланом, на трафик второго абонента мы навешиваем метку с 20-го Вилана. Когда наш свитч получает такие кадры, он по этим меткам принимает решение, по какому Вилану коммутировать полученные кадры. Метки внешние он снимает. У этих кадров, на самом деле, две метки. Одна та, которую мы поставили, другая та, которую клиент поставил. Та, которую мы поставили,

мы ее поставили в момент отправки кадра под рамку. Потом мы при получении кадра такую метку срезаем, и получается содержимое со всего лишь одной меткой. Мы кадр коммутируем по внешней метке, которую мы только что срезали, по Вилан-ID, который мы назначили в соответствии со внешней меткой. И отправляем клиенту кадр со всем содержимым, включая внутреннюю метку, на которую мы вообще даже не смотрели. А клиент уже на этой метке принимает решение, что с этим кадром делать самостоятельно. Если мы хотим настроить такой транк, то, во-первых, для того, чтобы все работало корректно, понадобится вот эта вот самая команда VLAN.1Q-tag-native, чтобы если вдруг вы указываете, что у вас есть клиентский порт, на котором у нас проходят 802.1Q-шные кадры с разметкой клиента, чтобы вы не спутали клиентские кадры с разметкой 802.1Q и свои собственные кадры, которые тоже у вас, возможно, имеют разметку 802.1Q. Поэтому вы говорите, если мы на клиента смотрим танком, то все VLAN, которые приходят от клиента, они все должны быть в тагет.

Указываете VLAN.1.tag-native, указываете, что у вас есть вот этот вот порт, который транковый порт между вашими двумя свечами. То есть вот здесь вот у нас кадры будут передаваться с нашими сервисными метками. На этом порту указываете switchport mode-trank, просто обычный транк. И если вы хотите передавать кадры с двумя разными метками, чтобы у вас физически метка ваша и метка клиентская отличались по типу, то вы указываете switchport-trank, .1Q-user-type, и дальше указываете тип. Классический вариант, при котором сервисная метка получает свой отдельный из RTIP 88.8, он вот здесь вот как раз и реализуется. То есть те кадры, которые вы будете отправлять с меткой, со своей вот этой вот сервис-таг меткой, они будут иметь из RTIP не 81.0, а 88.8. Здесь отправили 88.8 метку, здесь срезали ее и получили оригинальный кадр. То есть, в принципе, настройка транка здесь неинтересная. Настройка абонентского порта немножечко интересная, потому что есть команда switchport-mode,

дальше .1Q-tunnel. Вот эта вот команда указывает, что это вообще таксессовый порт. То есть мы себя ведем на этом порту как аксесс. То есть мы говорим, что на этом порту у нас просто приходят какие-то кадры, которые мы дальше оборачиваем заголовком. Мы не читаем заголовок, который пришел на этом порту, мы не ориентируемся на те метки, которые там есть. Но отличие от классического switchport-mode-access заключается в том, что мы на этом порту разрешаем прием кадров с 802.1Q-шными метками. Мы на этом порту ожидаем прием кадров с длиной кадра на 4 байта больше, и мы, получив какую-то кадр, у которого, возможно, есть 802.1Q-шные метки, у которой, возможно, кадр переросток, мы на него сверху навешиваем VLAN ID, тот, который вот здесь вот указан в команде switchport-access-VLAN10. То есть switchport-mode.1Q-tunnel говорит, на порту могут приходить кадры, размеченные 802.1Q, но мы не читаем их содержимое. Мы не ориентируемся на эту метку 802.1Q, мы расцениваем такие кадры,

как просто обычные кадры. Да, у них какой-то Ethertype. Да, у них Ethertype 8100. Ну и что? Это просто какое-то содержимое. Мы берем этот кадр, навешиваем на него VLAN ID, десятый в нашем случае, после отправки кадра под ранковым интерфейсом, мы навешиваем 802.1Q-шную метку, сообразно тому VLAN ID, который мы назначили для того, чтобы сказать соседу, дорогой сосед, коммутируй этот кадр по таблице 10-го VLAN. Сосед принимает такой кадр с меткой, снимает метку, выкидывает ее, но предварительно смотрит, какой VLAN ID следует назначить, доверяя метке, которую он только что выкинул, назначает VLAN ID кадру, коммутирует этот кадр по таблице 10-го VLAN. Есть команда L2ProtocolTunnel. Она позволяет получать кадры совершенно произвольного типа. Дело в том, что на свечах, которые у нас, как это называется, на свечах, которые смотрят на абонентов, у нас есть обработка кадров тех самых

CDP, VTP, LLDP и прочее. Она может быть и выключена, но вы не отправляете, вы не принимаете кадры на абонентов, но при этом вы просто игнорируете такие кадры, вы их по умолчанию дальше не пересылаете. Ссылаете. Связано это с тем, что такие кадры, они в принципе не подлежат коммутации. То есть если вы видите какой-то кадр, например, CDP, вы не коммутируете CDP никогда и ни за что. Вы его сами потребляете. Эти кадры идут на специальный мультикастовый Mac. Если свеч видит кадры, идущие на мультикастовый Mac, хорошо ему известно, он его просто сам потребляет. Он не направляет его на таблицу коммутации. Можно себе будет это представить, как то, что вот есть у нас железный свеч, и дальше на нем есть отдельные виртуальные коммутаторы. Коммутатор 10-го Вилана, коммутатор 20-го Вилана, коммутатор 30-го Вилана. И отдельно есть сущность, которая называется центральный процессор, CPU. И вот у нас есть какой-то порт. Неважно, он аксессовый или не аксессовый. Допустим, по умолчанию, аксессовый порт у нас. Вот мы говорим, этот порт относится в Вилан 10-й.

Switchport mode access, Switchport access VLAN 10. Это значит, что этот порт проассоциирован с 10-м Виланом. И когда какие-то кадры приходят на этом порту, мы говорим, мы в соответствии с командой Switchport access VLAN 10 назначаем VLAN ID 10-й на этот кадр, и дальше отправляем этот кадр на коммутацию по Вилану 10-му. Кадр отправляется, порт с 10-м Виланом проассоцирован, и, соответственно, 10-й коммутатор дальше принимает решение, что с этим кадром делать. Если у нас есть транк, мы говорим, на транковом порту у нас есть allowed VLAN 10-й и 20-й. Ну, значит, у нас вот 10-й и 20-й Виланы проассоцированы с этим интерфейсом. Трафик приходит с меткой 802.1Q10. Мы говорим, мы доверяем этой метке. Транковый порт отличается от аксессова тем, что он разрешает прием кадров с меткой и этим меткам доверяет. Вот он доверяет метке полученной, он выкидывает эту метку, восстанавливая оригинальный формат кадра, отправляет кадр на таблицу коммутации 10-го Вилана, то есть вот сюда вот, и дальше в таблице 10-го Вилана

поднимается решение, что с таким кадром делать. Но если вы видите кадр CDP-шный, CDP, он бегает без метки, и он бегает без метки не потому, что это на эти Вилана, а потому что этот кадр некоммутируемый. Он никогда не направляется на коммутацию ни 10-го, ни 20-го, ни 30-го, ни 1-го, ни 166-го, ни 4094 Вилана. Он направляется всегда на центральный процессор. И если вы видите, что у вас на порту включен режим Uni, у вас трафик CDP-шный на центральный процессор не направляется, потому что запрещено политикой. Но если вы хотите, чтобы у вас абонент фактически вот этот вот свитч и вот этот вот свитч чувствовали, что они соединены просто прямым проводом, чтобы вот эти вот свитчи просто прикидывались шлангом, в этом случае эти свитчи должны будут фарвардить кадры такие вот CDP-шные, LLDP-шные, что там еще бывает, Spanning 3. В этом случае вы можете сказать L2 Protocol Tunnel. Тогда такие кадры тоже будут оборачиваться заголовками, и такой кадр приходит,

там CDP-шный, и мы говорим, окей, мы направляем его на 10-й VLAN или там на 20-й VLAN. Мы коммутируем этот кадр по таблице того VLAN, который у нас там сказан. То есть мы вместо того, чтобы обрабатывать эти кадры как адресованные персонально нам, мы говорим, это кадр клиентский, мы на него навешиваем сервисную метку, мы его коммутируем по обычным правилам VLAN, сервисного VLAN, который у нас есть. Вот. Можно будет явно в виде указать, какие протоколы вы хотите коммутировать, то есть можно будет сказать, что коммутируется CDP, Spanning 3, LLDP, что там еще бывает? VTP, наверное, бывает, не помню. Spanning 3, CDP, LLDP точно можно. Вот. По умолчанию эта штука выключена. То есть по умолчанию CDP у вас на клиентских свечах работ не будет. То есть они не будут видеть никаких соседей. Если вы включаете L2 протокол Тану, то у вас вот эти два свеча начинают друг друга видеть по CDP. напрямую.

Если вы хотите включить 802.1 AD, то это делается немножечко иначе. То есть в логиках та же самая. С точки зрения как бы физики абсолютно тот же самый механизм будет работать. Вы точно так же на транке отправляете кадры с двумя метками. Точно так же вы можете сказать, что внешняя метка будет 88.8, внутренняя метка будет 8100, как то, что клиент проставил. Но настройка будет немножко отличаться. Если мы хотим работать с механизмом 802.1 AD, то он предполагает, что внешняя метка должна быть только 88.8.8. То есть не то, что мы берем метку 802.1 Q, но и искусственно ей переделываем Azure Type. Это именно 802.1 AD, который предусматривает, что меток будет ровно 2, и что внешняя метка будет 88.8. В этом случае транкви-порт точно так же настраивается в фифпорт-мод транк, и дальше указывается команда ethernet.1 AD NNI. Эта команда указывает, что на этом интерфейсе будут отправляться кадры с меткой 802.1 AD.

И что этот интерфейс, он фактически транк с точки зрения 802.1 AD. С точки зрения абонентского порта, который смотрит на клиент, то есть вот здесь вот мы говорим у нас NNI, а здесь у нас, соответственно, порт uni. Вот. С точки зрения абонентского порта мы указываем, опять же, ту же самую команду switchport.access.vlan.chivota, switchport.mod.access. Но здесь, если мы не укажем просто команду, которая здесь вот есть, ethernet, что-то там, uni-эспорт, то на этом порту не будет разрешен прием кадров с 802.1 Q метками. Но мы указываем ethernet.1 AD, uni-эспорт, и это значит, что мы получаем кадры на этом парке, и мы их разрешаем понимать с 802.1 Q метками. То есть они потом будут обернуты 802.1 AD, но проблем с 802.1 Q не будет. При этом мы не доверяем тем меткам 802.1 Q, которые будут получены. Мы говорим, что они будут коммутироваться по таблице 10 VLAN в любом случае.

S, который означает, что VLAN ID, который вы будете назначать на этот кадр, он в любом случае будет назначаться по правилам switchport.access VLAN. В нашем случае 10. То есть S, которые приходят на эту порту, кадры приходят, мы назначаем на них S VLAN. В принципе, в определенных ситуациях вы можете доверять 800 Q-шным VLAN, которые были получены на этом порту, и дальше обрабатывать это как-то по-особенному, но это обычно не требуется. То есть S-порт – это такой классический вариант, который в подавляющем большинстве случаев используется. Далее. Далее, далее. Если у нас есть 802.1 на D, то трафик, который приходит с метками двумя на роутер, тоже можно будет обрабатывать. Так же, как в случае с обычным транком, который 802.1 Q-шный у нас будет. У нас, например, свитч есть.

На этом свитче есть абоненты. И дальше мы смотрим на роутер, и мы хотим сказать, что вот на роутер надо принимать трафик нескольких разных VLAN-ов. Хотим принимать трафик. И 10-го VLAN-а, и 20-го VLAN-а, которые все приходят с разными метками. В случае с 802.1 AD ситуация тоже подобной бывает. То есть у нас есть какие-то абонентские порты, на которых сидят соседние коммутаторы абонентов, и, соответственно, есть трафик, который приходит с разными 802.1 Q-шными метками на наши провайдерские свитчи. Мы на них навешиваем еще одну метку 802.1 AD и направляем на роутер. На роутер приходят кадры с двумя метками. Внешняя метка – это наша провайдерская сервис, внутренняя метка – это наша провайдерская сервис. В некоторых ситуациях требуется роутеру залезать внутрь вот этих вот кадров, которые приходят, и обрабатывать содержимое, которое он будет там видеть. В какой ситуации это, очевидно, будет необходимо? Например, если у вас есть вот эти вот самые клиенты, и вы на клиента пригоняете, ну, например, два VLAN.

В одном VLAN у вас есть PPPOE, в другом VLAN у вас работает, там, не знаю, телевизор. В этом случае VLAN с телевизором вы просто отдельно мультикастовый VLAN делаете, и трафик, который приходит в этом самом телевизоре, вы пускаете на всех абонентов одинаковый. Да, у вас при этом как бы во всех, например, там, не знаю, в 123-х VLAN на всех клиентов будет пригоняться мультикастовый поток с телевизором. Кроме того, у вас там будет 345-й VLAN, в котором у всех абонентов будет PPPOE для доступа в интернет. И, кроме того, есть еще пачка VLAN, которые клиент может использовать для своего собственного взаимодействия. То есть у него есть две точки присутствия, где он хочет присутствовать, и вот он говорит, у меня вот здесь вот между этими двумя свечами будет бегать 802.1-киушный транк. Но помимо того, что там бегает 802.1-киушный транк, я хочу еще в двух специальных VLAN-ах получать трафик интернета, и трафик телевизора. Вот эту вот штуку мы можем сделать, но для того, чтобы это сделать, мы, понятное дело, не должны будем вмешиваться в клиентские VLAN-ы, в подавляющее большинство клиентских VLAN-ов, но мы должны будем вмешаться в VLAN-ы вот с телевизором и с интернетом.

Поэтому нам понадобится на порту роутера разобрать весь трафик, отобрать тот трафик, который приходит с двумя конкретными метками, внешне и внутренне, и с этим интерфейсом, с этим трафиком что-нибудь сделать. Нам потребуются точно такие же субинтерфейсы, как мы это делали раньше, только мы будем указывать команду encapsulation.1-q с указанием двух меток. Если мы хотим работать с iOS-XE, то в этом случае нам нужно будет сказать, что, возможно, метки, которые приходят внешне, будут не 802.1-киушные. То есть мы указываем команду .1-q tunneling ethertype 0x88A8. То есть внешняя метка, которая будет приходить, она будет кривая. 88A8 — это сервисная метка. Внутренняя метка уже будет, соответственно, нормальная 8100. И в этом случае мы говорим, что у нас есть вот родильский интерфейс, от него потребуется только то, чтобы он не был выключен. encapsulation .1-q 100 указывает на то, какой клиент у нас будет. И дальше second.1-q — это вторая метка, которая у нас будет.

Мы указываем пачку виланов, которые нас интересуют. Можно указать один вилан, можно указать диапазон виланов. То есть вот здесь мы указываем диапазон клиентских виланов с 2001 по 2100 и 3001, 30000. Можно указать вообще слово any. То есть если мы хотим во всех виланах, которые приходят от клиента, вести себя одинаковым образом. Ну, тоже иногда такое бывает интересно. Вот. В этом случае мы получаем субинтерфейсы, в которые отбирается нужный нам трафик. Мы на этих интерфейсах можем повесить IP-шники, можем не повесить IP-шники, можем дайло-профайл повесить. То есть мы можем сказать, что на этом интерфейсе у нас работает PPV-уэшный сервер. И вот с помощью такого нехитрого механизма сразу целую пачку интерфейсов можно будет настроить плюс-минус километр однотипно. В случае с XR нет возможности задать вторую метку вот таким широким диапазоном накрыть. То есть вы должны будете для каждого отдельного клиентского вилана использовать отдельные second.1q метки.

Но вы можете сделать, если у вас любые метки устроят, любые вот случайно .1ad100.1q any, вы можете в субинтерфейс отобрать трафик, у которого сервисная метка вот такая, а клиентская метка все равно какая. Но опять же, чаще всего для PPP-уэ используется. Вот. Такой вот механизм достаточно несложный. В принципе, похож на то, что мы видели с вами в CCNA. Позволяет нам с помощью вот этого механизма CISC отбирать трафик, который приходит в транке на роутере с указанием определенных меток. Еще одна штука, которую хочется рассказать про коммутацию, это то, что вы коммутацию не обязаны выполнять на настоящих коммутаторах. На самом деле, слово такое коммутация, оно ничего конкретно не означает. Оно означает, что что-то происходит. Если мы хотим подчеркнуть, что у нас происходит фарварзинг кадров Ethernet

на основе определенного набора правил, то нам более корректно будет утверждать, что это происходит не как коммутация, а как бриджинг на основе протокола 802.1D. Как мы уже говорили, бриджинг на основе 802.1D – это вот именно то самое правило. С одной стороны кадр приняли, на все остальные парты, кроме некоторых, копию кадров отправили. Это вот ровно то, что предусмотрено стандартом 802.1D. Сам стандарт в версиях, как мы помним, там есть 802.1D 90-го года, 802.1D 98-го года, 802.1D 2004-го года, помимо процедуры, помимо самой концепции бриджинга, предусматривает еще и указание, что в некоторые порты копии кадров отправлять не надо, например, если там будет сформирована петля. То есть любой бридж с точки зрения стандарта 802.1D должен уметь работать с SOSPANUG-3. Ну так вот, первые бриджи, которые появились, они не были коммутаторами в привычном нам смысле этого слова. Это были роутеры. И они могли перекладывать кадры на основе определенной логики. Те коммутаторы, которые мы видим сегодня, работают с той же самой логикой.

Просто они это делают немножко быстрее, чем самые первые роутеры, которые начали уметь это делать. Но по большому счету мы можем заставить и современные роутеры, которые классические роутеры, вести себя точно так же, как коммутаторы. Принимать кадры с одной стороны. И несмотря на то, что маки в этих кадрах будут проставлены не принадлежащие самим роутерам, заставлять эти роутеры перекладывать кадры дальше по все остальные порты, кроме некоторых. Безусловно, никогда не будут отправляться копии кадров в порт источника. Безусловно, никогда не будут отправляться копии кадров в заблокированные порты с помощью Spanning Tree. Ну, то есть все это сделать можно на роутере, на маршрутизируемых портах. Если говорить про циску обычную EOS или про EOS XE, то там эта штука немножко называется по-разному. То есть это в любом случае концепция называется routing and bridging. И есть на старых EOS'ах возможность включить классический bridging, то есть CRB, conventional bridging. И есть возможность включить на классических цисках bridge IRB.

Это integrated routing and bridging. Разница между ними заключается в том, что если вы включаете CRB, то у вас роутер превращается в чисто switch. То есть он может коммутировать кадр, но он при этом не может маршрутизировать то, что приходит в этих самых коммутированных портах. То есть вы либо то, либо другое. Если вы включаете IRB, то вы позволяете вашему роутеру фактически часть себя превратить в switch, но чтобы у вас был маршрутизируемый порт, смотрящий в этот самый виртуальный switch. Классический роутер, он выглядит вот таким вот образом. У нас есть железка, у нее есть какие-то порты, трафик приходит на определенных портах. Кадры, которые приходят на этих портах, они будут адресованы на определенный MAC. Соответственно, все, что приходит на наш собственный MAC, мы открываем. Видим там IP-пакет, дальше формально куда-то идти IP-пакеты в соответствии с логикой IP. То, как работает обычный роутер. И вот порты, которые будут вести себя в такой логике, часто называются L3-портами. Мы на таких портах кадры будем открывать только если они приходят на наш собственный MAC

или на MAC-адрес мультикастового потока, который нас интересует. Если у нас есть порт, который мы хотим, чтобы вел себя немножко иначе, соответственно, вот в этом случае мы порт переключаем в, ну, своего рода в L2-режим. Это некорректное обозначение L2-порт или L3-порт. Это просто устоявшиеся термины в отрасли, которые никакого отношения не имеют к уровню модели OSI. Так вот, если вы указываете, что у вас порт работает в L2-режиме, то в этом случае кадры, которые приходят на этом портоне, могут приходить на совершенно любые MAC. Может прийти MAC на MAC-адрес получателя, MAC-адрес B. И в этой ситуации, что у нас происходит? У нас обычный роутер скажет, это не мне адресован, я такой кадр просто читать не буду. А роутер со включенным бриджингом, он скажет, окей, не проблема. У меня есть внутри себя виртуальный свитч. Я все кадры, которые приходят на этом порту, фактически замыкаю на виртуальный свитч. А дальше виртуальный свитч ведет себя, как обычный нормальный свитч.

Он коммутирует эти кадры во все порты, кроме порта-источника, который у нас там есть на этом же роутере. Если мы хотим некоторые кадры маршрутизировать, то есть мы хотим сказать, что у нас и свой собственный MAC-адрес A тоже присутствует, и мы на него тоже кадры хотим обрабатывать, то мы должны вот некоторый виртуальный интерфейс подключить к вот этому самому виртуальному свитчу, который у нас имеется. На обычных коммутаторах это происходит, как мы создаем виртуальный интерфейс, который называется SVI, Switch Virtual Interface. Вот на роутерах тоже можно сделать такую штуку, что если мы роутер превращаем в свитч, то у нас есть виртуальный интерфейс, который смотрит в этот вот кусочек свитча. В терминах, соответственно, EOS обычного эта штука будет называться BVI, Bridge Virtual Interface. Если мы используем IRB, то мы можем и коммутировать трафик, и виртуальный BVI интерфейс тоже создать, который будет смотреть в созданный нами виртуальный широковещательный домен. Если вы включаете Bridge IRB, вот эта вот фича, просто сама фича включается,

сам роутер гипотетически может, если вдруг он будет настроен, превращаться в свитч некоторыми своими частями. Это не происходит никакое принципиальное новое взаимодействие от того, что вы ведете эту команду, это просто разрешается такая возможность. Дальше вы должны будете создать виртуальные широковещательные домены. Так же, как на свитчах мы делаем там VLAN 1, VLAN 2. Мы должны будем сказать, что у нас есть новый широковещательный домен, трафик которого наш роутер может обслуживать, наш виртуальный свитч может обслуживать. И мы указываем Bridge. Дальше указываем номер широковещательного домена. Это напрямую не связано с метками 802.1Q. То есть, еще раз подчеркну, здесь мы указываем просто номер широковещательного домена. Он может совпадать с метками 802.1Q, может не совпадать. Вы совершенно вправе сделать виртуальный широковещательный домен с номером, с идентификатором одним, а 802.1Q-шные метки, которые будут приходить в кадрах, которые будут обозначать, что трафик должен обрабатываться в соответствии с правилами виртуального широковещательного домена номер 1,

они будут совершенно другие. Но, опять же, будет удобно, если они будут совпадать. Но они не обязаны совпадать. Вот. И, соответственно, мы говорим. Вот у нас, например, первый VLAN есть. Мы его создаем. Bridge 1 — это то же самое, что VLAN 1. И указываем ключевое слово. Protocol IEEE. То есть IEEE. Это мы указываем, что в этом широковещательном домене работают правила коммутации 802.1D. И заодно, мы это неявно указываем, работает Spanning 3. Вы можете указать, что правила коммутации будут другие. То есть, в принципе, если вы захотите, гипотетически, вы можете указать, что у вас коммутатор будет работать как-то иначе. Не по 802.1D-шным правилам. Но, соответственно, это не то, что мы хотим в подавляющем большинстве случаев. Мы хотим работать именно с 802.1D-шной коммутацией, бриджингом. И, соответственно, мы запускаем там Spanning 3. Если мы хотим создавать вот этот самый BVI-интерфейс, то мы должны будем сказать Bridge 1, ну или виртуально широковещательный домен, который мы создаем,

Route IP. Если этого не сделать, то вот эти вот самые BVI-интерфейсы не будут получать трафик. Если вы скажете Route IP, то вы сможете создать интерфейс, который будет получать именно маршрутизируемый трафик, адресованный на сам роутер. Помимо того, что роутер сможет какими-то своими интерфейсами коммутировать трафик, он еще сможет и маршрутизировать трафик, который приходит на коммутируемых интерфейсах. Ну и вам нужно будет создать, собственно, те интерфейсы, которые вы отдадите на виртуальную коммутацию. Здесь есть нюанс. Вы можете в Bridge Group, то есть вот в этот самый широковещательный домен, запихать интерфейсы не только физические и Ethernet-овские. Вы можете взять и сказать, давайте мы создадим субинтерфейсы, и эти самые субинтерфейсы отдадим в широковещательный домен. Точно так же, как если у нас есть два свеча, которые соединены между собой 802.1Q-транком, и, соответственно, мы говорим, у нас есть кадры, которые приходят с меткой VLAN-а 10, другие кадры приходят с меткой VLAN-а 20. Фактически то, что происходит у нас на свече получателя, есть два виртуальных широковещательных домена,

10 и 20. У каждого из них есть свои отдельные правила коммутации. И трафик, который приходит с меткой 10, мы прочитали метку, выкинули метку, назначили VLAN-аиде этому кадру в соответствии с тем, что мы прочитали в этой метке. Мы поверили тому, что там есть однозначное соответствие, и прочитали метку 10.2.1Q-шную, назначили VLAN-аиде 10. Мы не обязаны это делать. Мы можем сказать, что если кадры приходят с меткой 802.1Q-а 1.2.3, мы назначаем VLAN-аиде 3.4.5. Такое можно сделать, на цисках можно сделать. Просто так никто не делает, потому что это неудобно. Та же самая история и с другим VLAN-ом. Вот мы приняли какой-то кадр с меткой 20-го VLAN-а, опять же, прочитали 802.1Q-шную метку, сказали, мы доверяем этой метке, мы назначаем VLAN-аиде кадру, случайно так получается, но равным тому, что в метке написано, и дальше коммутируем трафик по метке 20-го VLAN-а. Так вот, если вы включаете bridging на роутере, то это все то же самое будет происходить. У нас точно так же отправляются кадры от отправителя с разными метками,

но мы включаем на роутере функцию bridging, мы включаем 10-й bridge и 20-й bridge, и мы создаем субинтерфейсы для того, чтобы отбирать трафик 10-го и 20-го VLAN-а, точно так же, как мы это делали на нескольких слайдах до того. То есть мы говорим, что у нас есть субинтерфейс 10-й, субинтерфейс 20-й, на каждом из них encapsulation.1Q, там, допустим, 10 и 20, и загоняем каждый субинтерфейс в bridge-группу. На каждом субинтерфейсе, который смотрит в определенный широкопрещательный домен, мы указываем команду bridge-групп и дальше номер bridge-а, номер VLAN-а, если хотите. То есть если мы хотим сказать, что у нас есть два субинтерфейса на одном физическом интерфейсе, то мы делаем интерфейс, допустим, гигабит 0-0.100, encapsulation.1Q 100, и дальше bridge-групп, bridge-групп 100. Но номер VLAN-а совпадает с меткой.

Рядом точно так же создаем другой субинтерфейс, интерфейс gigabit 0-0.200, encapsulation.1Q 200, bridge-групп 200. Только надо предварительно создать сами бриджи, указать, что это бриджи нормальные 802.1D, и что в каждом из них мы, возможно, захотим маршрутизировать трафик. После чего в каждый из этих бриджей мы можем заглянуть и сделать BVI-интерфейсы, bridge-виртал интерфейс, который будет смотреть в виртуальный коммутатор так же, как смотрят свечи виртал интерфейс на свечах. На этот BVI-интерфейс можно повесить IP-шник, на этом интерфейсе есть MAC-адрес, и трафик, который будет приходить на этот самый MAC-адрес, проходящий через виртуальный свеч, он будет заворачиваться на центральный процессор, и центральный процессор будет думать, что он пришел через вот этот интерфейс BVI-1. Если мы хотим сделать то же самое на роутере с операционной системой Cisco EOS XE, то там это тоже называется интергрейт от роутинга бриджинг, но настройка будет происходить немножко иначе. Мы должны будем на интерфейсе сказать,

что у нас есть физический интерфейс, Gigabit Ethernet 0.0, но на этом интерфейсе мы не плодим виртуальные субинтерфейсы. Мы говорим, что трафик, который приходит на этом интерфейсе, мы заворачиваем в так называемый service instance. То есть мы указываем service instance, то есть Ethernet, мы говорим, что вот трафик, который приходит с некоторыми свойствами, будет обрабатываться по правилам сотого, ну, своего рода, бриджа, сотого широковещательного домена. Мы говорим, соответственно, что вот все, что приходит с вот таким вот набором правил, мы обрабатываем одним образом. Все, что приходит с другим набором правил, мы обрабатываем другим образом. Здесь есть следующие особенности. Первая особенность заключается в том, что у нас появляется три разных идентификатора. Первый идентификатор называется service instance. Это локально значимое число. Оно для той концепции, которая здесь на слайде показана, никакой роли не играет. То есть оно не обязано совпадать ни с чем. Вы можете просто сказать, что у вас есть одно число x,

а другое число, вот там, допустим, здесь y. И, ну, единственное, что вам нужно сделать, что это просто какой-то идентификатор был того, что вот у нас некоторые кадры обрабатываются одним образом, а некоторые кадры другим образом. Здесь делаем номер 100, здесь делаем номер 200. Единственное, что от этих двух чисел требуется, чтобы они не совпадали. Далее вы указываете, что в каждый сервис instance вы отбираете трафик с определенными метками 802.1q. Привычная команда для субинтерфейса, encapsulation.1q100, отбирает трафик с метками 802.1q, с номером 100, с номером VLAN. Если мы хотим отбирать трафик неутегированный, то мы указываем encapsulation.ntaget. Немножко, опять же, изменения по сравнению с синтексисом привычным нам с субинтерфейсов. И, наконец, мы должны будем сказать, куда мы засовываем трафик, который пришел с указанными метками. То есть, если мы хотим сказать, что у нас 802.1q на кадре приходит, вы, наверное, прочитали там сотую метку, мы должны сказать, трафик с такими метками мы коммутируем

по таблице такого-то VLAN. Вот для этого у нас есть команда bridge domain, и дальше мы указываем номер домена. Номер домена — это фактически номер VLAN. И есть еще один нюанс, который заключается в том, что если вы делаете субинтерфейсы на обычном IOS, у вас при отборе трафика в субинтерфейс, когда вы указываете encapsulation.ntaget.ntg чего-нибудь, заголовок 802.ntg при этом срезается. То есть, когда вот здесь вот, здесь вот мы сделали encapsulation.ntg.ntg 100, bridge group 100, трафик, который идет на bridge, он уже не содержит 802.ntg метку. Мы восстановили оригинальное содержимое кадра. То есть, к нам приходит кадр с меткой, вот здесь вот мы в момент получения кадра метку срезаем и направляем трафик на виртуальный интерфейс уже без метки 802.ntg, уже в том виде, в котором оригинальный кадр шел. Если мы работаем на IOS XE, то когда мы отбираем трафик в service instance, даже если мы указываем encapsulation.ntg 100, метка при этом не срезается.

То есть, фактически, вы говорите, мы сейчас будем коммутировать кадр, и у него все еще есть 802.ntg метка, мы ее не выкинули. Это особенности IOS XE. Если вы хотите коммутировать кадр в сторону какого-то получателя, но коммутировать все-таки, приведя этот кадр в оригинальное состояние, вы должны эту метку выкинуть ручками. По умолчанию IOS XE этого не делает. В случае, если вы работаете с untagget кадрами, то это не требуется делать, там ничего не надо выкидывать, там кадр и так свой нормальный вид имеет. А если вы хотите, например, сделать что-то типа, вот у вас есть роутер, он с одной стороны принимает кадры, там, допустим, с меткой сотой, и вы хотите отправлять эти кадры дальше в виде native encapsulation, то вы должны будете здесь создать, ну, типа switch, да, типа VLAN сотой. Вы должны будете трафик отобрать в этот самый сотый VLAN, и вы должны будете выкинуть метку. То есть вы не должны будете кадр в том виде, в котором он к вам пришел, дальше присылать. Вы должны будете его модифицировать. Вы должны будете выкинуть метку. EOS XE по умолчанию это сам не делает.

Это надо сделать ручками. И команда будет rewrite, ingress tag, дальше вы указываете, убираете одну метку сверху. Это 802.1Q-шная метка. Ну и слово symmetric, оно будет полезно в некоторых сценариях для того, чтобы, для того, чтобы, да, чтобы обратный трафик вернуть с меткой сотой. То есть чтобы трафик, который шел обратно, он бы назначал напротив эту метку. Вот. Соответственно, если вы такое сделали, то у вас есть, ну вот здесь вот у нас один сервис instance сотый, другой сервис instance двух сотый. Трафик, который приходит с меткой 802.1Q-шной сотой, мы отправляем по таблице коммутации сотого VLAN. Трафик, который приходит без метки, просто обычный кадр Ethernet, мы коммутируем по таблице двух сотого VLAN, ну как обычный native VLAN. И, соответственно, для каждого из этих виртуальных широковещательных доменов у нас тоже так же, как и в случае с обычным Windows, есть возможность загнуть внутрь и сделать маршрутизируемый интерфейс,

который будет смотреть в эти широковещательные домены. Эта штука будет называться не BVI, а BDI, Bridge Domain Interface. Точно так же мы указываем BDI, дальше номер бриджа, и у нас получается интерфейс, который смотрит в широковещательный домен. На него можно повесить no shutdown, можно повесить IP-шник, можно повесить service policy, можно повесить access-листы. То есть, ну, обычный интерфейс, который обычный IP-шный интерфейс. Ничего с ним интересного нет. Вот. Такая вот штука. Если говорить про iOS XR, на нем тоже такая штука есть, но она сильно сложнее выглядит. То есть вот для того, чтобы просто обычный бриджинг сделать между там несколькими интерфейсами, придется вот такую простыню ввести. На экзамене, естественно, от вас ничего этого не потребует вводить. Я просто для справки вам показываю, что оно вот такое вот бывает. Вот. Соответственно, что здесь можно будет заметить? Первое. У нас можно будет создать точно так же интерфейсы,

которые смотрят в определенный широковещательный домен. То есть если у нас есть, допустим, бридж 1, то вот интерфейс, который смотрит на бридж 1, он выглядит точно так же, как в обычном iOS. Все. Но нам нужно будет создать эти самые бриджи несколько хитрым образом. Нам будет нужно создать сначала бридж-группу. Это, ну, просто некая виртуальная сущность. В этой бридж-группе надо будет создать бридж сам. И этот бридж создается не по номеру. У него есть специальное название. И это название, вот BD, допустим, 1, оно никакого отношения к номеру VLAN ничего не имеет. Он просто название. Дальше внутрь этого бриджа вы должны будете запихать интерфейсы, которые у вас есть. Можно запихивать физические интерфейсы, можно запихивать субинтерфейсы, так же, как на обычном iOS. И вы в этот же бридж запихиваете routed interface BVI1, то есть тот самый BVI1, который у вас здесь вот создан. То есть вы сначала создаете виртуальный интерфейс, который потом когда-нибудь будет смотреть в бридж, неважно какой, и вы даете ему номер. На обычном iOS вот этот номер совпадает с номером VLAN,

если хотите, с номером бриджа. А здесь он просто номерованный. И вы в конкретный бридж запихиваете номер виртуального интерфейса BVI. Для того, чтобы в интерфейсе вы могли обрабатывать трафик, который будет коммутируемый, вам нужно будет на этом интерфейсе немножко поменять настройки по отношению к обычным настройкам L3 на интерфейсе. Вам нужно будет запустить на интерфейсе команду после названия интерфейса L2 transport. То есть вы указываете интерфейс gigabit.net, 0.0.0.2, L2 transport. Вы тем самым переводите интерфейс в типов коммутируемый режим. Это что-то аналогичное тому, что на свитче можно сделать команду switchport на iOS-овском свитче. Но это не аналог, это что-то похожее. Вы фактически на этом интерфейсе тем самым разрешаете использовать сервисы, которые называются L2 VPN. И, соответственно, вот создание бридж-группы, оно происходит на самом деле в контексте L2 VPN. Есть нюанс. Вообще-то в подавляющем большинстве случаев

вот эта вот штука L2 VPN предполагает, что у вас есть MPLS. И вообще-то в подавляющем большинстве случаев вы вот эти вот бриджи будете создавать с виртуальными туннелями, которые будут строиться через MPLS-ную сеть с другими точками присутствия. И вообще-то в реальном мире концепция вот этих L2 VPN-ов, она будет намного сложнее, чем вот здесь на слайде показано. То есть на слайде уже минималистичная конфигурация, настолько, насколько это возможно. Вы сначала должны будете перевести ваши интерфейсы в режим L2 VPN. Потом вы будете в рамках службы L2 VPN настраивать бриджи и запихивать в них интерфейсы. И если вы хотите работать с метками 802.1-кьюшными, то вам точно так же, как на EOS XE, нужно будет сказать, что на субинтерфейсе вот таком-то мы подключаем функции бриджинга, мы отбираем в этот субинтерфейс метки, ну, кадры с определенными метками, и мы точно так же, как в EOS XE, должны будем с этими самыми метками что-то делать. То есть метки должны будем переписывать, добавлять, удалять вручную. Автоматически роутер за нас этого делать не будет.

EOS обычный за нас автоматически все делает. EOS XR и EOS XE автоматически метки не добавляет, не удаляет. Их нужно добавлять ручками. Вот. Если маршрутизатор принимает на таком интерфейсе какой-то кусочек данных, ну, назовем это кадр, то он обрабатывает этот кадр не в соответствии с правилами IP, то есть он не смотрит, на какой MAC-адрес оно пришло, проверяет, не на свой ли MAC-адрес, например, дальше открывает, если на свой, то дальше направляет на таблицу маршрутизации. В случае, если мы включили на интерфейсе функции L2-транспорт, у нас начинают работать правила коммутации. То есть такой кадр начинает разбрасываться во все возможные интерфейсы. Ну, например, вот в нашем бридж-домене BD1 у нас есть четыре интерфейса. Интерфейс вот такой, интерфейс вот сякой, вот пятый, и вот первый, второй, третий, четвертый. Четыре интерфейса. Это фактически все равно, что у нас на роутере запущен свитч, у которого четыре интерфейса есть.

Один интерфейс в нашем случае 0.0.0.100, другой 0.0.0.1.200, третий 0.0.0.2. Физический интерфейс, и четвертый BVI1. Вот это вот BVI1, виртуальный интерфейс. Его не видно глазками, но он есть. Этот интерфейс там 0.0.0.2, этот 0.0.0.1.100, этот 0.0.0.1.200, этот 0.0.0.0.100. Ну, то есть вот как-то так это и выглядит. Если мы включаем полноценный L2 VPN, то, я еще раз подчеркну, там на самом деле все усложнится, потому что будут еще дополнительно в этот же интерфейс, в этот же Bridge Domain заноситься еще виртуальный интерфейс, который смотрят в туннеле. Но, да, мы сейчас это трогать не будем, а то совсем закопаемся. Давайте попробуем понастраивать чего-нибудь. Понастраиваем сначала простые транки, потом 802.1.q, потом 802.1.ad, ну и попробуем вот этот самый bridging на роутере тоже настроить, посмотреть, что там получится.

Итак, у нас есть сейчас несколько железок, с которыми мы работаем. Есть роутер на основе операционной системы XE, есть роутер на основе операционной системы XR, и есть роутер и свитч на основе операционных систем EUS обычной. Давайте с вами предположим, что транки вы с CCNA настраивать умеете, то есть обычные транки, и, соответственно, что в 802.1.ad-шные транки, вы поверите мне, что их можно настроить на железо, потому что дело в том, что наши свитчи 802.1.ad не поддерживают. То есть мы можем использовать QNQ, но это будет просто самый банальный транк, на котором мы просто указываем команду .1, да, сейчас как там, switchport trunk encapsulation 88 x8. Если мы говорим про настройку 802.1.ad на роутерах, то здесь мы уже как раз можем все понастраивать, и в этом случае мы можем настроить транк на роутере,

и у нас сейчас как раз есть два роутера. Это роутер на основе операционной системы XE, это CSR1000V, и роутер на основе операционной системы Cisco EUS XR. Это, соответственно, наши привычные наши железочки. Они друг на друга смотрят интерфейсами. Я сейчас уже включил CDP, и могу вам показать, что у CDP Neighbors роутер XE с XR видится за интерфейсом гигабит 0000. Роутер XR для XE виден за портом гигабит 1. То есть у нас гигабит 1 порт XE смотрит на гигабит 0000 порт роутера XR. Пожалуйста, включите их. То есть это нужно будет сделать следующим образом. Заходим в режим конфигура терминала на XR. Указываем интерфейс гигабит 0000. No shutdown. И commit. У меня этот интерфейс уже включен, поэтому у меня не пробегает сообщение диагностически.

У вас должно пробежать сообщение, что интерфейс включился. CDP у вас, если не включали вы, то возможность соседей видно не будет, потому что по умолчанию на провайдерских роутерах CDP выключен. Я его прямо в явном виде включал. Но тем не менее, если вы включаете интерфейс на роутере XR, то вот он примерно так и включается. Я верю, что вы интерфейс на роутере XE, гигабит 1, сможете включить самостоятельно. Но на всякий случай, .t, интерфейс гигабит 1, no shut. Тем самым мы включаем связь между двумя роутерами. У нас есть два интерфейса, которые друг на друга смотрят практически прямым проводом. И на этих интерфейсах мы сейчас можем сделать транки. Если мы хотим создать обычный 802.1Q-шный транк, то для этого нам потребуется следующее действие. Указываем, что у нас есть интер... Давайте с XE начнем. Интерфейс гигабит 1. Дальше мы указываем через точку номер субинтерфейса. Я сейчас нахожусь в субконтексте настройки интерфейса,

поэтому мне справка здесь не показывается. Допустим, я сделаю интерфейс гигабита 1.100. Это физический интерфейс гигабит 1. На нем субинтерфейс номер 100. Этих самых субинтерфейсов можно наплодить много. И я на него отбираю трафик, который... На этот субинтерфейс сотый я отбираю трафик, который по родительскому интерфейсу приходит с меткой 802.1Q-шного VLAN номер 100. In Capsulation. .1Q. На этом интерфейсе не требуется делать команду shutdown. Он так поднимается всегда включенный. Но, соответственно, на всякий случай, no shot, просто по привычке я его делаю. Далее. На этом интерфейсе мы можем повесить IP-адреса. То есть IP-адрес... Давайте сделаем там 10.100.1. Не знаю, 1.

255.255.255.0. У нас есть один интерфейс с метками 802.1Q-100. И мы сначала прописываем инкапсуляцию, потом прописываем IP-адрес. Если мы сначала сделаем IP-адрес, система будет ругаться. Вот я сейчас сделаю еще один субинтерфейс. Вы тоже у себя делаете. Сделаем в итоге два интерфейса. И я на нем сначала пропишу IP-шник, а потом попытаюсь сначала прописать IP-шник, потом назначить инкапсуляцию. Мне это сделать не удастся. Система будет ругаться и говорит, что сначала прописываются метки, а потом прописываются IP-шники. Интерфейс гигабит 1.200. Инкапсуляция.1Q-200. Я обещал сначала IP-шник. Так. 10.200.201. И система говорит, что так сделать не получится. То есть можно назначить IP-адрес, только если у нас уже прописан инкапсуляция чего-нибудь. Ну вот прописываем инкапсуляция.1Q чего-нибудь.

И только после этого IP-шник уже поменяется. Со стороны роутера XR нужно будет сделать ответные действия, и они, в принципе, будут достаточно похожи. То есть если мы говорим, что у нас есть роутер с операционной системой EOS XR, то мы на нем делаем интерфейсы точно так же. Интерфейс гигабит 0.00.0.100. На него отбираем трафик. И вот инкапсуляция. Дальше здесь мы указываем либо .1Q, либо .1AD, если у нас транк будет 802.1AD. Ну, у нас .1Q. И указываем номер VLAN-а 100. Как видно, здесь справка не дает повесить native. То есть мы не можем сказать, что давайте отбирать на этот субинтерфейс трафик и с меткой сотов VLAN-а, и без метки вообще. Там, где справка CISC предписывает указать вот такую конструкцию, она у нас не применяется. Система говорит, что это некорректный ввод. Ну, мы указываем .1Q 100 просто без ничего. Если мы хотим использовать .1Q 100 метки

и потом сказать, что у нас есть транк QNQ, фирменный CISC, где натурально две Q метки идут одна за одной, можно после указания первой метки сказать, что будет еще и вторая, second .1Q. Но чаще всего все-таки в провайдерских сценариях используется не .1Q и потом еще раз .1Q, а .1AD и потом еще раз .1AD. Формат у них, как понятно, одинаковый, только EtherType у 802.1ADшной метки будет 88A8. Ну, вот в нашем случае мы сделали субинтерфейс, отобрали в него трайв к сотов VLAN-а и вешаем на него IP-шник. IP-адрес 101001002255255255. В принципе, все равно, какой VLAN вы используете, все равно, какой IP-адрес вы используете. Роутеры сейчас пока не осведены в единую сеть, и мы, в принципе, можем любые адреса вешать, какие нам захочется. Так. Ну и давайте другой субинтерфейс создадим.

Двухсотый. Скажем тоже, что там у нас есть IP-адрес. 210.200.202. Система принимает ввод IP-шника, несмотря на то, что мы encapsulation.1Q200 не задали. То есть то, где EOS обычный и EOS XE ругается, EOS XR не ругается. Дело в том, что фактическое назначение этого IP-шника не происходит. Оно происходит только тогда, когда мы commit сделаем. И вот если я сейчас попытаюсь commit сделать, система ругнется. Она скажет, что не назначен на субинтерфейсе, не назначен на интерфейсе encapsulation.1Q или что-либо еще. То есть некорректная настройка. Смотри, не заругался. Ну, вообще должен был бы, по идее. Очень непонятно, какой трафик туда отбирать. Вот. Ну, у нас есть два субинтерфейса, на которых есть IP-шники. На родительском интерфейсе никакие настройки не заданы. На субинтерфейсах заданы IP-адреса,

и эти адреса будут у нас пиндиться. PING 10.100.100.1. А, фокус не удался, факир был пьян. Так, может, с другой стороны? Да я вроде сделал везде no-shot. Так, show run. Ну, на всякий случай, так, конечно, нехорошо делать, но интерфейс gigabit 0.0. работает, все работает, все вроде корректно. CDP работает, а IP что-то как-то не очень. Подозрительно это. Ну, давайте с другой стороны проверим. PING 10.100.100.2. Из другой стороны что-то не очень.

Что такое может быть? Так, может, они у нас в VRF разных. Ну-ка, show CDP detail. Так, он показывает, что у нас менеджмент адресов на нем нет. Что-то где-то я прошляпил, видимо. Перепутал интерфейс? Да вроде не перепутал. Интерфейс 0.0.0. Show CDP neighbors. Gigabit 0.0.0. Так. После повторения эксперимента выяснилось, да, что у нас трафик от XE-шного роутера уходит, но не возвращается на него обратно. И пакеты ARPA от него уходят, пакеты ARPA на него ответные приходят,

но, соответственно, XE-роутер их почему-то не читает. В дебаге ничего не видно. В то же время на VEUS, если мы поднимаем конфигурацию точно такую же, то есть у нас там интерфейс Gigabit 0.0.0. Мы на него вешаем на shutdown и поверх него создаем два субинтерфейса. Gigabit 0.0.100, Gigabit 0.0.200. Сейчас отдельно сделаем. Интерфейс Gigabit 0.0.200. Incapsulation.1.q200. IP адрес 10.200. 255, 255, 255. Вот у нас есть два субинтерфейса. На обоих на них есть IP адреса. Оба они формируют connected сеть. Show IP road. У нас появляются два маршрута. Два connected маршрута. На двух разных субинтерфейсах. На EOS обычном и на EOS XR. Show IP road.

Тоже здесь все есть. У нас connected маршрута. Один и второй. И, соответственно, все пинги пингаются. Ping 10.100.100.3. В моем случае. Вот они пингаются. 10.200. тоже будет пингаться. 3. Так. Это у меня сейчас Vrshark показывает не тот интерфейс. Я сейчас вам правильный Vrshark покажу. На Capture. Вот. Сейчас запускаю снова пинги. И пинги здесь у нас вот они показываются. Пинги пингаются. Причем инкапсуляция действительно происходит. Два роутера друг на друга смотрят транком. Используется 802.1Q-шные заголовки. Внутри лежит IPV4 вложение. И дальше уже просто обычные пакеты там бегают. Вот. Если мы захотим включить 802.1Q&Q,

то нам потребуется абсолютно аналогично сделать субинтерфейсы, которые будут иметь просто две метки. И у нас будут отправляться пакеты, которые будут использовать и внешнюю метку, и внутреннюю. Ну, опять же, мы можем это сделать сравнительно легко. Conf T интерфейс гигабит 0 дробь 0, дробь 0, дробь, не знаю, 0.300. И мы указываем, что encapsulation .1AD не знаю, 100 и .1Q не знаю, 123. В этот интерфейс будет отбираться трафик с двумя метками и отправляться. Трафик с этого субинтерфейса тоже будет с двумя метками. IP-адрес 10.123.123.2 255.255.0 Неважно, какие IP-шники будут,

мне сейчас лень настраивать второй субинтерфейс на другом роутере, но do ping 10.123.123.3. Мы сейчас должны увидеть ARP. Вот он ARP бегает и у него двойной заголовок. Снаружи 802.1AD причем, а, вот мы видим, кстати, что у него 81.00 почему-то вложение. Так. Интересно, те вкипляшут. Да, 81.00. Как-то подозрительно это. Вот. И внутри... Не-не-не-не, я ошибся, извините, да, я ошибся, не туда посмотрел. Вот он, 88.00. Это указание на то, что внутри лежит

в кадре Ethernet. То есть у самого кадра Ethernet первый самый Ethertype фактически относится к заголовку MAC, то есть он за пределами MAC Client Data, и вот он, QNQ 88.00. Дальше после него лежит 4 байта следующие. Вот эти вот 2 байта фактически относились к оригинальному кадру, но они указывают на то, что лежит конкретно внутри этого заголовка 802.1.ad. То есть 88.00 указывает на то, что дальше у нас 802.1.ad, дальше 81.00 указывает на то, что дальше 802.1.q, и 0.8.06 указывает на то, что дальше за ним лежит ARP. Если бы вдруг мы настраивали ответную часть, то с другой стороны мы могли бы настроить в принципе точно такой же интерфейс, на него сказать тоже отбираем трафик 802.1.ad. с дополнительной меткой 802.1.q, точно так же там бы пинге пингались. Если мы бы хотели настроить связь между нашим роутером 802.1.ad. шным транком

смотреть в некую среду, а со свеча принимать транк 802.1.ad. и дальше коммутировать трафик по каким-то своим соображениям, но в принципе тоже у нас такая возможность могла бы быть. Мы сейчас на свече можем посмотреть, как именно это может выглядеть. Я честно говоря не уверен, что он поддерживает наш свеч, но попробовать можно. Copsulation, в смысле enable, conft, интерфейс gigabit 0.0, switch port mode trunk, он предупреждает, что надо сначала сказать, какой trunk, switch port trunk, encapsulation.1.q, switch port mode trunk. и дальше мы можем сказать, что либо мы используем схему qnq, то есть именно qnq цисковский, когда именно натурально две qnq метки используются, либо мы используем 802.1.ad. Вот с некоторой вероятностью 802.1.ad у нас dot1.ad.

ad. О, смотрите, поддерживается NNE. Вот же прикольно. так, со стороны абонентских портов у нас интерфейс будет какой-нибудь, не знаю, gigabit 0.1. Мы указываем, что у нас switch port node access, switch port access vlan, не знаю, какой-нибудь сотый, сотого vlan у нас нет, нам его создают, но сейчас в таком положении он будет использовать сотый vlan на самом switch нам на самом деле это не нужно было, нам нужно было сказать ethernet dot1.ad uni s port и тем самым мы говорим, что наш switch не будет использовать сотый vlan наш, он будет, точнее, будет использовать сотый vlan наш, но он будет дальше приходящие кадры на этом порту, несмотря на то,

что они, возможно, приходят с меткой, дальше обрабатывать в соответствии с логикой сотого vlan, и дальше, если он будет отправлять этот в транк 802.1.ad, он будет дополнительно к тому, что приходит в кадре, еще и сотый vlan тоже делать, и этот сотый vlan будет указываться с 88.a.8 меткой. Какой в этом случае нужно будет использовать mtu на свече и на роутере? На роутере, если мне память не изменяет, там автоматически назначается правильный уже mtu, то есть сейчас надо проверить момент, хороший на самом деле вопрос, show, show, show, show, интерфейс, gigabit 0, drop, 0, drop, 0, drop, 0, mtu, да, здесь mtu 1514 байт, на самом деле заголовки без учета чексумы, мы здесь должны будем дополнительно к вот этим вот 1514 байтам добавить еще сверху 8 байт. У нас будет

использоваться 2 802 одинкиюшные метки, и мы должны будем показать, что у нас mtu тут будет с запасом 8 байт. conft, интерфейс, gigabit 0, 0, 0, mtu, что у нас тут получается, 1526, то есть вот с запасом относительно того, что у нас получается, 1526 это две метки заведомо туда влезают. Commit. На интерфейсах с вот этими вот на субинтерфейсах с указанием encapsulation дополнительно mtu прописывать не нужно. Там ограничения фактически наследуются от родительского интерфейса. Что касается show interface сейчас, вот он у нас теперь

подрос, стал 1526 байт. Если мы возьмем допустим сотый субинтерфейс, вот у него mtu тоже подрос. Так. Ха-ха-ха-ха. 300. Слушайте, я вам наврал. Не надо было там mtu прописывать, он автоматически подстроился. Я привык на обычных ciscoх, надо подстраивать. Здесь автоматически все. То есть я меняю mtu на родительском интерфейсе, я указываю размер нормального кадра, cisco сама уже дополнительно на роутерах xr автоматически подстраивает размер mtu, на дочерних субинтерфейсах. То есть здесь мы включили размер кадра, получается 1534 байта, с учетом того, что у нас размер кадра на родительском интерфейсе, который вмещает в себя нормальное вложение, может быть 1530 байт с учетом заголовков. То есть вот это 1526 байт на родительском интерфейсе,

на субинтерфейсе с одним виланным заголовком 1530 байт, на субинтерфейсе с двумя заголовками cisco сама сумела посчитать, показывает 1534 байта. В принципе, не будет большой ошибки, если вы повключаете МТУ с запасом на своих транзитных раутерах. В принципе, это не будет в большинстве случаев ни на что влиять. За редким исключением, если вдруг вы, например, по USPF будете дружить, он вам в этом случае будет ругаться и говорить, что у вас МТУ какой-то кривой не совпадает. Ну, да, тогда надо будет аккуратно посмотреть, какой МТУ должен быть правильней. на транзитных железках провайдерских в принципе, хорошей практике будет иметь как раз задранный МТУ, чтобы у вас запасов его хватало, чтобы в любом случае, если пользователь к вам присылает пакет нормального размера, чтобы там вы не навесили одну метку 802.1Q, две метки 802.1Q, одну метку MPLS, две метки, три метки, четыре метки MPLS, а для MPLS нормальная ситуация будет, когда у вас там три-четыре метки, чтобы у вас все это дело пролезало в любом случае.

Поэтому с запасом здесь, в принципе, вполне нормальной практикой будет использовать. Так, что касается IOS обычного, вот на нем точно имеет смысл уже МТУ посмотреть, show интерфейс gigabit 0, дробь 0, физический интерфейс, МТУ 1500 байт, одну метку он автоматически добавляет. Если мы смотрим gigabit 0, 0, сотый, у него тоже, соответственно, размер содержимого с учетом одной метки, он знает, что одну метку использует, вот одну метку он нормально посчитал, 1500 байт вложения плюс 4 байта метки, плюс все, что необходимо, соответственно, все это корректно обрабатывается. На свече, да, на свече это через System2 делается, то есть, как взять, System2, он такой не умеет, наш свеч слишком умный, у него это все делается

на интерфейсах, интерфейс, gigabit 0, 0, вот, у него есть команда МТУ, на младшеньких свечах команды МТУ нету, на этом есть, то есть мы можем сказать, что кадры на этом интерфейсе имеют свои собственные ограничения, не какие-то глобальные системы, а вот именно на уровне отдельного интерфейса каждый. В большинстве случаев, если мы говорим про маленькие, младшенькие свечики, вы не можете рулить отдельно МТУ на интерфейсе, вы можете менять только глобальный МТУ систем, МТУ систем, МТУ джамбо. Но вот, если у вас достаточно нормальный свеч, начиная с четырех тонников каталистов, кажется, и на всех старших МЕшных свечах вы можете рулить МТУ на интерфейсе. Еще раз подчеркну, хорошая практика будет на провайдерских железках в любом случае МТУ задирать. Не надо задирать его сильно, но задирайте его так, чтобы в любом случае туда пролезло какое-то разумное количество байт дополнительных заголовков. У вас может быть

в случае, если вы используете Mac and Mac, там лишние 20 байт заголовка. В случае, если вы используете MPLS, лишние 12 байт заголовка. При метке по 4 байта норма совершенно. Если вы используете 802.1Q или 802.1AD, у вас будет там 8 байт заголовка. Где-то это все само посчитается, где-то не посчитается. Поэтому проще сказать, давайте добавим 50 байт, сделаем там 1550 МТУ, этого запасом хватит. А в ситуации, когда у нас будет использоваться там, допустим, тот же самый OSPF, ну, используем команду IPMTU, которая указывает ограничения на размер IP пакетов, отправляемых через этот интерфейс. И если мы будем работать именно с OSPF, он берет, принимает во внимание именно настройку IPMTU. Что у вас там на уровне кадров, какие ограничения сверху заданы, по OSPF по большому счету все равно. Если вы не задаете IPMTU, то в этом случае OSPF пытается угадать его. И он пытается посчитать, что там вы задаете на канальном уровне, какие ограничения, какие влезают туда IP пакеты,

и он вычисляет значение IPMTU из настройки канального уровня. Но если вы все правильно делаете, вы делаете M2U1 на интерфейсе, не знаю, 1600 байт, вы тем самым разрешаете кадры до 1600 байт с содержимым в обычном OSPF. Рядышком указываете M2U1 на интерфейсе. M2U1 на интерфейсе. M2U1 на интерфейсе. Так, ну, этот свитч, понятное дело, на нем такой нельзя сделать. На роутере интерфейс, там, Gigabit 0.100, IPMTU 1500. Вот. И на роутерах вы будете отправлять IP пакеты не больше, чем 1500 байт размером. Вот это вот корректная настройка. Когда свитчи у вас не препятствуют forwarding больших кадров, а IP пакеты при этом обрабатывают столько разумного, стандартного 1500 байтового размера. Так, это что касалось 802.1Q-шных транков на роутерах. Еще у нас был слайд про BVI. BVI, BDI и прочее. Я, честно говоря,

не знаю, как вам показать BDI, учитывая, что наши роутеры CSR как-то козлят. Но давайте посмотрим, как это делается на обычных iOS-ах через вот эти, например, два особо интерфейса, которые у нас есть. Первое, что нужно будет сделать на роутере для того, чтобы роутер превратить в немножко switch. Делаем bridge IRB. Здесь есть вариант обычный, то есть, ну, правильный bridging IRB, который и роутить, и forwardить кадры может одновременно. То есть, forwardить чужие кадры через концепцию bridging, и часть кадров забирает на себя, потому что часть кадров будет адресована в этом бридже персонально ему, забирает их на виртуальный интерфейс BVI и дальше роутит то, что пришло по таблице маршрутизации. Bridge IRB. Это единственный вариант, который доступен сегодня. Все остальное, это придание старинно глубокой, не надо так делать. Дальше. Указываем, что у нас есть VLAN. Ну, не VLAN в смысле, но метка 802.1Q, а VLAN в смысле отдельный обособленный широковещательный

домен. Bridge, ну, например, там, не знаю, 100. Может он совпадать с меткой VLAN, может не совпадать. И мы должны будем указать два поля в настройке бриджа. Первое. Какой бридж? Фактически 802.1Q, 802.1AD-шный. Rotocall и E.E.E. Здесь можно проулить немножко этим, сказать, что у нас поддерживаются кривые всякие бриджи. Вот. Ну, это единственный вариант, который нас интересует E.E. Затем указываем bridge 100 root IP, что мы часть IP-шных пакетов из этого бриджа забираем на BVI-интерфейс. И фактически это все, то есть с точки зрения самого виртуального свеча, вот все, что нужно было сделать, мы сделали. Дальше в этот свеч надо запихать интерфейсы. Идем в настроек интерфейсов. Интерфейс gigabit 0 drop 0.100 и говорим этот интерфейс переходит в владение бриджа.

Bridge group 1. А, ну, 100 у нас. При этом настройки с него IP-шные, по идее, должны больше не применяться. Если мы хотим еще какой-нибудь интерфейс туда запихать вести, то то же самое делаем. Запихиваем его в сотый бридж. Обратите внимание, сейчас мы забриджевали два субинтерфейса, на которые приходит трафик и отправляется трафик с разными 802.1 кьюшными метками. То есть кадры, которые приходят на нашем интерфейсе с сотым виланом, они будут коммутироваться обратно в сотый вилан. Например, если у нас кадр пойдет сейчас широковещательный с меткой сотого вилана дойдет до нашего роутера, он обратно через наш же интерфейс, через тот же самый гигабит 00 выплюнется обратно, но с меткой двухсотого вилана. Давайте попробуем, я вам покажу это прямо в этом самом в в Airshark.

Так, пинога 10, 100, 100, не знаю, 5. Я сейчас должен буду увидеть ARP. Так, и я хочу, давайте остановим это все, я хочу убедиться, что у нас есть метки. Так, вот сотая метка, ARP запрос, сотая метка, сотая метка, сотая метка, нет, фокус не удался, факер был пьян, везде сотая метка стоит. Смысл заключается в том, что сейчас наш роутер ведет себя как свитч, да, и у нас кадры, которые приходят через интерфейс вот этот, отправляются обратно через интерфейс вот этот, но у нас на этих субинтерфейсах сейчас прописаны в виланной метке. Соответственно, все, что приходит через интерфейс вот этот,

оно приходит с меткой сотого вилана, все, что выходит с вот этого интерфейса, оно выходит с меткой двухсотого вилана. При этом оно реально коммутируется между собой. Поэтому очень важно понимать, что метка, которую вы отправляете в 802.1Q с номером вилана фактически никакой связи не имеет. Когда вы отправляете кадр с меткой, эта метка стирается в момент получения кадра в подавляющем большинстве случаев, но перед смертью эта метка отправляет сообщение свечу или роутеру, пожалуйста, коммутируй меня по такой-то таблице. Когда мы создаем транковый интерфейс, мы говорим доверять тому, что приходит в метке. То есть, если в метке написано сотый вилан, мы сотый вилан и используем. Мы можем прописать другие правила на свече. Мы можем сказать, что если кадр приходит с меткой сотого вилана, на самом деле это не сотый вилан, надо его коммутировать по таблице 50-го или 200-го вилана. То есть, такие правила прописать можно. Просто это не очень удобно и в пределах одной автономной системы чаще всего метка как раз указывает коммутировать это по таблице такого-то вилана. Бридж 200 не создали. А здесь у нас нету бриджа 200, бридж только сотый есть.

У нас два интерфейса сейчас в один и тот же бридж смотрят. В один и тот же свитч, если хотите. Давайте попробую порисовать. Страсть как люблю рисовать. Что я сейчас сделал? У меня есть физический роутер, на нем есть виртуальный свитч. Я его назвал свитчом номер 100. У меня есть железный интерфейс. На нем есть два субинтерфейса. Один субинтерфейс с меткой 100, другой субинтерфейс с меткой 200. При этом эти два субинтерфейса, они оба заведены на вот этот виртуальный свитч. Поэтому кадры, когда приходят с меткой физической, на физический интерфейс с меткой сотой, они проходят на виртуальный свитч. Метка с них при этом стирается. То есть, вот сюда, вот на виртуальный свитч уже доходит обычный кадр. И дальше этот свитч коммутирует этот кадр во все остальные порты. То есть здесь не так много портов, у него всего один порт. Поэтому он коммутирует этот кадр обратно во тот же самый физический порт, просто в другой субинтерфейс. И кадр отправляется с этого субинтерфейса с меткой 200-го Вилана.

Номер метки и номер Вилана, номер, хотите, бриджа, напрямую между собой не связаны. То есть одно дело, что написано в метке, а другое дело, по какой таблице коммутируется кадр, куда идет маклёринг. Напрямую они не связаны. Другое дело, что чаще всего в сетях предприятия они совпадают. То есть это просто удобно. Но они не обязаны совпадать, они могут быть и разными. Так. После того, как вы построили связи между вашими маршрутизаторами, коммутаторами, маршрутизаторами в режиме бриджа, дальше возникает проблема, как избавиться от петель. И есть замечательный протокол, который изначально предусмотрен как часть механизма бриджинга, то есть это протокол Spanning 3. Это не какая-то отдельная сущность для бриджинга, то есть это часть процедуры бриджинга, которая предусмотрена стандартно 802.1d. Появилось оно в 1990 году.

И, соответственно, самый первый вариант Spanning 3 — это как раз вот медленный Spanning 3, ванильный Spanning 3, который еще как бы иногда называются. И он реально медленный. То есть в определенных ситуациях ванильный Spanning 3 802.1d 90-го года может класть сетку на 60 секунд. Там плюс-минус километр. Если мы хотим ускорить работу, то, понятное дело, что класть сетку на минуту в современном мире — это вообще не вариант. То мы можем использовать более быструю версию Spanning 3 — это Rapid Spanning 3. Она более быстрая за счет отказа от топологии, в которой у нас может быть больше, чем два участника в одном проводе. Если у нас есть среда, в которой может быть больше двух участников, то все ускорения Rapid Spanning 3 превращаются в тыкву. Более того, если вы берете два свитча с поддержкой RSTP и связываете их между собой через свитч без поддержки RSTP,

просто ванильный медленный свитч, то, соответственно, у вас тоже все это дело не будет работать. То есть у вас быстрый свитч с одной стороны, быстрый свитч с другой стороны будет втыкаться в непонимание со стороны транзитного медленного свитча. Медленный свитч будет вести себя медленно. Если вы берете и соединяете два быстрых свитча через какую-то прокладку, либо тупой свитч, который в Spanning 3 в принципе не умеет, либо через, допустим, Hub, либо действительно соединяете толстым желтым коаксиалом, в котором у вас юзеры сидят, то в этом случае, опять же, ускорение Rapid Spanning 3 вы использовать просто не можете. В этом случае два свитча у вас попытаются использовать, попытаются вот здесь вот согласовать фактически работу по быстрому режиму. Они друг друга будут видеть, потому что транзитный свитч без поддержки Spanning 3, он будет в Spanning 3 кадры просто фарвардить. Но из-за того, что он просто фарвардит кадры, у вас два свитча понимают, что они находятся в одном широкопрещательном домене. При этом у них видно, что есть полный дуплекс.

То есть если два узла смотрят друг на друга, видят, что Spanning 3 и мультикастовые кадры проходят друг до друга без каких-то изменений. Они предполагают, что они соединены прямым проводом. Транзитные свитчи, если они хотят прикидываться толстым желтым коаксиалом, прикидываться просто пустым местом, они очень здорово могут это прикидываться. И вот два свитча Spanning 3 в этом случае, они не будут видеть, что в сети между ними есть какой-то узел. Они будут говорить, между нами ничего нет, между нами просто прямой провод. И они будут использовать алгоритмы аппаратного ускорения. Алгоритмы ускорения работы Spanning 3. Но, несмотря на то, что они будут использовать алгоритмы, эти алгоритмы работают только в ситуации, когда внутри между ними петли нет. И если вдруг у вас здесь получится вот такая вот история, или какая-то еще вот история вот здесь вот такая, которая формирует по факту петлю, или вот здесь вот еще будет какой-нибудь канал, то в такой ситуации петля у вас все равно может возникнуть.

И в такой ситуации быстрый Spanning 3 себя будет вести некорректно. Поэтому, если вы включаете алгоритмы ускорения на Rapid Spanning 3, вы должны будете понимать, что это все должно корректно быть размечено. Если где-то у вас вот топология такая, что два быстрых свитча смотрят через свитч, который вообще Spanning 3 не поддерживает, там нельзя включать ускорение. Там вы должны будете понимать, что вот этот вот свитч — это фактически толстый желтый коаксиал. У нас в этом коаксиале сидят четыре разных участника. Следовательно, здесь вы должны работать в режиме совместимости, в режиме медленного Spanning 3 ванильного 1990 года. Если вы хотите, вы можете использовать MST. MST от Rapid Spanning 3 отличается тем, что он тоже быстрый, но при этом поддерживает VLAN. Это протокол стандартный. Его иногда называют 802.1s, но более правильно его называть 802.1q. То есть если у вас есть VLAN 802.1q, и если у вас есть Spanning 3, то вы имеете стандартный протокол для работы с VLAN в бриджинге.

Это 802.1q 2003 года. 802.1s — неплохой протокол, но он требует некоторой настройки. То есть у него не то, что прям катастрофически сложно настраивается, но настройки все-таки у него должны быть, они должны быть согласованы. Если у вас много свитчей, и эти свитчи постоянно требуют какой-то переконфигурации, у вас постоянно там создаются новые VLAN, новые транки, то в этом случае MST настраивать немножко сложновато. Ну, потому что просто вот сама конфигурация, которая есть, она требует, чтобы она везде была плюс-минус километр одинаковой. Поэтому, да, вы в MST должны будете следить за тем, чтобы конфигурация у вас синхронизировалась. Если говорить про Cisco, есть протокол VTP, который умеет потаскивать настройки MST, VTP версии 3. Но в оборудовании других вендоров, да, VTP нет, и как следствие MST надо настраивать ручками. Если не хочется работать с MST, потому что он сложный, ну, как сложный, сложный, да, в кавычках сложный, то можно использовать стандартные,

в кавычках для Cisco протоколы PVST. Они не только на Cisco есть, то есть PVST и PVRST есть на оборудовании других вендоров, те же самые Juniper, те же самые Huawei, на них все это дело тоже поддерживается. На свитчах Cisco по умолчанию работает Spanning 3 на всех VLAN-ах, на всех портах. Вы можете выключить Spanning 3 на уровне определенного VLAN-а. То есть если вы хотите, вы можете сказать, нам не надо в определенном дереве работать с Spanning 3. Если у вас по умолчанию работают на Cisco Spanning 3, то он работает в режиме либо PVST, либо Rapid PVST. До вот такого вот ИОСа использовался, медленный фирменный Cisco PVST. Начиная с вот этого ИОСа работает быстрый Cisco-овский Rapid PVST. Он строит отдельное дерево за каждый VLAN. Если у вас в базе VLAN-ов 10 VLAN-ов, значит у вас создаются 10 деревьев. Вы можете сказать, что вам не нужно использовать Spanning 3 в определенном дереве, и команда глобального конфига будет no Spanning 3 VLAN, допустим, не знаю, 100.

И в этом случае за 100 VLAN дерево Spanning 3 строится не будет. Можно сказать, что у Spanning 3 VLAN с первого по 4094. Вы тем самым выключите Spanning 3 вообще глобально на всем свече. Вы не можете выключить Spanning 3 на уровне порта. То есть такой фичи исключить вообще работу Spanning 3 на уровне порта нет. Но есть такая штука, как бы Badoo-фильтр, про которую мы поговорим отдельно. Если вы хотите поменять режим работы, ну, если вы используете старую циску, как минимум вы хотите переключить ее в Rapid PVST, как максимум вы хотите переключить ее в MST. Вы должны будете использовать команду Spanning 3, Mode и дальше указать режим. Таймеры во всех вариантах Spanning 3 по умолчанию используются стандартные. Те, которые рекомендованы стандартным 802.1D. HelloTime, как часто посылать BPD-ушки раз в 2 секунды. Forward Delay, время распространения информации от любой точки сети до любой другой точки сети. Если мы используем медленный ванильный механизм

распространения информации Spanning 3 на основе таймеров, это 15 секунд. За 15 секунд абсолютно любая железка должна отправить информацию. И вот она точно гарантированно за эти самые 15 секунд разбежится по всей сети. Forward Delay рассчитан по специальной хитрой формуле, но мы можем сказать, что он рассчитан, исходя из того, что у вас между любыми двумя точками сети будет не больше 7 прыжков между свечами, между бриджами. То есть если у нас один свитч, другой свитч, третий, бридж, четвертый, пятый, шестой, седьмой и восьмой. Вот между ними раз, два, три, четыре, пять, шесть, семь транзитных прыжков. Если у вас HelloTime 2 секунды, то в самом неудачном раскладе 2 секунды потребуется на первый прыжок, 2 секунды на второй прыжок, 2 секунды на третий и так далее. Вот 7 прыжков, 14 секунд. Плюс некоторое время требует обработка самих BPD-ушек. Если у нас какой-то бридж начинает рассказывать что-то своему соседу, тот может своему соседу рассказать это с задержкой до 2 секунд, тот своему соседу с задержкой еще до 2 секунд,

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

чтобы объявить смену топологии. Вы говорите, вот я недавно видел BPD-ушку от соседа, я верю, что он еще раз что-нибудь пришлет. При этом по факту MaxH 20 секунд — это не то, что вы считаете 20, 19, 18, 17 и дальше до нуля. Вы считаете до MaxH с MessageH. То есть когда к вам приходит BPD-ушка от соседа, в ней указывается, как далеко, в скольких прыжках сосед находится от рута. MessageH указывается в секундах, как далеко мы от рута. И дальше вы будете считать от вот этого MessageH до MaxH. То есть приходит BPD-ушка, в которой написано «Я в 4 секундах от рута». Значит, вы начинаете считать 5, 6, 7, 8 и так до 20. В неудачном раскладе, если вы находитесь прямо рядом с рутом, к вам приходит сообщение от рута. То есть вы говорите «Я нахожусь в рута от одной секунды». И после того, как вы перестаете принимать BPD-ушки от рута, дальше вы считаете до 20. В 802.1.d были стандартные стоимости. я просто напоминаю, что эти стоимости были.

Стоимости в 802.1d считались по формуле «гигабит, деленный на скорость интерфейса». Соответственно, на 10-мегабитном интерфейсе была рекомендованная стоимость 100, на 100-мегабитном интерфейсе «рекомендованная стоимость 10», на гигабитном интерфейсе «рекомендованная стоимость 1», на любом интерфейсе быстрее, чем гигабит, тоже стоимость была 1. 802.1d 1998 года предложил так называемую «ревайз-формулу». 119 42 но те кто на сессии на и были эти создавали те форму должны будут хорошо знать и в 2004 году появилась так называемая длинная формула это 100 пардон это 20 терабит деленное на скорость интерфейса то есть 10 мегабит 20 терабит деленное на 10 мегабит это у нас будет 2 миллиона 2 миллиона 100 мегабит 200 тысяч гигабит 20000 и 10 гигабит из негрисованы 10g это у нас 2000 это так называемая

длинная формула до далее на ciscoх по умолчанию используется схема с extended system id которая генерирует отдельный отельный брэдж идеи для каждого виртуального коммутатора до каждого виртуального брэджа который у нас уча есть что такое б�ن это же железка который перекладывает данные между интерфейсами нас есть интерфейс 1 и интерфейс другом и вот мы говорим мы создали виртуальный коммутатор нам допустим стол там фанского интерфейса кадр перекладывая другой интерфейс кадры которые приходят на вход виртуальному виртуальному бриджу сотому, они не маркированы никакими метками, они просто приходят. Кадры, которые уходят с виртуального коммутатора, они тоже без каких-либо меток. После чего, когда они отправляются через транковый интерфейс, на них добавляется метка вилана, с которого там оно ушло, или какая-то другая метка, если вдруг у нас не совпадает номер бриджа и номер метки.

Но, если мы используем свитчи цисковские, то в подавляющем большинстве случаев у нас Extended System ID схема будет использоваться, идентификатор в бриджа ID будет равен номеру вилана, ну и естественно, что кадры, которые будут отправляться с метками вилана, они будут совпадать в метке номер вилана и номер метки. Если мы хотим использовать PVST или протоколы на его основе, PVST+, который поддерживает транки ASL-овские, или PVRST, который использует механизм ускорения 802.1W, то в этом случае физическую топологию мы разделяем на отдельные экземпляры, на отдельные деревья, и в каждом дереве выбираем отдельный, отдельного рута. Как следствие, у нас раздача рутовых Alternate, Designated и BeCut портов будет различаться в разном дереве. Физически топология будет одна и та же во всех деревьях, но выбор рута и выбор портов, ролей портов у нас будет в каждом дереве

соответственно разным. Если мы говорим про схему с Extended System ID, то каждый виртуальный коммутатор, который у нас есть на железке, он будет соответственно иметь отдельный свой Bridge ID с использованием следующей схемы. Первые 4 бита будут означать 4 бита приоритета. Они самые старшие, и они сильнее всего влияют на Bridge ID. Поэтому стандартная схема, которая используется в Spalning 3, у кого Bridge ID больше, тот и прав. Нет, тот и не прав. У кого Bridge ID меньше, тот и прав. Вот она с использованием самых старших бит будет как раз рулиться. Если нам нужно сделать Bridge ID одного коммутатора меньше, чем Bridge ID другого коммутатора, то исправлением вот этих самых старших 4 бит мы можем этого добиться. Следующий 12 бит, это вот, собственно говоря, схема с Extended System ID откусывает 12 бит от изначального большого поля, которое в стандарте называется просто Priority. Но в стандарте эти 16 бит приоритета нафиг я не уперлюсь. Просто потому, что 16 бит приоритета дают нам 65 536 различных значений и 65 тысяч различных приоритетов

в одной и той же сети нам могут гипотетически понадобиться, только если у нас 65 тысяч коммутаторов используются. А 65 тысяч коммутаторов в одной сети это какая-то слегка безумная сеть. Она немножко неразумная по размеру. Кроме того, это 65 тысяч различных приоритетов означает, что у нас не просто 65 тысяч коммутаторов есть, а у нас еще есть определенный порядок наследования роли ROO카� mitz 0. В случае, если вот у нас есть один ROOT, мы хотим сказать вот он должен становиться ROOT seen всегда, когда у нас все хорошо работает. Если он сдохнет, второй коммутатор должен становиться soon. рутом. Если он сдохнет, третий коммутатор должен становиться рутом. Вот мы все 65 тысяч коммутаторов указываем, кто в каком порядке должен наследовать эту роль. В реальности, естественно, никто так не делает. Если у вас реальная сеть есть, она строится по иерархической схеме. У вас есть там свечи ядра, у вас есть distribution блоки, ну или блоки агрегации. И дальше в этих блоках агрегации есть уже абонентские свечи, которые там, триугольники опять же рисуются. Ну, то есть как-то оно вот так вот выглядит, что у нас есть distribution блок,

в рамках которого есть два distribution свеча и пачка access свечей. И каждый access свеч связан со своим distribution блоком. И distribution блоки точно так же связываются с двумя свечами ядра. Так вот, если у вас такая сеть есть, у вас есть свечи ядра, которые связывают в себя вообще все, и они должны становиться рутами. Если у вас глобальная L2 сеть. Если у вас один свеч становится рутом, то вы можете сказать, окей, у нас тут пачка вот этих самых транковых портов, которые смотрят distribution на ядро. Вот там, чтобы эти транки были загружены более-менее равномерно, нам нужно разбить нашу топологию на два типа деревьев. Те, которые будут с рутом о левом свече. И, соответственно, запасной рут, в этом случае secondary рут, должен быть другой свеч. И в других деревьях, в деревьях рут должен быть правый свеч, а этот будет secondary. То есть нам по факту нужно будет два приоритета для того, чтобы обеспечить корректную работу сети, если у нас живое ядро. А если у нас ядро не живое, если оба

свеча ядра сдохли, то это не важно, кто у нас там будет выбираться рутом в пределах одного distribution блока. У нас сеть не работоспособная. То есть какая разница, кто будет рутом в пуске сети, который отвалился и который не имеет связанности с стальным миром. Даже если вдруг вы возьмете и сделаете, допустим, кольцо из distribution коммутаторов по всей сети, вот у вас будет там резерв на всякий случай, если вдруг ядро развалилось, можно будет как-то войти в обход. Абсолютно пофигу, кто из distribution станет рутом. Они все одинаковые, все однотипные. Дайте им третий приоритет. То есть у вас будет четыре приоритета. Два приоритета на работу основных рутов. Один приоритет запасной, чтобы не становились рутами обычные access свечи. И четвертый приоритет — это вот, собственно, сами все access свечи. У вас достаточно двух бит приоритета для того, чтобы решить задачи, задачи приоритетов в реальной сети. Ну вот, соответственно, схема Sextended System ID, когда вы от 16 бит приоритет откусываете 12 под идентификатор бриджа, она позволяет вам создать

четыре, задать четыре бита приоритета, тем самым создать 16 различных значений приоритета, что все равно в четыре раза больше, чем действительно нужно. Вот. Если у нас есть сеть, в которой мы используем свечи или бриджи, более корректно сказать, бриджи с указанием, что мы строим отдельное дерево за каждый ВИЛАН, то у нас на физическом коммутаторе будет по факту два виртуальных бриджа, два виртуальных коммутатора. Один у нас будет за ВИЛАН, ну, допустим, там, не знаю, десятый или там первый. Давайте первый ВИЛАН. ВИЛАН. И вот это второй ВИЛАН. То есть мы сделали два дерева и, соответственно, в каждом дереве мы хотим раздать приоритеты. Вот, допустим, в первом дереве мы говорим, мы сделаем приоритет получше, чем в среднем. Во втором дереве мы сделаем приоритет такой же, как у среднем. То есть стандартный средний приоритет — это восьмерка, 16-ти речные или 32 768, если мы говорим про десятичное представление. Другой свеч у нас точно так

же разделяется на два виртуальных коммутатора, на виртуальный коммутатор или виртуальный бридж первый и второй. В первом делаем приоритет стандартный, во втором делаем приоритет получше. У нас получается два дерева. Одно дерево первого ВИЛАНа, другое дерево второго ВИЛАНа. В первом дереве левый коммутатор становится рутом, в правом дереве второй коммутатор становится рутом. Раздача портов, соответственно, designated port. Здесь у нас root-порт в первом дереве, а во втором дереве root-порт и designated port. То есть вроде бы порты одни и Но каждый конкретный порт в каждом конкретном дереве получает свою отдельную роль. Если у вас портов много и если у вас виланов много, то вот этих вот виртуальных портов, то есть сущности, которые получают роль в рамках конкретного дерева, на свече может становиться слишком много. На цисковских свечах есть ограничения по количеству виртуальных портов, по количеству вот индивидуальных ролей каждого конкретного порта в каждом конкретном дереве. Если мне память не изменяет, там что-то порядка 15-20 тысяч на одной железке, вот максимум, сколько циска может сожрать.

Если у вас больше получается, то есть у вас много, очень много портов, много, очень много виланов используется, то есть, ну, например, там, не знаю, 4 тысячи виланов и все используются, и вы используете 4 тысячи деревьев, и в каждом коммутаторе у нас там, не знаю, 48 портов. То есть всего у вас получается, если на всех портах, на всех 48 портах у нас есть транки со всеми-всеми виланами, получится итоговое количество виртуальных портов 4094 вилана умноженное на 48 портов. То есть примерно 4 тысячи умножить на 50. Это 20, 0, 0, 0, 0. 200 тысяч виртуальных портов. Вот циска такое количество не сожрет. Если вы на 48-портовом свече пытаетесь создать гипотетически 4 тысячи 94 вилана и создать 48 транков, общее количество виртуальных портов превышает очень сильно максимальное количество виртуальных портов, которые может сожрать циска. Поэтому вы должны будете сказать, вот 20 тысяч портов виртуальных она типа сожрет. То есть либо мы говорим, не 48 портов могут быть транками, а только 5, либо мы говорим, не 4 тысячи 94 вилана мы создаем на нашей железке, а только там 400.

То есть мы сокращаем в 10 раз количество виртуальных портов и железка на пределе своего возможности, но тем не менее хоть как-то может функционировать. Нельзя сделать так, чтобы у нас все виланы и все порты были транками со всеми виланами и участвовали во всех деревьях одновременно. Просто не пролезаем по количеству виртуальных портов. В каждом дереве нужно будет задать приоритет. Это можно сделать либо в явном виде указываем Spanning 3, указаем идентификатор дерева. Если у нас используется PVST, то дерево указывается за каждый отдельный вилан. То есть в дереве номер 1 указываем приоритет для виртуального коммутатора. Priority и дальше некоторое число. Допустимые значения — это числа, которые делятся на целом на 4096. То есть это числа, которые в 16-ти ричном виде имеют вид x, 0, 0, 0. Вот это вот x — это число от 0 до f. То есть x — это в диапазоне от 0 до f. Это 0, 4096, 8192 и так далее.

Хорошо известные приоритеты. 32 768 — приоритет по умолчанию, то есть 8, 0, 0, 0. 28 672 — это запасной root. То есть тот root, который должен становиться root, если основной root отвалится. У него приоритет лучше, чем у всех остальных, дефолтный, но все-таки хуже, чем у основного root. И 24 576 — это приоритет основного root. Если вы хотите, вы выставляете этот приоритет явно в виде, прибиваете его гвоздями и ждете, пока у вас кто-нибудь его отнимет. Если хочется не вычислять, какое там значение должно быть, просто сделай меня root. Вот есть такой макрос — spanning 3, дальше указываете идентификатор дерева, root primary. Оно делает вас root, если есть такая возможность. Если приоритет текущего root 32 768, то вам выставляется приоритет 24 576. Если приоритет текущего root другой, то есть лучше, чем 32 768, то вам выставляется приоритет такой же, как у него, если ваш MAC-адрес меньше, чем у него.

И тогда ваш bridge ID станет меньше, чем у него. То есть у вас действительно сделает root. Либо если ваш MAC-адрес больше, то тогда такой же приоритет, как у него, вам делать не надо. Вам нужно сделать приоритет на единичку меньше. И вам делается приоритет на 4 тысячи на 6, на единичку меньше. И тогда вы все равно становитесь root. Sparling 3 VLAN root secondary, Sparling 3 дерево какое-то root secondary, прибивает вам гвоздями приоритет 28672. Это макрос ничего вам не гарантирует, он просто прибивает вам такой приоритет. Он лучше, чем стандартный. После того, как вы создали виртуальные коммутаторы, запустили Sparling 3 в них, разметили приоритеты, раздали порты этим самым bridge. Дальше можно заказывать отображение Show Sparling 3. Show Sparling 3 и дальше указываем идентификатор дерева. В нашем случае дерево VLAN 1. Здесь вот эта штука показывает, в каком режиме работает ваш Sparling 3. Здесь это просто надо знать, если пишет IEEE, это на самом деле PVST+.

Если вам пишет RSTP, это на самом деле не RSTP, это на самом деле PVST, то есть быстрый фирменный цисковский Sparling 3. Ну, MST это MST, то есть MST тут сложно ошибиться. По каждому дереву вам показывается то, что ваш свитч о нем знает, какой приоритет у рута, какой макадрес у рута. То есть на самом деле вот эта вот штука, это какой bridge ID у рута. Откуда взялся bridge ID неизвестно, потому что когда нам приходят бпдушки от рута, там не написано, используют он схему с Extended System ID, не используют. Поэтому просто вот такой вот приоритет 16 бит и такой вот макадрес 48 бит. Если вы рут, показывается, что вы рут. Если не рут, показывается, каким портом вы смотрите на рута, и на каком расстоянии вы от рута находитесь. Дальше показывается блок, который рассказывает про вас. Какой приоритет у вас? Вы уже точно знаете, какой приоритет у вас и почему он такой. Показывается ваш приоритет. Первые 4 бита и Extended System ID 12 бит – это идентификатор виртуального рута.

Макадрес, он у вас на всю железку один и тот же, поэтому вот показывается, что вот он всего есть такой. И дальше таймеры, которые на вас настроены, и порты, которые в этом дереве присутствуют. В нашем случае показываются 4 порта. Они все, поскольку мы рут, десигна этот фарвардинг, стоимость каждого порта 4. Ну, для гигабита это как раз характерные стоимости. Кстати, забыл сказать. Если вы используете pvst, то используется формула 98-го года. Revised формула 119.4.2. Если вы используете rst, то используется длинная формула 2004-го года. 20 терабит делим на скорость интерфейса. Ну, в нашем случае мы видим, что вот это вот rstp, это на самом деле не rstp, это на самом деле pvrst, и мы используем короткую формулу revised 98-го года, 119.4.2. Если вы используете mst, то имейте в виду следующие вещи.

Вы должны будете привязывать отдельные виланы, которые у вас будут, к деревьям, которые вы должны будете ручками создать. Если вы используете pvst, у вас автоматически создается отдельное дерево за каждый вилан. Если вы используете mst, вы должны будете ручками создать деревья и привязать к этим деревьям виланы. У вас в абсолютно любом случае есть одно дерево, которое строится для служебных нужд. Оно называется internal spanning tree. То есть вот это вот ist, это дерево, которое в любом случае свечи внутри mst-шной зоны, mst-шного региона будут строить. Кроме того, вы можете сделать пользовательские деревья и привязать те виланы, которыми вы хотите рулить, к тем деревьям, которые вы создаете. Каждое дерево в терминологии mst будет называться словом instance или обозначаться mst instance, msti. Если вы используете несколько свечей, которые настроены в единой логике, у которых конфигурация mst-шной совпадает, то есть вот везде здесь на всех этих свечах настроен mst,

они у вас проверяют, что настройки на них одинаково и совпадают. И вот совокупность неразрывных свечей, которые настроены в единой логике, будет называться словом mst-регион. Ре-ги-он. Это все свечи, у которых одинаковая конфигурация mst, где у нас одинаковые инстанции созданы и одинаково привязаны виланы к этим инстанциям. Если у нас есть какие-то свечи, которые настроены не в одной логике с нами, то есть либо инстанции не созданы так же, как у нас, либо виланы к ним привязаны не так же, как у нас, либо есть какой-то вообще сосед, который не поддерживает mst. То есть вот здесь у нас будет, не знаю, pvst-шный свеч, цисковский pvst-шный свеч, или здесь рядышком будет mst-шный, но другой в чужом регионе, то есть он не настроен с нами в одном стиле. Либо здесь будет так называемый cst, common spanning tree, это просто ванильный свеч, может быть медленный, может быть быстро, не суть важна, то в любом случае мы с ними будем вести взаимодействие,

прикидываясь одним мега-свечом. Весь регион mst схлопывается до одного свеча. И фактически все остальные свечи думают, что они дружат с одним и тем же свечом. При этом даже если вдруг какой-то другой свеч будет, опять же, неважно, чужой mst, или фирмен цисковский pvst, или какой-то ванильный свеч с другой стороны находиться, физически подключаясь к другому свечу в регионе, они на самом деле будут думать, что это вот один мега-свеч, у которого просто четыре интерфейса в нашем случае. При работе с mst цисков по умолчанию используют длинные формулы, то есть 2 миллиона на 10-мегабитном интерфейсе, 200 тысяч на 100-мегабитном, 20 тысяч на гигабитном, и 2000 на 10-гигабитном. Дальше. Если, да, забыл сказать, если у нас есть свечи, в которые строят регион, то вот внутри этого самого региона у нас будут строиться деревья инстанции, mst-инстанции,

которые мы сделаем кастомные, instance internal spanning 3, он же instance номер 0, опять же, служебный, который, опять же, внутри региона строится, но вот все вот эти инстанции, они снаружи не показываются. Если мы хотим работать снаружи с другими свечами, то мы прикидываемся одним мегасвечом, и мы участвуем в дереве, которое строим со всеми остальными участниками, прикидываясь одним свечом. Вот дерево, в котором мы взаимодействуем с другими, будет называться CIST, Common and Internal Spanning Tree. Внутри нашего региона internal spanning 3, а снаружи со всеми остальными участниками мы дружим по CST, по классическому common spanning 3. И вот когда мы хотим сказать, что у нас есть вообще все, то, что есть в Spanning Tree в MST, вот эта штука называется CIST. Дальше. Если мы говорим про MST, у нас в этом MST бегают BPDU. В отличие от PVST, где BPDU бегает по одной за каждое отдельное дерево,

заодно VLAN, в MST используется просто одна BPDU, и она будет содержать несколько priority-векторов. То есть у нас отправляется BPDU, и она говорит, у меня priority-вектор в таком-то VLAN такой, в другом VLAN другой, в третьем третий, и, соответственно, у вас все свечи друг к другу эти самые BPDU пересылают. Если вы отправляете BPDU, то для того, чтобы свеч понял, какие VLAN надо как коммутировать, нужно будет, чтобы VLAN у вас к инстансам были привязаны везде одинаково. Если у вас будет передаваться BPDU, и она настроена не в той же самой логике, что на получателе, то в этом случае от нее читается только кусочек, относящийся к дереву common spanning 3. То есть мы не читаем то, что относится ко всяким остальным инстансам. Нормальная BPDU, которая идет, она говорит, я за instance номер 0 имею вот такой priority-вектор, за instance номер 1 имею вот такой priority, за instance номер 2 имею вот такой priority-вектор.

При получении мы говорим, доверяем мы соседу или нет. Если он с нами находится в одном регионе, то есть настроен корректно, так же, как и мы, то мы читаем всю BPDU, мы видим, как он относится к рутам в каждом конкретном инстансе. Если мы видим, что он настроен некорректно по отношению к нам, мы читаем только instance номер 0 и фактически говорим, вот в том месте, где хранится priority-вектор instance номер 0, BPDU, она фактически представляет собой обычную ванильную BPDU-шку в RAID-успаринг 3. И мы говорим, вот если мы отрежем все, что там дальше идет после самого первого инстанса номер 0, у нас получится обычная растепешная BPDU-шка. И мы читаем только ее. А то, что там хвост какой-то еще есть, который непонятно что написано, ну мы этому не верим, потому что сосед в другом регионе относительно нас. Если у нас используется MST, и если у нас все свечи настроены корректно и однотипно, они находятся в одном регионе с нами, то мы в этом случае можем сделать следующее. Мы можем сказать, что у нас используется два дерева, синий и красный, то есть дерево номер 1, дерево номер 2.

MST 1, MST 2. И мы привязываем виланы, 11 и 12 виланы привязываем к первому инстансу, 21 и 22 виланы привязываем ко второму инстансу. И мы смотрим, что мы знаем про первое дерево. Вот на нашем свече мы говорим, у нас root в MST 1, MST 1 находится сверху. Соответственно, вот этот порт будет root-овый, и вот этот порт будет alternate. Во втором дереве за MST 2 root-on у нас будет нижний свеч, MST 2. Соответственно, вот этот порт будет root-овый, вот этот порт будет alternate. У нас два дерева, они обслуживают сразу целую пачку виланов. Дерево синий обслуживает виланы 11 и 12, дерево красный обслуживает виланы 21 и 22. Соответственно, в дереве первом, мы говорим, первый порт находится в состоянии root-forwarding, трафик 11 и 12 вилана ходит через первый вилан.

Через второй интерфейс трафик не ходит. И в другом дереве у нас привязаны виланы 21 и 22, соответственно, в первый интерфейс трафик 21 и 22 вилана не ходит, там у нас все заблокировано, а во второй интерфейс трафик 21 и 22 вилана напротив таких ходит. По сравнению с PVST, у нас вместо целой пачки BPD-ушек, которые иначе мы бы должны были отправлять и принимать, по одной за каждый вилан, мы отправили всего одну BPD-ушку на каждый интерфейс, или приняли и отправили, и как следствие построили сразу все деревья за один проход. Ну и, соответственно, разблокировали или заблокировали коммутацию в зависимости от состояния одного дерева. Если у вас виланов много, то использовать фирменные цисковские Spanning 3 не получается на свече. Виланов много, интерфейсов много, транков много, виртуальных портов много. Если вы используете MST, то вы в любом случае ограничены количеством виртуальных деревьев. Цисковские MST не позволяют построить

больше 16 инстансов, хотя по стандарту, в принципе, гипотетически инстансов может быть до 64, но цисковские MST не позволяют 64 сделать, она делает до 16 инстансов. И если у вас 16 инстансов, 16 деревьев, и в каждом дереве, вы говорите, у нас может быть, допустим, 48 портов, то 48 умножить на 16, это у нас 768. Вот 768 виртуальных портов у вас на 48 портов на свече можно получить. То есть это сильно меньше, чем максимальное ограничение в 16 тысяч или в 20 тысяч портов, которые есть у цисков. При этом, как уже говорилось, все свечи проверяют корректность настроенных соседей. Если соседи настроены с вами однотипно, корректно, то они с вами находятся в одном регионе. Если соседи работают, может быть, по MST, может быть, по классическому Spanning 3, может быть, неважно почему, они не настроены с вами в одном регионе, если у них конфигурация с вами отличается.

Поэтому они с вами не будут находиться в одном регионе. И для всех свечей, которые не находятся с вами в одном регионе, все свечи, формирующие регион, представляются одним таким мегасвечом. То есть внутренности дерева MST, внутри MST не видны тем, кто находится снаружи этого дерева. Если у вас будет в этом дереве выбираться рут, то, соответственно, этот рут просто будет один такой гига-мега рут. Все свечи, на самом деле, будут говорить, что они рут с точки зрения классического ванильного Spanning 3. Но внутри сети они будут разбираться между собой. И у вас есть, на самом деле, два рута, как правило, в MST. Есть рут, который строится за все дерево CIST, и есть рут, который называется региональный рут. Это может быть, соответственно, разные сущности. Внутри сети, в любом случае, внутри MST все равно выбирается региональный рут. Это тот, кто самый главный коммутатор с точки зрения самого MST. И есть еще просто глобальный рут. Это самый главный коммутатор

с точки зрения вообще всех участников взаимодействия с Spanning 3, включая внешние какие-то свечи. Если у вас самый главный рут будет находиться внутри региона MST, то он же будет и региональным рутом. То есть, например, вот мы говорим, самый главный рут или просто рут это вот этот вот свеч. Он находится в MST, поэтому он же будет и региональным рутом, и фактически именно им будут прикидываться все остальные свечи. То есть мы говорим, вот этот вот свеч, у него есть там bridge ID какой-нибудь. Bridge ID B. Вот все свечи говорят, меня зовут B. Вот этот, говорит, меня зовут B. Вот этот, говорит, меня зовут B. и вот этот свитч говорит, меня зовут Б. То есть все BPD-ушки, которые отправляются всеми-всеми свитчами, они все будут абсолютно одинаковые. Но внутри сети, они, естественно, будут внутри МСТ-шного региона, они будут немножко различаться. Если у вас самый главный рут будет находиться за пределами МСТ-шного региона, то есть какой-нибудь другой свитч скажет, а у меня приоритет такой, что вот вы все со своими МСТ-шными запашками

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

Вот этот порт будет root порт. Вот этот порт будет десигнейтед. Этот порт будет десигнейтед. Этот порт будет, например, root порт. И этот порт будет alternate порт. И, соответственно, он будет заблокирован. Внутри дерева АСТ Сначала мы разобрались, нашли, кого заблокировать, и заблокировали внутреннее взаимодействие внутри МСТ по некоторым портам. После чего мы говорим, что все, что здесь есть, оно уже эффективно прикидывается одним мегасвечом, и все подушки, которые будут отправляться за пределы нашего региона МСТ, они будут отправляться все одинаково. Внутри самого рута не формируется петля. Но, возможно, с участием нашего коммутатора формируется петля со внешними участниками. Да, внутри самого региона МСТ петель нет, но, возможно, надо будет избавиться от каких-то внешних петель. Но, опять же, если у нас от настоящего рута приходят какие-то BPD-ушки, то мы выбираем тот порт, на котором BPD-ушки от настоящего рута приходят самые вкусные.

Ну, вот здесь у нас появляется рут-порт. Самый вкусный рут-порт, который смотрит на настоящего рута. Вот здесь у нас designedポт. Здесь у нас designedポт. Здесь у нас рут-порт. Здесь у нас designedポт. Это у нас alternate-порт, потому что здесь у нас root. Вот с точки зрения всего мегасвеча получается этот alternate-порт. И вот этот порт блокируется. Равным образом он блокируется вот здесь. Этот порт у нас alternate-порт, который смотрит наружу на настоящего рута. Ну и здесь у нас получается designated port, здесь designated port, здесь root port, здесь root port. И вот эти двое между собой договариваются, что они там приняются. Designated port, alternate port. И вот этот порт тоже будет заблокирован. То есть вот таким вот образом коммутаторы принимают решение, что заблокировать в дереве MST. Так, как настраивается MST?

Мы сейчас не будем с вами детально изучать все вот эти вот плюшки, кто кого, как выбирает, какие там форматы BPDU. Мы сейчас быстренько пробежимся по тому, как это настраивается, и забудем Spanning 3 как страшный сон. Первое. Вы должны будете сначала на коммутаторах настроить саму конфигурацию MST. Делается это следующим образом. Вы входите в конфигурацию Spanning 3 MST Configuration. Приглашение к ководу изменяется, Config MST. Дальше все команды, которые вы вводите, они попадают в буфер команд. Вот мы в EOS XR вводим все команды в режиме конфигуратора терминала, потом делаем commit. И только когда мы делаем commit в XR, у нас все команды сбрасываются по факту в текущую конфигурацию, в активную конфигурацию. До того момента оно как бы в буфере формирует кандидатскую конфигурацию. Так вот, в обычном EOS мы обычно этого не наблюдаем. Все команды, которые вводим в конфигуратор терминал, они сразу попадают в раненый конфиг. Но есть нюанс. Вот если вы правите именно MST конфигурацию, то когда вы находитесь в приглашении к конфигу MST, все команды тоже попадают в буфер.

И вам надо выйти из этого контекста, чтобы по факту они сбросились и применились. Вы в настройке MST должны задать несколько вещей. Первое — это название домена MST, просто текстовая метка, длиной до 30, по-моему, одного байта. Потом вы указываете так называемый номер ревизии. Это никакого отношения не имеет к ревизии в это пэшные или там чего-то еще, это просто число. Оно если совпадает, значит в одном домене, в одном регионе MST. Если не совпадает, значит в разных. То есть главное, чтобы совпала просто текстовая метка, просто вот это вот число. И еще должен совпасть хэш от вот этой вот колбасы. Эта колбаса указывает, какие инстансы вы создаете и к каким VLAN вы какие инстансы привязываете. В нашем случае мы делаем два инстанса. Первый с номерами VLAN вот такими, второй с номерами VLAN вот другими. Если вы находитесь в контексте конфига MST, вы можете посмотреть, что именно вы на конфигуре, то есть какая у вас кандидатская конфигурация MST. Просто команда show без ничего показывает, какие инстансы вы наплодили, с какими VLAN вы работаете.

Ну и когда вы выходите exit из конфигурации MST, вы попадаете в приглашение обычного конфига. И соответственно у вас show spanning 3 MST configuration покажет, как у вас прямо сейчас MST работает. Понятное дело, что здесь вот можно взять и посмотреть, что у вас есть там имя какое-то, номер ревизии какой-то, какие-то инстансы созданы. Обратите внимание, считается один инстанс нулевой, в котором все VLAN по умолчанию. И все остальные инстансы, которые вы сами настроили, они прибавляются к этому нулевому инстансу. Поэтому вот мы сделали два инстанса, а по факту настроенных три, потому что есть еще MST 0. Затем, если вы хотите настроить ваш MST-шный свитч, вы можете задать приоритеты, вы можете задать стоимости портов, чем-то еще. Но самое главное, вы должны будете переключить ваш свитч в режим MST. Рекомендуется сначала задавать конфигурацию MST, а потом только делать команду spanning 3 mode MST. Если вдруг вы хотите проверить, совпадают ли ваши настройки на ваших свитчах или не совпадают,

самый простой способ сделать это — выполнить команду show spanning 3 MST configuration digest. У вас два свитча, и вы думаете, а не в одном MST-шном регионе или не в одном? Или у них что-то различается, просто вы это не можете глазками откладить. Вот вы указываете на каждом из них show spanning 3 MST configuration digest, и все, что проверяется при попытке подружиться по MST у двух свитчей, здесь вам показано. Должно совпасть то, что у вас номер, не номер, а название домена, должен совпасть номер ревизии, просто банальное число ни на что не влияет, главное, чтобы было одинаково. И вот этот вот хэш, то есть самый первый вот этот вот длинный хэш. Просто смотрите, обычно смотрят там первые несколько символов, если совпадает, уже хорошо. Очень редко может быть такое, что первые символы совпадают, остальное не совпадает. То есть если оно совпало, значит все хорошо, значит у вас свитчи в одном MST-регионе. Если два свитча в одном MST-регионе находятся, они между собой реплицируют состояние деревьев всех MST-шных инстансов,

и виланы у них работают одинаково в одной и той же логике. Если у вас два свитча не находятся в одном MST-шном регионе, вы их изначально настроили, они там были, а потом вы взяли в одном месте номер ревизии, поменяли на двоечку, а в другом забыли. В этой ситуации у вас получится, что два свитча будут работать через ванильный Spanning 3. То есть они оба поддерживают MST. У них в обоих MST настроен, но настроен по-разному. Поэтому они работают, как будто бы вы запустили на них обычный, просто классический Spanning 3, который ничего про виланы не знает. И он блокирует коммутацию на порту целиком, а не потому, что там сказали отдельные деревья. Есть команда ShowSpanning 3. Соответственно, ShowSpanning 3 мы заказываем диагностику за дерево. Если мы работаем с MST, то деревья у нас ShowSpanning 3, MST 0, ShowSpanning 3, MST 1 и так далее. И в MST 0 деревья, MST 0 это instance IST. У нас есть отдельно региональный root, кто региональный root, вот здесь показывается.

И есть указание, кто основной глобальный root. То есть показывается в нашем случае, что мы сами имеем вот такой вот MAC-адрес, вот такой вот приоритет, а глобальный root имеет вот такой вот MAC-адрес, вот такой вот приоритет. Но при этом это явный root, который находится за поделами нашего региона. При этом региональный root это мы сами. В MST дереве действительно есть два рута. Один глобальный root за всю топологию, за оси MST. Другой отдельно региональный root только за тех, кто понимает, что такое MST. Показывается, как можно добраться до каждого из рутов. Вот это вот указание, сколько стоит добраться до глобального рута. Если бы мы были не региональным рутом, рядом здесь бы показывалось, кто региональный root и сколько стоит добраться до него. Дальше. Показывается в дереве, в любом дереве, какие интерфейсы есть, сколько стоит каждый интерфейс.

Хорошо видно, что стоимости здесь большие. И показано, какие роли портов у нас тут будут. Рут порты у нас в forwarding, designated порты в forwarding, alternate порты в блоке. По каждому порту здесь вот в колонке тип показывается, в каком состоянии находится этот порт. Point-to-point. Это значит, что у вас там включены все алгоритмы ускорения Spanning 3 по сравнению с медленным Spanning 3. Если на порту обнаружен не MST-шный сосед, а какой-то другой, показывается, что да, у нас там point-to-point. Но при этом с той стороны какой-то rapid-spanning 3-шный, просто не MST-шный сосед, поэтому мы с ним дружим в режиме эмуляции классического ванильного Spanning 3. Еще бывает такое, что некоторые свечи, у них будет строиться тот самый хэш от инстансов не совсем стандартным образом. То есть вот если вы видите вот такой вот, то в этом случае вам надо на порту будет поменять тип хэша, который вы формируете. Сказать, что на порту будут отправляться боподушки с нестандартным хэшем. Это очень маловероятно, что вы когда-то встретите. Если вы работаете с ненулевыми инстансами, то там все просто, абсолютно так же, как с PVST.

То есть вот в ShowSpanning 3 MST1 нам покажут дерево, кто root. В нашем случае этот switch сам root. Кто мы. Вот мы. Какой у нас приоритет. То есть откуда он взялся. И показано состояние портов. Какие порты в это дерево входят и какие роли они получают. Мастер — это на самом деле root. То есть там нет термина root, есть термин мастер. Так. Далее. Если мы включаем Spanning 3, то на CISC мы нагло пользуемся тем, что есть такая штука, как Spanning 3 Toolkit. Это набор ускорений, который CISC изначально, когда давным-давно придумала для работы с Spanning 3. И потом она часть из этих штук отдала добровольно в стандарт Rapid Spanning 3. Ну вот один из важных элементов, который CISC добровольно совершенно отдала в рамках работы над быстрым Spanning 3 — это механизм port fast.

Изначально его придумали для медленного Spanning 3, и он заключался в том, что вы могли на порту сразу порт переводить в Designated Forward. Если вы смотрели, что у вас есть CISC-свеч, который смотрит на обычного абонента, вот абонент включается, и у вас изменение топологии, потому что изменяется состояние портов, у вас появляется новый Designated Port. В норме это в обычном медленном Spanning 3 изменение активной топологии. То есть смена топологии, все выключаются на свои порты на 30 секунд. Port fast — механизм, который позволил не перестраивать смену топологии, не объявлять смену топологии тогда, когда у вас появляется новый порт. Соответственно, port fast — это порт, который смотрит напрямую на абонента, на котором в норме петли нет. Вы начинаете работу, у вас порт включается, он сразу переходит в Designated Forwarding без отправки Topology Change. Если же вы получаете на этом порту BPDU, то значит, с той стороны находится свитч, и не просто свитч, а свитч, который считает, что вы не можете быть Designated Port,

потому что он находится ближе к роту, чем вы. Кто посылает BPDU, тот находится ближе к роту. Следовательно, ваше предположение, что с той стороны находится абонент, неверно, следовательно, смена топологии. То есть в норме на port fast — порту вы просто переходите в состояние Designated Forwarding сразу, не дожидаясь 30 секунд блокировки. Но если вы принимаете BPDU на этом порту, вы теряете Designated Forwarding и запускаете пересчет топологии. Эту штуку не следует включать на портах, которые смотрят на соседние коммутаторы. То есть если вы знаете, что с той стороны коммутатор, эту штуку включать не нужно. Включается она либо на обычных абонентских портах, либо на транках. Вы, по-моему, ее даже не можете включить на порту, на котором вы находитесь в динамическом режиме. То есть у вас установлен режим порта SwitchPort Mode Dynamic Auto, Dynamic Desirable, то port fast на этом порту вы не включите. Вы можете на порту в явном виде прибить гвоздями этот режим,

сказать Spanning3 port fast или Spanning3 port fast edge. Port fast edge — это новая команда. Она по факту на новых илысах показывается в справке, но Spanning3 port fast просто тоже пожирается. И слово edge намекает на то, что на самом деле именно этот механизм port fast вошел в быстрый Spanning3, то есть 802.1.w, как Rapid Spanning3, или 802.1.d 2004 года, как официальное название стандарта, в себе вот эту функциональность уже имеют. Вы можете объявить порт так называемым edge-портом, и тем самым у вас порт сразу будет переходить в Dissegmented Forever сразу после включения. Это может делать абсолютно любой Switch, не обязательно цисковский. Так что механизм изначально появился как цископорт fast, фирменная цисковская приблуда для медленного Spanning3. А потом она стала стандартной штукой и стала называться edge-портом. Но, соответственно, на цисковских железках вот она должна с одной стороны называться edge-портом, потому что это стандартное обозначение,

а с другой стороны, ну, исторически она всегда называлась portfast, поэтому обозначение Spanning3 portfastedge. Если вы хотите включить эту штуку на транковом интерфейсе, то вы можете это сделать, но не надо включать на транковом интерфейсе portfast, если это смотрит на соседний Switch. Вы должны будете включать Spanning3 portfastedge-tranc команду, если вы смотрите этим интерфейсом на сервер. То есть если у вас там, например, гипервизор, на нем крутятся виртуалки, и вам нужно в разные виртуалки подавать трафик разных VLAN. Включаете portfast, переводите порт в designait forwarding сразу, и у вас все виртуалки будут получать доступ к интерфейсу сразу после включения. Вы можете воспользоваться командой Spanning3 portfastedge-default. Опять же, на старых Switch'ах нет слова edge, есть просто Spanning3 portfastedge-default в глобальном конфиге. И тогда все интерфейсы, которые у вас работают в аксессе, они получат статус portfast. То есть у вас интерфейс включается, на нем нет команды Spanning3 portfastedge,

но у вас есть в глобальном конфиге команда, что все порты, которые по факту в портфасте, на них должны включаться... Все порты, которые находятся в аксессе, простите, на них по умолчанию включается portfast. Удобная штука, рекомендуется к использованию. В реальности у вас же будет абонентский Switch, на нем есть порты, эти порты все на них, я надеюсь, прописаны у вас SwitchPort NodeAccess. Соответственно, на всех этих портах вы смотрите на обычных абонентов, вы указываете команду Spanning3 portfastedge-default, на всех вот этих интерфейсах у вас Spanning3 переходит в portfast режим и не ждет 30 секунд. Два порта, которые у вас там были, четыре порта апплинка на аксесс-свиче, они у вас транковые, я надеюсь, и, соответственно, там у вас portfast не работает, потому что это транки. Рядом с portfast неплохо держать BPDU Guard. В случае с... На самом деле, в случае с провайдерским сценарием BPDU Guard — это такая особая тема,

и надо 10 раз подумать, хотите ли вы его использовать или нет, но в целом BPDU Guard рекомендуется использовать на тех портах, которые смотрят на обычных абонентах, за которыми не может быть свечей. Если вдруг на BPDU Guard порту приходит BPDU, то порт падает в WordDisable. Можно включить на отдельном интерфейсе команду Spanning3 BPDU Guard Enable или выключить в явном виде, запретить работу BPDU Guard на интерфейсе команды Spanning3 BPDU Guard Disable. Либо можно сказать, что включается автоматически BPDU Guard на всех портах, которые порт фастует. В предприятии это норма. То есть, если у вас есть сеть предприятия, там BPDU Guard обычно рекомендуется включать. Вы указываете Spanning3, порт фастедж, BPDU Guard Default. На всех портфастовых интерфейсах у вас включается эта штука. На провайдерских сценариях вы должны будете очень хорошо подумать, стоит вам это делать или нет. Если вы боитесь, что какой-нибудь абонент может в ваш провод воткнуть свитч и прислать вам BPDU,

поучаствовав тем самым в вашей Spanning3 топологии, то в этом случае имеет смысл, наверное, защититься. BPDU Filter — это еще одна фича, которая выключает эффективно отправку и прием BPDU на порту. То есть, фактически, если вы включаете BPDU Filter, то вы тем самым выключаете порт из возможности блокировки трафика на нем. То есть, если вы включаете этот на порту команды BPDU Filter, то порт у вас перестает BPDU-шки отправлять и принимать. Если у вас на порту все равно приходит BPDU-шка, то вы ее просто игнорируете. Такой порт всегда будет designated. Он, правда, все равно проходит через состояние listening, learning, forwarding, но, тем не менее, если вы сочетаете его с портфастом, то он сразу переходит в designated forwarding и оттуда уже никогда не уходит. Есть нюанс. Вы можете включить BPDU Filter на отдельном интерфейсе, командой Spamning3 BPDU Filter Enable.

И вы можете включить его автоматически на всех портфаст интерфейсах, так же, как мы делали с BPDU Guard, есть команда Spamning3 PortFastEdge BPDU Filter Default. Но эта команда ведет себя крайне непредсказуемо. Если вы используете PortFastEdge BPDU Filter Default, то эта команда не включает BPDU Filter на всех интерфейсах. Она сначала отправляет немножко BPDU в каждый интерфейс. И если с той стороны не приходят ответные BPDU, то тогда на каждом порту включается BPDU Filter. А если приходит, то тогда она не включается. То есть вы можете эту команду иметь на интерфейсах, а она по факту не работает. Вы можете эту команду иметь в глобальном конфиге, а на интерфейсе она не работает. Поэтому ее имеет смысл включать с очень большой осторожностью и с некоторыми сомнениями. Если вы хотите включить BPDU Filter на всех интерфейсах, потому что у вас провайдерский сценарий, вы знаете, что ваши абонентские порты никогда петлю не сформируют, потому что они там заходят по проводу в отдельную квартиру, вероятность того, что две квартиры вам устроят петлю,

она все-таки маловероятна, то вы можете просто повключать BPDU Filter на интерфейсах ручками. Использовать порт FastEdge BPDU Filter Default – плохая идея в среднем, потому что если вдруг у вас порт втыкается в свитч, и свитч соседа начинает присылать BPDU-шки, то BPDU Filter там не будет. Так. В реальных сетях, если вы используете BPDU Filter, его рекомендуется сочетать с порт Fastem и рекомендуется сочетать с BPDU Guard. Иногда есть у людей непонимание, почему все три механизма имеет смысл использовать на порту, и можно ли использовать некоторые только механизмы, почему вот такая комбинация вообще имеет смысл. Порт Fast – это про то, что порт начинает работать в designated forwarding сразу. BPDU Filter – это про то, что BPDU-шки не отправляются, не принимаются. А BPDU Guard – это то, что если BPDU-шка приходит, то порт расстреливается. Смотрите, что здесь надо будет понимать.

Порт Fast на порту надо будет включать по-любому, чтобы у вас не проходило лишнее designated listening, designated learning. То есть если вы на порту собираетесь в любом случае не обрабатывать Spanning Tree, то нет смысла не включать порт Fast на порту с BPDU-фильтром. Вы можете включить отдельно BPDU-фильтр и не включать порт Fast. Но в этом случае вы 30 секунд будете просто сидеть и курить бамбук, пока у вас порт проходит все транзитные состояния. Если вы включаете порт Fast и BPDU-фильтр, у вас порт сразу переходит в designated forwarding. Почему имеет смысл с BPDU-фильтром включать и BPDU Guard тоже? Дело в том, что в некоторых случаях CISCO будет принимать BPDU-шки от соседа и будет игнорировать их. То есть она будет видеть, что приходит BPDU-шка от соседа и со включенным BPDU-фильтром она все равно ее пропускает. Она говорит, что эта BPDU-шка некорректная, поэтому я ее обрабатывать самостоятельно не буду, поэтому я ее буду дальше пропускать в сеть. BPDU Guard такие BPDU-шки все равно отследит и расстреляет.

Поэтому рекомендуется сочетать и BPDU-фильтр, и BPDU Guard. Это немножко странно выглядит в конфиге, но тем не менее это мера березосторожности, которая спасает сеть в случае, если в камп приходит немножко такая модифицированная BPDU-шка. Так.