Транспорт IEEE 802

Мы с вами вчера познакомились с операционной системой Cisco EOS XR, и, соответственно, с этой операционной системой можно кое-что делать. Ну, нас интересует в первую очередь, что нужно будет делать с маршрутизаторами и коммутаторами. Коммутаторов на основе XR, правда, нет, но, тем не менее, мы можем из маршрутизатора сделать некое подобие коммутатора. Мы можем сделать так, чтобы маршрутизатор на самом деле работал с кадрами из Орнета. И, соответственно, нам нужно будет понимать, какие, в принципе, теоретические вещи можно делать с кадрами из Орнета. На самом деле, если посмотреть на то, что такое современный Орнета и что такое, ну, например, тот же самый протокол IP, с которыми приходится работать в основном маршрутизаторе, то выяснится, что и IP, и Орнета — это на самом деле некие механизмы, которые позволяют нам на некоторой коробочке с надписью, например, Cisco взять, получить некий набор данных с одного интерфейса и дальше скопировать эти данные на другой или на некоторые другие интерфейсы. То есть что роутер, что свитч, они же, что маршрутизатор, что коммутатор делают одно и то же.

С одной стороны кусочек данных принимают, с другой стороны кусочек данных выпьевывают. Если мы посмотрим на актуальное поведение коммутатора, например, RazorNet, если у нас просто идет нормальное, обычное, корректное взаимодействие, то чаще всего коммутатор у нас знает все MAC-адреса, которые в сети используются, и большая часть кадров, которые коммутатор обрабатывает, он обрабатывает по схеме – с одного порта кадр пришел, с другого порта кадр ушел. То есть чаще всего мы видим именно такой сценарий. В случае с маршрутизаторами, с IP, мы увидим точно такой же сценарий. С одного порта IP-пакет пришел, с другого порта IP-пакет ушел. То есть что маршрутизатор, что коммутатор делают примерно одну и ту же вещь. Разница только в том, на какие критерии они будут обращать внимание при принятии маршрутизационного или коммутационного решения. То есть на что они смотрят для того, чтобы понять, что с полученным кусочком данных делать. В свое время, исторически, в модели OSI, той самой семиуровневой модели,

было предложено решать задачи сетевого взаимодействия. Не как попало, а вот разбивая их на определенные пачки. И, соответственно, была такая третья пачка, которая называлась сетевой уровень. Пачка номер три, она же Network Layer, она же в модели DOT называлась интернет взаимодействия. И вот образцово-показательный протокол, который умел принимать решение, как взять какой-то кусочек данных с одной стороны и переложить его в какой-то другой порт, вот специально для этого был создан протокол IP, который умел хорошо решать подобную задачу, среди прочих. Он много умел задач решать, но вот это он в том числе умел делать. В тот момент, когда все это дело придумывалось, никаких других особых вариантов не было. То есть у нас был протокол IP, который адресно был заточен под перекладывание пакетов между интерфейсами. И других протоколов, которые бы это делали, которые были бы штатно под это заточены, не было. Но с течением времени появлялись другие протоколы, которые в каких-то аспектах решали, может быть, те же самые задачи, в каких-то другие.

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

чем они на это дело не похожи. Ну и, соответственно, для чего я все это вам рассказываю? Для того, чтобы показать, что, в принципе, если вы хотите построить какое-то провайдерское взаимодействие, вам все равно, на чем его строить. На Ethernet, на IP, потому что все эти протоколы так или иначе, что Ethernet, что IP, в современном мире занимаются одной и той же задачей. Просто они решают эту задачу немножко по-разному. Есть достаточно большое количество оборудования, которое заточено под работу с коммутацией на основе протоколов семейства Е802. Е802 — это, в первую очередь, тот самый Ethernet. То есть у нас есть то, что мы называем коммутаторы. Коммутаторы работают с кадрами Ethernet. Они, с одной стороны, кадр получают, с другой стороны, кадр выплевывают. Есть у нас маршрутизаторы. Это тоже устройство, но они работают по другому механизму, по другому критерию, будут принимать решение о фарвардинге данных. С одной стороны они получают тоже кусочек данных, возможно, тоже по Ethernet. И с другой стороны, через другой порт они выплевывают тоже кусочек данных.

Возможно, тоже, соответственно, по Ethernet. Вы можете в своей сети использовать любой из этих механизмов. Можете их сочетать. Cisco, в принципе, понимает, что, учитывая, что все современные провайдеры оказывают услуги на основе протокола IP, что так или иначе у вас IP в любом случае появится в сети. То есть у вас по-любому должны будут быть какие-то маршрутизаторы, у вас по-любому должны будут быть какие-то BRAS-сервера, Broadband Remote Access сервера, где у вас будет происходить стык в сети, стык, скажем, области, в которой сидит клиент, с какими-то другими областями в сети. То есть у вас где-то по-любому IP появится. Но в то же время устройства, которые работают на чистом IP, они достаточно дорогие. Они существенно дороже тех устройств, которые мы будем называть коммутаторы. И как следствие, если вы построите чисто коммутируемую сетку на основе только 802-го семейства протоколов, то она, как правило, окажется дешевле. Поэтому актуальная концепция построения провайдерской сети,

если вы строите ее на основе коммерчески доступных технологий, это строить где-то близко к абоненту сеть на основе 802-х протоколов. То есть то, что у нас там коммутаторы доступа есть, то, что у нас там еще, это все, соответственно, вот, как правило, у нас сети Ethernet. А дальше в какой-то момент переходит это все дело в IP, и дальше уже начинают работать IP-технологии. Поэтому в среднестатистической провайдерской сети есть и то, и другое. И 802-е сети, и IP-шные сети. И вот один из наших модулей, который мы сейчас начинаем смотреть, это будет как раз то, как устроены части провайдерской сети, работающие с протоколами семейства E802. В первую очередь, конечно, Ethernet. Само собой, разумеется, я уже подчеркиваю еще раз, что оригинальный Ethernet никакой коммутации не имел. И для провайдерских сценариев оригинальный Ethernet вообще никак не был предназначен. Если вдруг вы никогда, никогда не сталкивались с оригинальным Ethernet,

или хотя бы с тем, с той разновидностью Ethernet, которая появилась чуть позже, но она все равно была предназначена для работы в локальных сетях, это был просто длинный общий кабель. И к этому кабелю цеплялись все абоненты. Длина кабеля была ограничена в 10BS5, она была до 500 метров, в 10BS2 до 200 метров. И вот вы брали длинный кусок кабеля, разматывали там 400 метров кабеля, оконцовывали его. Это был просто одна такая длинная шланг, длинная змея. И к этой змее подключали ваших абонентов такими вампирчиками. Если мы говорим про 10BS5, это были вампирчики, которые просто натурально вклацывались в этот кабель. Если говорить про 10BS2, который на картинке нарисован, это были чуть более, скажем, элегантные устройства, то есть не надо было проклотсовать, прокалывать физически кабель. Вы должны были использовать не единый монолитный кабель, а кабель, разбитый на такие вот сегменты. И, соответственно, в каждом сегменте у вас были на концах разъемы.

То есть вот такой вот у нас был кабель с разъемами на концах. Разъемы назывались RJ58, если меня склероз не изменяет. И эти разъемы, эти кабели, куски кабеля соединялись между собой в колбасу, длина которой не должна была превышать 200 метров. То есть вот это вот 200 метров максимум было. На концах у этого провода обязательно были специальные заглушки. Они же назывались терминаторы. У них было вполне определенное сопротивление. Ну, я вам сейчас все рассказываю. На самом деле это вам, конечно, не нужно. Но главное, для чего вы должны будете этот слайд сейчас посмотреть и понять, оригинальный Ethernet не был предназначен для коммутации и не был предназначен для работы в провайдовских сценариях. Это был протокол для организации локальной сети с использованием одного большого провода, в котором, возможно, были коллизии. В этом проводе любые два участника, которые теоретически могли передавать друг другу данные, они же могли устроить и коллизии. У вас вот этот вот провод, он же был областью,

в пределах которой вы могли передавать данные. В современном смысле это называется братказ домен, шариковещательный домен. Он же по определению был доменом коллизий. Ну, и он же, можно сказать, что он был такой честный L2. То есть вот почему я сейчас использовал термин L2? Потому что оригинальная модель OSI, которую мы все знаем, семиуровневая, она делится на уровни. И эти уровни, вопреки популярному мнению, к ним не относятся протоколы. Когда мы говорим, что, допустим, протокол Ethernet это протокол второго уровня, нифига не так. К протоколам к уровням не относятся. К протоколам относятся задачи, которые решаются для сетевого взаимодействия. Протоколы как раз решают задачи. Физический уровень, это первый уровень модели OSI, это то, как вы организуете физическое взаимодействие в пределах одного провода. Как вы, какое напряжение выбираете, какое сечение провода. И результатом решения всех задач первого физического уровня у вас будет то, что вы можете вообще передавать какие-то данные,

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

Плюс надо будет сказать, кому конкретно данные передаются. Здесь появляется какая-то адресация. Часть битиков мы будем передавать с полезными данными, а часть с какими-то служебными заголовками, в которых будет указано, кому мы это дело передаем. Потому что иначе все узлы будут принимать эти данные на физическом уровне. И никто не сможет понять, это им вообще или не предназначено. Здесь уже у нас появляется задача контроля качества доставки в пределах провода. То есть если что-то побилось по дороге, там та же самая коллизия произошла, то понять, что данные, которые прибежали, это неупорядоченная, неосмысленная последовательность, это просто какой-то набор бит, который мы неправильно считали из канала. Поэтому, когда мы говорим про L2, это как раз взаимодействие в пределах натурального провода. То есть у вас есть две железки, которые соединены прям прямым проводом, физически прямым проводом. Когда мы сегодня говорим про протокол Ethernet, называемый протоколом L2, это не L2, это другое кое-что. И чуть дальше я покажу, что это именно такое.

Собственно, вот здесь сейчас как раз и покажу. Современные Ethernet, они не используют прямые провода, они используют коммутацию. И коммутация — это на самом деле эмуляция одного толстого желтого коксяла. То есть если у нас есть коммутатор Ethernet, что он делает? Он берет провода, которые у нас смотрят на каждый провод в отдельный порт. И он делает так, чтобы абоненты, которые сидят за этими проводами, они бы вообще даже не знали, что в серединке между ними есть какое-то устройство. То есть вот у нас есть абонент узел А, вот у нас есть абонент узел Б. Они чтобы думали, что они находятся в одном большом проводе. И узел С, здесь который есть, и узел Д, чтобы они тоже все думали, что они действительно в одном проводе находятся. Но физически бы они в одном проводе не находились. Сигнал, который передаёт узел А, и сигнал, который передаёт узел Б, они бы не сталкивались между собой, не формировали бы коллизию. Поэтому каждый провод — это у нас домен коллизий, в котором может возникнуть ситуация, что у нас случилась коллизия. Но между разными проводами у нас коллизия распространиться не может,

потому что сигнал, который передаётся на одном проводе, он не передаётся дальше в другие провода. Но здесь возникает вопрос. А, вот нам, если очень хочется информацию, которая пришла в одном проводе, передать дальше в другой провод, что мы в этом случае будем делать? И в этом случае мы решаем задачу третьего уровня – перекладывание данных между проводами. У нас сигнал прошел в одном проводе, мы должны переложить его в другой провод. И это задача третьего уровня модели OSI – межсетевое взаимодействие. Сетевой в этом случае у нас есть один network, один канал здесь, другой network, один канал здесь. Мы должны эти два канала объединить между собой, чтобы решить задачу взаимодействия между ними. Это задача третьего уровня в оригинальном Ethernet, нерешаемая в принципе, потому что оригинальный Ethernet на коммутацию не был заточен. Вот. Коммутатор, когда мы говорим про чистую коммутацию в Ethernet, это устройство, которое действует в соответствии со стандартом не 802.3, а 802.1D. И некоторые другие стандарты, которые еще есть. То есть это не 802.3 стандарт, это 802.1.

Это уже не совсем Ethernet. Коммутация в соответствии со стандартом 2.1D может работать и не с Ethernet, в том числе, гипотетически. По факту мы всегда будем видеть, что там в 100% случаев Ethernet, но это просто потому, что все остальное вымерло. Что делает коммутатор в таком случае? Он объединяет несколько разных проводов, несколько разных доменов коллизий, физически разные домены коллизий, объединяются в общий широковещательный домен. У нас эмулируется широковещательный домен. Поэтому, если вдруг вы объединяете несколько проводов в одну среду передачи данных, вот сегодня мы говорим, что это будет один общий братсказ домена. На самом деле, это виртуальный широковещательный домен. По-честному, если говорить про широковещательный домен, у нас вот этот вот провод, этот домен коллизий, он же сам с собой широковещательный домен. Вот этот вот провод, это отдельный провод, и он же тоже сам с собой широковещательный домен. Но если мы объединяем эти два провода в один широковещательный домен, то мы говорим, это у нас по факту общий широковещательный домен, состоящий из двух проводов.

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

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

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

наличие или отсутствие свитча никоим образом не видно. То есть, любой свитч пытается сделать так, чтобы абоненты и не поняли, что он вообще присутствует. Поэтому как абоненту вас отправляли какие-то кадры или принимали какие-то кадры, так они продолжают принимать. Безусловно, Switch не должен будет вести какую-то деятельность, которая препятствует получению кадров нормальными абонентами. Если узел А отправляет какие-то данные, вот он ожидает, что узел Б их получит, например, потому что он отправляет их на узел Б, явно в виде указа в его адресе. Вот в этом случае, естественно, коммутатор не должен делать то, чего не может сделать как СиАЛ. КОКСИАЛ не может сделать так, чтобы узел А отправил какие-то данные, а узел Б эти данные получил, а узел С не получил. То есть на уровне коаксиального провода все узлы получают все кадры, которые только были отправлены. Но в некоторых случаях коммутатор может немножко модифицировать поведение свое и может копии некоторых кадров не отправлять в некоторые порты, если посчитают, что в этом нет необходимости. То есть, например, если у нас есть узел А и узел Б,

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

И на самом деле я вам обещал, что я не буду рассказывать штуке, которые есть в CCNA. А в то же время вот про работу коммутатора в CCNA рассказывают. Так вот, если вы, особенно если вы учили принцип работы коммутатора по какой-то литературе, не по нашим курсам CCNA, вы с очень большой вероятностью на самом деле не знаете, как работает коммутатор. Потому что классические курсы CCNA или даже CCNP, а зачастую даже CCI-шные какие-то книжки, они рассказывают про то, что у нас коммутаторы действуют по-разному в зависимости от того, что там пришло на порту. Если у вас на порту пришел кадр Unicast, они говорят, мы тогда запускаем процесс Unicast forwarding. Если они говорят, видим, кадр какой-то broadcast пришел, значит, процесс broadcast forwarding. Если пришел какой-то кадр Unicast, но мы не знаем, где он находится, мы запускаем процесс Unicast фладинга. Типа это вот все разные процессы, и в зависимости от того, что пришло, вот оно по-разному как-то себя ведет. Это неправда. То есть суровая правда жизни заключается в том, что процесс, по которому работает коммутатор,

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

Вообще никогда, ни при каких обстоятельствах. То есть если мы получили копию кадра, просто кадр какой-то, вот мы дальше думаем, на какие порты его отправить. У нас коммутатор там 24-портовый. Вот один порт, на котором кадр был получен, сразу вычеркивается из потенциального набора выходных портов. То есть ни при каких условиях копия кадра обратно не отправится. Дальше. Не надо отправлять копию кадра, если у вас есть порт, который принадлежит той же группе агрегации. На CCNA мы проходили, что можно взять несколько портов, простите, объединить в один логический порт. Это в циске называется EtherChannel, в стандарте называется aggregation, в некоторых вендорах называется bundling. Ну то есть если у вас есть несколько портов, которые формируют одну и ту же группу, вот любой кадр, который пришел из любого порта в этой группе, обратно в те же самые порты, которые формируют ту же самую группу, не передается никогда. Никогда не отправляется копия кадр в порт, если этот порт был заблокирован Spanning 3.

И еще один момент здесь не написано, но никогда не отправляется вообще никуда копия кадра, которая пришла из-под порта заблокированного Spanning 3. То есть если кадр, входящий на порту, на котором Spanning 3 сказал блокинг, соответственно, кадр сразу выкидывается, на всех портах он фильтруется. Никогда не отправляется копия кадра, если у нас порт заблокирован Storm Control. Ну то есть, опять же, вендорский механизм, но во многих вендорах есть. Если вдруг на порту обнаружена какая-то нездоровая активность, у нас Storm Control может придушить коммутацию на этом порту. Но вот в этом случае мы не отправляем копию кадра туда, куда Spanning 3, не Spanning 3, а Storm Control будет блокировать. Мы не отправляем копию кадра в порт, если этот порт не просоциирован с тем же VLAN. Здесь, опять же, если вы CCNA проходили в каких-то других учебных центрах, если вы его изучали по книгам, то вы можете думать, что у нас VLAN, это вот всегда про метку 802.1Q. На самом деле нет. У нас есть широковещательные домены,

и вот эти широковещательные домены, каждый VLAN это каждый широковещательный домен. Мы на свече, если говорим, у нас на свече есть обработка кадров определенного VLAN, мы фактически создаем указание, что мы создаем новый широковещательный домен, с которым будут просоциированы некоторые порты. И вот если мы принимаем какой-то порт, на каком-то порту кадр, мы этот кадр ассоциируем с некоторым VLAN, который у нас на коммутаторе создан. Мы должны будем назначить этому кадру так называемый VLAN ID или VID. Никакого отношения к метке это не имеет. То есть если это транковый порт, если там 802.1Q на заголовке есть, если вы этим заголовкам доверяете, вы можете прочитать метку 802.1Q, посмотреть на то, что у вас там в Control Information содержится, прочитать указание на номер VLAN, вы можете довериться этой метке и назначить VLAN ID в соответствии с тем, что в этой метке прибежало. Но это процесс как бы напрямую не связанный. То есть вы можете иметь или не иметь транк.

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

мы понимаем, что это кадр 10-го VLAN. Фактически мы на нем пишем, что это 10-й VLAN. Только не 800 2.1Q-шную метку ставим, а вот просто отдельно как-то понимаем, что это кадр 10-го VLAN. И дальше говорим, с 10-м VLAN проассоциирован вот только второй порт. Третий и четвертый порт с VLAN 10-м не проассоциирован. Поэтому копия кадра потенциально никогда вот сюда вот и вот сюда вот не отправляется. А сюда может быть отправиться, если вдруг мы посчитаем это необходимым, если вдруг никакое другое решение коммутационное, они скажут, что на этот порт копию кадра отправлять не надо тоже. Если у вас есть транковый порт, ну будет у вас какой-то порт, на котором и 10-й, и 20-й VLAN будут разрешены, значит, он будет смотреть и в 10-й, и в 20-й порт, он будет проассоциирован с обоими VLAN-ами, и копия кадра, полученного на вот этом порту, в этот порт исходящий транк может быть отправлена. Потому что у нас и 10-й VLAN может быть использован в нем, и 20-й VLAN тоже может быть использован. После того, как мы пробежали все порты, которые у нас есть на свече, и посмотрели на них, копию кадра на этот порт надо отправлять или не надо,

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

который ему адресован, даже если мы не отправим этот кадр на порту, за которым получателя нет. Поэтому если у нас есть 24-портовый свеч, и у нас на первом порту приходит какой-то кадр, который адресован узлу, про который мы знаем, что он сидит за вторым портом, на остальных 22 портах мы точно фильтруем отправку копии этого кадра. Вот это вот правило. Мы никогда не отправляем копию кадра в порт, если получатель известен за другим портом, на самом деле реализует логику Unicast forwarding. Кадр приходит на одном порту, кадр уходит из-под другого порта. Просто потому, что он очень редко приходит из-под того же самого порта, где сидит получатель, и поэтому получатель известен за каким-то другим портом, через один порт вошел, через другой вышел, на всех остальных мы его заблокировали и не отправили копию кадра. Если мы приняли какой-то кадр, и в нем написано, кому адресован этот кадр, и мы видим, что этот кадр адресован Вася, а Васе у нас неизвестно, кто неизвестно за каким портом сидит, то это правило не срабатывает,

и мы разбрасываем копии кадра по портам в соответствии с другими правилами. По умолчанию разбрасываем по всем портам. Но при этом мы не отправляем копии кадров в заблокированные порты, мы не отправляем копии кадров в порты, которые в той же группе агрегаций, и все ост Soph. Так. Для того, чтобы понимать, за каким портом кто сидит, коммутатор будет использовать некую табличку, в которой он будет вести учет, кто где находится. Соответственно, в этой табличке будут указываться, за каким портом сидит какой MAC-адрес, и плюс к тому, есть, чаще всего мы в коммутаторах будем иметь поддержку Виланов, соответственно, будет идти на самом деле не пара MAC-адрес плюс порт. Атройка. MAC-адрес плюс Вилан плюс порт. То есть, в каком Вилане, за каким портом, мы знаем, кто где сидит. Один и тот же MAC-адрес не может быть виден за несколькими портами. То есть, не может быть такого, что мы знаем, что Вася сидит и за вторым, и за третьим портом. Это нелогично.

Но в то же время, мы можем знать, что за одним и тем же портом может быть несколько MAC-адресов соседей. То есть, мы знаем, что за каким-то портом сидит Вася, Петя, Коля и Сережа. Это нормально, они сидят за свечом. Ну или они могут сидеть не за свечом, они могут сидеть в толстом желтом коаксиале. То есть мы на свече говорим, у нас есть некий порт. За этим портом сидят MAC-адреса Вася, Петя, Коля, Сережа. Может быть, здесь есть другой свеч, на этом свече сидят 4 абонента. Может быть, там соседнего свеча нет, потому что коммутатор, который там, возможно, находится, он пытается прикинуться толстым желтым коаксиалом. Может быть, он настолько хорошо прикинулся, что мы просто не заметили, там действительно толстый желтый коаксиал. Там Вася, Петя, Коля и Сережа. То есть то, что там есть коммутатор или нет коммутатора, мы доказать не можем. Мы видим, что на порту 4 MAC-а. Ну окей, 4 MAC-а. Может быть, это будет потому, что там действительно просто коаксиальный провод. Дальше. В этой самой табличке у нас должна быть информация,

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

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

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

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

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

Некоторые кадры будут ввести MacLearning в одну таблицу, некоторые кадры будут ввести MacLearning в другую таблицу. Когда у нас будет кадр принимать решение, на какие порты копия кадра отправляется, на какие нет, то вот процедура. Мы не отправляем копии кадра на тех портах, где точно нет получателя. Она будет как раз обращать внимание на таблицу коммутации, на таблицу, в которую идет MacLearning. И когда у нас приходит какой-то кадр, мы должны будем понять, соответственно, по какой именно таблице мы будем принимать решение, где получателя нет. Если мы знаем, что у нас есть некий получатель, который сидит за портом А, то, соответственно, вот это должно происходить применительно к одному и тому же VLAN. Обычно на коммутаторах поддерживается небольшое число этих самых виртуальных широкопрещательных доменов, виртуальных таблиц коммутации. Ну, то есть, если мы говорим про 802.1Q, максимальное количество VLAN теоретическое будет вот такое, 2 в 12 степени минус 2.

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

Например, мы прописываем, что вот на порту, который смотрит на вот этого абонента, все кадры будут получать VLAN ID 10. В самом кадре этого не написано. Это написано в конфигурации, что все, что пришло из-под обычного порта абонента, все получает VLAN ID 10. Соответственно, все кадры будут коммутироваться по таблице 10-го VLAN. У нас есть указание, что в 10-м VLAN коммутируются вот эти вот двое товарищей. Соответственно, если вдруг мы принимаем решение, куда копии кадров мы отправляем, мы смотрим в отдельную табличку 10-го VLAN. Мы не смотрим в табличку 20-го VLAN. И мы никогда копии кадров в те порты, которые не просоциированы с 10-м VLAN, не отправляем. То есть сюда копии кадров отправляться не будут по-любому. Они с 10-м VLAN не просоциированы. Если у нас есть порт, который смотрит на соседний свитч, и в этом проводе на соседний свитч мы хотим отправлять кадры, которые относятся к разным широкопрещательным доменам, то у нас есть сложность, заключающаяся в том, что по одному и тому же порту будут передаваться кадры

разных широкопрещательных доменов. И логика, которая работала с обычными абонентами, что все, что приходит от абонента, всегда получает один и тот же VLAN ID. Здесь уже работать не будет. То есть вот у нас есть пользователи одного широкопрещательного домена, и они разбиты по двум разным свитчам. И пользователи другого широкопрещательного домена, они тоже разбиты по двум разным свитчам. Провод между ними всего один. Мы не можем сказать, что все, что приходит по этому проводу, вот здесь вот, оно получает метку 10-го VLAN. Это будет неверно, потому что вот здесь у нас, может, 10-й VLAN есть, и здесь тоже 10-й VLAN есть. Но вот здесь у нас 20-й VLAN. И кадры 20-го VLAN по этому проводу бегают тоже. Поэтому для того, чтобы указать, под какой таблицей кадр будет коммутироваться, какой именно VLAN ID нужно будет ему назначить, в какую таблицу будет идти MacLearning на получающем коммутаторе, отправитель может сделать подсказку. Он на кадр делает пометочку и говорит, вот этот кадр отправляется с меточкой 10. Если получающий коммутатор будет доверять этой метке,

он может сказать, я вижу, что коммутатор мне отправил подсказку, я принимаю эту подсказку, я доверяю тому, что мне соседний коммутатор эту подсказку отправил, я ее прочитаю. Я увижу там число 10. Вот это вот 10 мы будем надавать словом метка. И дальше эта десятка, которая в этой метке хранилась, срабатывает как VLAN ID. То есть метку прочитали, увидели там число 10, назначили на кадр VLAN ID 10. VLAN ID — это сущность, которая существует только в представлении самого коммутатора. Она нигде по сети не передается. Но, соответственно, метка — это сущность, которая есть в кадрах, которые бегут по проводу. Мы можем эту самую метку увидеть, потому что она записывается в сам кадр. Для того, чтобы записать эту метку, придется формат кадра немножко модифицировать, но все равно мы можем взять, запустить в Airshark, мы можем взять, запустить там осциллограф, померить, увидеть какие-то колебания в проводе и понять, что да, там метка передается. То есть метку видеть можно.

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

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

кадр пробежал в виде ноликов и единичек по проводу, в виде вольтов там каких-то, и дальше на порту получателя метку выкинул получатель. Кадр восстановил свое оригинальное значение. То есть у нас вот здесь вот был какой-то кадр, здесь он передается по проводу с маркировкой, здесь кадр восстанавливает свое оригинальное значение. После того, как кадр пошел про танковую порту и пришел на порт получателя, в нем метки больше нету. 802.1Q заголовка у этого кадра больше нету. Но зато у него есть VLAN ID 10. Потому что мы прочитали метку, мы прочитали, что в ней было написано число 10, и мы выкинули оригинальную метку, но VLAN ID мы при этом назначили в соответствии с тем, что в этой метке было. Обратите внимание на следующий очень важный факт. 802.1Q метка и VLAN ID – это не связанные между собой сущности. Они могут быть разные. Вам никто не мешает отправить кадр с меткой 10, а VLAN ID ему назначится 100 или 200. То есть то, по какой таблице коммутируется кадр, то и туда идет MacLearning. И то, что написано в 802.1Q метке –

это вообще не связанные вещи. Часто связанные, часто они похожи друг на друга. Если написано в метке 10, значит, VLAN ID будет 10. Но оно совершенно не обязано так быть. Так. Как будет выглядеть кадр с маркировкой 802.1Q? Я думаю, что вы знаете. Между отправителем-получателем и следующим двухбайтовым полем, которое может быть либо из артайп, либо длина, и на которое транзитные коммутаторы не обращают внимания. Потому что транзитные коммутаторы смотрят, куда идет кадр, какие порты надо будет зафильтровать, копию кадра, и откуда идет кадр. Соответственно, куда провести MacLearning, на какой порт, на какой MAC-адрес. Дальше все остальное транзитному коммутатору неинтересно. То есть если у нас есть коммутатор, который сидит и смотрит на абонентов, вот он смотрит на получателя, он смотрит на отправителя, все остальное ему по барабану. Ну вот еще на чексуму смотрят. Но если мы говорим, что у нас есть два коммутатора, которые будут смотреть друг на друга, в этом случае нам некуда записать метку 802.9, например.

И в этом случае мы добавляем новое поле после отправителя-получателя. Но для того, чтобы понять, что это поле проставлено, для того, чтобы доказать, что кадр у нас изменился, в то место, где у нормального кадра лежит число EtherType, в кадрах модифицированных будет лежать вниз, как ни странно, число EtherType, 8100. То есть вот если вы 16-ти ричное значение 8100 видите, это кадр-мутант, кадр, который мы дописали доп.заголовок. Соответственно, если вы хотите выкинуть эту самую метку 802.1Q, вы вычеркиваете все, что дальше есть, и вы получаете оригинальное содержимое кадра. Но есть нюанс. То, что у вас получилось, должно остаться валидным кадром Ethernet. Поэтому чексума, которая у вас раньше была, вы выкидываете при добавлении метки и делаете новую. Ну и когда вы выкидываете метку 802.1Q, модифицированную чексуму вы тоже выкидываете и восстанавливаете оригинальную старую. Чексума вам доказывает, что то, что прибежало вот в этих вот данных, оно не побилось по дороге. Поэтому если вы восстанавливаете кадр в том виде,

в котором он был изначально, то чексуму вы тоже, естественно, восстанавливаете оригинальную. 802.1Q кадры будут иметь EtherType 8100. И из 4 байт, которые добавляются в рамках 802.1Q-шного заголовка, 2 байта вот занимают этот самый тег протокола Identifier. Еще 2 байта тег Control Information добавляются 16 бит. Вся полезная информация, которая хранится в заголовке 802.1Q. Среди прочего, там хранится 12-битный номер VLAN. Еще там хранится 802.1P-шные 3 бита приоритета и 1 битик, который раньше назывался Discard Eligible Identifier. Да и если вы отправляли какой-то кадр и вы хотели сказать, что это просто... Простите, раньше этот флаг назывался canonical формат Identifier. Если вы хотели отправить кадр и вы хотели сказать, что этот кадр нативный Ethernet-овский, что можно проводить процедуру MacLearning, вы там выставляли нолик. Если вы хотели отправить кадр и сказать, что в этом кадре какие-то кривые MacAdress

и процедуру MacLearning по этим MacAdress вести нельзя, что встречалось в случае, если вы инкапсулировали токен ринг в Ethernet, можно было такое делать в свое время. Вот в этом случае вы там выставляли единичку. С 2014 года битик canonical формат Identifier устарел. Вместо него используется битик Discard Eligible Identifier. Если вы хотите отправить просто кадр, вы выставляете в нолик. И поэтому кадр, который просто отправляется, он неотличим от кадра, который просто Ethernet-овский кадр в старой логике. Соответственно, если вы выставляете в единичку этот битик в кадре, то в современной логике это означает, что кадр можно при перегрузке выбросить. То есть вы можете не заполнять 802.1.p биты приоритета три штуки, но вы можете поставлять, что некоторые кадры будут более важны или не более важны. С 802.1.q очень хорошо живется предприятие. Вы можете взять и широкопричательный домен, который у вас формируется при использовании,

например, неуправляемых свечей, разбить на несколько не пересекающихся широкопричательных доменов, которые формируются на свечах с виланами. Но есть нюанс. Если вы провайдер, вы, конечно, можете использовать 802.1.q и вы можете сказать, что вот у вас есть там провайдерские абонентские свечи, которые смотрят на 24 абонентов и у него есть там какой-то апплинк. Ну и получается, что вот у нас есть абонент Вася, Петя, Коля, Сережа и каждого из них мы можем там запихать в свой отдельный вилан. И покуда Вася, Петя, Коля, Сережа присылают просто обычные кадры изернета, все работает замечательно. Они доступа к этим самым меткам вилана не имеют и все как бы хорошо. Но проблема заключается в том, что в какой-то момент у вас появляется клиент предприятия. Предприятие говорит, вот у меня есть офис в Москве, у меня есть офис в Питере, и я хочу, СПБ, я хочу, чтобы у меня между Москвой и Питером отправлялись бы кадры изернета. Могу я такое сделать? Могу. Но я хочу,

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

из Арнен, да? Да, у них из Артаев 81.00 проставлен, ну и что? Мы можем еще одну рядышком такую же метку поставить. Вот у нас будет две метки, там, кадр будет идти, оригинальный кадр был, там, не знаю, с IP, из Артаев у него был 0800. Дальше мы проставили, не мы, а клиент проставил метку, там, не знаю, какую-нибудь 8100 и вилан номер, там, не знаю, 12, и мы как провайдер говорим, ну, на такой кадр мы еще раз налепляем 802.1Q метку. У него было вот здесь, вот, 0800, здесь у него было 8100 и, соответственно, метка 12, а мы говорим, вот мы хотим на этого клиента назначить вилан 123. Окей, не вопрос, 8100 и 123. Но возникает проблема. Проблема возникает с тем, что непонятно по внешнему виду кадра, вот эта 8100 это ваша метка или это метка вашего клиента. Поэтому, когда вот такую вот идею Циско предложила,

говорите, ну, давайте делать две метки, в чем проблема-то. Индустрия на это дело посмотрела и сказала, да, две метки – это хорошая идея, но давайте мы будем две метки вешать разные, чтобы было видно, какую метку проставил клиент, а какую метку проставил наш провайдерский свеч, чтобы не получилось, что клиент проставил какую-то метку, а мы дальше случайно по ней сориентировались. Поэтому для того, чтобы в провайдерских сценариях не путаться, какую метку проставил клиент, какую метку проставил провайдер, используются два разных типа меток. Соответственно, внутренняя метка будет называться Customer Tag, C Tag, вот это вот, вот это, это то, что клиент вам отправил. А провайдерская метка будет называться Service Tag. И, соответственно, Service Tag будет иметь Ethernet, Ether Type, простите, не 81.00, а 88.00. То есть, вот это вот Ether Type 88.00, а 8 специально означает, что это 802.1Q метка, но проставленная дополнительно к клиентскому кадру, который приходит. В этом случае нам не важно, есть у клиента

вот эта вот метка или нет. То есть, клиент может нам присылать кадры с метками, может присылать кадры без меток. Мы просто по своим меткам, которые мы поставляем, отправляем этот кадр куда-то дальше. В чем преимущество такой схемы? Что вы, как провайдер, абсолютно абстрагируетесь от клиентских Виланов? У вас клиент проставил номер Вилана 12, не проблема, он может проставлять там хоть миллион, если влезет в два байта. Вы используете метку 123, что позволит вашему свечу, там, если мы хотим, не как здесь нарисовано, давайте два разных свеча, один в Питере, другой в Москве. Вот здесь вот мы будем передавать кадры с двумя метками, и они будут идти со 123 сервис-провайдерской меткой, S-Tag. А то, что кадры будут отправляться действительно в сторону клиентских свечей, там, питерских и московских, с какими-то метками Вилана, которые клиент проставил, ну да, будут отправляться. Вот. Хорошая идея. Кажется, хорошая. Но есть нюанс. Нюанс заключается в том,

что маки при этом все равно у вас остаются. То есть кадр, который был, вот кадр, который прислал клиент, у него там какая-то метка 802.1 кьюшная, какой-то изортайп, какой-то вот данные какие-то бегут, чек-сумма. Все здорово, да? Но не здорово вот это вот, что мак-адреса у вас в этом случае все клиентские будут видны. Вы будете их натурально лернить. То есть в свой 123 Вилан вы все равно мак-адреса клиентские будете лернить по-любому. И если у вас абонент захочет носовать вам 100 тысяч миллионов мак-адресов, они все равно будут лерниться. И, скорее всего, будут забивать вашу таблицу коммутации. Ничего хорошего от этого, как вы понимаете, не будет. Потому что таблица мак-адресов, она не бесконечная, память не резиновая, и рано или поздно она заканчивается. А если у вас закончилась память под мак-адреса, дальше все клиенты начинают у вас страдать. Поэтому 802.1.ad это стандарт, который помогает в простом сценарии взять и наклеить вторую метку 802.1.q. Здесь надо различать просто Q&Q. Это фирменное

цисковское наименование ситуации, когда вы две 8100 метки вешаете на один и тот же кадр. 802.1.d это та же самая логика. Мы делаем два заголовка формата 802.1.q., но метка у нас получает из RTI 88.a8, наружная метка. А внутренняя остается 8100. Это две разные сущности, очень похожи друг на друга, но вот Q&Q обе метки 8100, 802.1.ad это метка, сервисная метка 88.a8. Если мы хотим абстрагироваться от клиентских мак-адресов тоже, то есть не просто виланы иметь обособленные, а вот еще и мак-адреса иметь обособленные, то индустрия предложила для этого механизм, который называется мак-н-мак 802.1.h. Он же провайдер Backbone Bridges. Смысл заключается в том, что клиент присылает нам какой-то кадр, у этого кадра, ну там сначала идет преамбула, понятное дело, но частью кадра не является, дальше мак-адрес отправителя, мак-адрес получателя, что внутри лежит, полезные данные и какая-то чексума.

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

и мы не хотим эти адреса лернить. То есть, в случае с 802.1 кьюшными мы должны будем лернить адреса. Мы в любом случае это должны будем делать по-любому. А вот в случае с MAC-н-Мак мы говорим, окей, к нам пришел какой-то кадр. Прекрасно. Мы делаем новый кадр, у которого этот оригинальный кадр будет вложением прямо целиком. И логика у этой штуки будет на самом деле очень сильно напоминать оригинальный протокол, который назывался ASL у ЦИСКи. Самый первый протокол транкинга, который ЦИСКи придумал до появления 802.1 кьюшного, до появления всего остального. Он на самом деле очень сильно напоминает этот самый механизм MAC-н-Мак. То есть, вы берете оригинальный кадр, оборачиваете его новым заголовком вместе со всем содержимым. То есть, содержимое заголовки оригинального кадра просто становится содержимым нового кадра. И у этого нового кадра заголовки будут иметь какие-то свои MAC-адреса. Вот это BDA, BSI. Это бриджи, которые формируют самый мост. Вот здесь у нас есть какой-то MAC-адрес, и у нас вот здесь есть какой-то MAC-адрес. Вот это MAC-адрес, сорс-адрес,

и здесь destination-адрес. Один свитч другому свитчу посылает какой-то кадр. Этот новый заголовок появляется в момент отправки кадра по провайдерскому транку, и, соответственно, в момент получения такого кадра, после того, как новый кадр будет получен, и вся информация из вот этого сервисного заголовка будет считана, сервисный заголовок выкидывается, восстанавливается оригинальное значение. В 802.1.i.h. помимо того, что у нас есть MAC-адреса новые, которые лернятся, у нас есть еще указание на номер VLAN, потому что, опять же, провод, к которому у нас передаются данные с одного и того же MAC на другой MAC, один и тот же, и нам нужно где-то здесь все-таки VLAN указывать. Этих VLAN-ов у нас будет, на самом деле, два. У нас будет раз, вот эта вот метка. Эта метка будет очень похожа на ту метку, которая была в 802.1.ad. То есть, в Tag Protocol Identifier вот это BTPID, Bridge Tag Protocol Identifier, у нас вкладывается число 88.a.8.

Дальше BTCI Tag Control Information вкладывается номер VLAN-а и 802.1.p. Ну, в общем, это просто обычная 802.1.q-шная метка просто с сервисным тегом 88.a.8. Здесь номер VLAN-а, там указывает 123 VLAN-а, что это у нас именно клиент, которого мы хотим трактовать как клиента 123-го. здесь и клиента 123-го здесь. Это по какой таблице коммутации у нас все в итоге должно будет коммутироваться на наших провайдерских фичах. Но есть также и вот такая вот фиговина. Шестибайтовое поле, которое будет указывать на то, с каким типом услуги мы будем иметь дело. Сначала идет двухбайтовое поле Service Tag Protocol Identifier. Здесь 88.a.7 будет храниться число. И дальше во флагах я не помню там, что хранится, а вот интересная штука будет храниться вот здесь. Вот трехбайтовое поле, в котором указывается тип услуги. Вы можете отправить не просто указание, что я продаю, я передаю

по провайдерскому вот этому самому транку, специальному хитрому, кадров 123-го широкопрещательного домена, который надо отправить на клиента. Вы можете там рассказать, что это за трафик, то есть какой он, и вы можете в зависимости от типа этой самой услуги делать разные вещи. Вы можете сказать, ага, это, например, кадр, кадры, что у нас там бывает из того, что было бы интересно, ну, не знаю, мультикастовое телевидение, к примеру, да? Вот, соответственно, кадры, которые относятся к этому типу услуги, они достаточно быстро должны проходить по сети, они сразу небольшие, у них есть ограничения по объему, они не превзойдут определенную полосу. Ну, и, соответственно, мы их обрабатываем одним образом. Если у нас есть какие-то другие типы услуг, мы говорим, окей, это значит, будет другая услуга, и вот здесь, вот в трехбайтовый тип услуги или код услуги мы можем записать, соответственно, много-много, там 16 миллионов разных значений. Это, ну,

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

метки 8002.1Q, был 1522 байта. Прям был, частью кадра не является. Если вы оборачиваете все это дело еще мак-н-мак заголовком, то у вас здесь 6 плюс 6 плюс 2 14 плюс 2 18 плюс 2 20 плюс 4. 24 байта дополнительно вырастает ваш кадр. То есть 1522 байта было, минус 4 байта плюс 20 байта, 1542 байта у вас получается в итоге. То есть максимум размер кадра становится больше на 4 байта. Это много. Так, я нигде не ошибся. Я, наверное, где-то ошибся, да? Я ошибся на 4 байта. 1546 байт. Суму забыл посчитать. Вот. Так что если вы можете это себе позволить, пожалуйста, используйте. То есть вы тем самым себя защищаете максимально, насколько это вообще возможно. так.

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

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

Провайдеры не хотят передавать тот трафик, который уйдет в никуда. Во Frame Relay у нас для этого была сигнализация. У нас был LMI, который притаскивал живые DLC-айки. То есть, если абонент в сети находится, тот, с которым вы можете вести взаимодействие, вам сигнализация скажет, вот такая-то там 400-й DLC-айка живая. В Ethernet авторы протокола оригинального такой возможности, естественно, не предусмотрели, потому что просто толстый, желтый, как сел, там ничего не предусмотрено, никакую обратную связь. Но в случае, если мы делаем сеть на коммутаторах, мы можем предусмотреть возможность получения обратной связи от сети, пройдет ли некоторый кадр до получателя или не пройдет. Механизм будет называться OAM, Ethernet Connectivity and Fold Management. Он описывается несколькими стандартами, в том числе 802.1.AG. И, соответственно, работать он будет следующим образом. У вас есть абонентские железки, которые могут отправлять обратную связь, могут отправлять сигнализацию, которые скажут, что со мной все хорошо,

я живой. И вот сообщения, которые будут идти в рамках этой самой обратной связи, они будут проходить через провайдерскую сеть, и провайдерская сеть будет эти самые сообщения клонировать на все узлы, с которыми, получается, будет разрешено вести взаимодействие. То есть, смотрите, у нас есть вот эта вот провайдерская сеть, P-сеть, P-network. К провайдерской сети у нас подключены роутеры клиента. Клиентский роутер 1 и 2. Мы на клиентских роутерах просим включить так называемый MEP, Maintenance Endpoint. И вот эти вот MEP начинают отсылать специальные сообщения вида «Я живой». Провайдерская сеть, она подключает же не только этого клиента, там много клиентов на их свечах находится. Но вот среди прочих есть и другие роутеры того же самого клиента, другие железки того же самого клиента. И MEP, отправляя сообщение со мной, все хорошо, отправляет это сообщение на свитч провайдера. Свитч провайдера говорит «Окей, я знаю, что этому клиенту

разрешено вести взаимодействие с вот такими вот соседскими портами». И он во все эти соседские порты отправляет копию сообщений. Не копия сообщений, там чуть более сложная штука. На самом деле там LDP-шные сообщения будут посылаться с указанием того, что вот у нас есть MEP CE1, который сейчас прямо живой. То есть сигнализация начинает расползаться по сети, все участники сети, которые получат такое сообщение, поймут, что вот эта вот железка, она в сети присутствует. В том числе такое сообщение получит и CE2, роутер CE2. То есть у нас MEP CE2 получит сообщение о том, что в сети живет MEP CE1. Он увидит MAC-адрес этого самого CE1 и сможет понять, что если он хочет отправить кадр из Эрнета в сторону CE1, то, соответственно, трафик такой пройдет по сети. То есть CE1 роутер живой, с ним все хорошо. Если у нас есть какой-то другой роутер, тоже того же самого клиента, который точно в том же самом, ну, если хотите, в Вилане находится, да,

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

То есть если вдруг вы будете говорить, что ваши роутеры должны принимать во внимание результаты этого самого мепа, то в этом случае лишний трафик они просто отправлять не будут. Со стороны провайдера нужно будет сделать небольшие ответные действия. Дело в том, что вот эти вот кадры у АМА, они не совсем обычные кадры, они некоммутируемые. То есть на самом деле, когда они идут, они идут на порт, ну, если хотите, на порт свеча, провайдерского, дальше свеч должен будет эти кадры прочитать, увидеть, что в них содержится, и на всех остальных портах он отправляет не копию оригинального кадра, он отправляет информацию о том, какие узлы живы за ним, то есть какие мепы на нем зарегистрированы, если хотите. Вот, поэтому на стороне провайдерского свеча нужно будет включить штуку, которая называется maintenance intermediate point. Кадры у этого самого ОАМа будут точно похожи на LLDP, то есть они точно так же будут передаваться в snap-вложении

на такие же MAC-адреса 01800C, так называемый кадры slow protocol. И у кадров ОАМ есть три основных типа, с которыми приходится работать. Первый — это continuity check message. Это просто обычные сообщения типа «Я живой». Это сообщения, которые идут на специальный мультикастовый адрес, и они расползаются по всей сети. То есть у нас расползаются сюда, сюда, сюда, сюда, сюда. То есть вы отправляете один такой кадр, а его сама сеть дублирует на все остальные точки. Второе сообщение, которое есть, это сообщение своего рода ping. То есть если вы хотите узнать, жив ли конкретный сосед, с которым вы потенциально могли бы иметь хорошее взаимоотношение, ну вот вы некоторое время назад видели от него такой вот continuity check message, и вы хотите проверить, он прямо сейчас живой или нет, вы можете отправить на него ping. И вы отправляете такой ping, и у вас одна железка в Ethernet,

и может pingать другую железку в Ethernet. Это ping не тот, который в ACMP ping, потому что для ACMP-пинга нужно, чтобы был живой IP, нужно, чтобы был живой ACMP-протокол, чтобы там правильно все корректно было прописано, чтобы нигде ничего не терялось. Эта штука работает прямо в Ethernet. То есть у вас сам Ethernet позволяет с помощью специального хитрого вложения отправить кадр, на который получатель должен будет отреагировать так же, как если бы он получил настоящий ping ACMP, что он в ответ вам отправил сообщение «Я живой». Вот эти вот самые loopback messages, это сообщение типа «Ты живой?» «Да, я живой». И есть еще одна штука, которая называется Trace Road Messages. По сути своей, это как трассировка в ACMP, то есть вы отправляете пакеты, которые вызывают какую-то реакцию на всех транзитных узлах. И транзитные узлы должны будут отреагировать на такие сообщения и отправить вам что-то в ответ. Работает это следующим образом. Вы отправляете кадр. Этот кадр не содержит никакого поли-ттел.

Он просто коммутируется по… Ну, не коммутируется, он распространяет информацию по стандартным правилам вот этих самых CCM. То есть мы отправили один кадр на провайдерскую железку. Провайдерская железка отправляет эти кадры на все порты, которые проассоциированы с тем же самым VLAN. Дальше здесь то же самое происходит. Копии кадра получают вообще все. Но параллельно с тем, что информация в этих самых Trace Road Messages распространяется на всех получателей, дополнительно в сторону отправителя отправляется сообщение «Я все сделал». И, соответственно, вы получаете этот кусочек данных Unicast от каждого транзитного свеча, который в сети у вас находится. И вы понимаете, что вы отправили сообщение «Как себя чувствует CE2?» И вы получили сообщение от PE1, что он в свою очередь прокоммутировал этот кадр, от PE2, что он в свою очередь прокоммутировал этот кадр. И вы получаете таким образом построенную трассу. Каким образом трафик от CE1 дойдет до CE2?

Это, еще раз подчеркну, не через ICMP делается. Это делается без подключения протокола IP. Вы внутри этого Ethernet можете вкладывать абсолютно любое вложение. Хотите, IPX гоняете. Но у вас есть механизм, который позволяет вам проверить, насколько корректно работает ваша Ethernet-сеть. Ну, не ваше, а ваше подключение к провайдеру. Насколько хорошо или насколько плохо вы можете работать с конкретной провайдерской сетью. То есть вот такие вот штуки, они существуют, и вы на них можете ориентироваться. Мы с вами не будем рассматривать пример того, как это настраивается, потому что, в принципе, где-то это используется, где-то это не используется. Так что сказать, что повсеместно это нужно внедрять, нельзя. Ну, как правило, хорошего тона, чтобы это бы работало бы. Так, дальше. Что еще у нас тут есть? Если у нас есть коммутатор, он будет заниматься, на самом деле, не совсем коммутацией. Как мы уже говорили, любой коммутатор работает по правилу,

что все кадры на всех портах клонируются, кроме тех портов, на которые копия кадра отправлять будет не надо. Эта техника, она будет очень сильно зависеть от процедуры MacLearning. И вот этот вот механизм, куда надо отправлять копии кадров, куда копии кадров отправлять не надо, он будет являться основой процедуры коммутации. Более правильно процедуру коммутации было бы назвать, на самом деле, процедурой бриджинга, потому что фактически то, что мы делаем при коммутации, мы объединяем в один широковещательный домен несколько разных доменов коллизии. У нас получается виртуальный широковещательный домен, содержащий в себе несколько проводов. И между этими проводами фактически то, что происходит, происходит перекладывание данных. Или как раз тот самый бриджинг. Если вы хотите, вы можете использовать эту самую процедуру. То есть если вы покупаете коммутатор, вы на самом деле используете эту процедуру в любом случае. Но вы при этом понимаете, что все кадры у вас коммутируются на основе заголовка Ethernet.

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

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

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

железка на него отреагирует через пять минут, если успеет. Так что механизм для того, чтобы защитить нашу сеть, нам нужен будет все равно. Если нам нужно построить два разных канала между двумя разными точками, мы все равно должны будем их построить. И для того, чтобы защищаться от петли, нам нужны будут какие-то дополнительные штуки. Первая штука, которую мы будем с вами вспоминать, на самом деле не то, что изучать, а вспоминать в рамках CCNA, это агрегация интерфейсов. Мы в CCNA эту штуку проходили, и вы наверняка помните, что это просто мы берем несколько параллельных проводов в Ethernet и объединяем их в один логический канал. Это иногда называется агрегация, иногда называется бандлинг, иногда называется Ether Channel. Ether Channel — это фирменное цисковское название. Технология Ether Channel состоит из того, что вы берете несколько проводов и соединяете их в один логический порт, плюс логика балансировки. Логика балансировки является неотъемлемой частью, неотъемлемой компонент технологии Ether Channel.

Изначально эту штуку придумала компания Calpana, которую потом купила Cisco, и, соответственно, вот Ether Channel — это технология фактически наследник самых первых механизмов агрегации каналов, если вдруг вам это интересно. Сегодня механизм агрегации каналов является стандартным, описан. Сначала был в стандарте 802.3.ad, вот троечка означает, что это связано с Ethernet. Но потом эту штуку перенесли в 802.1. 802.1.x.a. 2008 года стандарт описывает просто логику объединения каких попало каналов. Но опять же, потому что теоретически, гипотетически вы можете объединить несколько проводов разных, разной природы. В принципе, это совершенно не обязаны быть провода 802.3. Но чаще всего, естественно, мы объединяем именно Ethernet провода. Какая логика будет у работы коммутаторов, которые соединяют несколько проводов в один логический канал? Мы немножко изменяем логику коммутации,

тем самым, что если у нас какой-то кадр ушел в один порт, соответственно, он пришел в другой порт на другой железке, вот обратно в тот же самый группу портов этот трафик не уходит никогда. То есть, тем самым, мы добавляем дополнительную строчку в алгоритм разбрасывания копий кадра на все порты. Когда мы говорим, что у нас есть коммутатор, он любые кадры, которые на него приходят, разбрасывает на все порты, кроме некоторых. Вот правила, которые говорят «кроме некоторых», они как раз и говорят, что никогда не отправляем копий кадров в исходный порт. Никогда не отправляем копий кадров если мы знаем, что получатель не сидит за некоторым партом, что мы знаем точно, где он сидит, и он сидит не там. Вот еще одно правило здесь — это мы никогда не отправляем копию кадра на порт, который входит в ту же самую группу, в тот же самый агрегат, что и порт источника для кадра. То есть у нас есть, допустим, четыре порта. Первый порт, второй порт, третий порт и четвертый порт. И кадр, который пришел на первом порту, не отправится никогда в порт номер два, потому что он относится к той же самой порт группы.

Вы в соответствии с этой логикой можете управлять балансировщиком, и вы можете сказать, что трафик, который отправляется в вот такой вот логический порт, он отправляется поочередно, допустим, между первым и вторым интерфейсами. Часть трафика пойдет по одному интерфейсу, часть по другому, и вы тем самым можете гипотетически добиться балансировки трафика по двум разным интерфейсам. У вас два интерфейса есть, оба работают, оба forward traffic, и гипотетически производительность такого логического канала может быть больше, чем производительность одного провода. Если у вас там два гигабитных порта, вы объединяете их в группу, то гипотетически вы в такой логический порт можете носовать два гигабита трафика. По факту вы не можете всегда быть уверенны, что два гигабита вы в этот порт сможете носовать, потому что, во-первых, у вас будет балансировщик, который будет принимать решение, куда он балансирует трафик. Он может балансировать трафик по очень какому-то странному механизму. Например, он может балансировать трафик так, что весь трафик пойдет по первому порту,

а по второму порту не пойдет ничего. И тогда вы как бы номинально имеете интерфейс производительностью 2 Гбит, а по факту больше Гбит туда не влезает. Может быть такое, что у вас не прям все отправляется в один порт. Но, допустим, большие кадры отправляются в один порт, маленький кадр отправляется в другой порт, и вы видите там 100% загрузку одного интерфейса гигабитного и 1% загрузки другого интерфейса, тоже гигабитного. Но, соответственно, количество кадров одинаковое. Но за счет того, что в один интерфейс идут только большие кадры, а в другой порт идут только маленькие кадры, ну, опять же, загрузки получаются сильно разные. Поэтому механизм агрегации, как правило, не является надежным способом повысить производительность канала. Это механизм повышения надежности. Но в реальных случаях вы можете увидеть реальное повышение производительности. Даже если у вас балансировщик работает как-то не очень хорошо, ну, в среднем на 50% добавление второго интерфейса у вас по идее должно повышать производительность по-любому.

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

будет вызывать так называемый ресеквенсинг, что на получателя придет сначала один маленький кадр, потом другой маленький кадр, а потом большой кадр. У нас получается, кадр сначала шел первый, потом второй, потом третий, а на получателя пришло сначала второй, потом третий, потом первый. То есть эта штука, она вызывает лютые проблемы у реальных протоколов связи. Что TCP будет страдать от этого, потому что у него процедура ресеквенсинг будет вызывать неприятные эмоции. Что всякие голосовые приложения Voice over IP тоже от этого сильно будут страдать. Поэтому в реальных сетях оборудование не делают таким, чтобы оно выполняло загрузку кадра в наименее загруженный порт. Потому что ресеквенсинг — это абсолютное зло, и бороться с ним на уровне получателя не всегда будет возможно. Поэтому мы должны будем просто предотвратить ресеквенсинг и не допускать его возникновения. Как следствие, мы должны будем убедиться, что когда у нас есть кадры какого-то одного приложения, или если хотите, одного потока, чтобы они всегда шли в один и тот же порт.

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

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

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

Он может руководствоваться только содержимым заголовков. Но есть нюанс. Если вы используете, например, Телнет, у вас все заголовки в рамках одной и той же Телнетовской сессии будут одинаковые. У вас одинаковые IP-шники, source и destination. У вас одинаковые MAC-адреса, опять же, source и destination. У вас одинаковый протокол, содержимое протокола. У вас одинаковые, например, что там еще, TCP-UDP-шные порты. То есть вы можете на основании этих параметров принимать решение, куда девать кадр. Приходит кадр, который надо прокоммутировать в порт, и вы смотрите, что вот такие вот параметры у некоторых кадров будут одинаковые, значит, их надо всегда отправлять в один и тот же порт. Как проще всего это сделать? Если не ввести табличку, что вот мы только что прокоммутировали кадр с IP-шником, там, 1001, идущий на IP-шник 1002, с MAC-адресом таким, на MAC-адрес такой, с протоколом таким, там, TCP-порты такие. Вот чтобы не ввести табличку, не ввести по ней учет, кого, куда вы только что отправили,

очень просто. Вы берете вот от всего вот этого дела, считаете хэш. Если у вас два провода, вы говорите, хэш получился четный, прекрасно, отправляем наверх. Хэш получился нечетный, отправляем вниз. Какие бы пакеты ни были, у них у всех в рамках одного и того же приложения вот эта вот штука будет одинаковая, хэш от нее тоже будет одинаковый, и вам не нужно будет ввести табличку всех сессий, которые ваш свитч через себя пропускают. Ему достаточно будет от каждого кадра брать какой-то очень простой хэш и смотреть на результат, четный или нечетный. Ну, на самом деле, этих проводов может быть не 2, а 3, 4, 5. В этом случае вы можете брать остаток отделения от вашего хэша на указанное число проводов. У вас есть три провода, прекрасно, берете хэш, считаете остаток отделения на 3, на целый, сколько там остаток получается, и говорите, вот у нас там получается результат 0, 1 или 2. 0, значит, делится на целый, 1, значит, делится с остатком 1, 2, значит, остатка 2. Ну, вот прекрасно, вот вам номер порта, по которому надо все это делать, отправить. Эта штука бронебойная,

абсолютно надежная, и именно она называется зарчена. Вот эта вот логика балансировки, когда вы берете параметры пакетов, которые проходят через ваш коммутатор, берете от них какую-то простенькую функцию хэша и делите ее на целый, на количество портов. Для того, чтобы это все хорошо работало, оно у вас должно работать очень быстро, и, соответственно, по факту, там берется, на самом деле, не хэш, то есть хэш это как-то очень серьезный вочет, а вы просто ксорите это все, побитого складываете и смотрите последние 4 бита результата. Последние 4 бита вам дают 16 разных значений. Количество проводов, которые могут поддерживаться, например, той же самой цифрской, может быть до 8 проводов, поэтому поделить одно число на целое, на другое число, у вас всегда есть возможность. Чем хороша, чем плохая агрегация? Тем, что надежность канала, если вы берете несколько физических проводов, объединяя их в логический канал, у вас будет выше. То есть один провод сдоха, трафик продолжил ходить через второй,

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

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

вы должны будете убедиться, что у вас провода, которые формируют этот самый агрегатный канал, они проложены именно параллельно. То есть не должно быть такого, что на картинке нарисовано, когда у вас с одной железки какой-то идут два провода, которые с ее точки зрения объединены в логический канал, которые идут физически на две разные железки. Почему такое делать нельзя? Дело в том, что у вас по факту в этом случае будет возникать такая полупетля. И несмотря на то, что полной петли у вас здесь не возникнет, как следствие у вас не будет, например, шторма. Но у вас будут проблемы, которые вызывают негативные последствия, которые характерны, в общем-то, для петли. Например, у вас есть абонент. Этот абонент – узел А. Он хочет отправить широковещательный кадр. Он формирует кадр, говорит, я узел А, отправляю бродкаст. Отправляет его на Switch. Switch говорит, я должен отправить бродкаст. Что с бродкастом мы делаем? Мы его разбрасываем на все порты, кроме порта источника и каких-то других портов тоже. То есть мы не используем логику вида

бродкаст, неизвестно, откуда пришел, поэтому мы его там блокируем. Мы его разбрасываем на все порты, но если у нас есть вот такой вот логический канал, то мы отправляем такой бродкаст только на один порт в этом бродкаст. На один порт в этом логическом канале. Такой бродкаст доходит до свеча получателя, до вот этого верхнего свеча. Что делает он со своим бродкастовым кадром? Он его разбрасывает на все порты, кроме порта источника. Разбрасывает на все, все, все порты, в том числе и на тот порт, который формирует петлю. Здесь получатель говорит, окей, я принял бродкаст, что мне с ним сделать надо? Разбрасывать на все порты, кроме порта источника. И, естественно, в том числе он отбрасывает копию порта обратно в агрегированный канал. Он не знает, что некоторый порт на нем, не знаю, здесь гигабит 0, там 1, и некоторый порт на другом свитче, гигабит 0, 2, с точки зрения соседней циски, являются агрегированным каналом. Он обратно в этот порт отправляет копию кадра. Приходит кадр из интерфейса агрегированного

на наш оригинальный свитч. Понятное дело, что этот свитч отбрасит копию кадра на все порты, кроме порта источника. Это полбеды. То есть узел А получит свой собственный кадр, который он же самый отправил. Это фигня. Другая проблема заключается в том, что свитч, теперь получив копию кадра от адреса узла А из-под логического канала, он говорит, я знаю, где сидит узел А. Я только что получил копию кадра из агрегата. Следовательно, все новые кадры на узел А я буду отправлять в агрегат. Да, в итоге узел А потом такие кадры будет получать. То есть вот такой он пройдет, и в итоге, да, он доставится до узла А. Может быть, а может быть и нет. Дело в том, что если вдруг будет проходить юникастовый кадр от какого-то другого узла, Б, до А, Б отправляет кадр на узел А, где вот этот вот свитч говорит, куда его надо девать. Его не надо отбрасить вот сюда, вот. То есть его на этом порту надо заблокировать. На порту, за которым сидит действительно узел А, копия кадра при этом не будет отправляться, потому что наш коммутатор знает,

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

Нет, только те, кто отправил браткаст, до тех пор, пока они не отправят какой-то новый кадр, будут терять свой трафик. То есть это будет такая сеть, которая чуть-чуть подглюкивает. Но все равно это ничего хорошего, конечно, не принесет. Что можно сделать, если очень сильно хочется? То есть если нам хочется взять, сделать, например, access switch, который смотрит на два distribution switch. Distribution switch 1, distribution switch 2. Мы можем сделать так, чтобы два свеча, вот эти distribution 1, distribution 2, прикидывались бы одной железкой. И они бы знали, какие порты формируют агрегированный канал. Более строго, если кадр пришел от access switch до distribution switch 1 через порт, который формирует группу, чтобы этот кадр ушел на второй distribution switch с некой пометкой, что оно пришло из-под порта, там, гигабит 0.0, формирующего группу агрегированный группу, там, не знаю, 1. И, соответственно, когда distribution switch 2 получил бы такой кадр, он бы сказал, я не буду копию этого кадра

отправлять в гигабит 0.0, там, не знаю, десятый интерфейс, который в ту же агрегированный группу 1 входит, потому что этот кадр уже пришел из группы агрегированный группу 1. Естественно, штатного зорнита такой фечи нету, но вы можете взять и объединить несколько свечей в логическую какую-то группу, и она может называться самыми разными способами. Это все вендорские штуки, стандартных способов организовать это нету. Самый простой способ, как вы можете это сделать, это сделать стекирование. В целом, не очень хорошая идея в большинстве случаев, но, тем не менее, да, она позволяет вам подобные вещи сделать. Стекирование. Если говорить про циску, stackwise, flex-stack, это разновидность stackwise, либо, если вы используете шеститонники, есть такая штука, называется VSS, Virtual Switch System. Она позволяет вам делать именно этот, что у вас есть один шеститонник, другой шеститонник, они связываются между собой специальным секретным проводом, в котором бегают немножко модифицированные кадры. И вот вы в этом случае со стороны абонентских свечей можете построить

мульти-шасси-слаг, мульти, как называется, многоногую агрегированную группу. Одна нога в группе смотрит на один свитч, другая нога в группе смотрит на другой свитч, и все это дело объединенного группы. И все это корректно работает. Если говорить про Nexus, например, в Nexus эта штука называется VPC, Virtual Port Channel. Ну, у большинства других вендоров тоже что-то подобное так или иначе бывает. Общее название группы такой технологии, группы таких технологий, называется M-Lag, мульти-шасси-слаг. Иногда MC-лаг. Вот. Если говорить про Cisco, особенность цисковского балансировщика заключается в том, что агрегировать в одну группу можно до 8 портов. Если вам очень сильно хочется, вы можете в группу носовать больше портов, но работать по факту будет только 8. Связано это с тем, что у вас фактически берется там в разных источниках, написано по-разному, 3-бита или 4-бита энтропии. И, ну, фактически, да, там, итогом работы того,

что балансировщик сможет посчитать, куда девать копию кадра, в какой именно физический порт отправить копию кадра, это вот он будет брать 3-бита, которые будут получаться в результате вычисления хэша и деления на целое его на количество портов в группе. Вот результат у Cisco всегда будет 3-битный. При этом часто говорится, что балансировщик Cisco использует 4-бита энтропии, когда он берет какой-то кадр, в этом кадре есть какие-то параметры, там, IP-шники, источника получателя, MAC-адресайз источника получателя, TCP, UDP-порты источника получателя. Вот от этого всего дело берется, ну, я раньше использовал термин хэш, на самом деле там используется XOR, функция XOR, логическая исключающая или, и вот от этого XOR-а, последнего, берется 4-битика. И дальше мы число 4-битовое делим на целое на число 3-битовое, то есть количество каналов, и у нас получается какой-то там результат. Так, далее.

В принципе, по стандарту нигде не написано, что агрегировать в одну группу мы обязаны. Каналы, которые настроены одинаково. Требуется, чтобы был одинаковый доплекс, и, по-моему, все. То есть там требования минимальное количество по стандарту. В реальности практически все реализации агрегирующих каналов на реальном железе требуют, чтобы порты были настроены прям совсем одинаково, чтобы это были одинаковые порты по скорости, по дуплексу, по режиму trunk access. То есть вы не сможете, например, взять и в реальном цисковском железе организовать в одной группе линк 100-мегабитный и гигабитный. Система вам этого сделать не даст. Но, тем не менее, по стандарту это не запрещено. Если вы хотите взять и настроить в одну группу порты, которые настроены неправильно, то в некоторых случаях система может вам сразу дать отбой. То есть если вы попытаетесь, вот, например, взять и добавить в одну группу интерфейс гигабитный и 100-мегабитный,

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

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

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

ничего не проверяется автоматически, то есть система доверяет вам как администратору, вы все сделали правильно и вы молодец. Но если вы что-то сделали неправильно, сеть может оказаться под угрозой. Второй вариант это использовать процедуру какой-то автоматического контроля. Есть два протокола, которые позволяют это сделать. Link Aggregation Control Protocol, стандартный протокол LATSP и фирменный цисковский протокол PugP, Port Aggregation Control Protocol. Фирменный цисковский протокол ничем по сути не лучше LATSP. В цисков своих документах, блюпринтах, даташитах заявляет, что он во всех отношениях лучше LATSP. На самом деле это не так. У него есть маленькое преимущество, но это маленькое преимущество полностью уходит в никуда, учитывая, что это маленькое преимущество работает только на очень конкретном железе цисковском. И это очень конкретное железо, оно очень дорогое. То есть вы должны будете для того, чтобы воспользоваться тем самым маленьким преимуществом ПАГПа, купить прям по алфавиту самое дорогое железо циски, и тогда, может быть, в некоторых ситуациях ПАГП вас спасет.

Но для провайдовских сценариев это абсолютно не актуально, поэтому вот этого товарища мы сразу вычеркиваем. Нет никакой нужды его использовать в реальном мире. Остается только LATSP. Совсем без проверки плохо, поэтому статическую агрегацию мы тоже вычеркиваем. Так что вот этот вот сценарий, он единственный возможный, если вы используете агрегацию каналов. Так. В случае, если мы построили отказоустойчивые каналы от одного свеча до другого, просто протянули два провода, может быть, одной трассы, может быть, разными, мы защитились от отказа одной железки. Но если у нас есть необходимость построить какой-то резервируемый канал через несколько устройств, то в этом случае агрегация нас не спасет. Мы вынуждены будем использовать какой-то другой механизм. Еще одна проблема будет связана с Ethernet,

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

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

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

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

но вы можете этот Spanning 3 придушить. То есть вы можете его не использовать. Это будет ваше суверенное решение, но, по крайней мере, делать коммутаторы, которые вообще не умеют Spanning 3, это нестандартное поведение. Классический Spanning 3 строит вот это вот самое дерево за физическую топологию. То есть он не различает виланы, транки, там все вот это вот. Он просто говорит, что у нас есть порт, который смотрит на центральный коммутатор. Будет это вилан аксессовый, какой-то там вилан, не знаю, десятый, вилан двадцатый, неважно. Порт смотрит в сторону физического коммутатора. Значит, этот порт является кратчайшим путем. И поэтому 802.1D-шный Spanning 3 не умеет работать с виланами. Он строит дерево за физическую топологию. В то же время это возникает иногда из-за этого проблемы, потому что трафик по виртуальным проводам, виртуальным вот этим широкопрещательным доменам, ходит иногда не по той же самой трассе, что и у нас соединяет физические коммутаторы между собой.

Потому что может быть такое, например, что у нас есть два свеча, и вот они соединены двумя проводами. В одном, мы говорим, у нас ходит только десятый вилан, в другом ходит только двадцатый вилан. Spanning 3 классический, скажет, у нас петля, у нас есть два параллельных провода, они формируют петлю. Вот альтернативный способ добраться до рута есть. Вот этот вот коммутатор рутовый. Вот этот коммутатор, соответственно, говорит, у нас есть вариант добраться до рута вот так или вот так. Значит, один порт надо выключить. Если вам нужно уметь работать с виланами, то есть вы должны будете использовать такой протокол, который понимает, что виланы существуют. И в этом случае блокировка коммутации в некоторых портах должна происходить с учетом информации о виланах. В этом случае вы должны будете использовать либо фирменный цисковский протокол PVST или PVRST. Это протокол, который будет строить отдельное дерево за каждый вилан. Либо вы можете использовать стандартный протокол 802.1.smst. Этот протокол будет строить деревья по вашему выбору, и затем будет коммутацию в виланах привязывать к состоянию в определенных деревьях.

802.1.w – это ускорение стандартного протокола 802.1.d 90-го года, которое выпущено было в 2004 году. То есть вот этот стандарт 802.1.d развивался. Была версия 90-го года, потом версия 98-го года, где косметические изменения произошли. И потом 802.1.d 2004 года. И ее выпустило более новую версию протокола Sparling 3, которая в некоторых случаях может работать существенно быстрее. Классический Sparling 3 может выключать коммутацию на портах в сети на срок достаточно заметный в определенных ситуациях до минуты. А Rapid Sparling 3 – это вот 802.1.d 2004 года или 802.1.w. То же самое все. Это просто синонимы. Он в некоторых случаях может сократить время с одной минуты недоступности сети до порядка десятков, иногда сотен миллисекунд. То есть вместо того, чтобы минуту сидеть и куковать, пока Sparling 3 пересчитает апологию,

вы взяли, запустили Rapid Sparling 3, он там все посчитал, и за 20 миллисекунд, за 30 миллисекунд сеть привел в нормальное состояние. В любом случае Sparling 3 будет работать следующим образом. Он сначала блокирует вообще все. То есть на всех коммутаторах, на которых работает Sparling 3, начало работы заключается в том, что вы выключаете вообще все. Дальше. Вы должны будете определить, кто из коммутаторов является центральным. Он будет называться специальным словом root, то есть корневой коммутатор в дереве. Вот он здесь у нас выделен желтым кружочком. Дальше. Каждый коммутатор, который root-ом не является, должен будет понять, в какую сторону до root-а проще всего будет добраться. Должен будет определить один порт, который смотрит на root-а самым выгодным образом. Процедуру определения выгодности мы сейчас оставим за скобками. Дальше. В нашем случае вот этот вот коммутатор скажет, вот этот вот у нас будет root-порт, то есть тот порт, который на root-а смотрит самым выгодным образом. Вот этот вот скажет, вот здесь у нас на root-а самым выгодным образом смотрит. Вот этот, ну, у него два варианта,

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

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

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

тогда, когда стало понятно, что все сети из ОРН строятся на коммутаторах. То есть уже не было толстого желтого коаксиала практически нигде. Поэтому, если вдруг вы используете Rapid Spanning 3, если он обнаружит, что у вас в сети нет толстого желтого коаксиала, он может испытать некое преимущество. Он может не закладываться под то, что в канале у вас может быть много абонентов. Как ведет себя классический Spanning 3? У вас есть один коммутатор, один бридж, другой коммутатор, другой бридж, и, соответственно, между ними есть провод. Вот два свеча, два бриджа, которые друг друга видят, они не могут сказать, давайте мы отправим предложение, я со своей стороны порт заблокирую, а ты со своей стороны порт разблокируешь. Это не может происходить, потому что неизвестно, сколько еще бриджей в этом канале может находиться. Это же может быть толстый желтый коаксиал. Классический Spanning 3 90-го года исходит из того, что ничего кроме коаксиалов не существует, потому что в тот момент, когда он создавался, все Ethernet были только коаксиальные.

И в одном проводе у вас могло быть 2, 3, 5, 10, 50 миллион абонентов. Вы не могли отправить сообщение, давайте вы все заблокируете свои каналы, а я его разблокирую, потому что, ну, пришло бы вам, там, не знаю, 10 ответов. Да, окей, все хорошо. А где гарантия, что нет 11-го коммутатора, который не получил ваше сообщение и не заблокировал со своей стороны порт? И, как следствие, у вас в итоге недозаблокированный порт вызовет петлю. Поэтому классический Spanning 3 работает по принципу немытьевых катаний. Он просто по таймеру говорит, что я буду там в течение 15 секунд отправлять сообщение, и все в пределах моей среды точно и гарантированно услышат эти сообщения, если я буду просто долбить, долбить, долбить, долбить в среду, передавая определенные данные. Рано или поздно меня все услышат. Rapid Spanning 3 говорит, что коаксиалов больше нет. То есть, если у нас есть два свеча, которые связаны между собой проводом, они друг друга видят, они друг другу могут отправлять сообщение. Один может отправить сообщение, я тебя вижу. Второй отправит сообщение,

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

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

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

не будет вызывать смену топологии, если он будет просто подниматься. То есть если мы объявляем Edge порт, он переходит в состояние Designated Forwarding сразу, не дожидаясь процедуры стандартной 15 секунд listening, 15 секунд learning. То есть мы включили Edge порт, мы объявили, что этот порт будет смотреть на абонента, порт поднялся, перешел в App, смены топологии не произошло, порт сразу перешел Designated Forwarding. Но, если вдруг на этом порту приходит BPDушка, это значит, что наш порт не может быть больше Designated Forwarding, значит, мы начинаем работать как будто бы, как обычно работаем, когда мы получаем какую-то BPDушка на порту, мы начинаем смену топологии. То есть это для конечных абонентов очень удобная штука, которую можно использовать со Spanning 3. Если у нас есть фирменный цисковский протокол, который умеет работать с виланами, PVST или PVRST, то он будет строить дерево

не за физическую топологию, а за определенный вилан. То есть он в каждом вилане будет отправлять отдельную BPDушку. Если у вас транк, в транке можно передавать 10 виланов, в каждом из 10 виланов он будет отправлять отдельную BPDушку. PVST – это оригинальный протокол, который придумал еще Калпана. PVRST, простите, PVST+, это адаптация этого протокола под 802.1Q-шные транки. И PVRST – это адаптация PVST+, для работы с теми же ускорениями, которые были придуманы в Rapid Spanning 3. То есть, если вы хотите использовать в 2019 году Spanning 3 с цисковскими механизмами работы с виланами, то вы должны будете использовать именно вот эту штуку, Rapid PVST. Помимо того, что в Rapid PVST есть механизм работы с виланами по сравнению с быстрым Rapid Spanning 3 обычным, в нем же есть еще и Spanning 3 Toolkit. Это набор механизмов, которые на цисковских свечах можно использовать

для повышения стабильности работы Spanning 3 и в некоторых случаях для ускорения его работы. Но ускорение его работы было актуально для вот этого товарища, а вот для стабильности это вот в PVRST Spanning 3 Toolkit все еще держится. Пример того, как это можно будет посмотреть, будет выглядеть следующим образом. У нас есть такое вот колечко. Колечко выглядит как, допустим, Distribution Switch 1, Distribution Switch 2 и Access Switch. И, соответственно, нам хочется, чтобы мы проложили два провода от Access Switch до Distribution Switch. в норме, соответственно, трафик, чтобы ходил по обоим этим проводам. Если вдруг один провод отвалится, трафик начинает ходить через второй. Мы не хотим, однако, чтобы трафик всегда шел через один порт и дожидался бы выключения этого порта для того, чтобы перейти на второй. Мы хотим, чтобы деньги мы заплатили за два порта, за две SFP, за две линии связи, и по факту обе линии связи бы использовались. В этом случае мы можем сделать хитрую штуку. Мы можем сказать,

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

будет привязан к отдельному своему дереву. Дерево за десятый вилан, дерево за двадцатый вилан. В дереве за десятый вилан мы говорим, что рутом будет distribution switch 1, в дереве за двадцатый вилан мы говорим, что рутом будет distribution switch 2. И магическим образом все начинает работать. Если вы хотите использовать МСТ, то логика у МСТ будет примерно похожа на ПВСТ. То есть у нас есть физическая топология, которая содержит петли. мы ее разбиваем на несколько логических деревьев. Не то, что разбиваем, мы ее как бы клонируем. И в каждом отдельном дереве мы выбираем своего рута, свой корневой коммутатор. Но мы делаем это не в пропорции один к одному к каждому вилану делать свое отдельное дерево, потому что это много БПДушек, много нагрузки на свечи. Мы вместо этого делаем немножко деревьев, потому что чаще всего у нас топология устроена таким образом, что вариантов, как можно отправлять трафик от одного свеча до другого, не так много. То есть это либо на один порт пойти, либо на другой. В подавляющей большинстве

сценариев у нас как раз картинка Distribution Switch 1, Distribution Switch 2 и, соответственно, Access Switch. Вот от Access Switch хочется трафик направить либо сюда, либо сюда. Но нет смысла в этом случае городить огород с миллионом разных деревьев. Мы можем сказать, давайте сделаем то же самое. Дерево 1, дерево 2. Если у нас виланов много по сравнению с PVST, мы не хотим отправлять много БПДУшек, мы говорим, давайте сделаем два дерева. Дерево 1 и, соответственно, в нем будут связи вот такие. И дерево 2. Это будет, соответственно, вот как-то так выглядеть. И, соответственно, мы называем это дерево номер 1 и дерево номер 2. А дальше скажем, что коммутацию в разных виланах следует осуществлять в соответствии с тем, как себя чувствует дерево номер там такое-то. Мы можем сказать, что у нас виланы 11 и 12 коммутируются по дереву номер 1, виланы 21 и 22 коммутируются по дереву номер 2. Вот, опять же, пример, что у нас есть вот некий свитч, он говорит, у нас два интерфейса.

Можно трафик направить сюда, можно трафик направить сюда. Ну, соответственно, в дереве номер 1 верхний порт у нас рутовый, смотрит на рута, ну, допустим, вот этот рут-порт в дереве 1. И нижний порт в этом случае будет заблокированный. То есть это будет альтернативный порт, это альтернативный способ добраться до рута. Очевидно, он невыгодный. Выгоднее пойти напрямую, чем идти в обход. Поэтому трафик первого дерева не ходит во второй интерфейс. Как следствие, коммутация 11 и 12 виланов во второй интерфейс не осуществляется. В то же время для другого дерева, второго, мы говорим, что рутом во втором дереве, рут 2, у нас будет нижний коммутатор. И другие виланы 21 и 22 вниз как раз ходят, потому что во втором дереве нижний порт будет рутовый, а верхний порт будет заблокирован. Поэтому 21 и 22 виланы ходят через вниз, а не через верх. Ну, это же та же самая история, что и с ПВСТ,

ПВРСТ, что у нас строится несколько деревьев. Только деревья стоят не 100-500 миллионов штук, сколько виланов, а всего там ограниченное количество. Если говорить про ЦИСК, ЦИСКО позволяет строить до 16 деревьев. По факту столько даже не нужно. Обычно в подавляющем большинстве сценариев достаточно только двух деревьев. Но гипотетически стандарт допускает существование до 64 деревьев кастомных, плюс еще одно служебное. Так что если вдруг у вас прям какая-то очень-очень странная топология, то вы гипотетически можете все равно МСТ для нее адаптировать. Ну, подавляющая большинство сценариев достаточно два дерева. Если говорить про ПВСТ, ПВСТ это протокол фирменный ЦИСКовский и он несовместим с классическим спальнинг 3. То есть если у вас есть свитч ЦИСКовский и свитч не ЦИСК, не знаю, какой-то другой, какой-то непонятный другой свитч, и вы их соединяете между собой, то, соответственно, запустить, сказав,

что с одной стороны у вас есть ПВСТ или ПВРСТ или ПВСТ+, не суть важно, и с другой стороны 802.1Д не получится. То есть ПВСТшные кадры, они прям не похожи на 802.1Д У них другой заголовок, у них другие МАК-адреса, у них другой тип положения, немножко структура у них похожа, но по большому счету ПВСТ это 802.1Д кадры, только упакованные иначе, и прям сильно иначе. Поэтому подружить между собой ЦИСКу и не ЦИСКу именно по ПВСТ невозможно. Если говорить именно про ЦИСКовские свитчи, то рядом с ПВСТ будут бегать еще и 802.1Д кадры, для того, чтобы обеспечить как раз такую совместимость, чтобы там не совсем все плохо было. Если у нас с другой стороны не ЦИСКа, мы будем отправлять и по одной БПДУшке за каждый ВИЛАН, и дополнительно ванильную БПДУшку 802.1Д. Но если говорить про МСТ, то в этом случае у МСТ все хорошо, он просто в каждый интерфейс отправляет просто всего

одну БПДУшку, которая к тому же еще и совместима со стандартом ванильным спайнинг-3. То есть, если у вас есть свитч МСТшный и свитч какой-то другой, который 802.1Д поддерживает, 802.1Д, то БПДУшка МСТшная и БПДушка 802.1Дшная они совместимы между собой. То есть, два свитча в этом случае все равно договорятся. Вот. Фактически можно будет сказать, что МСТ это расширение для РСТП. Ну, своего рода такое расширение. Ну, такое, да. То есть, это следующая версия протокола спайнинг-3. В принципе, версия, то, что это следующая версия протокола спайнинг-3 может быть подтверждена и тем, что в самой БПДУшке пишется так называемая версия протокола. Каждая БПДУшка, каждый пакетик, который отправляется, он начинается с двух полей. Первое поле называется протокол, и там всегда ноль, что означает, что это вообще какая-то версия спайнинг-3. А вторая циферка, это называется

версия протокола, и нолик во втором поле означает, что это медленный спайнинг-3 802.1D 1990 года. А двоечка означает, что это быстрый спайнинг-3 802.1D 2004 года. А троечка означает, что это МСТ. То есть, как бы, следующая версия спайнинг-3, которая появилась путем эволюции этого самого протокола. Может вас заинтересовать, куда девалась версия номер один. Ну, это был такой экспериментальный протокол. Кое-какие следы до сих пор этого протокола видны в формате BPDU, но он никогда не пошел ни в продакшн, ни в стандарт. То есть, когда-то был в качестве экспериментальной работы, и его потом похоронили, а потом выпустили сразу репет спайнинг-3. Если говорить про скорость работы спайнинг-3, то у спайнинг-3 есть разные версии. Есть медленный спайнинг-3, есть быстрый спайнинг-3. Медленный, что стандартный, что цисковский, работает действительно медленно. Он в случае, если у вас

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

Вы можете настроить таймеры с очень маленькими значениями. Вы можете сказать, давайте отправлять каждый HelloPacket, вот эту BPDU, в 4 миллисекунды. То есть действительно это можно сделать с практически миллисекундными задержками. Вы можете сказать, давайте нам нужно будет время на передачу данных из одной части сети в другую, тот самый forward delay, допустим, там 50 миллисекунд. Вы можете это сделать, если захотите, но нигде не гарантируется, что это обязательно будет поддерживаться. Например, циски такие субсекундные таймеры не поддерживают. Если они увидят таймер, в котором, BPDU, в который приходит, приходит BPDU, и у них написано таймер будет там 0,004 тысячных секунды. То есть минимальное значение, которое можно проставить 1,256 секунда для hello time. И, соответственно, если циска такую штуку получит, она скажет, это число меньше одного, следовательно, это число 0. Она скажет, это не 0,004, а это число 0. А 0 это невалидный таймер.

То есть просто такого быть не может, поэтому она скажет, я вообще никакую BPDU не получил. Что означает, если что-то вам приходит, BPDU какая-то, которая к вам приходит, и в ней написано, что я считаю себя диссигментным свечом, и мой таймер вот такой, что этот свитч гарантированно на вас смотрит диссигмент от порта. Если вы говорите, я не верю той BPDU, которая у меня присылает, значит, вы игнорируете то, что какой-то другой свитч будет диссигмент от свечом. Вы, в свою очередь, говорите, я буду диссигмент от свечом в этом сегменте, и вы отправляете в ответ свою BPDU. Но, если ваша BPDU будет inferior по сравнению с той BPDU, которая у соседа, вы друг на друга будете смотреть диссигмент от порта. И вы будете сегменты. Вот. Так что, так делать не надо. Вы можете это сделать технически. Если у вас гомогенная среда, если вы знаете, что в вашей сети абсолютно точно все оборудование поддерживает вот такие вот субсекундные таймеры, например, у вас Huawei. Вот Huawei нормально с такими таймерами работает. Или там у вас Arista.

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

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

Можно будет сказать, что спанинг-три это практически дистанс-векторный протокол. То есть, когда мы передаем сообщение, что у нас есть определенный способ добраться до рута, это фактически как то, что у нас есть рип, который анонсирует определенный префикс, этот префикс разбегается по сети. В принципе, в спанинг-три даже есть специальный показатель, message-age, который указывает, как далеко вы удалены от рута. Но это та же самая метрика рипа по большому счету. И так же, как и рип, спанинг-три любой подвержен проблеме подсчета до бесконечности. Как эта проблема формируется для рипа? У нас есть один роутер и второй роутер. Один роутер анонсирует какой-то префикс, говорит, я знаю сетку А. И он говорит, я знаю ее за один прыжок. Соответственно, второй роутер говорит, окей, я понял, что ты знаешь эту сетку, я дальше буду, соответственно, говорить всем, что я знаю эту сетку за два прыжка. Он говорит, я знаю за два прыжка сюда, знаю за два прыжка сюда. И он обратно посылает сообщение, я знаю за два прыжка в обратно, в ту же самую сторону. Это, конечно, можно выключить, и по умолчанию это чаще всего выключено Split Horizon, но, тем не менее, такая вот штука есть.

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

будет делать, прям медленно и печально. РАН и испанинк 3 точно так же будет себя вести. Представьте себе, что у вас есть вот такая вот кольцевая топология, и РУТ находится не в этой самой петле. В этом случае, если РУТ отсылает сообщение, говорит, я РУТ, я знаю, как до себя добраться за 0 копеечек. Дальше у нас, давайте назовем это, не знаю, коммутатор номер один. Вот нижний коммутатор говорит, у нас РУТ будет первый, и во все стороны это все дело отсылается. Все свечи в топологии знают, кто у нас РУТ. Это РУТ первый коммутатор. И дальше друг к другу рассылают сообщение. Я знаю способ добраться до РУТа. Понятное дело, что кто-то у нас в этом случае Петлю заблокирует, ну, гипотетически, да. Но в какой-то момент может случиться проблема. РУТ отваливается. Вот этот вот коммутатор, который узнает, что РУТ отваливается, он видит, что РУТ отвалился, БПДУшки больше не приходит. Он говорит, ахтун, калярма, РУТа больше нет. И он отсылает сообщение. Какое сообщение он отсылает? РУТа больше нет. Это значит, что он говорит, ребята, у нас РУТ. РУТ новый, это я.

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

еще не началась, то есть никто не получил сообщение о топологии change, но у нас все свечи уверены, что РУТ первый где-то еще доступен. Только непонятно где. Кто-то где-то когда-то его видел. Но там начинается по счету до бесконечности, там у нас будет сообщение messageH, не сообщение, простите, а таймер messageH, и каждый РУТ, каждый свеч, который пересылает БПДушку, что я где-то слышал о чуваке, который когда-то видел РУТа, он увеличивает значение messageH на единичку до тех пор, пока оно не превзойдет значение maxH. Но это опять же процедура очень медленная, и она в разных сценариях будет длиться, там, ну, чаще всего она длится порядка 40 секунд. Hello сообщение будет раз в 2 секунды, messageH растет до maxH с единички до 20, то есть 20 секунд, 20 раз нужно будет отправить сообщение, каждая отправляется раз в 2 секунды, то есть 30-40 секунд в определенных редких, однако, ситуациях, даже быстрый spanning 3 или протоколы, основанные на нем, будет тупить

в случае, если у вас РУТ не входит в кольцо. Если у вас топология примерно такая, как на рисунке, есть отдельная петля, штатно существующая, и есть отдельный РУТ, который не входит в эту петлю, то вот такой вот подсчет до бесконечности у вас может наблюдаться. За это его не очень любят провайдеры, потому что провайдеры это люди, которых хлебами кормят и построят кольца. Эти кольца не всегда связаны друг с другом, не всегда можно выделить один какой-то свитч, через который проходят вообще все кольца. Поэтому бывает такое, что РУТ отваливается и в каком-то кольце начинается по счету бесконечности. Чтобы такого не происходило, есть рекомендация не использовать Spanning 3. То есть, если вы можете использовать Spanning 3 и РУТа всегда включить во все кольца, вот это вас не касается. Если вы не можете использовать Spanning 3 в таком формате, что у вас РУТ обязательно входит во все кольца, часто провайдеры закладываются под то, что вот эта вот штука, которую я на картинке нарисовал,

она для них неприемлема. Прямо в принципе. То есть, если вы используете быстрый Spanning 3 и рассчитываете на то, что у вас переключение перейдет до 100 миллисекунд, а оно по факту длится полминуты, за эти полминуты вам все линии колл-центра оборвут негодующие клиенты с криками в ней интернет не работает. Для решения этой проблемы вендоры, которые адресно создают решение для провайдеров, они предложили использовать специальные отдельные протоколы для провайдерских колец. У CISC тоже такой протокол есть, он называется REP, Resilient Ethernet Protocol. Он будет работать ну примерно как Spanning 3, только несколько проще. Он не предназначен для совершенно произвольной топологии. Вы указываете в явном виде, кто у вас формирует петлю. В этом смысле Spanning 3 работает иначе, потому что он ожидает, что петля может возникнуть где угодно. Здесь, нет, здесь вы запускаете, ну такой специальный кастрированный Spanning 3, который не пытается обнаружить петлю, который точно знает, где она есть, и в случае, если он видит, что петля нормально,

хорошо работает, он блокирует вполне определенный порт. А если он видит, что с петлей какая-то проблема возникла, что какой-то свитч из петли выскочил или какой-то свитч, допустим, порт потерял, он в этом случае разблокирует, опять же, вполне хорошо известный порт. Для того, чтобы это работало, вам нужно будет фактически на всех свитчах указать, где конкретно у вас есть петля. То есть вот, например, на этом свитче мы говорим, у нас есть левое плечо петли порт Е1, правое плечо петли порт Е2. Е это edge, то есть мы смотрим в сторону петли вот этими двумя портами, левым и правым. И на втором свитче мы говорим, у нас есть левый порт и правый порт, левый порт и правый порт. И, соответственно, левый порт одного свитча смотрит на правый порт другого свитча. Вы можете этот самый REP использовать в формате петли, или вы можете REP использовать в формате две точки выхода из вашего кольца, из вашей, простите, коммутируемой сети, вы говорите, вот у нас есть, допустим, один роутер и второй роутер. И мы хотим сказать, что вот здесь у нас между этими двумя роутерами, в принципе,

разницы особой нет, но они анонсируют одни и те же адреса во внешний мир. И вот мы хотим сказать, что у нас штатно пользователи должны левая часть ходить на левый роутер, правая часть должна ходить на правый роутер. Если вдруг у нас один из, там, не один из роутеров, а где-то в сети случается обрыв, то вот те узлы, которые находятся до обрыва, продолжают пользоваться своим роутером, те узлы, которые находятся после обрыва, перескакивают на другой роутер. Но вот эта вот штука встречается редко, а в кольце оно встречается прям повсеместно. Если вдруг вы используете не ЦИСКа, то ЦИСКовский протокол вы, соответственно, использовать не можете, но вы можете использовать альтернативные протоколы, которые зачастую есть и стандартные. То есть первый протокол, основной, который здесь можно будет упомянуть, это ERPS. Это ИТУшный протокол, то есть он не ИЕшный, он не РФСИшный, он отдельный ИТУшный, но тем не менее он такой хороший стандартный протокол. Работает примерно так же, как и РЭП. И второй протокол, который тоже так же себя ведет,

по сути, это экстримовский протокол, называется EAPS, Ethernet Automatic Protection Switching, и, соответственно, он был стандартизирован РФСИ. Кроме того, есть вендоры другие, которые делают свои собственные протоколы. Вот из того, что имеет смысл упомянуть, это Light Telesis, у них тоже свой отдельный протокол Ethernet Protection Switching Ring. То есть не Ethernet Ring Protection Switching, E-RPS, а Ethernet Protection Switching. Ну, смысл у них у всех один и тот же. Вы заранее создаете кольцо, и вы говорите, какие части этого кольца, куда должны смотреть. Если вдруг у нас все хорошо, то, допустим, верхний свитч говорит, вот этот порт у нас блокируется. Если вдруг мы понимаем, что у нас где-то в сети случился отказ, то этот порт разблокируется. Эта штука очень быстрая, она бронебойная, то есть с ней ничего не может пойти не так, ну и время сходимости у нее, как правило, там, единисидятки миллисекунд. То время, которое вам требуется на обнаружение отказа практически, потому что у вас для того,

чтобы обнаружить отказ, например, в Ethernet по витой паре, требуется от 32 до 48 миллисекунд. Вы должны потерять три подряд линк-пульса. Каждый линк-пульс отправляется раз в 32 миллисекунды. Раз в 16 миллисекунд. То есть один раз потеряли, 16 миллисекунд прошло, второй раз потеряли, 16 миллисекунд прошло. Ну и в зависимости от того, когда был предыдущий, то есть третий будет либо почти сразу, либо там еще через 16 миллисекунд. Поэтому для Ethernet-менных портов у вас время переключения будет как минимум по 32 до 48 миллисекунд. Меньше просто не получится в обнаружении. Вот у вас лампочка на порту гаснет за это время. Ну и после того, как вы обнаружили, что у вас случился отказ, вы дальше должны будете отослать сообщение соседнему свечу. Тот должен будет отослать сообщение своему соседу и так далее. И хоть это и происходит достаточно быстро, но все равно там пара-тройка миллисекунд у вас на это все уйдет. Поэтому классическое время, которое требуется репу и его аналогам для переключения, это считается порядка 50 миллисекунд. У провайдеров вот эта вот штука

очень популярна, потому что у провайдеров случайно кольца не зарождаются нигде, они все зарождаются строго по проекту, и вы просто понимаете, что у вас есть там одно кольцо, допустим, основное, и к нему рисуются резервные кольца какого-то такого плана ромашка. И, соответственно, в каждом кольце вы запускаете отдельный сегмент репа. Вот такого плана. Ну и последнее, что здесь стоило бы упомянуть, это проблема выхода в свет. То есть если у нас есть коммутируемая сеть, это, конечно, хорошо, и мы можем предоставлять услуги L2 VPN и те самые вот E3, ELAN, E-Line, но, скорее всего, мы все-таки захотим предоставлять какие-то услуги. И эти услуги должны будут основаны быть на IP. И в какой-то момент нам нужно будет перейти от Ethernet к IP. Если мы скажем, что у нас есть один роутер, который выполняет такую задачу, мы обречены на то, что у нас есть единая точка отказа. Если у нас есть несколько роутеров, мы обречены на то, что в Ethernet мы не сможем легко направить трафик на нужный роутер.

То есть это должны будут делать роутеры сами, и для этого у нас есть механизмы переключения. FHRP, First Hop Redundancy Protocols. Протоколов в курсе предусмотрено три. Это HSRP, VRRP и GLBP. HSRP и GLBP фирменные цисковские. VRRP — это протокол, про который циска рассказывает, несмотря на то, что он стандартный, потому что он брат-близнец HSRP. Он очень похож на HSRP, вплоть до степени смешения, и поэтому циска на него предъявляет патентные требования. Существуют другие протоколы, которые решают ту же самую задачу, что циска про них не рассказывает, ну и в какой-то степени обоснованно, потому что либо они вендорские, опять же, преприетарные, и на оборудовании других вендоров не поддерживаются, либо они не стандартизированы в некоторой смысле, потому что циска в свое время, ну, очень неплохой протокол КАРП запретила стандартизировать. Она сказала, зачем? У нас уже есть HSRP и GLBP, а также VRRP, который у нас украли. Ну, то есть зачем четвертый протокол,

если он решает ту же самую задачу? И поэтому, да, ИИИ новый протокол не стандартизировало, и поэтому по факту он распространение, опять же, тоже не получил. Поэтому, да, вот у нас есть протоколы FHRP, когда несколько роутеров договариваются о том, кто будет обслуживать трафик. И, соответственно, создают некоторую виртуальную сущность, выделяют виртуальный IP-адрес, выделяют виртуальные MAC-адреса, и если вдруг роутер, который обслуживает трафик, с виртуальным IP-шником, с виртуальным MAC-ом, выходит из строя или перестает быть доступен, то другие роутеры на себя забирают его функции. В VRRP, как уже было сказано, протокол стандартный, но Cisco на него предъявляет патентные клеймы, поэтому некоторые вендоры его реализовывать боятся. Cisco в свое время выпускала письмо, и говорила, что, ребят, не волнуйтесь, короче, уже мы в свое время пытались запретить выход в VRRP, но нам это сделать не удалось, поэтому, пожалуйста, делайте у себя этот самый протокол.

Но знаете, все равно что доверять налоговым инспекторам, которые говорят, вам не надо заполнять налоговую декларацию, все будет хорошо. То есть вот в этой ситуации вендоры оказывались в очень странной ситуации, когда вроде бы им как бы Cisco говорит одной рукой, что да, конечно, делайте у себя, реализуйте VRRP, а с другой стороны она вот уже практически пишет патентный клейм, где говорит, что вот вендор X своровал у нас протокол, который назвал VRRP, а на самом деле это наш HSRP. С HSRP ситуация такая, что он есть, на него тоже есть RFC, и связано это с тем, что Cisco его в свое время пыталась лицензировать. То есть она говорила, любой желающий может HSRP у себя на железе реализовать, но только нам надо занести денежку. И отсюда как раз патентная проблема у VRRP, который очень похож на HSRP, то, что Cisco говорил, ну это фактически вот любой желающий хотел у себя реализовать HSRP, он его реализовал, только переименовал. И денежку нам не заплатил, поэтому пусть платит. GLBP протокол фирменный цисковский,

специфичный для именно цисковского оборудования. Он имеет ряд проблем того характера, что, в общем, непонятно его позиционирование. Он не поддерживается на очень многие железка, где его имело бы смысл иметь. Он поддерживается на тех железках, которые никому, в общем, особо не интересны, рынку не интересны. Задачу, которую он решает, тоже не совсем понятно, поэтому протокол как бы, он увлекательный. Его интересно поизучать, но по факту в продакшн пускать его как-то особо незачем. У других вендоров, в частности, Extreme Standby Router Protocol, тоже, по сути, брат-брезинец HSRP. У АВА и свой протокол, который и FHRP реализует, и транки реализует, и много там другой чего реализует. Ну вот, да, по факту есть вагонная маленькая тележка разных протоколов, и по факту выбрать какой-то один протокол, который будет универсальный, всецело правильный,

не получается. То есть там, где, например, для транков, у нас 802.1Q. Это единственный протокол, который по факту сегодня не можно использовать. Для агрегатов 802.1, 802.1 на X тоже, LATS, тоже единственный протокол, который можно использовать. Других вариантов нет. А вот в FHRP стандартного варианта решения проблемы не существует. Поэтому каждый вендор предлагает решать ее по-своему. HSRP будет работать следующим образом. Вы берете несколько роутеров, которые находятся в одном широкомещательном домене, и объединяете их в группу. Один маршрутизатор будет объявляться активным за эту группу. Соответственно, что делает активный маршрутизатор? Он отвечает на запросы ARPA клиентов, когда клиент говорит, у кого IP-шник вот такой вот. Активный роутер отвечает, у меня IP-шник вот такой вот, вот вам MAC-адрес, соответствующий этому роутеру. Если этот активный роутер докнет, то роль активного перехватывает другой роутер, и он уже будет отвечать на запросы клиентов, на тот же самый IP-шник, что IP-шник вот у меня, вот вам виртуальный MAC.

Во-вторых, он будет выбирать этот самый виртуальный MAC. То есть тот, кто первый встал, тот выбирает виртуальный IP-шник, тот выбирает виртуальный MAC. И дальше все роутеры, которые будут перехватывать роль активного роутера, они будут уже раздавать все тот же самый виртуальный IP-шник, все тот же самый виртуальный MAC. В принципе, в HSRP не обязаны все роутеры знать, какой у вас будет виртуальный IP-шник. Достаточно будет, чтобы тот, кто первый стал активным, его знал. И виртуальный Mac тоже он придумывает. Еще одна штука, которой будет заниматься активный роутер, это будет он фарвардить кадры, которые будут приходить на указанные MAC-адрес. То есть, когда у нас есть какой-то клиент, он наряд на всю сеть, у кого из вас IP-шник 10.0.0.1, активный роутер отвечает, у меня такой IP-шник, вот мой MAC, виртуальный MAC. И дальше клиент начинает посылать на этот виртуальный MAC кадры, которые содержат IP-пакеты, которые адресованы во все остальные сети. Вот, соответственно, пока роутер является активным, он кадры, приходящие на указанный MAC, обрабатывает, как будто они адресованы ему самому.

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

По умолчанию раз в три секунды активный роутер отправляет сообщение «Я активный роутер». Соответственно, если у нас происходит переключение, то вот эти вот новые hello-пакеты, которые будут отправляться новым активным роутером, они же вызовут и переключение таблиц коммутации на новый порт. То есть фактически у нас произойдет MAC флаппинг. Но только один раз. Обычно свечи не ругаются, если у нас происходит флаппинг. То есть они понимают, что это нормально, если вдруг один раз где-то кто-то был известен за одним портом, а потом случился за другим. Плохо, когда один и тот же MAC постоянно известен за двумя разными MAC'ами, тогда вот он там то за одним, то за другим, то за одним, то за другим. Это значит, что у нас где-то петля случилась. Тогда обычно нормальные свечи поднимают панику и там журналируют сообщения на консоль. Далее. Есть у нас механизм, с помощью которого назначается роль активного роутера. Механизм в ETSRP, он очень интересный. Дело в том, что Cisco посчитала, что если делать просто активный роутер и все остальные, которые сидят и ждут,

пока он сдохнет, то процедура переключения, если активный роутер сдохнет, будет занимать определенное время. То есть надо будет дождаться, пока активный роутер сдох, объявить какие-то выборы, даже чтобы все остальные роутеры договорились, кто из них станет активным. В общем, это все долго. Для того, чтобы нам не делать выборы после падения активного роутера, Cisco предложила идею. Давайте у нас, говорит, Cisco будет запасной роутер. Standby. Вот именно он всегда будет становиться активным, если активный роутер дохнет. То есть не надо будет дожидаться перевыборов, если вдруг у нас активный роутер сдох. Standby сразу подхватит на себя его задачи. Только-только мы определили, что активный роутер сдох, а у нас уже на готове запасной. То есть без перевыборов, без ничего. И в такой ситуации HSRP действительно будет выбирать запасной роутер. То есть на самом деле, когда мы говорим про то, что у нас есть какие-то выборы в HSRP, никогда в HSRP нет выборов за роль активного роутера. Все выборы происходят за роль запасного. Сначала начинается все с того,

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

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

это hello сообщение идут, и hello от активного роутера будут нужны для того, чтобы, во-первых, перестраивать таблицы коммутации на свечах, а во-вторых, чтобы запасной роутер слышал, что активный все еще живет. Если активный роутер перестает отсылать его сообщение, запасной немедленно перехватывает у него инициативу. И запасной роутер, стендбай, тоже отправляет hello пакеты. Соответственно, это означает, что процедуру перевыборов запускать не нужно. Или, напротив, процедуру перевыборов запускать нужно, если кто-то приходит и говорит, а я буду более правильным запасным. То есть, например, у нас там есть такая штука приоритет. Вот у стендбая приоритет 100, и тут кто-то проснулся, у которого приоритет 110. Вот он может объявить перевыбор и может сказать, стендбай теперь буду я. Вот у меня будет стендбай, а вот этот вот, у которого приоритет 100, будет никем. В одной группе HSRP может быть один активный роутер, один стендбай, и все остальные никто, сколько бы их ни было. Поэтому обычно в нормальной ситуации, если вы не сумасшедший, то вы делаете в одной группе два роутера. В любом случае работает только один. Все остальные не работают.

Ну, хотя бы один из всех остальных сидит и страхует основного, а все остальные не просто вообще ничего не делают. Они сидят, слушают стендбая, чтобы, если вдруг он сдохнет, объявить перевыборы за роль стендбая. Ну, то есть, это бесполезное действие объединять в одну группу 3, 4, 5, 10 слистов роутеров. Вы можете объявить в одной, в одном широкопрещательном домене 2, 3, 10 HSRP групп. Никто вам это делать не мешает, но, опять же, чаще всего это не нужно, за исключением того, что у вас может быть такое, что вашим роутерам понадобится 2 виртуальных IPшника или 2 виртуальных мака. То есть, если вы хотите сказать, что у вас 2 роутера придумывают, например, 2 IPшника, вот в этом случае вы в одном широкопрещательном домене можете сделать 2 HSRP группы. Чаще всего это будет полезно, когда у вас есть IPv4. Одна группа нужна для IPv4 и другая группа для IPv6. Вот вы делаете 2 группы, и, соответственно, у вас одна группа отвечает за IPшник IPv4, другая группа за IPv6. Если вы используете HSRP,

то вы, возможно, используете дизайн, при котором у вас используется и Spanning 3. То есть, это не всегда так. Может быть, у вас дизайн, который называется Loop Free, тогда вот этого канала у вас нет. Ну, соответственно, тогда у вас петель по факту нет, и Spanning 3 вам там не нужен. Но если у вас Spanning 3 есть, то у вас получается вот здесь петля и вот здесь петля. И Spanning 3 в такой петле будет блокировать кольца. И вот здесь у нас, получается, Spanning 3, скорее всего, заблокирует какие-то линии. Сколько вот у нас каналов есть от access-свечей до distribution-ов? Ну, один оставит живой, остальные заблокируют. И в этой ситуации вы должны будете понимать, что HSRP у вас не должен случайным образом выбирать активный роутер. Он должен у вас совмещаться с ролью Spanning 3-шного рута за указанный широкопрещательный домен. То есть, если вы используете PVST или PVRST, то вы объявляете одновременно и Spanning 3-шного рута, и HSRP-активный роутер на одних и тех же distribution-свечах. Если вы используете MST, то вам следует, опять же, в соответствии с тем деревом,

которому принадлежит указанный VLAN, роль активного роутера будет назначать. То есть не должно быть такого, что у вас роль HSRP-активного роутера на одном distribution-свече, а Spanning 3-шный свитч на другом distribution-свече. Иначе получится проблема следующего характера. У нас есть Spanning 3, вот, например, вот это вот дерево. Мы смотрим, есть петля. Вот это вот у нас root. Вот, соответственно, здесь у нас designated port, root port, designated port, root port, designated port, alternate port. Alternate port блокируется. Ну, логично, да? И, соответственно, дальше мы выбираем HSRP-активный роутер. Если мы назначим HSRP-активный роутер на нижнем distribution-свече, то у нас, получается, трафик от вот этого свеча до вот этого свеча должен будет ходить вот по такой вот трассе. И дальше будет выходить наружу. Это неинтересно. Мы хотим, чтобы трафик выходил сразу напрямую во внешний мир, не проходя по inter-switch-линку между двумя distribution-ами. Если мы хотим такое сделать, то вот имеет смысл совмещать роль

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

в любой момент времени. Например, если он почувствует, что приоритет текущего активного становится хуже, чем приоритет текущего запасного. Вот строго хуже. То в этом случае запасной при включенной настройке может отобрать роль активного сразу же, не дожидаясь падения. Ну тогда в этом случае активный роутер становится никем и может подраться за роль запасного, которая как раз только что освободилась. Так, VRRP. Стандартный протокол RFC 5798. На самом деле этих RFC-шек была CD-пачка. Есть VRRP второй версии, есть VRRP третьей версии. В любом случае он очень похож на HSRP за двумя исключениями. Первое исключение у нас не выбирается запасной. То есть VRRP всегда выбирает только основного. Соответственно, если у нас основной дохнет, объявляются перевыборы из числа всех остальных выбираются основной. Названия там немножко другие. Понятно, что название штука косметическая. Активный роутер

называется мастер, а все остальные называются бэкап. Далее, вторая особенность VRRP заключается в том, что у HSRP виртуальный IP-шник обязательно должен отличаться от физических IP-шников. У VRRP может быть такое, что физический IP-шник будет совпадать на одном из роутеров с виртуальным IP-шником. В этом случае у вас есть такая штука, как приоритет, которая указывает, кто с какой вероятностью станет виртуальным роутером, вот этим самым мастером. И обладатель физического IP-шника, совпадающего с виртуальным IP-шником, всегда гарантированно будет становиться мастером. То есть у него будет специальный приоритет 255, который обычный роутер не может никогда получить. То есть если вы хотите на обычном роутере настроить виртуальный IP-шник, и он будет отличаться от физического IP-шника, то приоритет будет в диапазоне от 1 до 254. А если вы настраиваете веропин на железке, у которой физический IP-шник совпадает с виртуальным, то у нее приоритет жестко всегда прибит гвоздями 255. Вы его поменять не можете.

Так, далее. Точно так же мастер будет отправлять Hello-пакеты. Точно так же, если их никто не услышит, то объявляются перевыборы. Ну, в общем, логика почти такая же, как в HHSRP, только чуть попроще. Отрезали, скажем, отдельно стендбая, совместили роль стендбая и актива и получили веропи. Так, далее. Еще один протокол, который у нас есть, решает ту же самую проблему выходов во внешний мир. Это GLBP. Gateway Load Balancing Protocol. Фирменный цисковский протокол, основан на HHSRP второй версии, решает проблему, что если мы купили там 4 роутера, то работает по факту только один. Если мы HHSRP запустим, вот один будет выбран активным, и он будет работать, второй будет запасным, и он не будет работать, но хотя бы хоть какую-то видимость деятельности создает. И двое других просто сидят на папировании, ничего не делают. Если мы хотим, чтобы мы заплатили денег за 4 роутера, мы можем использовать GLBP, и тогда у нас по факту будут работать все 4 роутера.

Вы не можете заставить работать в GLBP больше 4 роутеров, хотя в принципе протокол это позволяет, но текущие реализации это не позволяют сделать. Вы можете заставить работать только 4 роутера из всех. То есть если у вас там 7 роутеров в группе, 3 будут вообще ничего не делать, 4 будут работать. Как эта штука будет действовать? У вас точно так же, как в HHSRP, выбирается активный роутер. Но активный роутер, он будет называться Active Virtual Gateway. Это некий диспетчер, который будет раздавать роли фарвардеров. Фарвардеров у вас будет 4 штуки, но не больше, чем количество маршрутизаторов в группе. То есть если в группе 2 маршрутизатора, значит, будет 2 фарвардера. Если в группе 1 маршрутизатор, будет 1 фарвардер. В группе 4 маршрутизатора, будет 4 фарвардера. 5 маршрутизаторов, снова будет 4. То есть 6, 7, 8 маршрутизаторов все равно 4 фарвардера. Этот самый диспетчер раздает адреса фарвардеров, и когда у вас запросы клиентов приходят, говорит клиент, у кого из вас IP-шник 1001,

который у меня прописан в качестве шлюза по умолчанию, вот этот самый диспетчер будет в разнобой отвечать разными MAC-адресами, которые будут ассоциированы с ролью каждого конкретного фарвардера. То есть у нас есть фарвардеры 1, 2, 3, 4, AVF1, AVF2, AVF3, AVF4. У каждого из них есть свой MAC, MAC-адрес 1, MAC-адрес 2. MAC-адрес 3. Ну и MAC-адрес 4. И вот AVG-шка будет в разнобой на ARP-запрос и отвечает этими самыми MAC-адресами. Вы можете отвечать совсем в разнобой. Вы можете отвечать каруселькой 1, 2, 3, 4, 1, 2, 3, 4. Вы можете отвечать в соответствии с некими пропорциями, чтобы, допустим, более жирные роутеры получали больше клиентов. Вы не можете, однако, гарантировать, что более жирные роутеры получат больше трафика. Но, тем не менее, приблизительно это, возможно, будет примерно так и происходить. Ну и AVF-ки уже будут получать трафик, идущий на их MAC-адреса, и будут его дальше фарвардить. Если вдруг какой-то AVF выходит из строя, то соседний роутер начинает работать за себя и за того парня. То есть он получает два MAC-адреса и начинает обрабатывать трафик,

приходящий на оба MAC. В любом случае, какой бы вы протокол не использовали, вы должны будете понимать очень хорошо, очень простую вещь, что внутри вашей коммутируемой сети вы построили очень надежную, очень хорошую внутреннюю коммутируемую сеть на основе 802, там чего-то там. Ну и дальше у вас начинает работать протокол IP. Соответственно, во внешнем мире у вас тут должны быть вот на вот этих вот роутерах маршруты. То есть у вас должно все вот здесь вот хорошо работать, должен там SPF прибежать, BGP-сессии должны установиться. Если чего-то из этого нет, например, внешний интерфейс отвалился, и у нас SPF не работает, BGP не работает, DNS не работает, нет смысла заявлять роль активного роутера. Вот если вы настраиваете любой протокол FHRP, вы обязаны с помощью каких-то внешних дополнительных механизмов определять, насколько ваш роутер достоин быть внешним вот этим самым активным роутером. Если он принимает решение, что он недостоин,

он должен отправить hello-сообщение с криками «Я недостойный роутер». У меня приоритет, например, понизился. Раньше был приоритет, допустим, 100, а сейчас он говорит «Я буду отправлять приоритет 50». Второй роутер, который до того момента был, ну, что-то типа запасным, например, он должен сказать «Окей, я вижу, что текущий активный роутер не справляется, у меня приоритет 100, я должен забрать роль активного роутера у текущего активного». Если у нас HPHRP, мы должны будем включить приемцы. Если у нас VRRP, он включен по умолчанию. То есть мы говорим «Мы теперь будем hello-активного роутера отправлять, и, соответственно, hello-100 в ответ пойдет сообщение». И этот роутер сдастся и скажет «Окей, забирай свой виртуальный IP-шник, свой виртуальный Mac, и дальше с ним делай, что хочешь». То есть мы должны будем обязательно отслеживать состояние внешнего мира и проседать по, скажем, по нашей активности на внутреннем интерфейсе. Если вдруг у вас отвалится изнутри связь, то есть вот здесь вот отвалится, например, канал,

то ничего страшного, все продолжит работать, как предполагалось. Но вот это вот отдельная проблема. Что делать, если у нас внутри связь есть? То есть все клиенты видят, что у нас активный роутер все еще живой, а он дальше фарвардить трафик в интернет не может. Во всех случаях это решается костылями. То есть если мы используем CISC, мы должны использовать, ну, такой кастрированный язык CISC, который называется создание объектов отслеживания, и такой простенький механизм скриптования. Если мы используем оборудование других вендеров, то там тоже, по сути своей, надо это все делать будет скриптами. То есть нельзя сделать просто два роутера, сказать, объединяем их в группу и радуемся жизни. Потому что если берем один, выключаем, второй продолжает работать. Это только половина беды. Вторая половина беды, что будет, если у нас роутер есть, с ним внутри сети связь есть, а вот наружу он трафик выдавать не может. В этом случае проблема легко особо не решается. Так, это все, что касалось теоретической части про семейство протоколов 802-го комитета.

Давайте следующий модуль у нас будет посвящен практической работе. То есть мы будем смотреть, как это все дело настраивается на CISC. CISC и EOS обычный, CISC и EOS XE и EOS XARB.