CEF (часть 1)

следующий модуль будет посвящен аппаратному ускорителю циск экспресс-форвардинг и вы можете задать вопрос как же так мы ведь уже что-то подобное проходили в роуте откуда он взялся но на самом деле все правильно потому что циск экспресс-форвардинг это механизм который позволяет задачу маршрутизации решить за предсказуемое время и на самом деле свести ее к сложности задача коммутации и по сути своей цик ска экспресс-форвардинг может использоваться на коммутаторах для того чтобы заставить их выполнять маршрутизацию для большинства случаев когда мы говорим давайте использовать например l3 свечи там будь то это l3 access свечи или distribution свечи которые будут выполнять маршрутизацию они могут выполнять эту самую маршрутизацию именно за счет того что в них есть ускоритель циск экспресс-форвардинг вы фактически не можете его выключить в большинстве современных платформ потому что это ну как бы основа того что фарвардит трафик вы не можете заставить

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

Разница в том, как они принимают решение, куда девать кадр. То есть с одной стороны кадра они принимают, а дальше они куда-то его девают. В процессе принятия решения заключается разница между коммутатором и маршрутизатором. Но есть нюанс. Иногда можно будет встретить коммутаторы, которые занимаются маршрутизацией, прям по-честному. И вот они фактически, да, это коммутатор, который на самом деле маршрутизатор. Он принимает с одной стороны кадр, запускает движок маршрутизации и принимает решение, куда такой кадр девать в соответствии с, например, таблицей маршрутизации. Но при этом он выглядит как коммутатор, он коммутатором сам и является. И в то же время можно себе представить другую ситуацию. Представьте себе такой чистый маршрутизатор, например, CISC 7200. И в него можно вставить свитч-плату. И тогда на этом маршрутизаторе появятся свитч-порты. И у вас маршрутизатор будет коммутировать трафик. Если вы не знаете, как выглядит 7200 маршрутизатор, вы можете представить себе D-Link DIR300.

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

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

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

не будет отличаться от маршрутизации. С одной стороны кадр приняли, с другой стороны кадр отправили. И получается, что у нас как бы L2 известный не сильно отличается от процедуры маршрутизации пакета, когда у нас в случае с известным Unicast, known Unicast в L2, кадр приходит с одной стороны, мы его выплевываем с одного порта, с другой стороны. В случае с IP-пакетами мы тоже IP-пакет получаем с одной стороны, мы его выплевываем с другой стороны. Вот. Это самый простой вариант, known Unicast, когда мы знаем, куда девать такой кадр, за каким портом сидит получатель этого кадра. Есть трафик, который будет называться known Multicast. Это мы с вами не рассматривали на курсе CCNA, но тем не менее это довольно частая штука. Если у вас коммутатор знает, где находится получатель Multicast трафика, то он на порты с получателями копию кадра отправляет, на все остальные порты не отправляет.

Здесь в кавычках написано known, потому что процесс распознавания, кто за каким портом какие Multicast группы согласен принимать, он будет немножко отличаться от того, как мы распознаем получателей Unicast трафика. Если Unicast трафик, мы просто запоминаем, кто из-под какого порта, какие кадры с каким Source Mac нам присылал, то вот known Multicast будет работать с помощью служебных протоколов. Например, если говорить про IPv4, там есть Multicast в IPv4. И к Multicast, в смысле, к IPv4 прилагается служебный протокол, который называется IGMP, Internet Group Membership Protocol. Вот если вы хотите присоединиться к какой-то Multicast группе в IPv4, вы посылаете специальный запрос. И вы говорите, я присоединяюсь к Multicast группе IPv4. Как следствие, маршрутизатор, который слышит такой запрос, он видит, из-под какого порта он прибежал, и он знает, какой Multicast IPv4 будет соответствовать какому Multicast IPv4.

И он автоматически понимает, что если вы присоединились к определенной группе IPv4 Multicast, то вы же будете и слушать определенные Multicast кадры. И поэтому вам он эту копию кадра будет отправлять, а всем остальным нет. Вот пример. У нас есть свитч. Соответственно, свитч у нас имеет некоторое количество получателей. Раз, два, три, четыре. У нас есть источник трафика. И, соответственно, здесь у нас отправляются IP-пакеты с адресом получателя 224.0.0.0.5. У нас есть узел. Он хочет присоединиться к группе 224.0.0.5. Он посылает запрос. IGMP. Join. И он указывает, на какой IP-шник он хочет присоединиться. 224.0.0.5.

IP-пакет с сообщением Join перехватывается свитчом в тот момент, когда он идет на сервер. И, соответственно, свитч запоминает, что вот на этом порту join на Multicast в IPv4 группе 224.0.0.0.5 был получен. Как следствие, получатель будет принимать обратный трафик, который пойдет от источника до всех этих абонентов. Какой-то другой узел тоже посылает сообщение Join. И свитч опять же понимает, что вот на этом порту у нас есть получатель группы 224.0.0.5. Если IP-пакеты пойдут на 224.0.0.5, свитч должен будет сделать так, чтобы IP-пакет прошел вот сюда. IP-пакет прошел вот сюда. IP-пакет не прошел сюда, чтобы он здесь был заблокирован. И, соответственно, сюда, чтобы он здесь тоже был заблокирован. Вот для того, чтобы это реализовать, свитч подслушивает эти самые join и ведет базу, кто за каким портом заджойнился. И потом видит кадры, содержащие IP-пакеты, идущие на Multicast в IPv4 адрес 224.0.0.5.

Эти кадры будут идти на Multicast в IPv4 адрес 01, на Multicast в IPv4 адрес 005e 00005. Свитч, зная, что кто-то join ился на определенную Multicast в IPv4 адресу, понимает, что он должен являться получателем Multicast в IPv4 адреса вот такого вот. Соответственно, сюда копии кадров на этот Mac будут валиться, сюда копии кадров на этот Mac будут валиться, сюда копии на этот Mac не будут валиться. То есть с помощью IPv4 мы в IPv4 перехватили сообщение join, ну не то, что перехватили, подслушали сообщение join. И стали понимать, за каким портом Multicast в IPv4 будет интересен, за каким портом не будет. Под Multicast своя ARP таблица, в смысле ARP? ARP здесь вообще никакого нету.

ARP нужен для того, чтобы join.cast адреса резолвить, а Multicast он не использует резолвинг ARP вообще никаким образом. Таблица с Mac'ами? Нет, Mac'и там те же самые. Таблица с Mac'ами на свитче пополняется за счет всегда Mac адресов источника. Мы перехватываем кадры, которые идут из-под определенных Mac'ов. Multicast'овые Mac'и никогда не могут идти в качестве Mac адреса источника, поэтому в таблице Mac адресов они будут всегда отсутствовать. Но под механизмы типа IJMP snoping будет специальная отдельная табличка использоваться. И как вы помните, да, у нас при прохождении кадра через Switch, Switch всегда разбрасывает копию кадра на все порты, кроме некоторых, куда копии кадра посылать не надо. И вот мы смотрим, куда, в какие порты копию кадра посылать не надо, сразу одновременно по многим разным механизмам. Смотрим и знаем ли мы, где находится адрес получателя. Если знаем, то на все остальные порты, кроме физического порта получателя, копию кадра не разбрасываем.

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

То есть это не любой мультикаст с помощью такого механизма можно будет перехватить. IPv4 мультикаст, который будет передаваться в азернете в виде мультикастовых кадров, мы перехватить можем. Это будет IGMP snooping. Есть IPv6 мультикаст, для него будет другой служебный протокол, который называется MLD. Он то же самое делает, по сути своей, тоже позволяет перехватывать сообщение join и понимать, за каким портом будет получатель IPv6 мультикаста, за каким не будет. И если мы видим, что кадр идет, судя по всему, содержащий мультикаст в IPv6, то мы, соответственно, ориентируемся на эти самые join. Но есть мультикастовые кадры, которые просто мультикастовые, которые непонятно откуда взялись, и никаких перехватчиков для них, соответственно, не будет. В этом случае Switch будет обрабатывать их как следующий тип трафика, который называется Boom Broadcast, Unknown Unicast или Unknown Multicast. Да, соответственно, да. Known Unicast – это те кадры, которые идут на MAC адреса, которые известны у вас в таблице коммутации.

Для Known Unicast, помимо стандартных правил, никогда не отправлять кадр в порт источника, никогда не отправлять кадр в порт, который принадлежит той же порт-группе, что и порт источника. Вот, добавляется дополнительное правило для Known Unicast, подчеркну, что мы не отправляем копии Known Unicast в порты, за которыми не сидит получатель. Если мы знаем, что какой-то кадр пришел, и он есть, его MAC адрес есть в табличке MAC адресов, которые мы умеем перехватывать. То есть мы перехватили, например, IGMP сообщение о присоединении группе 224.005. Мы понимаем, что это мультикастовый формат, который мы умеем перехватывать. Мы говорим, в этом случае мы кадры, идущие на известные мультикастовые адреса, будем дополнительно подвергать дискриминации по еще такому признаку, что если у нас приходит какой-то кадр на известный мультикастовый MAC, который мы перехватывали джойнами, и мы увидели, что были джойны на некоторых портах, и на некоторых портах джойнов не было,

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

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

Группа, в которую принадлежит Source-порт. Source-порт. Дальше. Третье. Spanning Tree заблокирован. Четвертое. Всякие механизмы типа FlexLink и прочее выписывать не буду, оно достаточно очевидное. Четвертое. Это для Known Unicast. К Known Unicast не порт получателя. Не порт получателя. Вот. Дальше. Пятое. Для мультикастового... К Known Multicast напишу. Если мы знаем, что кадр, который мы перехватили, это кадр известного нам мультикастового протокола, например, IPv4. И если мы видим, что мы должны были для того, чтобы отправлять копию кадра на определенный порт, перехватить Join, но мы не перехватили его, то, соответственно, для Known Multicast не получено...

Там присоединение, в кавычках, да? Присоединение или Join. Вот. Ну и, соответственно, вот этих вот дискриминационных решений, вот на самом деле всего 5 штук. Весь остальной трафик, который приходит, он не к Known Unicast, не к Known Multicast, соответственно, проверяется только вот по вот этим трем пунктам. Мы не отправляем копию в SourcePort, мы не отправляем копию в те же порты, что и входят в ту же группу, что и SourcePort. Мы не отправляем заблокированные порты. Ну, а все остальные порты мы копию распространяем без каких-либо изменений. В случае, если у нас есть L3 Traffic, это будет специальный особый случай, если у нас есть железка, которая выглядит как свитч, но, соответственно, у нее есть какие-то порты, которые, возможно, даже коммутируют трафик, и она получает на каком-то порту кадр, который надо промаршрутизировать. В этом случае, на самом деле, внутри этой коробочки будет еще дополнительно роутер. Он, может быть, не виден глазами, но он там, ой, пардон, он там на самом деле есть.

И у этого роутера на порту будет MAC-адрес. Обычно у свитчей на каждом порту MAC-адресов нету. Но вот в этом случае, соответственно, если у нас есть коммутатор, который в душе маршрутизатор тоже, у него внутри под корпусом есть роутер, у этого роутера есть порт, который смотрит в сторону той же самой свитч-группы, и, соответственно, на этом порту есть MAC-адрес. Кадр, который приходит на маршрутизацию, он должен прийти именно на этот самый MAC-адрес, который принадлежит вот этому роутеру. После чего роутер этот кадр получит, откроет, увидит там IP-пакет, ну и каким-то образом дальше обработает. Когда мы говорим про железки уровня DIRDX, напомню, что это железка, у которой 4 порта, на которых написано LAN, и 1 порт, на которых написано WAN. На самом деле эта железка будет собой представлять как раз такой простенький, домашний в кавычках роутер, у которого есть в одном и том же корпусе именно роутерный модуль. У него один порт будет выведен на крышку, и, соответственно, он будет подписан WAN.

Другой порт у него не выведен под крышку, и он не виден, но на самом деле он приходит на Switch-модуль, который в той же самой железке есть. И на нем именно есть IP-шник, типа 112.168.01. И на Switch-модуль есть еще 4 порта, которые выведены, опять же, в панель устройства, и вот они вот так вот и выглядят. И, соответственно, это вот LAN 1, LAN 2 и так далее. То есть это вот примерно вот так вот все и выглядит. При этом под корпусом это все дело под общим находится. Вот так. Иногда еще тут же рядышком есть и точка доступа. То есть вот здесь вот какая-то точка доступа, у нее есть антенка, и все это дело может вещать Wi-Fi. Это тоже все включено в тот же самый виртуальный роутер. Так вот, если мы говорим, что у нас есть вот этот вот роутер, который не виден, но который включен в тот же самый широковещательный домен, что и пользовательские порты, то, соответственно, у него появляется MAC-адрес.

На физических портах, которые есть у свеча, MAC-ов обычно нет. Если есть MAC, то он есть на как бы один на весь свеч, из-под которого будут отправляться, например, спанинг-трешные кадры. Но это, опять же, виртуальный интерфейс, на самом деле, который принадлежит самому вот этому самому свечу. Вот у него есть какой-то отдельный виртуальный интерфейс, и вот из-под него, на самом деле, будет посылать какие-то кадры. Вот. Если мы принимаем на порту какой-то кадр, который идет на наш собственный MAC, мы его открываем, видим там внутри IP-пакет, дальше уже IP-пакет обрабатываем по таблице получателей, после чего, когда принимаем решение, в какой конкретно порт отправляем каждый конкретный пакет, дальше заворачиваем его в новые заголовки канального уровня и отправляем в сеть. L3 будет обрабатываться кадр. Но если мы говорим про L3, мы в первую очередь имеем в виду IP, что IPv4, что IPv6. Они обрабатываются по двум разным правилам. Первые правила используются для Unicast и его разновидности Anycast.

Unicast – это ситуация, когда мы отправляем кадр, и он обрабатывается только одним получателем, гарантированно одним. И известно, что IP-шник получателей есть только у одной железки. Anycast – это расширение Unicast, когда мы отправляем кадр, в нем указываем адрес получателя. И этот адрес получателя принадлежит нескольким разным железкам, но обрабатывать этот кадр будет только одна железка, которая ближе к нам. Все остальные этот кадр не получат и не будут обрабатывать. Ну и второй вариант трафика L3 – это, соответственно, Multicast и его разновидность Broadcast. Multicast – это ситуация, когда вы отправляете один пакет, и он обрабатывается несколькими разными узлами. Ну вот как раз вот в SPF 224.005 мы отправляем один пакет, и он доходит до всех сразу. Ну, до всех OSPF роутеров сразу. Разновидность Multicast – это Broadcast, когда вы отправляете пакет, и он обрабатывается вообще всеми. Вот. Два правила у нас используются. Соответственно, как обрабатывать Unicast-овый трафик, и как обрабатывать Multicast-овый трафик.

Для IP, что IPv4, что IPv6, эти правила друг на друга вообще не похожи. То есть, как обрабатывать Multicast и как обрабатывать Unicast – это прям две большие, очень сильно большие разницы, как говорят в Одессе. Вот. Да, если в L2 разницы там особо нету, ну, различаются только набором дискриминационных правил, то в L3 там все грустно. Мы с вами в рамках CCNP вообще не рассматриваем Multicast-марштузируемый в IPv4, в IPv6. Но если вдруг на CCA пойдете, то там придется немножко погрузиться в тему. Ну и там, конечно, мозг может закипеть. В случае с L2. Как уже говорилось, принцип коммутации L2 – это отправить копию кадра во все порты, кроме тех, куда копию отправлять точно не надо. У вас есть список тех причин, по которым каждый конкретный кадр не надо отправлять в каждый конкретный порт. Не надо отправлять в порт источника. Не надо отправлять, если вы знаете, что у вас агрегировано несколько портов в группу, в остальные порты в той же группе. И не надо отправлять в те порты, где заведомо этому кадру будут не рады.

То есть если у вас Cnone Unicast, то известный порт получателя. Если у вас известный Multicast, то вы знаете, что с той стороны не пришел GMP Join или MLD Join или что-то еще. Для того, чтобы быстро определить, знаете ли вы получателя трафика или нет, вам потребуется способ как-то это сделать за предсказуемое и очень небольшое время. То есть к вам приходит кадр на интерфейсе, производительность которого, ну например, 10 гигабит в секунду. Чтобы вы понимали, это 10 миллиардов бит в секунду. Соответственно кадры могут приходить на очень большой скорости, и эти кадры могут быть очень маленькие. У нас минимальный размер кадра это 64 байта. Ну плюс там всякие интерфрейм спейсинги, прочее, прочее, прочее. Там 80 байт на самом деле. Но давайте представим себе, что в среднем у нас 100 байт это размер, как называется, размер одного кадра. Соответственно, если у нас есть 10 гигабитный интерфейс, это означает, что в среднем там приходит 10 миллионов пакетов в секунду.

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

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

И для того, чтобы это быстро делать, нам нужно фактически искать по содержимому. То есть, мы не можем сказать, посмотри в ячейку номер один, правильно ли там MAC, совпадает ли он с тем, что мы ищем. Если совпадает, то окей, если не совпадает, посмотри в ячейку номер два и так пробежаться по какому-то более-менее вменяемому количеству ячеек. Потому что время, требуемое на обработку линейного поиска в таблице, оно будет просто невменяемым. Поэтому для того, чтобы быстро работать с известным юникастом, для того, чтобы быстро работать с мультикастом, нам потребуется специальный тип памяти, который называется CAM, Content Addressable Memory, или память, адресуемая по содержимому. Мы задаем памяти с таким контроллером вопрос, есть ли у тебя в таблице значение с ключом определенным, который мы ищем. Есть ли у тебя значение с MAC-адресом, каким-то MAC-адресом, который нас интересует в таблице. И, соответственно, CAM-модуль, он может за предсказуемое и небольшое время выполнить поиск по содержимому и выдать вам результат.

Вот эта вот память, она не простая память. То есть сам модуль памяти там простой, а контроллер, который всем этим делом управляет, он не простой. И вот эта вот память, она достаточно дорогая. То есть, еще раз подчеркну, сама память там обычная, а вот контроллер, он, соответственно, дорогой. За счет того, что он дорогой, много этой памяти воткнуть не получается. То есть этой памяти у вас будет ограниченное количество. Как она будет устроена? У вас есть свитч. Этому свитчу постоянно надо обрабатывать. Ну, ладно, мультикаст, хрен с ним. Возьмем самый простой, самый дешевый свитч, купленный в переходе за 500 рублей. Мы видим, что в любом случае свитч может обрабатывать кадры. В любом случае он делает это довольно быстро. Так что у любого свитча, так или иначе, вот небольшое хотя бы количество этой ассоциативной памяти или контент-адреса Белмемори так или иначе есть. Любой свитч будет оперировать следующим образом. К нему приходят кадры, которые идут из-под какого-то source-адреса на какой-то destination-адрес.

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

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

Это мы не можем найти в начале 4 Quốc-адреса материала 3 кадра. Мы купим в знак Sticker Earth. Мы передали этот кадр на обработку матрицы коммутации. И, соответственно, матрица коммутации быстро нашла такое решение, что кадр известный, no uniqueast, и, соответственно, получатель находится за вторым портом. Дальше на всех портах, которые есть на этой железке, мы принимаем решение, надо ли отправлять этот кадр вот сюда, надо ли отправлять этот кадр вот сюда, надо ли вот сюда, надо ли вот сюда, надо ли вот сюда. И вот мы говорим, это первый порт. Сюда отправлять этот кадр не надо, потому что мы знаем, где сидит получатель, и он сидит за вторым портом. Сюда надо отправлять копию кадра, потому что никакого дискриминационного решения нет. Сюда, соответственно, мы можем его отправить. Надо ли сюда отправить? Нет, не надо. Опять же, потому что это третий порт, а мы знаем, что получатель находится за вторым портом. Надо ли сюда отправлять? Не надо, потому что мы знаем, что получатель за вторым, а четвертый порт. И так далее. В пятый и в шестой порт мы не во все эти порты не отправляем копию кадра, потому что мы знаем, что получатель сидит только за вторым портом.

Вот в сторону второго порта мы отправляем копию кадра. Если вдруг искомого адреса в таблице нету, то тогда Content Addressable Memory вернет за предсказуемое и небольшое время информацию о том, что записи нету. И тогда по этому признаку мы понимаем, что это неизвестный нам Unicast, что использовать дискриминатор вида мы не знаем, что мы знаем, что какого-то получателя за определенным портом нету, потому что получатель за другим портом мы уже не можем. Так. Да. Как-то так. Если мы говорим про роутеры, которые работают с IP-пакетами, то там получается использовать камни получится, потому что роутеры у нас работают с таблицами маршрутизации, а там нельзя задать вопрос в таблице, есть ли у тебя вот такая строчка, в точности вот такая или нет.

Потому что в таблице маршрутизации у нас хранятся маски и IP-шники сетей. И нам требуется определить, какая из хранящихся записей лучше всего подходит для отправки трафика по определенному маршруту. То есть в случае с CAM с Content Addressable Memory мы задаем вопрос, у тебя вот точно такой MAC-адрес есть в таблице или нету. В случае с T-CAM мы задаем вопрос, у тебя вот это есть в таблице, если есть, выведи нам запись, которая лучше всего подходит под то, что мы спрашиваем. То есть мы задаем вопрос и требуем не точное совпадение, а все совпадения, которые есть, но среди всех совпадений, которые есть, мы требуем лучшие. Потому что в таблице маршрутизации у нас может быть маршрут, который подходит, но не лучшим образом, есть и другой, который подходит лучше. В отличие от MAC-адресов, которые либо есть, либо нет целиком. Так, да, в случае с маршрутизацией нам потребуется новый тип памяти, который называется T-CAM или Ternary Content Addressable Memory.

Слово Ternary намекает на то, что оно троичное и что в таблице по факту хранятся значения, вот отдельные, скажем, элементы того, что может храниться, которые могут принимать одно из трех значений. Нолик, единичка или что-то еще. Неважно. Откуда взялось вот это вот название Ternary Memory, троичная память? Дело в том, что у нас в таблице маршрутизации, но чаще всего мы как раз про таблицу маршрутизации будем говорить, когда будем говорить про T-CAM, хранятся IP-шники и маски. Мы когда говорим, у нас есть таблица маршрутизации, сетка, например, 192.168.2.0.24. По факту мы храним два разных значения, 192.168.2.0 IP-шник и 24 это 255.255.255.0 маска, но они означают, что любые IP-адреса, начинающиеся на 192.168.2, нас устроят, мы можем использовать этот маршрут для отправки трафика в сеть назначения.

И в таблице маршрутизации у нас выходной интерфейс будет Gigabit.02 для этого маршрута и MAC-адрес получателя вот такой. Я думаю, что после курса по роуту вы примерно представляете, что хранится в кэше аппаратного ускорителя CF для того, чтобы отправить трафик по конкретному маршруту. Там хранится интерфейс и готовый канальный заголовок для отправки трафика на этом интерфейсе. Ну так вот, когда мы говорим, что у нас есть вот IP-шник и маска, по факту там хранится вот такая вот штука. Там хранятся какие-то биты, которые нам важны и хранятся какие-то биты, которые нам не важны. В сумме этих битов получается 32 штуки, если мы говорим про IPv4, ну или про IPv6. И сначала идут биты, которые важны, потом какие-то биты, которые нам не важны. Вот 192.168.2 вопросик как раз намекает на то, что первые 24 бита мы требуем, чтобы они совпали, а следующие 8 бит мы требуем, чтобы они были неважно какие, могут совпадать, могут не совпадать. Если совпадают, то неважно с чем совпадают, все равно это на результат не влияет.

И по факту мы говорим, что вот если у нас есть, например, маршрут до сети 10.000. 0.10.000. По маске 255.255.255.0. Это по факту означает, что у нас сетка 10.000.24 представима в виде 0.000. 1.0.1.0. Это 10. 0.0.0.0.0.0.0.0. Это второй нулевой октет. 0.0.0.0.0.0.0.0.0. Это третий октет. И дальше x, x, x, x, x, x, x, x. Это четвертый октет. У нас каждый битик, каждый элемент адреса представляется в виде либо 0, либо единички, либо неважно чего. Вот это x. И, соответственно, вот если вы сможете хранить в памяти одно из трех значений, 0, единичка или неважно что, то с помощью множества таких вот элементов памяти, ячейок памяти, вы сможете закодировать эту самую токам.

Вы задаете вопрос. У меня есть айпишник 112.168.22. Под какие записи попадает этот айпишник? Соответственно, вот в табличке у нас есть 112.168.22 адрес и вот несколько маршрутов, которые вы, в принципе, можете здесь угадать, что это за маршрут. Это 10.00 по 8 маске, 112.168.1.0 по 24, 112.168.2.0 по 24 и 0.00.0.0 маршруты. Ну вот в этом случае мы говорим, есть ли совпадение вот здесь. И, очевидно, его здесь нет. Мы требуем, чтобы первый актет был десятка, и здесь у нас не десятка. Есть ли совпадение вот здесь? Нет. Мы требуем, чтобы в третьем актете была единица, а здесь у нас двойка. Есть ли совпадение в третьем маршруте? Есть. у нас 192 168 2 вопросик 192 168 22 совпадение есть то есть этот маршрут подходит для того чтобы по нему отправить трафик если совпадение вот здесь есть мы требуем чтобы все 32 бита были неважно

какими они действительно не важно какие например они стой на за два 168 22 поэтому совпадение у нас есть по две строчки но для того чтобы все-таки вернуть один результат мы говорим нам нужно каким-то образом сравнить эти две строчки вот та строчка где вопросиков меньше она будет более хорошо подходящая под результат запроса здесь у нас 32 вопросика здесь у нас 8 вопросиков соответственно вот этот вот результат будет выдан в качестве итогового значения если вы храните в памяти ячейки 0 1 или неважно что если у вас может быть несколько результатов за счет того что разное количество бит попало под совпадение и разное количество в битвы сказали ну ты же требовал неважно что вот мы там неважно что и сравнили то в этом случае вот чем меньше этого самого неважно что получилось тем лучше вот таком соответственно по заданному ключу по заданному образцу за предсказуемое время возвращает наиболее подходящую запись или говорит о том что записи такое нету эту

штуку можно использовать в таблице маршизации эту штуку можно использовать в access листах то есть везде где-то нам требуется какое-то совпадение или несовпадение но на самом деле ее можно использовать как обычную кам то есть в принципе если у вас есть вот это вот самая троечная память вы можете сказать окей мы можем хранить нолики единички и неважно что давайте неважно что не будем просто договоримся не хранить она может хранить но может же не хранить да мы же можем представить себе что мы в договариваемся до что в определенной ячейке просто не складываем вопросики мы складываем только нолики единички поэтому если у вас есть свеч который может хранить записи в таком и он может в принципе в этой таком храните просто обычную базу mac адресов он использует продвинутую т.к. троичную память как обычную кам память поэтому если мы говорим про например на оборудование циски вы в любом курсе встретите указание что для таблицы коммутации используется отдельная кам память а для таблицы маршрутизации используется отдельный т.к. память это брехня вы можете взять посмотреть содержимое т.к. памяти увидеть что на самом

деле таблица mac адресов хранится в т.к. ами потому что есть только один блок памяти это блок памяти т.к. отдельной памяти под мог адреса нету как обрабатывается трафик на коммутаторе у нас приходит кадр этот кадр понимается на каком-то порту дальше вы говорите нам нужно принять решение на каких портах мы кофе кадр отправили у нас есть такая порт такой порт такой порт такой порт такой порт такой порт такой порт уже одна Bros baggage book м bro о north pro вот нам надо на каждом из этих портов принять решение на На каких портах мы отправляем копию этого кадра, на каких нет. Соответственно, мы одновременно запускаем несколько механизмов оценки того, в какие порты копию кадра мы отправляем и в какие не отправляем. Запускаем поиск по MAC-адресу получателя. Соответственно, знаем ли мы, где сидит MAC-адрес получателя. Если у нас есть вложение IP, что мы разрешаем пропускать, что мы не разрешаем пропускать.

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

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

Можем сказать, что мы разрешаем прохождение кадров на этом порту только если у них MAC-адрес источника вот такой, а MAC-адрес получателя вот такой. То есть, например, левая половина MAC-а, это называется OUI, Organizational Unit Identifier, и она выделяется под оборудование конкретного производителя. Мы можем сказать, у нас в сети используются только ноутбуки Lenovo, и мы разрешаем прохождение кадров только с OUI-шками, принадлежащими Lenovo. Если вдруг кто-то принесет свой ноутбук, и он окажется, не знаю, MAC-буком, вот мы его коммутировать просто не будем, потому что он кадры будет отправлять из-под MAC-а с неправильной левой частью. Вот такие вот вещи вы можете сделать. Вы одновременно запускаете процедуру поиска MAC-адреса получателя, одновременно запускаете механизмы поиска по всяким защитным механизмам типа Security Access листов, и одновременно определяете, хотите ли вы этот кадр фарвардить или не хотите, в зависимости от каких-то киос, аксесс-листов.

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

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

У нас есть вместо одного большого физического коммутатора, одного большого, назовем это VLAN-а, несколько виртуальных маленьких свечей. Мы взяли большой коммутатор, разрезали его на части и сказали, у нас есть виртуальный коммутатор, отвечающий за один широкопечательный домен, за другой широкопечательный домен. И, соответственно, кадры, которые к нам приходят, мы по какому-то признаку отправляем на коммутацию в одном широкопечательном домене. Дальше. Самый простой вариант, как это может произойти, это, например, мы можем сказать, что вот этот вот порт, который у нас получил кадр, он в аксессовом режиме принадлежит VLAN-у номер один. Дальше. Мы говорим, что этот кадр приходит на MAC-адрес виртуального роутера. Соответственно, у него есть MAC-адрес. Он фактически как отдельная железка подключается к этому самому VLAN-у. Иногда мы можем сказать, что вот этот вот самый MAC-адрес принадлежит центральному процессору. И назовем это CPU. Иногда можно сказать, что это MAC-адрес нашего интерфейса SVI.

Вот эта вот штука, когда у вас есть что-то, что смотрит в VLAN, на котором есть MAC-адрес, вот эта вот штука будет называться SVI или Switch Virtual Interface. Но в любом случае, да, в голове у L3-коммутатора есть маршрутизатор. И вот этот маршрутизатор будет смотреть в разные VLAN-ы. Кадр, который принимается, он, соответственно, направляется по таблице коммутации на виртуальный MAC-адрес вот этого самого SVI-интерфейса. Дальше. Здесь у нас начинает работать маршрутизатор. Этих маршрутизаторов, кстати, может быть несколько. У нас может быть несколько маршрутизаторов с несколькими разными таблицами. Здесь у нас будут VRF-ы разные, VRF-1, VRF-2 и так далее. Ну вот, да, мы говорим, у нас есть VRF, там, допустим, один. Вот он принимает кадр по таблице, определяет, куда такой кадр надо девать и говорит, выходным интерфейсом должен быть интерфейс, который мы смотрим в сторону VLAN-а, например, 2. И дальше. Уже второй виртуальный коммутатор говорит, мы принимаем кадр, содержащий IP-пакет,

но этот кадр уже в новой заголовке будет обернут, и принимаем дальше коммутационное решение, куда такой кадр надо будет девать. И направляем этот кадр в сторону выходного интерфейса. При этом кадр, который мы получили с одной стороны, и кадр, который мы отправили дальше в другую сторону, они не совсем похожи друг на друга. У них будут одинаковые L3-вложения, то есть одинаковые заголовки IP, например. Ну то есть у них destination адрес будет совпадать, 112.168.22. Source адрес будет совпадать, 112.168.1. TTL. Из него транзитный коммутатор должен вычесть копеечку, копеечку по этому TTL у нас изменится. 64, допустим, был приходящий кадр TTL, и 63, соответственно, будет исходящий. Как следствие, чексумма, которая была, изменится, потому что она считается от всего IP-заголовка, и, соответственно, в исходящем кадре транзитный коммутатор должен будет пересчитать чексумму. Ну и на заголовке канального уровня это тоже должно отразиться. Соответственно, у нас был какой-то кадр, содержащий один IP-пакет. Здесь у нас, получается, заголовки были из-под какого-то Мака

на MAC-адрес нашего виртуального роутера. Здесь, соответственно, в исходящем кадре у нас source адрес будет MAC-адрес нашего роутера, а исходящий адрес – это какой-то другой MAC-адрес, куда он будет направляться. Поэтому у нас здесь, хотя мы и говорим, что это, в принципе, данные мы получили с одной стороны, данные выплюнули с другой стороны, но по факту в этих данных меняются почти все заголовки. Меняется все в заголовке канального уровня. И MAC-адрес отправителя, и MAC-адрес получателя в этом случае меняются, и чексумма, естественно. Меняется TTL, и меняется чексумма в заголовке IP. Пусть IP-шники не меняются, но тем не менее чексумма, TTL меняются. Может быть, изменится метка Kiosk. Ну то есть это уже не тот кадр. Получается, что у нас вот здесь, вот в этом широковещательном домене был один кадр, здесь, вот в этом широковещательном домене у нас другой кадр, и пакет, который мы перекладываем между этими широковещательными доменами, он вот в какой-то степени остается тем же самым. Но мы в нем тоже кое-какие вещи все-таки меняем. В какой-то момент у людей, которые строили коммутаторы, возник вопрос,

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

Вот. Вот эта вот процедура, это как раз и будет то, что называется Frame Rewrite. У нас есть кадр, который приходит на наш роутер, на наш свитч, L3-коммутатор, и мы его перекладываем в другой порт, ну или в другие порты, точно так же, как мы это перекладываем со всеми остальными L2-кадрами. Вот. У нас приходит кадр, содержащий пакет, мы его перекладываем в другие порты, но у нас просто немножко добавляется дискриминационных правил. Мы говорим, что в некоторые порты мы кадр будем перекладывать, в некоторые не будем. Ну, соответственно, мы будем одновременно принимать его внимание, и там VLAN-отправителя, и VLAN-получателя, и то, какие-то мои пишники будут внутри. Все эти правила прекрасно описываются троичными вот этими запросами TK. То есть мы можем сказать, что если кадр приходит у нас вот здесь вот, и мы на входе говорим, что он будет принадлежать VLAN-у 1, то дальше мы по какой-то таблице, может быть, достаточно сложной таблице, но тем не менее по достаточно сложной таблице принимаем решение,

что этот кадр должен выйти через вот этот вот интерфейс, и у него заголовки должны определенным образом поменяться. Должны перебиться вот такие заголовки, в L2 все поменяется, в L3 надо будет вот здесь вот с таким вот смещением вычесть единичку, там в IP-заголовке с вот таким вот смещением надо пересчитать чек-сумму по известному алгоритму. Ну, то есть это все, да, хоть и сложные правила, но они достаточно формальные. Кадр пришел с одной стороны, мы повесили на него указание, что он пришел в первом VLAN-е, и дальше мы запустили обработчик в TK-ме, типа, посмотри, пожалуйста, по вот таким IP-шникам, по вот таким вот MAC-адресам, по вот такому-то VLAN-у, что мы должны сделать с этим кадром, как мы должны его перебить и в какой порт мы его должны послать. И, соответственно, коммутатор, да, он, как бы можно сказать, что он внутри себя запускает маршрутизацию, да, но на самом деле он всего лишь смотрит в этот самый TK-ам, находит набор правил, которые применяются к конкретному этому правилу, находит среди них самое подходящее, говорит, в результате в TK-ам я посмотрел,

и в TK-ам решил, что этот кадр надо отправить вот сюда вот, и перебить его вот таким вот образом. То есть это не процедура сравнимая с маршрутизацией, это классическая коммутация, просто по более сложному правилу. Обычный коммутатор Ethernet говорит, я коммутирую только там по принципу, посмотрел, в какие порты это может отправиться, в какие не может, и на каждом порту либо заблокировал, либо не заблокировал. Здесь мы будем смотреть не только по MAC-адресу получателя, но и по множеству других полей, куда мы отправляем копию этого кадра, куда не отправляем. Если мы принимаем решение, что этот кадр, допустим, следует обрабатывать, как будто бы он прошел через роутер, ну, соответственно, сразу мы понимаем, что максимум количества портов, куда мы его будем отправлять, это вот там, не больше одного. Вот. Вот эта штука будет называться Frame ReWrite. Frame ReWrite.

Вот. Ее может делать коммутатор. Она очень простая. Ну, как очень простая? Она не простая. Это все операция, как бы, комплексная. Но она выполняется за предсказуемое время. Она реализуется с помощью ТКМа. И она за один запрос, за один проход по таблице самого ТКМа возвращает вам готовый результат. Куда девать такой кадр? Что в нем надо поменять? Чтобы результат был неотличим от того, как будто бы вы выполнили полноценную маршетизацию. Так. Да. Далее. С Frame ReWrite обсудили, что если у вас есть вот этот вот самый аппаратный ускоритель ЦФ, у вас есть супервизоры. Вот у нас супервизор 1, у вас супервизор 2. У нас есть эти супервизоры, которые пополняют по каким-то правилам ТКМ. В этом ТКМе хранятся правила, которые мы указываем, будут ли применяться в конкретном случае или не будут. И когда кадр проходит, соответственно, каждая линейная карта, которые вот эти линейные карты у нас,

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

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

И, соответственно, мы отправляем такой кадр с перебитыми какими-то заголовками канального уровня, сетевого уровня, чем-то еще, в сеть назначения. Для того, чтобы это все работало, у нас есть супервизор, ну или центральный процессор, который пополняет таблицу маршрутизации с помощью OSPF, RIP, EGRP, BGP, статистических маршрутов, всего чего угодно. Эти маршруты складываются в таблицу маршрутизации. Дальше они пережевываются, складываются, префиксы в кэш аппаратного ускорителя SHOIP-CF. Показывается, в нашем случае у нас есть маршрут 112.168.4.0 по 24 маске. Это префикс. И по каждому префиксу высчитывается сосед, которому надо отправить кадр, который приходит под этот префикс. Причем не просто какой-то абстрактный IP-шник NextHop, а в нашем случае вот 112.168.4.0 направить на 112.168.3 статический маршрут, а 112.168.3 через 112.168.2 нам направляется BGP, NextHop притащил, а 112.168.2 OSPF говорит, ходи в 112.168.1.1,

а 112.168.1.1 это connected interface. Вот получается, что этот говорит, ходи через тот, тот говорит, ходи через сюда, сюда говорит, ходи через здесь, а здесь у нас вот он connected. Но в цехе показывается всегда NextHop, который connected, который с нами в одной канальной среде. То есть уже готовый пережеванный результат, который за один проход даст нам идеальные указания, куда отправить такой кадр. То есть фактически здесь содержится вся необходимая информация для перебивки кадра в части его заголовков. Если мы складывали бы готовые пересчитанные заголовки канального уровня в кэш аппаратного ускорителя сразу по каждому префиксу, то при пополнении таблицы маршрутизации FullView BGP, например, то же самое 700 тысяч префиксов, мы бы это вынуждены были бы повторить там 700 тысяч раз, потому что префиксы у нас много префиксов, и по каждому пришлось бы хранить отдельный заголовок. В качестве оптимизации Cisco решила, что префиксы складываются в таблицу с указанием просто,

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

если бы они были разные. Ну, они бы, конечно, были все время одинаковые, нам пришлось бы существенно меньше раз количество соседей пощупать, но тем не менее, да, вот мы бы должны были сделать это все одновременно. А так, по факту, у нас сейчас пришел трафик туда до одного соседа, мы его прощупали. Сейчас пришел трафик до другого соседа, мы его прощупали. Сейчас пришел трафик до третьего, мы третьего прощупали. Еще десяток, которые там есть, которые в таблице как бы хранятся, но мы их по факту не используем. Они как запасные или там как что-то еще. Мы их не резолмим и будем резолтить только если, по факту, нам потребуется им отправить какой-то трафик. и вот в таблице аджасенсе у вас показывается что есть за интерфейсом вилан 2 сосед вот такой вот и сразу готовый заголовок канального уровня у вас посчитан для того чтобы трафик отправить ему то есть вот это вот это на самом деле 0 0 0 0 0 0 0 0 2 6 b c 6 это мак адрес получателя 0 0 0 0 0 0 0 0 3 5 7 4 d это мак адрес источника 0 8 0 0 сами понимаете type v4 и зар-тайп и это действительно

готовый заголовок ethernet а к нему приклеивается айпи пакет к нему приклеивается фрейм check sequence это все считается автоматически на кремнии и очень быстро и внутри айпи заголовка у нас меняется ттл у нас меняется чек сумма хэдер чек сам ну и возможно у нас есть какие-то поля которые надо внутри там тоже будет еще перебить опять же таком нам скажут что конкретно перебивать в каждом конкретном случае отцев соответственно будет хранить данные в нескольких разных таблицах сначала будут храниться пережеванный маршрут это сами префиксы префикс у нас может быть доступен из нескольких источников плюс циски позволяют выполнять балансировку по разным направлениям для одного и того же префикса поэтому эти самые префиксы ссылаются на самом деле нет на соседей напрямую она на так называемые бакеты бакеты это те самые шнурки или ну да то есть направление в которой можно посылать трафик

определенного префикса и соответственно вот уже бакеты ссылаются на аджайсинс и на непосредственно соседов смысл бакета в том что они позволяют реализовать неодинаковую нагрузку на несколько соседей у нас есть указание что есть наш роутер и вот он по и gp говорит что у нас есть один сосед и другой сосед и у одного есть возможность отправлять трафик в два раза лучше чем у другого в какую-то сеть то есть вот здесь у нас метрика допустим 100 копеек а здесь у нас метрика 200 копеек вот мы хотим 2 к 1 сделать загрузку загрузку сюда вдвое больше чем сюда вот мы в этом случае два бакета направляем на одного соседа один бакет на другого соседа и вот эти вот уже бакеты ссылаются на аджайсинси которые говорят какие заголовки надо перебить для конкретного для конкретного аджайсинси что поменяем чек сумму ттл какие-то еще правила вот ну и да может быть такое что у вас один сосед будет не знаю грешный вот а

другой будет знаю изорнета вский вот в этом случае заголовки у не естественно будут разные но никаких проблем все вот эти вот индивидуальные особенности конкретного соседа хранятся в таблице аджайсинси в таблице бакетов хранится указания с какой с каким отношением балансируем трафик и все это дело связывается с префиксами фибер-энтри багеты можно будет посмотреть команды шоу и пицц дальше указываем префикс и словом интернал вот здесь у нас пример как раз что есть и джерпишная сетка и у нее есть два маршрута с неодинаковой метрикой в логе джерпи мы можем это сделать через анык в косту лод балансинг команду вариант прописываем у нас получается здесь метрика 128 тысяч 256 тысяч вот мы хотим балансировать трафик как раз пропорции 2 к 1 в шоу и пицц нам показывается что префикс действительно у нас есть доступен через два через двух соседей сосед 100 и нас два 168 11 трафик шер 2 и 100 2 168 21 трафик

шер 1 и вот они эти самые бакеты соответственно мы берем три бакета 0 1 2 и говорим что вот у нас есть какой-то пакет который приходит и соответственно мы берем этот пакет точнее свойства этого пакета запихиваем в некую функцию и эта функция дает случайный какой-то ну более-менее хорошо распределенный результат и соответственно мы берем эту функцию и делим с остатком на 3 потому что у нас три бакета вот мы берем делимся остатки на 3 получаем одно из двух из трех значений либо 0 поделилась на цело либо один то есть после деления на 3 сдал остатка один либо двойка после деления на 3 дал остаток 2 и вот в бакет с таким номером и используем и отправляем кадр конкретный который мы хотим отправить в нашем случае мы задействовали три бакета 1 и 2 бакеты на 1 соседа 3 бакет на 2 соседа и получается при случайном

распределении пакетов при случайно распределение потоков мы будем загружать в сторону 1 2 3 бакетов трафик более-менее равномерно и тогда первый сосед получит трафика в два раза больше чем другой вот этих бакетов можно повесить до 16 штук на один префикс в ipv4 на самом деле до 32 но это зависит от платформы каждый аджесенсе который вы будете иметь возможность повесить может быть один из различных типов то есть вот нашем случае у нас показывается швай пицц разные префиксы есть и у них показываются какие аджесенсы к ним будут соответствовать вот здесь вот у нас есть например айпишник мы говорим что трафик до сети из 1111 1132 надо направить на 100 12 168 12 у нас есть типы attach это значит что это наши собственные как бы в кавычках наши собственные а пардон пардон пардон бру у нас есть 3 сиф это наш собственный трафик он

принадлежит именно нам если мы получаем такой кадр и видим что аджесенсе 3 сиф ну значит это надо его обработать на центральном процессоре на условном супервизоре и мы направляем ресивы на себя самих attach это означает что надо поискать соседа что мы его пока не нашли но надо поискать в таблице аджесенсе именно и там уже когда найдем будем направлять трафик ему если вдруг какой-то пакет проходит и вот у него аджесенсе стоит attach it то немедленно на самом деле здесь рядышком будет добавлен еще одна строчка с указанием того как достать трафик когда ставить трафик именно до конкретного соседа то есть у нас появится еще просто одна строчка в кэше cf а вот эти самые джазинси вот 12 168 12 есть явная пишник соседа есть attach it есть дроп есть receive они будут означать всякие разные вещи вот если у нас есть указанный айпишник куда направлять трафик это значит что это нормальная джазинси с ним все

хорошо мы пощупали соседа мы обнаружили его канальный адрес сформировали заголовок это запись типа кэш если мы видим запись типа receive то это значит это виртуальная запись и мы этот маршрут расцениваем как то что он смотрит на самих нас то есть это либо наши собственные пешники либо брат каст который нам интересен либо мультикаст который нам интересен ну то есть да и понятно что это надо направить на процессор он разберется интересно тоже по факту или нет если вы какой-то трафик 0 раутим в этом случае у нас есть виртуальный интерфейс 00 и вот то что смотрят в 00 она имеет тип нул есть дискард или дроп вы можете на уровне цеха сказать что определенный трафик вы не фарвард эти в принципе вы хотите его сбрасывать чтобы не тратить на него ресурсы например если вы не обрабатываете маршрутизируемый мультикаст то у вас есть запись 224 004 типа дроп это значит трафик который проходит через ваш роутер и попадает под определенную запись вы просто выбрасываете никому про это ничего не говорите то есть вы его не

обрабатываете и не собираетесь даже обрабатывать дискард от дропа будет отличаться тем что в случае с дискардом вы заставляете процессор уведомить отправителя но и вообще как-то процессор должен поднапрячься что-то сделать а дроп при этом просто тихо дропы это никого не уведомляет и последние два типа записи которые интересны это пункт и глин пункт это виртуальная запись которая будет означать что у нас есть определенное назначение которое мы знаем что вот пакеты на это определенное значение надо как-то специально хитро обрабатывать и это должен сделать супервизор ну например мы с каким-то соседом поднимаем и письмо вскую сессию вот мы говорим у нас 12 168 11 это айпишник который стоит 21 до этой пешник который мы знаем когда него доставить трафик но мы его обязательно в и письмо завернем поэтому в кэше аппаратного ускорителя есть такой сосед но есть указание что это сосед очень хитрый специфический

что пакет на него надо по-любому на супервизор отправлять это супервизор будет заворачивать дальше в шифрованные содержимое и глин запись это запись соседа которому мы попытались доставить чего-нибудь нам прошел пакет мы говорим мы сейчас будем фарвард пакет ему но нам нужен его канальный адрес и мы сейчас будем орать на всю сеть например арпом чувак скажи как тебя зовут какой у тебя и пишет не как у тебя мак мы тебя хотим пощупать за вы ими вот и глин запись это как раз запись которая создается для соседства которое только что было затребовано но мы еще не сформировали канальный заголовок для него то есть если вы сейчас возьмете с циски попингаете какой-нибудь узел который ну которого нету в сети который есть в вашей сети с точки зрения таблицы маршрутизации то есть у вас там айпишник 112 168 11 по 24 маски а вы пытаетесь пинге 100 12 168 1 200 вот в этом случае у вас сформируется глин запись для такого адреса но она через некоторое время пропадет потому что вы не

зарезал этот заголовок но тем не менее в течение некоторого времени она все еще в таблице присутствовать будет картинка которую мы видели на роуте то что через линейную карту трафик проходит всякие разные и у этой линейная карта обрабатывает трафик сама без подключения центрального процессора у нас есть routing engine он же супервизор который пополняется какими-то маршрутами там по spf почему-нибудь еще пополняет таблицу маршрутизации дальше на основании этой таблицы маршрутизации он прожевывает маршруты и складывает их в фиб в мастер копии forwarding information base и дальше этот фиб разливается на линейные кадры линейные карты и соответственно каждая линейная карта может обрабатывать трафик без подключения процессора в большинстве случаев но кроме случая когда у вас есть пункты когда приходит какой-то кадр и дальше мы фибы посмотрели нашли запись аджесин сети по пункт и в этом случае мы его посылаем на процессор уже процессор его обрабатывает и отправляет дальше в большинстве платформ вот этот

вот линк между линейными картами и routing engine он не очень производительный то есть сама линейная карта может быть очень жирный и она трафик через себя far варзит она этот канал до процессор вообще не задействует но в некоторых случаях вот особенно когда мы говорим про пункт записи трафик направляется таки на процессор из процессор уже направляется дальше и соответственно вот этот вот линк он может стать причиной определенных задержек поэтому может быть такое что трафик до 1 и пишет у вас ходит на одной скорости трафик другого и пишет который требует обработки на процессоре он будет ходить на совершенно другой скорости на существенно меньше это нормально да вот эта вот штука называется distributed cf то есть когда у вас отдельно routing engine формирует мастер копию фиба и отдельно линейные карты получают свою копию фиба да есть такая штука которая называется cf polarization вы вряд ли с

ней столкнетесь в реальной жизни но тем не менее на экзамене про нее могут быть вопросы циска в свое время очень гордилась тем что она ее поборола хотя в общем то она ее создала что здесь имеется ввиду если взять себе представить что у вас есть роутер с цифом и на него валится определенный тип трафика ну допустим трафик идет на айпишник 1001 вот в этом случае мы говорим давайте балансировать этот трафик давайте мы трафик будем направлять балансируя пир пакет то есть помните да что у нас есть балансировка по сети назначения и по соответственно по отдельным пакетом вот и мы видим что у нас приходит какой-то вот пакет отдеть на адресường 1 и мы начинаем его балансировать мы говорим там четные пакеты направляем на лево нечетно�� направо и дальше если у вас здесь вот будет еще один роутеров центов то соответственно он получит только четные пакеты если мы будем брать содержимое пакета здесь и содержимое пакета здесь то соответственно что здесь у нас будет

более-менее случайно распределение условно четных и нечетных пакетов а вот здесь вот наверху у нас получится что мы видим только четные пакеты эти пакеты уже будут не случайны они будут все Все в какой-то степени одинаковые. Причем эта степень одинаковости будет в самой чувствительной для нас точке. Именно та точка, которая нужна для определения, куда девать этот пакет. Соответственно, на все пакеты, которые мы будем получать здесь, если мы будем говорить, давайте мы там тоже будем делить на четные и нечетные, внезапно они у нас все получатся четные. Они у нас все будут направляться в одну и ту же сторону. А в другую ничего не будет отправляться, потому что нечетных пакетов у нас здесь нет. Или с отдельными пакетами плохой, наверное, пример. Давайте представим себе, что у нас есть вот как раз балансировка по сети назначениям. Вот мы говорим, у нас есть сетка 10 000-24, которую надо балансировать. И вот здесь вот четные IP-шники назначения пойдут в одну сторону, нечетные IP-шники назначения в другую. В этом случае все IP-шники назначения на верхнем роутере будут четные. Все IP-шники направлений на нижнем роутере будут уже нечетные.

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

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

Есть вариант балансировки, который говорит include ports. В этом случае мы будем балансировать трафик по заголовкам L3, и для известных протоколов транспортного уровня TCP и UDP у нас еще есть порты. Соответственно, вот в этом случае мы можем сказать, давайте разбрасывать по IP-шникам и по TCP и UDP портам. И в этом случае, если мы будем трафик разбрасывать по вот этим вот заголовкам одновременно, то у нас получится механизм балансировки, что мы там в одном месте можем только от L3 посчитать, в другом случае от L4. То есть получается у нас какая-то доля энтропии добавляется в случае алгоритма include ports. И, соответственно, для некоторых типов интерфейсов, особенно для туннельных интерфейсов это будет характерно, там есть проблема, связанная с тем, что пакеты, которые направляются в туннель, они все, как правило, очень сильно похожи друг на друга.

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

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