Cisco Express Forwarding

Следующий модуль будет посвящён аппаратному ускорителю, который называется Cisco Express Forwarding, и который на самом деле сильно упрощает процесс маршрутизации на железках Cisco. Задача маршрутизации состоит в том, чтобы найти: а) выходной интерфейс и б) канальный адрес того соседа, которому надо отправить трафик. В то же время, если мы используем классическую маршрутизацию, которую нам предлагает show ip route, то мы делаем рекурсивные запросы к ней. Мы говорим: «Как добраться до определённого IP?» Она говорит: «Ходи через вон того». Дальше мы спрашиваем: «А как дойти до вон того?» «Ходи через вот этого». «Как дойти до этого?» — «Через пятого соседа». «Как дойти до этого?» — «Через десятого соседа». И рано или поздно система должна вернуть connected-запись, connected-интерфейс, и на этом connected-интерфейсе мы последний next hop, который нам вернули, будем пытаться резолвить и найдём в итоге канальный адрес. И соответственно все транзитные записи, которые в процессе рекурсии мы находили, они на самом деле никоим образом никому не нужны. Они

нужны только для того, чтобы в таблице маршрутизации эта рекурсивная структура работала. То, что мы заранее не знаем, сколько записей нам придётся просмотреть в таблице маршрутизации, на самом деле играет очень злую шутку с нами, потому что если вдруг нам приходит какой-то пакет, который мы должны промаршрутизировать по-честному, мы говорим: «К нам пришёл пакет, мы сейчас будем искать ему next hop». И дальше мы начинаем шерстить таблицу маршрутизации: сначала смотрим все записи в таблице маршрутизации, находим лучший для IP-адреса назначения в пакете, потом мы снова шерстим все записи, ищем лучший для next hop, который нам вернула таблица на предыдущем результате, дальше снова, возможно, ищем лучший next hop для предыдущего — и так до тех пор, пока мы не находим connected-интерфейс. Сколько раз придётся прошерстить таблицу маршрутизации, заранее мы не знаем. Приходит пакет, мы говорим: «Погоди, мы сейчас будем шерстить таблицу». Придётся один раз прошерстить — хорошо. Придётся два раза прошерстить — похуже. 17 раз подряд придётся прошерстить — совсем не замечательно. И

получается, что время, которое требуется на маршрутизацию пакета при таком подходе, будет недетерминированным. Мы заранее его предсказать не можем, оно каждый раз будет меняться. Пришёл сегодня пакет — мы его промаршрутизировали за одну миллисекунду. Завтра пришёл тот же самый пакет — мы его промаршрутизировали за 10 миллисекунд, потому что у нас таблица маршрутизации поменялась. Мало того что роутер может быть по-разному загружен вообще, и время, которое роутер сможет уделить нашему пакету, заранее предсказать нельзя, так ещё и для каждого конкретного IP-адреса назначения время это может меняться в разные моменты времени. Получится, что затрачиваемое время на обработку каждого конкретного пакета вообще будет произвольным. Cisco на это дело долго смотрела и говорила: «Ну как-то это вообще грустно, что нам процессором приходится по этой таблице всё время проходить». Потому что вот у нас есть show ip route, здесь показывается, что у нас есть всякие маршруты. У нас есть OSPF-маршрут,

который стоит до сети 10.216.8.20 через OSPF, и пришёл от соседа 10.216.8.11. У нас есть BGP-маршрут, который идёт через 10.2.6.8.21. У нас есть статический маршрут, который через 10.216.8.31. Я хочу подчеркнуть, это абсолютно вполне реальный вывод, это не какая-то загадка для ума, как на самом первом слайде была про маршрутизацию, когда вам рекурсию поставили. Нет, на самом деле OSPF такие маршруты и притаскивает. Он говорит: «У меня есть сосед, который притащил мне IP-адрес 10.216.8.20 по /24 маске, префикс. Сосед 10.216.8.31 доступен через GigabitEthernet 0/0 интерфейс, этот сосед в connected-сетке 10.216.8.10 по /24 маске, мы знаем, как до него добраться, как следствие мы знаем, как добраться до 10.216.8.20». BGP притаскивает вам next hop, который не обязан быть connected и даже чаще всего им не является. В нашем случае BGP притащил сеть 10.0.2.168.30, он говорит: next hop в эту

сеть будет 10.0.2.168.21. Мы такой маршрут добавили в таблицу. Можете заметить, что мы знаем, как добраться до 10.216.8.20. Но если вдруг мы будем отправлять пакеты на 10.0.2.168.33, то мы сначала переберём всю таблицу, скажем: «Это лучший маршрут для этой сети, next hop — 10.0.2.168.21. Как до него добраться?» Снова шерстим всю таблицу, находим 10.0.2.168.20, говорим: этот префикс у нас connected на GigabitEthernet 0/0 интерфейсе, доступен через 10.0.2.168.11, находим MAC-адрес 10.0.2.168.11, отправляем пакет ему. Никто нам не мешает сказать, что у нас есть дополнительно статический маршрут, доступный через соседа 10.0.2.168.31. Мы статику прописали, говорим: 10.0.2.168.40 доступен через 10.0.2.168.31. Если у нас пакет пришёл на 10.0.2.168.41, что мы делаем? Шерстим таблицу, находим лучший маршрут по правилу longest prefix match, находим 10.0.2.168.40, говорим: «Как до него

добраться?» Через 10.0.2.168.31. «Как до 10.0.2.168.31 добраться?» Снова шерстим таблицу, снова находим лучший маршрут, но уже до .31, находим маршрут. «Как до него добраться?» Через 10.0.2.168.21. Снова ходим, в третий раз уже всю таблицу проходим, кроме тех, которые на предыдущем этапе сработали, маршрутов, и находим для него уже лучший маршрут — это наконец OSPF-маршрут. Три запроса сделали к таблице для того, чтобы определить, куда послать трафик до 192.168.40. Это действительно сложно, если мы процессором всё это делаем. С таблицей маршрутизации большой время, которое центральный процессор будет молотить эту самую таблицу, будет действительно большим. Представьте себе, что у вас магистральный роутер в интернете, у которого сегодня в интернете порядка 700 тысяч маршрутов. Ему на каждый пакет надо будет несколько раз пройти через всю таблицу. На каждый отдельный пакетик прошерстить там полтора миллиона записей. Полтора миллиона — это в лучшем случае, а то и все два миллиона. Это действительно большой объём работы, а

главное — на каждый пакетик. Есть у вас магистральный роутер, который обрабатывает сотни гигабит в секунду — он не может физически иметь такую вычислительную мощность, для того чтобы на каждый пакет подрываться и два миллиона записей прошерстить. Ему нужно каким-то образом помочь. И соответственно Cisco предложила помощь. Она сказала, что для магистральных роутеров у нас есть решение. Сделано это было довольно давно, и задачи, которые стояли на тот момент, они были не настолько амбициозные, как обработать 100 гигабит в секунду, но и мощности железа на тот момент были существенно ниже. Поэтому надо понимать, что центральный магистральный роутер, который обслуживал весь интернет, у него производительность была примерно на уровне Nokia 3310, поэтому и возможности у него были сильно меньше. И Cisco предложила: «Давайте мы будем кэшировать маршруты, потому что всё равно, когда у нас есть такая большая таблица, большая часть пакетов, которые приходят, они приходят в одном и том же направлении. Какой смысл: к нам первый пакет пришёл, мы его по-честному

промаршрутизировали, все два миллиона записей прошерстили, нашли выходной интерфейс, канальный адрес соседа, отправили пакет в его сторону. Следующий пакет, который пришёл, — он точно такой же, ничем не отличается, всё то же самое. Какой смысл повторно делать всю ту же самую работу? Нет смысла». И Cisco сказала: «Давайте мы сделаем специальную отдельную быструю память, в которую будем складывать IP-адреса, которые у нас уже прошерстили». Пришёл к нам пакет на 10.0.2.168.41, мы по-честному прошерстили всю таблицу маршрутизации, а может быть даже несколько раз, и в результате, когда у нас нашёлся выходной интерфейс и выходной адрес, мы сложили этот адрес в быструю память. Следующий пакет, когда проходит, первым делом мы смотрим в этой самой быстрой памяти: а нет ли уже этого IP-адреса? Если уже такой IP-адрес есть — не надо полноценно всё делать, надо предположить, что ничего не изменилось, и соответственно надо повторно тот же самый интерфейс и канальный адрес использовать

для обработки всех последующих пакетов в том же самом потоке, которые идут на тот же самый IP-адрес. Этот механизм кэширования результатов действительно очень сильно ускорил работу. Он в предположении, что все пакеты одного и того же потока обрабатываются одинаково, позволил Cisco быстро, действительно быстро обрабатывать очень большое количество пакетов. На каждый пакет роутер не напрягался по-честному, а халявил: он говорил «А этот пакет мы уже знаем, куда девать, потому что предыдущий пакет уже лыжню проложил, вот мы по этой же лыжне и отправим». Механизм естественно требовал, чтобы первый пакет потока всё равно маршрутизировался по-честному, но дальше уже последующая работа роутера с пакетами в потоке была достаточно простой. Плюсом этой штуки было то, что она несложно реализуется: быстренько перед тем, как запускать полноценную

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

RAM, отдельно флешка, что есть флешка большая, а есть флешка надёжная. Надёжная флешка делалась настолько маленькой, насколько это возможно. И соответственно памяти для кэша тоже делалось так мало, насколько это было возможно. Фишка не в памяти, фишка в контроллере той памяти. Сама память самая обычная. А вот контроллер памяти, который фактически управляет адресацией её, — он как раз хитрый и дорогой. Этот механизм route caching, кэширование маршрутов, его ещё называют иногда fast switching. Он появился в древних IOS-ах, и сегодня он уже упразднён. Начиная с 12.4(20) IOS на роутерах, 12.2(25) на свитчах, его больше нет. Если у вас IOS старше, в смысле древнее, то соответственно вы его можете задействовать, если захотите. Но если у вас 15-й IOS, то вы его включить не можете.

Да, естественно, всё это дело в кэше хранится не бесконечно, потому что если у вас роутер работает — знаете, я видел роутер, у которого uptime по 10 лет, — вы не можете вечно хранить все записи на все IP-адреса, которые вы обрабатывали. Поэтому кэш протухает, и соответственно, если у вас есть отдельные мелкие пакеты, которые бегут по одному и тому же адресу, но с достаточно большим временным разрывом, то ускорение там никакого не получается. Но это и не страшно, потому что такие пакеты — их мало, они мелкие и общую нагрузку не дают. Основную нагрузку, как вы понимаете, дают всякие приложения типа FTP: запустили, начинаем качать файл на скорости мегабит в секунду. И тут вы должны сказать: «Мегабит — это вообще что? В смысле гигабит в секунду?» Нет, нет, нет, это было когда-то. Мегабит в секунду был недостижимой большой скоростью, когда приличные люди очень бурно радовались, если у них модем запустился на 1200 бит в секунду, а не на 300. Поэтому, да, скорости были существенно ниже, чем мы сегодня привыкли.

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

Вы можете посмотреть запись кэша. Если определённая запись есть, то соответственно вы можете ей воспользоваться — не просто промаршрутизировав пакет по ней, а прямо посмотреть на неё вживую. Команда show ip cache. И дальше вы указываете IP-адрес и, на самом деле, маску префиксную. И показывается, какой префикс вы по-честному промаршрутизировали. У нас есть полноценный вывод show ip route. И мы видим, что четвёрка доступна через тройку, тройка доступна через двойку, двойка доступна через единичку. Первый пакет прошёл, всё это было по-честному посчитано. И дальше в кэше у нас 192.168.4.0/24 указывает на интерфейс GigabitEthernet 0/0. Это connected-интерфейс. И у него сразу уже готовый заголовок канального уровня. Здесь закодированы и MAC-адреса, и всё на свете. CEF и fast switching — нет, это не одно и то же. Fast switching — это старый механизм ускорения маршрутизации, который был до CEF. В некоторых книгах между ними различий не делают.

На самом деле различия есть. И различие заключается в том, что CEF сейчас актуален, а эта штука — нет. Эта штука сдохла начиная с 12.4 IOS. Прошу вас сейчас посмотреть на этот MAC header, который есть. Это готовый заголовок канального уровня. Когда к нам приходит пакет, который надо промаршрутизировать, мы находим запись в кэше. И мы говорим: в этом пакете есть IP-адреса. Они не меняются по дороге. Если у нас NAT нет, мы сам IP-пакет практически не трогаем. Мы там TTL вычитаем и чек-суммы перебиваем. И это всё, что мы с пакетом делаем. И соответственно на канальном уровне мы это заворачиваем в кадр. Например, в Ethernet. И в Ethernet-кадре мы должны проставить свой собственный MAC-адрес источника и MAC-адрес получателя, к которому идёт этот кадр. Если у нас не Ethernet, а какая-то другая канальная технология, мы должны проставить свой собственный адрес отправителя и адрес получателя, но в том формате, в котором это приемлет конкретный интерфейс. Если у нас, например, Frame Relay, надо DLCI проставить.

Если у нас PPP — там всё просто. Там просто надо отправить кадр, обернуть его каким-то предсказуемым заголовком. И соответственно вот у вас этот готовый канальный заголовок. Вы берёте эти байты, присобачиваете перед IP-пакетом. Вам ещё чек-сумму надо — 4 байта добавить, FCS. И у вас получается готовый кадр. Вот это MAC header. Вот это IP-пакет, который вы маршрутизируете. И вот это соответственно Frame Check Sequence. Вот он, готовый заголовок. Вот это от него — 00... Сейчас сотру, чтобы оно не мешалось. 00000C026BC6. Вот эта часть. Это destination MAC-адрес. 00000C03574D. Это source-адрес. Source MAC. 0800 — это у нас EtherType. Готовый заголовок канального уровня. Приклеиваем к IP-пакету.

Доклеиваем сзади чек-сумму. И у нас получается готовый кадр. Вот эту операцию — взять готовые 14 байт и ещё 4 байта чек-суммы и приклеить к кадру — её можно выполнить за предсказуемое время. Пройти быстро маленький кэш тоже можно за сравнительно предсказуемое время. Она, конечно, будет разная, но тем не менее очень маленькая, потому что запись компактная, и памяти этой тоже немного, и плюс она быстрая. Поэтому можно считать, что, в принципе, любая запись в этом кэше находится за предсказуемое время. И получается, что если у вас маршрут закэширован, вы за предсказуемое время находите интерфейс выхода и канальный адрес. И фактически у вас получается готовый кадр, который вы отправляете в этот интерфейс. Если у вас интерфейс не Ethernet-овский, а, допустим, Frame Relay-овский, у вас точно так же будет канальный уровень, только другой: вы берёте какой-то другой заголовок, Frame Relay-овский, тоже там предсказуемые все поля, предсказуемые заголовки FR, предсказуемый адрес получателя,

предсказуемое всё. Там только DLCI подставлено нужное, и соответственно вы добавляете его к пакету, и добавляете Check Sequence CRC-16, и всё, у вас получается готовый кадр Frame Relay. Эта штука очень и очень ускоряет работу. А главное, она делает обработку пакета предсказуемой по времени. У вас все пакеты, которые используют закэшированную запись, обрабатываются за одинаковое время. Это безумно ценная штука, если у вас есть голос или другие пакеты, которые требуют приоритетную обработку. Да, это очень быстро, и главное — одинаковое время требует. Но соответственно, да, первый пакет всё равно по-честному, ничего с этим не сделаешь. Для того чтобы запись в кэш попала, надо один пакет по-честному посчитать. Cisco на это дело смотрела-смотрела и сказала: «Вы знаете, у нас 2000-й год на дворе, а то даже уже и позже, и, в принципе, эту память под кэш мы можем делать уже достаточно большой. Потому что, в принципе, да, она, конечно, дорогая,

но если у нас есть какие-то серьёзные заказчики, которые готовы занести серьёзные деньги, мы, в принципе, можем сделать кэш такого размера, что в него влезет всё». На тот момент записей в интернете было порядка 100 тысяч. Cisco на это дело посмотрела и сказала: «Ребят, мы вам сделаем кэш на 100 тысяч записей. Насколько вы к этому готовы?» Тут ребята пошуршали денежками, Cisco сказала: «Намёк понят. Мы вам сделаем кэш такой, что в него влезет всё». 100 тысяч записей, ну с запасом — 256 тысяч записей, вам точно хватит. И соответственно размер памяти стал такой, что в него можно поместить всю таблицу маршрутизации. И логика вида «давайте мы сначала промаршрутизируем первый пакет, для того чтобы пополнить кэш» стала неактуальной, потому что, если у вас есть достаточно много памяти, вы можете посчитать next hop для получателя, next hop для какого-то префикса, и интерфейс для конкретного префикса в тот момент, не когда вы первый пакет по нему пропускаете,

а когда вы маршрут в таблицу маршрутизации заносите. И эта штука отличается от предыдущего механизма именно тем, что у вас обработка маршрута выполняется не тогда, когда первый пакет проходит до этого направления, а до того. Вы готовый next hop и готовый интерфейс выхода будете иметь до того, как у вас пройдёт первый пакет. Эта штука изначально называлась Topology Based Switching, и потом её переименовали в CEF — Cisco Express Forwarding. Вы добавляете маршрут в таблицу маршрутизации, вам OSPF притащил новый маршрут, вы говорите: «Окей, CEF, напрягись и посчитай по нему канальный адрес получателя и интерфейс». Пришёл BGP, добавил маршрут, мы сказали: «CEF, напрягись, посчитай и занеси в кэш». Пришёл статический маршрут. Мы сказали: «Окей, мы добавляем статический маршрут в таблицу маршрутизации, CEF, напрягись и посчитай готовый next hop и интерфейс выхода». И эта штука соответственно до сих пор работает.

Она включена по умолчанию на большинстве железок. На всех актуальных железках она используется по умолчанию, на большинстве железок, которые вы можете встретить в продакшене, она включена тоже по умолчанию. Исключения могут составить какие-то очень древние железки с очень древним IOS. Там может быть, её надо включать, но мне такие железки на практике не встречались. Что вы, соответственно, здесь будете иметь? Если у вас есть маршрут, который вы пытаетесь добавить в таблицу маршрутизации, у вас сразу начинают резолвиться все эти рекурсии. У нас есть указание, что добавили мы маршрут 192.168.4.0. Рекурсивный запрос сразу делается, как до него добраться. Через 3.1. Как добраться до 3.1. Через 2.1. Как добраться до 2.1. Через 1.1. И, соответственно, Gigabit интерфейс 0.0. И здесь вы можете сделать два вывода, противоречащих друг другу. Первый вывод. Давайте сразу на каждый маршрут будем иметь готовый канальный адрес.

Но если у вас в таблице записи, например, 700 тысяч, то на каждую запись нам придётся хранить полноценный MAC-заголовок. Например, в случае Ethernet эта штука будет 14 байт. Если у нас 700 тысяч записей умножить на 14 байт, это у нас получается 20 миллионов байт. Я правильно посчитал? Правильно. Вам 20 мегабайт надо хранить только в быстрой памяти, только этих MAC-адресов. А ещё же надо сами IP-шники хранить. Получается, что большую часть места на самом деле будут занимать эти 14-байтные заголовки. И на самом деле в этом нет смысла. Потому что, если у вас есть реальный какой-то роутер, у него нету 700 тысяч различных соседей, до которых надо просчитывать такие заголовки. У него есть 2, 3, 5, 10 разных соседей. Ну 20, ну 50, ну 100.

Но всё равно их ограниченное количество. Этих соседей можно на пальцах пересчитать. В большинстве случаев можно по пальцам одной, двух, трёх рук пересчитать. Не у всех есть 3 руки, но тем не менее, если несколько человек соберутся, они могут для каждого роутера сказать, что у этого роутера 5 соседей, у этого роутера 10 соседей, у этого всего 2. И идея заключается в том, что вы не пересчитываете, не просчитываете готовые заголовки канального уровня по каждому префиксу. Вы говорите, что 192.168.4.0 резолвится в интерфейс Gigabit 0.0, и NextHop IP-шник у него 192.168.1.1. Вы IP-шник сохраняете в таблице, а потом, когда первый пакет идёт с NextHop'ом 192.168.1.1, в тот момент, когда он понадобится, только тогда его MAC-адреса резолвятся. В таблице CEF у вас на каждую сетку, на каждый IP-шник, который будет через CEF резолвиться, будет храниться отдельно интерфейс плюс IP-шник соседа, через который он доступен, IP-шник NextHop'а.

И отдельно для этого NextHop'а через этот интерфейс будет указание, какой канальный адрес, какой канальный заголовок нужно будет использовать. Это заметно сокращает количество места, которое требуется для хранения всего этого дела, потому что вы отдельно храните там десяток-другой соседей с полными канальными заголовками. 10 умножить на 14 байт — это 140 байт. И, соответственно, отдельно храните 700 тысяч записей, каждая по 4 байта IP-шник, 5 байт с маской, ну и ещё номер интерфейса — 6 байт. Получается, намного меньше места требуется в этой самой быстрой памяти. Поскольку Cisco на тот момент очень сильно экономила на всём, она использовала такую концепцию. Отдельно хранятся сами префиксы, посчитаны почти полностью. Найден выходной интерфейс и найден IP-шник NextHop'а. И отдельно для этих IP-шников NextHop'а, которых мало,

их не будет очень много, их будет реально мало, посчитаны уже готовые канальные заголовки. Это и есть Topology-Based Switching. Это и есть тот самый алгоритм, который использует CEF, Cisco Express Forwarding. Эта штука сегодня используется на всех роутерах, как уже сказано, на всех свитчах. Смотрите. Фактически вы при обработке какого-то IP-пакета можете достаточно быстро, за очень небольшое время, найти тот интерфейс, через который пакет должен выйти, и найти новый заголовок канального уровня, который вы должны будете использовать. Поэтому, если вы используете свитчи, вы можете дополнительно их нагрузить этим самым CEF, и они у вас будут весьма быстро форвардить трафик с использованием этого аппаратного ускорителя. Фактически свитчи становится возможно использовать в качестве маршрутизаторов. Поэтому, если вы возьмёте современные какие-нибудь цисковские 2960 или 3750, 3850 свитчи, они все могут выполнять маршрутизацию.

У них у всех встроен CEF. Именно потому, что приходит какой-то кадр, вы дальше решаете, что с этим кадром делать, что вы отправите его на движок коммутации, что вы отправите его на движок аппаратного ускорителя CEF, время одно и то же требуется. И CEF достаточно быстро работает, он не захлебнётся, поэтому производительность CEF фактически равна производительности коммутации на ваших свитчах. На современных роутерах вы можете часто встретить то, что у нас на картинке нарисовано. Тут, как видите, есть анимашка. Я сейчас повторно вам эту анимашку покажу. Пока что расскажу, что на этой анимашке будет изображено. Если у вас есть большой роутер, действительно большой, типа того, который на картинке нарисован, у него, как правило, будет разделена думалка и делалка. Думалка — это то, что на картинке нарисовано RE — Routing Engine. Это та сущность, на которой запускаются процессы маршрутизации,

всякие OSPF, всякие BGP, к которой вы подключаетесь к консольке и админите вашу циску. Это думалка. Соответственно, у неё работают все вещи, которые мы называем Control Plane. Это именно она будет ответственна за пополнение таблицы маршрутизации. На картинке это отдельная вещь, отдельный виртуальный маршрутизатор, который подключён к тому, что называется Line Card. На самом деле эти Line Card подключены к Routing Engine, и в Line Card включаются уже провода. Когда мы видим большую толстую железку, в которой подключаются провода, они включены в интерфейсы, которые принадлежат делалкам, именно модулям, которые обслуживают трафик. Давайте я снова запущу анимашку, и вы посмотрите на неё внимательно. Когда у нас есть Routing Engine, у него есть RIB — Routing Information Base. Это обычная таблица маршрутизации. Соответственно, с помощью каких-то, например, OSPF-ских пакетов мы делаем нечто и пополняем эту таблицу маршрутизации.

Дальше аппаратный ускоритель CEF формирует FIB — Forwarding Information Base. Это пережёванная таблица маршрутизации специально для работы аппаратного ускорителя. Но на Routing Engine никакие пакеты по факту не обрабатываются. Он вообще транзитных пакетов не видит, потому что все пакеты, которые идут через большую толстую железку, они проходят через сами линейные карты. Поэтому копия пережёванной таблицы маршрутизации, которая называется FIB — Forwarding Information Base, она кладётся в память самих линейных карт. Этих линейных карт может быть несколько. Соответственно, у вас одна линейная карта, другая, третья, и на каждой из них будет копия FIB. Есть одна, в кавычках, мастер-копия на думалке и отдельная копия на каждой из линейных карт, на каждой из делалок. И когда у нас трафик проходит через нашу железку, он проходит через линейную карту, он входит в порт линейной карты, обрабатывается по таблице аппаратного ускорителя самой линейной карты, самим движком линейной карты,

самим движком этого модуля, и отправляется в сеть назначения. При этом процессор в обработку этого кадра вообще никак не вмешивается. Он этот кадр не видит. Физически, если вы посмотрите, на самом деле есть отдельный интерфейс, который соединяет думалку и делалку. На Cisco этот интерфейс не очень хорошо виден, но его можно просто физически проследить, когда вы будете смотреть дорожки, раскрывать коммутаторы, маршрутизаторы, видеть дорожки, по которым ток течёт. А на некоторых системах, типа Juniper, у вас прямо отдельный логический интерфейс есть, который соединяет PFE, это Forwarding Engine, и Routing Engine, который думает. Думалка и делалка соединены отдельными логическими интерфейсами. Не Gigabit 0.0, конечно, но они похожим образом называются. И, соответственно, трафик по этому виртуальному интерфейсу не ходит в большинстве случаев. Весь транзитный трафик проходит только через лайн-карты. Думалка к обработке кадров не подключается в большинстве случаев. Для каждого VRF свой RIB, свой FIB.

Физически там память, конечно, одна и та же, но можно считать, что разный. Разный VRF — это разные RIB и FIB. Так, кстати, пока не забыл, по-моему, этого на слайдах у меня не было, но это обязательно надо сказать. Некоторые термины, которые вам понадобятся и в жизни, и на экзамене, и даже в рамках курса, я их периодически употребляю, но, тем не менее, по-моему, я забыл их указать на самих слайдах. Первый термин, который нам понадобится… Так, что ли мелок не рисует? Первый термин — это у нас process switching. Process switching. Это процедура маршрутизации пакета по-честному, когда центральный процессор разберёт пакет и начинает по-честному искать в таблице маршрутизации next hop. Находит его, дальше по-честному начинает искать next hop для next hop, потом next hop для next hop и так далее, пока не найдёт готовый результат.

Естественно, эта штука самая медленная. Второй метод — это fast switching или route caching. По сути, то же самое. Fast switching. Это, соответственно, кэширование маршрутов. Естественно, ускоряет работу по сравнению с process switching, но требует process switching для первого пакета в потоке. Дальше результат кэшируется. Третье — это topology-based switching или CEF. Topology-based switching. Это тот самый CEF, который мы только что с вами разобрали. И четвёртый термин — это distributed CEF. Это как раз тот самый случай, когда база для CEF строится отдельно на физической железке, на routing engine. И, соответственно, результат клонируется на линейные карты. Эта штука называется distributed CEF, потому что по факту думалка сделала базу,

а дальше разложила её на разные делалки, на разные линейные карты. Естественно, что distributed CEF — это наиболее продвинутый вариант из всех, которые здесь есть. Естественно, он самый быстрый. В случае, если вдруг у вас так получится, что CEF, этот самый dCEF, distributed CEF, не сможет дать результат, он посмотрит на какой-то пакет и скажет: я этот пакет не могу обработать, я не могу найти для него выходной интерфейс, потому что там требуется с пакетом что-то сделать, что я сделать не могу. Например, какой-нибудь условно IPsec пошифровать. У нас есть правило, что что-то с ним надо сделать. Тогда этот пакет отправится на routing engine, и routing engine уже с этим пакетом будет работать, скорее всего, process switching. Если вдруг у нас что-то не получается сделать быстро, мы это не выбрасываем, мы это отправляем на routing engine, и оно уже дальше будет работать медленно. Но производительность, во-первых, будет ограничена производительностью центрального процессора на routing engine, а во-вторых, производительность будет естественным образом

также ограничена производительностью этого линка между ними, который хоть и никак не виден как отдельная сущность, но тем не менее он есть, и он по производительности тоже лимитирован. Так, эти все термины будут постоянно встречаться нам, поэтому надо их распознавать и запомнить. На экзамене, возможно, они тоже будут. Так, EVN тоже или я пропустил? Что имеется в виду? EVN к этому не особо отношение имеет. Это вообще был предыдущий модуль. Да, EVN — Easy Virtual Network. В чём отличие 3 от 4? Да, давайте ещё раз расскажу. Отличие 3 от 4 пункта заключается в том, что при topology-based switching, при обычном CEF, у нас и думалка, и делалка — это физически одна и та же железка. Чаще всего в такой ситуации это даже не железка, это какой-то процесс, который запущен на условной циске,

потому что Cisco Express Forwarding намекает на то, что всё-таки там Cisco как-то присутствует. И чаще всего это просто организация быстрой памяти, которая есть на циске, просто там они жонглируют фактически кусками памяти. Какой-то пришёл пакет, мы его сложили в одну память, потом подёргали другую память, переложили в третью и отправили пакет куда-то дальше. В случае с distributed CEF у нас получается, что отдельно роутер построил табличку, отдельно раздал её на линейные карты, и линейные карты уже по тому, что в итоге получилось, отправляют пакеты куда-то дальше. Distributed CEF, которая у нас четвёртым пунктом идёт, считается самой быстрой, потому что там всё реализуется аппаратным образом. Там не Routing Engine будет что-то делать, конструктивно соединённый с портами, с тем, что могло бы символизировать линейную карту, потому что там это действительно физически отдельное устройство, которое это делает аппаратно и независимо от роутера в принципе. Это визуально глазками видно, что это отдельная железка.

В случае с обычным CEF, который в третьем пункте, это глазками не видно. Если вы возьмёте роутер типа, не знаю, 29-й линейки какой-то, простенький, начального уровня, у него нет никакой отдельной железки, на которой было бы видно, что вот CEF работает там. А если вы возьмёте в то же время тот роутер, который на картинке здесь нарисован, ASR, правда, он там не IOS, там другая операционка, но всё равно глазками видно, что есть отдельно модуль думалка, и есть отдельно модули делалки. Они визуально разные. Вы можете взять, вытащить линейную карту, и она форвардить трафик не будет. А можете обратно воткнуть, она начнёт форвардить трафик. Да, distributed CEF — это наиболее дорогой, наиболее быстрый способ. И там CEF прямо по-честному работает. Там отдельная железка реализует форвардинг пакетов. В случае с какими-то роутерами начального уровня, да, там есть CEF, настраивается он теми же самыми командами. Но это, по сути, процесс, который работает на routing engine, на процессоре.

Да, он жонглирует памятью быстро. Да, он достаточно эффективно работает, позволяя форвардить трафик на очень больших скоростях. Но всё-таки это не прямо отдельная железка. Иногда это называется софтовый CEF, software CEF. Это будет равно software CEF. Линейные карты содержат записи только для своих интерфейсов или весь экземпляр таблицы форвардинга? Естественно, они могут каким-то образом оптимизировать то, что они получают. Возможно, routing engine будет присылать им специально пережёванную для них версию FIB, чтобы они лишнее не получали. Но если они будут получать целиком всё, для них это особо разницы не сделает. Разница будет в том случае, если у вас этих линейных карт будет несколько.

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

Одна таблица, в которой лежат пережёванные маршруты, и вторая таблица, в которой лежат пережёванные соседи. Соседи пополняются по мере необходимости, а маршруты пополняются по мере заполнения RIB. RIB – это show ip route, а FIB – это show ip cef. Это готовые записи для того, чтобы складывать их в линейные карты. А линейные карты по ним же будут быстро маршрутизировать пакеты. Show ip cef будет иметь записи для каждого маршрута в таблице маршрутизации. Причём есть обязательно запись 0.0.0.0 по нулевой маске. Даже если дефолтного маршрута у вас нету, запись такая всё равно будет. Логика заключается в том, что если у вас есть какой-то пакет, который пришёл на вашу железку, вы с ним что-то должны обязательно сделать. И если абстрактная Cisco с абстрактным process switching может посмотреть, сказать, у меня есть выходной интерфейс для этого пакета, мы его нашли, или нет выходного интерфейса, потому что маршрута такого нету.

Логика самого процессора может быть достаточно гибкая. То CEF, именно физический аппаратный distributed CEF, он умеет делать только одну вещь. Он умеет только посмотреть по таблице и найти выходной интерфейс. Точнее, найти выходное действие, найти соседа, к которому отправляется трафик. В случае, если у нас есть дефолтный маршрут, он будет как обычный маршрут работать. А в случае, если у нас дефолтного маршрута нету, пакет, который не попал ни под одну запись, надо будет дропнуть. Фактически, даже если у вас дефолтного маршрута нету, есть запись про 0.0.0.0/0, что надо этот пакет дропнуть. Для аппаратного ускорителя не бывает ситуации, что вообще никакой маршрут не найден. Как минимум, 0.0.0.0/0 либо будет в таблице, потому что он есть, и он говорит: всё, что не попало явно под все остальные маршруты, мы выбрасываем, либо в таблице маршрутизации будет настоящий 0.0.0.0/0, который пережуётся, и здесь на next hop будет какой-нибудь сосед.

Дальше. 0.0.0.0/8 дропается в явном виде. Это зарезервированный диапазон IANA, и пакеты, приходящие для форвардинга в эту сеть, они заведомо нелегитимны. Поэтому трафик до сети 0.0.0.0/8 сбрасывается. В то же время пакеты, которые приходят на адрес 0.0.0.0 в точности, именно 0.0.0.0, эти пакеты легитимны. Это значит, что мы сами отправили такой пакет, и у нас нет адреса. Мы, например, хотим его получить по DHCP. В этом случае мы как раз отправляем пакеты с адреса 0.0.0.0. И в такой ситуации мы говорим, это нормальный адрес, его мы ресивим. У нас получается 0.0.0.0/32 хороший, 0.0.0.0/8 заведомо плохой, а 0.0.0.0/0 — это дефолтный маршрут, он может быть либо no route, либо, если у нас есть маршрут в таблице маршрутизации, указывать на какого-то конкретного соседа. Это служебные записи, они добавляются автоматически,

мы к ним отношения особо никакого не имеем. Равным образом мы не имеем отношения к этим записям. Это 224.0.0.0/4, который дропается, это мультикаст, класс D. Из них 224.0.0.0/24 ресивится, это значит, что трафик, который приходит именно на 224.0.0.0 по /24 маске, его надо отправить на process switching, то есть обработать, потому что этот трафик адресован именно нам. Разгадка здесь простая. Это мультикаст, который локальный в сети, сюда, например, всякий OSPF будет относиться, EIGRP и прочее. Аппаратный ускоритель ничего про них не знает. Он говорит: если приходит какой-то абстрактный мультикаст, и у меня нет его обработчика, то его надо выкинуть. А если приходит такой мультикаст, который гипотетически может быть процессору интересен, то надо его в процессор отправить. И пусть уже он разбирается, интересно ему это или нет. Сам аппаратный ускоритель этого не может делать. Поэтому у нас есть указание, что если приходит мультикаст,

который может быть интересным, мы его отправляем на процессор. Пусть он разбирается. Receive — это как раз мы дёргаем процессор, мы говорим: привет, процессор, у нас тут транзитный кадр прошёл, но похоже он тебе тоже будет интересен. Receive означает, что мы его дальше не форвардим. Мы его направляем сразу на процессор, и всё. 240.0.0.0/4 дропается, это диапазон класса E, он зарезервирован, но из него есть отдельный IP-шник 255.255.255.255/32, это, как вы понимаете, бродкаст. Если трафик приходит бродкастовый, он потенциально нашему процессору тоже может быть интересен, поэтому он тоже ресивится. И дальше не форвардится. Так же, как и мультикаст. Это записи по умолчанию, даже если вы абсолютно пустую железку возьмёте в руки, у неё такие записи будут. Ещё одна штучка — 127.0.0.0/8. Если вы видите IP-пакет, который проходит через вашу линейную карту, и в качестве адреса назначения у него стоит 127.что-то-там, это заведомо какая-то лажа.

Такое быть не может. Поэтому такие пакеты фильтруются, дропаются и никаким образом не обрабатываются. Так, давайте я то, что служебное, выкину. Раз, два и три. Всё остальное здесь появляется из-за того, что мы чего-то настраивали. Здесь есть записи 1.1.1.1/32, 2.2.2.2/32. И здесь куча всяких 192.168.1.что-то-там. Давайте с ними разбираться, откуда они взялись и что они означают. Напротив каждой из этих записей стоит что-то в поле next. Для 1.1.1.1/32 стоит next hop 192.168.1.2 через интерфейс VLAN 1. Мы можем догадаться, что это на свиче дело происходит. В такой ситуации понятно, что трафик до 1.1.1.1, именно до такого IP-шника, мы направляем через соседа 192.168.1.2.

В отличие от таблицы маршрутизации, здесь next hop будет именно обязательно connected. Не может быть такого, что здесь показывается IP-шник, который не в одной сети с нами. Это именно next hop, который рядышком, adjacent. 2.2.2.2/32 показывается attached. Это значит, что трафик, который идёт именно на 2.2.2.2/32, это наш собственный пакет, адресованный именно нам. Значит, attached — это наш собственный IP-шник. Если мы видим такой пакет, который идёт на 2.2.2.2, он не просто нам потенциально интересен, и его надо ресивнуть, а он прямо нам точно интересен, это наш собственный IP-шник, мы его принимаем как свой собственный, как родной. Но конкретно в этом случае он attached на Null0, и мы его сбросим в итоге. Мы его примем как будто через интерфейс Null0, и там его ждёт незавидная судьба. Что касается IP-шников, которые действительно нам принадлежат.

Например, 192.168.1.0/24 — это сеть, в которой у нас есть живой IP-шник. И 192.168.1.1 — это наш IP-шник, мы его ресивим. Если приходят пакеты на адрес 192.168.1.0 или .255, это пакеты, идущие бродкастом. Традиционный бродкаст .255, то есть адрес хоста состоит из всех единиц. Но тем не менее адрес, состоящий из всех нулей в host ID, тоже будет считаться бродкастом. На старых-старых роутерах, напомню, что на старых сетях, ещё до введения бесклассовой маршрутизации, это считался именно адресом бродкаста. Потом уже только придумали для бродкаста использовать отдельный IP-шник. А до этого адрес самой сети считался бродкастом. CEF не знает, в какой логике будут отправляться пакеты, поэтому он на всякий случай говорит: ресивим.

Мы знаем, как обрабатываются такие пакеты, поэтому потенциально они могут быть нам интересны. Ресивим это, ресивим наш собственный IP-шник, ресивим бродкаст. Там пусть центральный процессор разбирается, что ему интересно, что нет. А 192.168.1.0 у нас стоит attached. И 192.168.1.2 attached. Давайте разбираться, откуда они тут взялись. Attached — это значит, что у нас есть интерфейс. Наш роутер, или в нашем случае свитч, неважно. У него есть интерфейс, на этом интерфейсе висит IP-шник 192.168.1.1/24. И вся сетка 192.168.1.0 где-то здесь расположена. Среди них есть 192.168.1.2. И мы подсказываем, что если мы хотим отправлять трафик в сторону 192.168.1.2, то именно на этом интерфейсе, VLAN 1, его можно достать.

Почему 2.2.2.2/32 дропается? Потому что он в интерфейсе Null0. Он доступен через интерфейс Null0. Воображаемый интерфейс Null0. И всё, что через него приходит или уходит, оно всё дропается. Как он туда попал? Например, мы добавили такой маршрут. ip route 2.2.2.2 255.255.255.255 Null0. Если мы такое сделаем, то весь трафик в сторону 2.2.2.2 будет дропаться. Null0 — это такой воображаемый интерфейс, аналог /dev/null. Если что-нибудь отправить в Linux в /dev/null, оно всё убьётся.

Как будто в никуда уйдёт. То же самое здесь. Null0 — интерфейс. Это такой интерфейс, что если в него что-то отправить, оно бесконечно быстро удалится. Типа чёрной дыры. Поэтому если мы говорим, что сетка 2.2.2.2/32 будет доступна через Null0, на самом деле мы говорим тем самым: отправляйте пакеты туда, отправляйте физически ни по какому интерфейсу, и они никуда не уйдут. Как раз для blackholing такого используется, когда нам нужно сделать так, чтобы пакеты до определённой сети никуда не уходили. Через таблицу маршрутизации можно сказать: отправляем их туда, и они там навечно останутся. И 2.2.2.2 мы таким образом говорим, что он доступен через воображаемый интерфейс чёрной дыры, а эти интерфейсы attached — они уже будут нормальные. Мы говорим, что вся сетка .1.0 будет доступна через интерфейс VLAN 1. И .1.2 — это IP-шник внутри этой сети. Мы знаем про его существование. Мы говорим: он тоже доступен через VLAN 1.

В чём разница между этим attached и этим attached? 192.168.1.0/24 — она attached, и она состоит из множества отдельных IP-шников. Когда мы говорим, что все IP-шники в этой сети будут attached, мы говорим, и 192.168.1.2 в том числе будет attached в этой сети. Но на 192.168.1.2/32 мы можем сделать adjacency. Мы можем сказать: это не просто пачка хостов, до которых мы знаем, как добраться. Это один единственный хост, он по /32 маске. И именно до него мы можем сделать next hop в таблице next hop-ов. Поэтому, когда у нас есть маршрут 1.1.1.1/32, доступный через 192.168.1.2, 192.168.1.2 у нас attached, и у нас получается такой next hop есть. Если трафик идёт до 1.1.1.1, мы знаем, как до него добраться. Если трафик идёт до 192.168.1.2, мы тоже знаем, как до него добраться. Фактически это attached можно было бы заменить

как то, что у нас есть next hop 192.168.1.2. Так. Здесь, в этом списке, могут появляться самые разные слова. Понятное дело, drop, no route. С ним всё очевидно. Attached означает, что у вас есть интерфейс, который смотрит на этого соседа. Receive означает, что трафик вы принимаете, как адресованный именно вам, направляете его на процессор, и он дальше уже будет разбираться, действительно ли этот трафик интересный или нет. Аппаратный ускоритель не умеет решать, интересный этот трафик или нет. Он лишь говорит, что пакеты, которые идут на такие адреса, они потенциально могут быть интересными. Дальше. Что там ещё бывает? Бывает такое, что мы направляем трафик на next hop, указывается IP-шник next hop,

и у каждого next hop будет указано, что за тип этого самого next hop будет. Сейчас разберёмся, что это означает. Единственное, почему-то не хватает таблички. Давайте я буду показывать тогда на живой Cisco. Enable, show ip route. У нас есть некая таблица маршрутизации. 10.0.0.0/24 — connected сетка, и в ней есть IP-шник, который наш собственный — 10.0.0.1. Я думаю, даже может быть не на этом роутере, а на другом. Там будет поинтереснее табличка. Enable, show ip route. Это наш роутер со Славой.

Здесь у нас есть несколько интерфейсов. На них у нас есть IP-шники. У нас есть интерфейс Dialer 1. Соответственно, там есть IP-шник 172.16.0.116. Причём, обратите внимание, он с /32 маской. То есть это без какой-то connected сети фактически. У нас есть connected IP-шник 172.16.0.1. Это не наш собственный IP-шник. Мы про него знаем, как до него добраться через интерфейс Dialer. И у нас есть свой собственный IP-шник 192.168.0.15 сети 192.168.0.0/24. Кроме того, этот интерфейс доступен через GRE-туннель. И давайте разбираться, как у нас в этой ситуации себя будет вести CEF. Show ip cef показывает, какие маршруты нам будут известны. Так, я что-то не понял.

Где здесь 101.101.101.101? Ну ладно, не страшно. У нас вот такая штука есть. У нас статический маршрут 0.0.0.0/0 через Dialer 1. Это маршрут по умолчанию. Через него будет как раз доступен 101.101.101.101. Вот так выглядит CEF-таблица. Здесь мы видим те записи, которые служебные. Это, во-первых, запись, что 0.0.0.0/8 дропается. Трафик транзитный не может никогда начинаться на 0, за тем исключением, что это IP-шник 0.0.0.0, который потенциально может быть наш. Например, в случае с DHCP мы запросы отправляем. Мы отправляем как раз из-под адреса 0.0.0.0. И кто-нибудь нам, возможно, захочет вернуть пакеты на этот адрес. Кроме того, мультикаст. В принципе, обычный мультикаст мы дропаем,

но локальный мультикаст мы гипотетически можем быть в нём заинтересованы. Поэтому его мы направляем на процессор. 240.0.0.0/4 — это класс E. Мы его дропаем безусловно. За одним исключением — если это бродкаст. И, наконец, есть дефолтный маршрут, доступный через соседа 172.16.0.1. И есть дроп loopback-ов, которые служебные адреса. Они не могут никогда появляться в качестве адресов источника или получателя в транзитных пакетах, поэтому они тоже дропаются. Дальше у нас есть эти два адреса. 172.16.0.1 и 172.16.0.116. Если пакет идёт на адрес 172.16.0.116, это наш собственный IP-шник, мы его направляем на процессор. Если трафик приходит на нашем роутере в сторону 172.16.0.1/32,

мы знаем, как до него добраться. Надо отправить этот пакет напрямую в Dialer 1. Там он будет attached, там он будет с нами в одном интерфейсе. Та же самая история с этой сеткой. 192.168.0.0/24. Этот IP-шник. IP-шник самой сети. 192.168.0.0. Любой хост в этой сети будет оттачат на туннеле. В частности, оттачатым на туннеле будет вот этот вот. 192.16.0.1 по 32-й маске. Давайте я сейчас попробую попингать другие узлы, которые в нашем туннеле будут жить. 162.168.0.102. 102.103.4. Найти, кто живой. Whorenched... 117.0.1 Earth...

119.0.1... Кто-нибудь, отзовитесь. Есть ли вариант, при котором мы MultiCast не дропаем и кидаем дальше? Есть. но до этого надо мультикаст поднимать маршрутизацию мультикаста так все живые черпи и вот я туплю я 100 100 100 пишнике меня достать на 100 168 0 номер комплекта перебирать да я бы долго перебирал 01 1 комплект 2 работает прекрасно шва 5cf столько пытался сделать всякого ненужного что на самом деле до потерял шоу айпи cf вот и соответственно вот в этой вот сетки 192 168 0 чего-то там у меня

показывается куча всякого барахла значит барахло что любые айпишники в сети 100 на 2 168 00 по 24 маски доступны напрямую в интерфейсе туннель 0 нам нужно каким-то образом узнать канальный адрес соседа и можно отправлять трафик туда если пакет идет именно на 100 на 2 168 00 то это считается потенциально возможным старым брат кастом и поэтому мы такой пакет принимаем сами если пакет идет на 100 на 2 168 0 255 это уже настоящий брат каста и мы потенциально понимаем что пакет нам тоже может быть интересен мы его дальше не фарварде мы его принимаем сами все остальное вот здесь вот у нас это айпишники узлов в этой сети 100 на 2 168 0 15 наш собственный айпишник и мы его принимаем все остальное это узлы которые действительно доступны через туннель 0 интерфейс и по ним может быть создана аджасинцы то есть это не строчка вот это вот 100 из 2 168 00 с 24 который говорит что это оттачат все через интерфейс 100 что там любой узел

будет доступен через этот туннельный интерфейс а здесь мы уже говорим что да точно вот именно этот узел доступен через интерфейс мы проверили если вдруг мы захотели отправить трафик по вот эту маршруту мы убедились что это оттачат маршрут мы говорим окей мы сейчас будем пытаться резолвить next hop в этом маршруте и дальше запускаем что-то там что у нас будет работать в качестве резолва рп и на черпи что угодно и заносим запись таблицу что да вот мы попытались по пингтитам вот этот вот айпишник и запись в аппаратный ускоритель сразу занесли что таким next hop возможно придется пользоваться вот соответственно мы 101 айпишник использовали потому что до него шел трафик вот эти вот записи по факту до них трафик вот эти вот записи по ним никогда трафик не шел я их пытался пингать это означает что я пытался за резолвить этого соседа аппаратный ускоритель не может знать получится у меня это или нет поэтому он запись для этих соседей создал что они потенциально вот могут быть они по

факту никуда не резолваться то есть если мы сейчас посмотрим покажи нам информацию по соседу там 112 168 0103 циска скажет от такого нету соседа он в неопределенном состоянии висит но по некоторым соседям такая информация у нас будет например вот 112 168 02 он тоже доступен через интерфейс но у нас по крайней мере для него будет уже аджесенсе давайте попробуем посмотреть на каком живого соседа у джессенсе это вот те соседи которые по факту есть с которыми у нас получилось установить канальный адрес и по которым у нас есть готовый канальный заголовок то есть несмотря на то что у нас показывается что что 2 168 0103 листом 102 такие адреса а тачат мы попытались при оттачатся к ним попытались установить какой надо канальный заголовок сделать чтобы отправить трафик в них и у нас ничего не получилось таких адресов нет поэтому в таблице аппаратного ускорителя записи есть аджесенсе соответственно соответствующего нету потому что ну не откуда его взять а вот эти вот аджесенсе они по факту есть мы попытались отправить пакеты на студенту

168 11 на 168 02 03 09 у нас получилось и готовые записи в качестве таблицы соседей в качестве таблицы на к стопов у нас уже присутствует мы можем посмотреть детально рассказ про каждого из этого из этих соседей там не очевидная команда будет show аджесенсе интернал кажется эти про конкретного show аджесенсе 100 минус 2 168 0 11 интернов вот и здесь показывается что мы знаем про этого соседа знаем его и пишник знаем интерфейс через который он будет доступен интерфейс у нас будет дайлер один вот он дальше

нет потом интерфейс туннель 0 а он уже доступен через дайлер один что означает 7 после айпи адреса сейчас я пытаюсь вспомнить что это означает не помню знал но забыл гипотеза что это номер интерфейс но либо номер интерфейс либо размер памяти который требует аджесенсе но лучше посмотреть в деталях я просто не помню извините так вот здесь вот по аджесенсе для соседа 100 и 902 168 0 9 показывает кучу всякого интересного если читать это все по порядку то показывается айпишник у нас известен показывается вот это вот штучка и вот эта вот штучка на самом деле очень интересная приглядитесь к ней

это готовый заголовок который надо представить к пакету идущему в сторону 122 168 09 чтобы она по факту дошло до 122 168 09 зачем cf добавляет запись если аджесенсе не установлена затем что она не знает она может быть установлена чуть позже и соответственно чтобы как бы заранее подготовиться к тому что аджесенсе через некоторое время будет запись по факту добавляется то есть ну просто и она так себя ведет инженером было удобнее так если вы подумаете на самом деле мне кажется вполне логичным то есть мне кажется вполне логичным что мы добавляем запись который не ведет никуда чтобы трафик который идет в сторону этого next hop а до тех пор пока мы соответствующие аджесенсе не создадим чтобы было сразу понятно что его надо дропать ну то есть вот как раз ситуация с потерей первого пинга когда у нас первый пинк теряется первый реквест пинга как раз та самая ситуация когда

соответствующий аджесенсе нету но с пакетом что-то надо сделать и вот мы указываем что сосед как бы вроде бы должен быть в интерфейсе но по факту его там нету поэтому его дропаем да вот вернемся все-таки к нашим кабанам я призываю вас обратить внимание вот на эту штуку это может показаться какой-то нечитаемый обрядятелен на самом деле вот эта вот штука это просто ip заголовок вот эта четверка это поле версии версия протокола и пиви 4 вот это вот пятерка это размер машинного заголовка в машинных словах то есть 5 машинных слов 20 байт занимает айпи заголовок вот это вот штука это размер поле это размер суммарной айпи пакета который у нас будет поле total лент мы его заранее а пардон пардон и 10 и 10 и 1 байт который опять же надо будет проставить ведь мы его заранее не знаем но он 1 байтовое поле которое можно может зависеть уже от содержимого пакета

мы его пока поставляем нулями вот эти вот два байт это поле total length мы не знаем заранее какой размер пакета будет поэтому мы говорим что для того чтобы получить айпи пакет который пойдет по грешному заголовку нам нужно сначала соорудить пакет а потом проставить в этом заголовке поле total length ну в зависимости от самого пакета когда мы шаблон вот этого заголовка делаем и заранее размер пакета уже конечно не знаем дальше вот эти вот четыре байта они указывают на поле с фрагментацией это у нас identification fragment offset и флаги опять же заранее мы ничего не фрагментируем поэтому просто забиваем нулями фф это ттл 2ф чё внутри лежит банальный 47 число 2ф это дважды по 16 32 плюс еще 15 как раз 47 6 2d 5 чек сумма чек сумма считается автоматически мы заранее и ничего с ней не делаем но вот это вот как бы поле под нее

есть она забита какими-то цифрами которые в предположении что у вас заголовок будет именно такой дадут корректный результат но в принципе когда вы будете именно для конкретного пакета заголовок приделывать у вас как минимум чек сумма будет меняться потому что тотал лент измерится вот эта вот штука от c 1000074 знать чуть такое это айпи получает источника то есть отце это у нас 172 10 16 16 ричные это 16 десятичные 00 это 00 и 74 это я здорово подозреваю что это 115 или 116 какой метам айпи шник мой собственный то есть вот это вот это мой собственный айпи шник источника вот это вот отце 10065 это айпи шник получателя зуб даю что это стоит 172 16 0101 дальше

00000000 00800 это заголовок горе то есть в заголовке горе мы не требуем ничего лишнего у нас 4 байтовый заголовок в котором лежит только указание чем внутри лежит 0800 это тип ipv4 то есть мы в конкретно этот пакет вкладываем ipv4 вложение у нас вот эти вот 24 байта как раз и означает что для того чтобы получить готовые пи пакет который отправляется по горышному туннелю нам нужно добавить вот это вот ну еще чек сумму посчитать плюс сразу же цев говорит а это в свою очередь пойдет через дайлер один а вот этот вот дайлер один соответственно будет свои заголовки иметь и для того чтобы это все в дайлер один упаковалась нужно будет добавить еще один заголовок и заголовок этот будет пипипишный где у нас пипипишный заголовок так не вижу не вижу не вижу не вижу не вижу

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

03 b 5 00 это мой мак адрес когда я оборачиваю кадр заголовка я в эти шесть байт складываю соответственно свой собственный мак адрес 88 64 это из арта и пч внутри лежит и вот все вот это вот это заголовок ппп я я отсюда узнаю вот честно говоря только вот это 00 21 что внутри лежит это внутри лежит айпи в 4 когда вы отправляете какой-то пакет внутрь грешного туннеля вот у вас next hop он будет стоять туннель 0 и там айпишник например стоимость два 168 09 вы берете вот это вот дальше у вас стоит а потом еще добавь заголовок который отправляется при дайлер один вы идете шоу аджа снаси дайлер один берете вот этот вот заголовок и отправляйте пакет сразу дайлер один то есть вам не надо повторно выполнять маршрутизацию типа угадывать а куда отправиться готовый пакет который сформировался после того как мы в горе все завернули

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

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

пакеты но для этого потребуется помощь центрального процессора cf сам не справится поэтому если у нас говорят там что вот эта вот запись там 1111 доступно через васю авось имеет тип пункт то мы отправляем этого васю на процессор пусть процессор разбирается это не совсем receive это вот именно что транзитный трафик который аппаратным ускорителем обработаться не может пусть центральный процессор получит этот кадр на анализ и уже сам разбирается запись для соседства у которого нету заголовка l2 вот тот самый как раз пример с и пиш никами которые которые я пытался пингать они как бы в таблице show ipcf есть в сабличке соседи их нету вот эти записи называются глин записями вот они такие не настоящие неполноценные они нужны просто для того чтобы несколько раз подряд не пытаться оформлять запросы на resolve mac адреса если

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

что мы там имея в качестве next hop а складываем в пережеванную фиб и дальше в таблицу соседей в таблицу аджесенсе указываем соответственно когда мы отправляем трафик через определенный интерфейс до определенного айпишника какой канальный заголовок мы будем ставить это у нас две таблички на самом деле есть еще одна табличка промежуточная который указывает как связаны между собой префиксы в цехе и вот эти вот самые аджесенсе фишка в том что у вас определенная запись в таблице маршрутизации может резолваться чем не резолвится может указывать на два разных next hop а вот как на примере show ip ip road у нас показывает что 192 168 00 по 24 маски по и джерп изучена и она смотрит на двух разных соседей причем они могут быть с разной метрикой в случае с югерпи у нас есть сетка 192 168 доступны через один первого соседа и через два первого у одного метрика 128 тысяч 266 другого 26512 то есть эта метрика как в

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

Хорошо, когда метрики вот такие вот красивые, как у нас Они ровно один к двум, вот прям как образцово показать, налажатся Но иногда бывает так, что метрики все-таки не совсем такие красивые И они могут быть кривыми Ну то есть, там, не знаю, одна метрика будет, например, 17, а другая будет 49 И вот пытаться распределить трафик в соотношении 17 к 49 может быть довольно проблематично ЦИСКО постарается максимально близкое распределение сделать Но она все-таки не будет именно 17 к 49, конечно же, делать Она будет все-таки ограничена в своих возможностях И по факту распределение будет какое-то другое, хоть и достаточно близкое к такой дроби Физически то, что у нас какой-то маршрут будет указывать на два разных NextHop Будет заключаться в следующем Бережеванные маршруты Это у нас IPCF Тот самый FIB, который содержит пережеванные маршруты Будут указывать не напрямую на NextHop

А на некоторые бакеты И, соответственно, эти бакеты уже будут указывать на NextHop Где это у нас есть? Это show IPCF Дальше вот указываем, что нас интересует какая-то сетка Internal Да Вывод в цехе будет следующий У нас показывается, что эта сетка 112-168-00 по 24-й маске Доступна через два соседа Через два NextHop Через NextHop 192-168-11 гигабит 00 И через 192-168-21 гигабит 01 То есть пока все честно Пока все предсказуемо Но есть нюанс Мы хотим распределить трафик в разных пропорциях Вот мы хотим сделать так, чтобы трафик до одного соседа был как побольше А до другого соседа поменьше То есть трафик share вот здесь вот указывается неспроста И мы хотим на самом деле указать, что нас интересует Как это сказать?

Нас интересует распределение трафика в неравных пропорциях Если бы пропорции были равны, можно просто было сказать Часть туда, часть сюда, все Но вот эта вот неравная пропорция, она добавляет дополнительную логику Логика заключается в следующем Когда у нас есть записи в кэше IPCF Ну в FIB Они могут указывать на нескольких разных соседей И максимальное количество соседей, которые мы можем указать Это 16 штук То есть вот у него будет 16 таких шнурков, которые могут указывать на разных соседей Если мы будем хотеть распределить между 16 соседями трафик одновременно и одинаково в одинаковых пропорциях То мы, конечно же, можем это сделать, просто указав, что у нас здесь сосед 1, здесь сосед 2, здесь сосед 3, здесь сосед 4, здесь сосед 5 и так далее вплоть до 16 Но если мы хотим распределять трафик между, допустим, меньшим количеством соседей, между тремя соседями То мы оставим только 3 шнурка задействованных, 3 вот этих бакета

А оставшиеся будут не задействованы Но трафик в этом случае будет балансироваться между тремя соседями Часть 1, часть 2, часть 3 Оставшиеся просто пустые и не задействованы Так вот, фишка заключается в том, что если мы хотим распределить трафик в пропорции между несколькими соседями Например, в пропорции 2 к 1 Мы можем сказать, что вот эти бакеты могут указывать на одних и тех же соседей То есть один бакет смотрит на одного соседа, а два других бакета смотрят на другого соседа, на одного и того же И получается в этом случае, что мы пакеты распределяем между тремя шнурками Но только два шнурка смотрят на одного и того же NextHop И получится, что вот этот NextHop 2, он получит в 2 раза больше трафика, чем NextHop 1 И получится распределение трафика 2 к 1 Что касается ограничений CFA Шнурков вот этих всего 16 штук Если мы делаем распределение в равных пропорциях

То мы можем все 16 штук задействовать, тем самым сделать 16 разных соседей Если мы хотим обеспечить неравномерную загрузку, не одинаковую на разных соседей То мы все равно ограничены этими самыми 16 штуками Поэтому мы можем сделать, допустим, 3 на 1, 5 на другого Или там 4 на 1, 5 на 3, 6 на... 4 на 1, 5 на другого, 6 на 3 Но мы не можем превозойти общее количество вот этих самых шнурков 16 Поэтому пропорции, которые мы можем соорудить в результате Они все равно будут ограничены тем, что бакетов у нас всего 16 Если нам нужно сделать пропорцию 17 к 49 Потому что EJRP нам притащил какие-то метрики У одного маршрута метрика 1700, а у другого 4900 Да, метрики относятся как 17 к 49 Дальше эту дробь уже не сократить В этом случае мы, конечно же, не сможем сказать Давайте 17 бакетов отправим на одного, 49 на другого

У нас всего бакетов 16 штук, всего 16 бакетов Поэтому нам надо будет подобрать такую пропорцию Которая даст нам максимально близкое значение к 17 к 49 Но при этом общее количество этих бакетов не будет превышать 16 Я думаю, что это приблизительно плюс-минус совпадает с 16 к 48 Приблизительно это у нас одна треть Поэтому я думаю, что если циске действительно такие маршруты предъявить Она сделает пропорцию 3 к 1 Она 3 бакета отдаст одному соседу И один бакет отдаст другому И пропорция по факту будет на самом деле 1 к 3 А не 17 к 49 Эта логика позволяет балансировать трафик Между разными соседями В том числе и между соседями, которые надо загрузить не одинаково В любом случае мы это сделать можем Но мы не можем бесконечно гранулярно это делать Мы все равно ограничены этими самыми бакетами

Для IPv4, для старых платформ всего на каждый префикс у нас 16 бакетов, 16 шнурков Для IPv6 — 32 шнурка А, пардон, 64 Для новых платформ, для IPv4 на самом деле будет 32 шнурка На экзамене про это говорить не надо Но да, по факту оно так и есть Если мы сейчас посмотрим на Cisco Хоть нарисованы, но тем не менее Show, IPv6 Какой-нибудь маршрут мне бы взять Какой-нибудь живой бы маршрутик Допустим, вот этот Internal 0,2 Чего мне не хватает Detail Нет, по-моему там Internal как раз

Потому что в Enable нужно перейти Enable О, да Internal показывается только в привилегированном режиме И здесь как раз показываются те самые бакеты У нас задействован только один бакет Который смотрит на интерфейс Tunnel 0 И соответственно балансировка здесь всего между одним бакетом будет осуществляться Как бы нам сделать так, чтобы у нас появилось два разных бакета Config IP route Давайте сделаем что-нибудь такое 192.168.0.2 И рядом 192.168.0.3

Давайте я разверну на весь экран, а то оно плохо показывается И здесь видно два бакета Один бакет смотрит на соседа 192.168.0.2 И другой бакет смотрит на соседа 192.168.0.3 Для каждого бакета показывается Next Hop на самом деле Нам говорят, что для этого IP-адреса 192.168.0.2 У нас есть для него adjacency И он доступен через Dialer 1 Мы можем взять и найти adjacency 192.168.0.2 И у нас получится готовый адрес Готовый пакет, который мы можем отправить сразу С помощью аппаратного ускорителя в нужный интерфейс Здесь не показывается, какой именно этот интерфейс будет Но это можно сделать за очень небольшое время В нашем случае мы будем балансировать трафик Часть трафика направим сюда, часть трафика направим сюда Физически они конечно же идут через один и тот же интерфейс Но тем не менее мы будем это расценивать как балансировку По умолчанию

Циска балансирует трафик по назначению Она говорит, что пакеты, которые мы будем отправлять по разным бакетам Они всегда будут идти на один и тот же IP-адрес Пакеты, идущие на один и тот же адрес, они всегда будут идти по одному и тому же бакету По одному и тому же Next Hop Здесь у нас сетка, которую я смотрю, она /32 по маске Поэтому на самом деле трафик балансироваться здесь не будет Но если бы я сделал /24 по маске То четные IP-адреса шли бы через один, нечетные через другой IP-адреса назначения Это сделано умышленно, специально для того, чтобы трафик одного и того же потока не балансировался между разными Next Hop Вы если захотите, можете переключить в балансировку по отдельным пакетам CEF можно переключить Это не EtherChannel Здесь можно сказать, что дорогая циска, я хочу трафик направлять до одного и того же IP-адреса по разным интерфейсам

И это может привести к разрушительным последствиям К тому что у вас голос начнет заикаться и все остальное Поэтому так делать не надо Хотя это физически сделать можно Interface Config Interface Tunnel 0 IP CEF, по-моему, да, CEF IP Route-cache может быть, policy Не помню

В общем можно включить per-packet балансировку И тогда пакеты, которые у вас будут выходить через определенный маршрут То есть будут идти по определенной записи в кэше CEF Они будут идти через разные Next Hop Даже если они будут идти на один и тот же IP-адрес Я вам это делать не рекомендую Если вдруг вам кто-то скажет, что надо включить per-packet балансировку Бейте его по лицу, это плохая идея IP load sharing Вот да Вот здесь IP load sharing per-packet Если ее включить, то трафик у вас будет идти до одних и тех же IP-адресов Трафик одного и того же потока, вероятно тоже Он будет идти одновременно по нескольким Next Hop И как следствие, может быть reordering Может быть такое, что трафик пойдет разными трассами за разное время У вас будет джиттер прыгать, у вас будет латенси прыгать Ничего хорошего в этом нет, не надо так делать

До тех пор, пока вы точно абсолютно не уверены, что это будет хорошая идея В целом это плохая идея Поэтому load sharing по-пакетную включать не надо Но мы сейчас это сделаем, я сделаю это, вы не делаете Per-packet Просто чтобы показать Раньше у нас здесь было написано per-destination балансировка А сейчас у нас будет здесь тоже Per-destination, а сейчас у нас на ту же самую штуку будет идти per-packet балансировка Вот она И трафик у нас может пойти разными трассами за разное время Зачем сделали? Просто для того, чтобы показать, что трафик одного и того же потока может распределяться между разными Next Hop Я иногда вам говорю, что мы можем включить балансировку и у нас будет задействовано одновременно несколько аплинков Рассказываю просто про то, что есть разные особенности у этого процесса По умолчанию, если вы будете

Кого-то пингать Например У вас IP-шник получателя Всегда будет один и тот же И даже если вы имеете Два разных Next-hop Вы всегда будете видеть Что пакеты у вас Идут по одному И тому же интерфейсу Если вы Не включаете Per-packet Балансировку У вас используется Per-destination Балансировка Трафик никогда не пойдет По разным интерфейсам Но если вы включите Per-packet Балансировку Трафик по факту Будет балансироваться Даже пингов Так Да Сейчас Последний уже Буквально слайд Общие слова И после этого Сделаем маленькую Лабораторную работку ЦЭФ Может вам Значительно Ускорить работу То есть Если вы Выключаете Зачем-то ЦЭФ То вы тем самым Снижаете Производительность Своего устройства ЦИСК Очень сильно В подавляющем Большинстве случаев ЦЭФ Выключать не надо На многих платформах Вы его выключить Просто даже не можете Во многих случаях ЦЭФ Автоматически

Будет Ну как бы В кавычках Выключаться То есть Если он увидит Какой-то пакет Который он не может Обработать Он его автоматически Посылает на Процессор И дальше Процессор Уже с ним справляется Эта штука Называется Пунтинг То есть Если вы Получаете Какой-то пакет Который ЦЭФ Не может обработать Он все равно Этот пакет Обработан Будет Только уже Процессор В подавляющем Большинстве Тех технологий Которые мы С вами изучаем ЦЭФ Может аппаратно Ускорять Работу этих технологий То есть Если у вас Есть какие-то Туннели ГРЕшные IPIP ДМВПН ЦЭФ С ними Соответственно Справляется С чем ЦЭФ Справиться не может IPsec Очевидно Что если у вас Есть такой-то IPsec Туннель То соответственно С ЦЭФом Будут некоторые Проблемы Если у вас Будет Например Какой-нибудь X25 интерфейс Там тоже Соответственно ЦЭФ про Такие старые вещи Тоже может не знать Да Железка у вас Может иметь Соответствующий интерфейс Потому что вы Пошли там На какой-то Барахолке

Купили соответствующую Литвую карточку ХВИК Там К примеру Да Или просто ВИК Ну соответственно Да Поддерживать Эту ЦИСКа может Но скорости Там такие Что ЦЭФ Там по факту Не нужен Но если у вас Этих карточек Много То каждый Из этих Карточек Каждый Из этих Интерфейсов Может дать Заметную Нагрузку На процессор И казалось бы Да Железка Мощная Железка Новая Но на ней Вот есть Несколько Вот этих Старых Интерфейсов Которые Вы туда Зачем Насобачили И они И у вас Процессор Отъедают Довольно Заметно Такое Может быть Во многих Случаях ЦЭФ Все-таки Справляется Со своими Задачами То есть Даже Если мы Включаем Какие-то Экзотические Вещи Фильтрацию Трафика ПБР Полиси Бэйстр Раутинг Иногда Даже Над Да ЦЭФ С этими Ситуациями Справляется Достаточно Неплохо Выключать ЦЭФ Еще раз Повторю Не надо Если что Команда По выключению ЦЭФ Есть Централизованная No IP ЦЭФ Ну и Соответственно IP ЦЭФ Просто

Повключить ЦЭФ На Железке И еще Отдельно На Уровне Интерфейса Можно ЦЭФ Включить Или Выключить И вот Эта На самом деле Даже Ее Вот Здесь Пытался Смотреть Вот Она IP Роуд Кэш Дальше Можно Сказать ЦЭФ Вот Если Вы скажете No IP Роуд Кэш Или No IP Роуд Кэш ЦЭФ Вы Тем Самым Выключите Обработку ЦЭФ Трафика Через Этот Интерфейс Поэтому Если Вдруг Вы Видите Какую-то Железку Которая Ктормозит У которой Постоянная Загрузка Процессора И Вроде Бы На ней Глобально ЦЭФ Не Выключен Но Есть Вот Это No IP Роуд Кэш На Интерфейсе То Знаете Это С Этим Есть Проблема Что Трафик Который Проходит Через Интерфейс Он Минуя Аппаратный Ускоритель Сразу Направляется На Процессор Вот Так Что Не Надо Эту Команду Вводить Без Лишней Нужды На То