В качестве примера используется C9300.

Модель: C9300L-24UXG-4X
Уровень управления (CP) = R0
Уровень передачи данных (DP) = F0, UADP/ASIC

Общие сведения о CEF: 

Почему Cisco Express Forwarding (CEF)? 
Технология высокоскоростной маршрутизации/коммутации пакетов, использующаяся в маршрутизаторах и коммутаторах третьего уровня фирмы Cisco Systems, и позволяющая добиться более быстрой и эффективной обработки транзитного трафика. 

«Необходимость — мать изобретения» — пословица.

Давайте совершим путешествие на сетевой машине времени в более простую эпоху (конец 80-х, начало 90-х годов).

Я собираюсь начать с основ программной пересылки и всех связанных с ней шагов пайплайна. У нас не было модных ASIC, как сегодня, поэтому все делалось на 100% за счет мощности процессора. Это было известно как «процессорная коммутация» и выполнялось для каждого отдельного пакета.  

1. Я маршрутизатор и получаю входной фрейм, является ли последовательность проверки фрейма (FCS) хорошей?

   • Плохая FCS = плохое оборудование, несоответствие дуплекса/скорости, неправильная работа сетевой карты/драйверов и т.д.

2. Извлечение IP-пакета

3. Проверка IP-пакета: Контрольная сумма IPv4 | Пропустить контрольную сумму IPv6

4. Является ли этот IP-адрес места назначения (DST) для меня?

   • Да = мы достигли конечного пункта назначения, Нет = переходим к шагу 5

5. Проверьте TTL: > 1, перейдите к шагу 6 | <= 1, завершите и отправьте ICMP "время превышено" источнику (SRC).

6. Проверьте базу маршрутной информации (RIB) по алгоритму на совпадение максимальной длины префикса DST (LPM).

7. Мне нужно создать новый фрейм для пересылки, какой следующий хоп?

   • Очень важный шаг в контексте CEF

8. Пакет готов к отправке, нужно уменьшить TTL на "1" в IP-заголовке и создать новую контрольную сумму (IPv4).

9. Отправить! Инкапсулируйте пакет в новый заголовок/трейлер канала передачи данных и поехали!

   • На этом этапе путешествия пакета через маршрутизатор он инкапсулируется во фрейм и «отправляется» в направлении выхода.

Введите "Fast Switching" (быстрая коммутация) в IOS версии 10.x. Это оптимизационная фича по «кэшированию» ранее коммутированных пакетов для последующего использования, позволяющая снизить нагрузку на процессор/обработку.

В результате команда CLI выглядит примерно так: "ip route-cache", поскольку это и есть то, что делает фича быстрой коммутации, кэшируя записи для использования в будущем. 

Как мы все знаем, кэширование в качестве метода оптимизации имеет компромиссы, как и ВСЕ, что мы делаем в инженерии. Этот подход «маршрут — один раз, переключение — много раз» имел несколько очевидных проблем.

1. Каждый отдельный новый пакет (уникальное место назначения) коммутируется процессом, поэтому большая нагрузка [опция burst] может поставить CPU на колени, моля о пощаде.

2. Необходимо очистить и обновить записи в кэш-памяти, это повлияет на CPU, так как первые несколько пакетов были коммутированы для создания свежих записей в кэш-памяти. 

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

4. Конвергенция и новые пути

Я думаю, что веб-кэширование имеет те же проблемы (несвежие данные), что и «быстрая коммутация». Я уверен, что есть и другие компромиссы, о которых я забыл, однако это все равно было улучшением по сравнению с чистой пересылкой на основе процессов. 

На дворе 1996 год и рождение CEF.

Для дальнейшей оптимизации пересылки нам пришлось сосредоточиться на преодолении ограничений «быстрой коммутации» и ее кэшированных записей. Какая часть процесса является НАИБОЛЕЕ интенсивной для процессора и требует максимального количества вычислительных циклов? 

Ответ? Поиск наилучшего пути для конечных сетей, выходного интерфейса для достижения этого конечного пункта назначения и, наконец, создание нового заголовка канала данных (перезапись фрейма, шаг #7 выше в пайплайне коммутации процессов).

Это был абсолютно линейный процесс сканирования RIB и поиска LPM. А теперь представьте, что вы просматриваете RIB с 1 млн. записей сверху донизу и обнаруживаете, что 0/0 — единственный правильный путь к месту назначения, и он находится в самом конце поиска? Всегда есть возможности для улучшения, и именно на это была направлена работа CEF.

Давайте начнем с основных усовершенствований CEF

1. CEF Forwarding Information Base (FIB): Быстрый поиск с помощью FIB (база данных пересылки), полученной из RIB. FIB создана для оптимизации быстрого поиска информации (префиксов), содержащейся в RIB и предназначенной для поиска соответствия LPM. Эти префиксы могут храниться в программном или аппаратном обеспечении. Данная информация (префиксы) структурирована в виде дерева, ориентированного на оптимальный поиск данных, когда речь идет о программном обеспечении/уровень управления. Информация (префиксы) также оптимизирована для оптимального поиска данных/указателей, когда речь идет об аппаратном обеспечении/уровень передачи данных (TCAM/ASIC).

2. CEF Adjacency Table (таблица соседства): Маршрутизатор может иметь миллион с лишним маршрутов в своей RIB, но только несколько соседей (next hops) [следующих прыжков (хопов)] для достижения этих мест назначения. В итоге мы используем общий next-hop, выходные интерфейсы и переписываем фреймы для этих DST.

При коммутации процессов это происходит для каждого маршрутизируемого пакета, при быстрой коммутации записи для каждого DST кэшируются. Появилась таблица соседства (Adjacency Table) и концепция «интеллектуального» маршрутизатора. С помощью CEF мы можем «смотреть вперед», проникая в таблицу RIB/ARP и формируя полную информацию о пересылке перед тем, как пакеты начнут двигаться вдоль цифровой магистрали. Затем эта информация о состоянии упреждающе программируется в аппаратное обеспечение для пересылки. В этом и заключается волшебство CEF!

Резюме: 

CEF FIB и CEF adjacency table являются ключевыми компонентами CEF и получили дальнейшее развитие за рамками процесса и быстрой коммутации. 

• FIB содержит все известные IP-префиксы из RIB, организованные для быстрого поиска с помощью структуры данных "дерево/префиксное дерево" в плоскости управления (CP).

• Поиск в FIB с использованием IP-адреса DST пакета в качестве ключа приводит к указателю на таблицу соседства, которая содержит предварительно созданные заголовков фреймов для отдельных следующих хопов, чтобы их можно было мгновенно применить к пакету. 

• Состояние программируется в аппаратном обеспечении/ASIC и затем используется для оптимальной пересылки и обеспечивает разгрузку процессора CP (CPU), чтобы он мог выполнять другие обязанности.

• Это сочетание программного (CP) и аппаратного (DP) обеспечения, работающего в гармонии, является причиной того, что CEF по-прежнему используется спустя 27 лет, в 2023 году.

Теперь давайте разберемся в некоторых деталях.

На устройствах Cisco IOS-XE, таких как ASR 1000s или Catalyst 9000s, плоскость управления (CP/General Purpose CPU) отделена от плоскости данных (DP/ASIC). Когда обновление должно быть передано из плоскости управления в плоскость данных, оно пройдет через поток данных, показанный на блок-схеме приведенной ниже.

Например (ASR1000), в CEF при изучении любого префикса на плоскости управления, это обновление передается от плоскости управления (IOSd) к менеджеру пересылки плоскости управления (FMAN-RP). Менеджер пересылки на плоскости управления использует утилиты ядра, такие как lsmpi, Hyper-transport (HT) links и т.д., чтобы... <выделено СИНИМ цветом, плоскость управления/программное обеспечение>

передать обновление менеджеру пересылки плоскости данных (FMAN-FP). Менеджер пересылки передает обновление ASIC Quantum Flow Processor (QFP) (процессор квантового потока), который программирует микрокод QFP для окончательного программирования подсистемы QFP, выполняющей фактическую пересылку пакетов в устройствах Cisco Aggregation Services Router (ASR 1000) (Маршрутизатор служб агрегации Cisco). <выделено ЖЕЛТЫМ, плоскость передачи данных/аппаратное обеспечение>

Теперь пришло время засучить рукава и немного поработать с CLI.

Существуют различные команды, которые можно использовать для проверки состояния CEF, и мы рассмотрим некоторые из них для Catalyst 9000. 

Сначала давайте убедимся, что CEF включен (по умолчанию включен).

Рассмотрим запись CEF для "10.0.0.1/32 и 0.0.0.0/0" соответственно. <CP/Software> (<плоскость управления/программное обеспечение>)

Примечание: Вот как мы на самом деле просматриваем базу данных пересылки (FIB), если вы хотите просмотреть всю FIB, это просто "show ip cef" <CP/Software>.

Я буду использовать эти два источника (RIB и ARP) для создания своей собственной таблицы соседства CEF.

• (RIB) n3tArk_C9300#sh ip route 0.0.0.0

Routing entry for 0.0.0.0/0, supernet

  Known via “static”, distance 1, metric 0, candidate default path

  Routing Descriptor Blocks:

  * 10.100.200.1  Next Hop 

      Route metric is 0, traffic share count is 1

• (ARP) n3tArk_C9300#sh ip arp 10.100.200.1

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.100.200.1            0   ac17.c85c.bcdc  ARPA   Vlan777

• Запись соседства

Как вы видите, у меня есть информация в плоскости управления (CP), а теперь давайте посмотрим, как CEF берет эту информацию и использует ее для создания записи соседства, которая будет использоваться в пересылке для плоскости данных (DP). <Still CP/Software> (<По-прежнему CP/программное обеспечение>)

• n3tArk_C9300#show platform software ip switch 1 r0 cef prefix 0.0.0.0/0 detail

Forwarding Table

0.0.0.0/0 -> OBJ_ADJACENCY (0x22), urpf: 36

Prefix Flags: Default

OM handle: 0x348036a748

Итак, на стороне CEF CP все в порядке, у нас есть запись с индексом/идентификатором соседства "0x22".

Давайте проверим, что будет запрограммировано в плоскости данных на более поздней стадии процесса менеджера пересылки (FMAN). Имейте в виду, что вы увидите ссылки на "QFP". Это ASIC в платформах ASR1000, в Cat9K мы используем ASIC под названием UADP/Doppler, но функционально это одно и то же. 

Ссылка: "show platform software" (показать программное обеспечение платформы) технически все еще является "плоскостью управления", но отображает, что HW дескриптор был создан и будет запрограммирован в путь пересылки.

• n3tArk_C9300#show platform software ip switch 1 f0 cef prefix 0.0.0.0/0 detail

Forwarding Table

0.0.0.0/0 -> OBJ_ADJACENCY (0x22), urpf: 36

Prefix Flags: Default

aom id: 231, HW handle: (nil) (created)

Отлично! Мы можем предположить, что эта запись CEF запрограммирована в HW/пути пересылки!

Это не входит в рамки содержания данного блога, однако могут существовать команды для более глубокого погружения в программирование аппаратной пересылки, такие как "show platform hardware xxx" или "show ip cef platform xxx", но идея вам понятна.

Интересно, как выглядят данные "рерайтинга"? 

Возьмите идентификатор индекса (0x22) из примера выше и выполните следующую команду

• show platform software adjacency switch 1 f0 index 0x22 #REMEMBER TO USE HEX AND NOT DECIMAL#

Number of adjacency objects: 41

Adjacency id: 0x22 (34)

  Interface: Vlan777, IF index: 40, Link Type: MCP_LINK_IP

  Encap: ac:17:c8:5c:bc:dc:5c:a6:2d:c4:c0:7b:8:0

#FRAME REWRITE: DST MAC|SRC MAC|ETHERTYPE#

  Encap Length: 14, Encap Type: MCP_ET_ARPA, MTU: 1500

  Flags: no-l3-inject

  Incomplete behavior type: None

  Fixup: unknown

  Fixup_Flags_2: unknown

  Nexthop addr: 10.100.200.1

  IP FRR MCP_ADJ_IPFRR_NONE 0

  aom id: 579, HW handle: (nil) (created)

Теперь давайте посмотрим на запись соседства VLAN 777!

• n3tArk_C9300#show adjacency vlan777 detail

Protocol Interface                 Address

IP       Vlan777                   10.100.200.1(12)

                                   0 packets, 0 bytes

                                   epoch 0

                                   sourced in sev-epoch 2

                                   Encap length 14

                                   AC17C85CBCDC5CA62DC4C07B0800

# FRAME REWRITE: DST MAC|SRC MAC|ETHERTYPE #

                                   L2 destination address byte offset 0

                                   L2 destination address byte length 6

                                   Link-type after encap: ip

                                   ARP

В заключение хочу сказать, что мы прошли путь от переключения процессов, до быстрого переключения, до CEF. Всегда помните, что все, что мы делаем в инженерии, имеет компромиссы. CEF — это здорово, но ничто не дается бесплатно, и цена за CEF — память. В современных платформах маршрутизаторов/коммутаторов это не так важно, как в прошлом. Я только что оценил Catalyst 8300 Edge (я знаю, это маршрутизатор с номенклатурой «коммутатор (свитч)») и понял, что смогу увеличить объем оперативной памяти до 32 ГБ!

Кроме того, я уверен, что среди читающих это людей есть те, кто помнит сообщения syslog, которые выглядели примерно так: «Не удалось запрограммировать таблицу пересылки». Вот что происходит когда память (TCAM/FIB или RAM/RIB) исчерпана.

Также, существует некоторая путаница относительно использования фактической «коммутации» или чистой коммутации фреймов второго уровня в отношении текущих реализаций CEF.

Я думаю, что Питер Палуч (Peter Paluch) мастерски резюмировал неразбериху по этой теме.

Все упомянутые вами методы — коммутация процессов, быстрая коммутация (которая устарела и больше не поддерживается в последних IOS) и CEF — относятся к маршрутизации Уровня 3. Как программные маршрутизаторы, так и аппаратные многоуровневые коммутаторы используют CEF. Другими словами, CEF может быть реализован как в программном, так и в аппаратном обеспечении. Маршрутизаторы на базе программного обеспечения выполняют CEF с помощью программ, а многоуровневые коммутаторы на базе ASIC реализуют значительную часть CEF в своих ASIC. 

Маршрутизация включает в себя быстрое определение соответствующего следующего хопа для полученного пакета и создание нового фрейма для него, чтобы он мог быть передан очередному хопу. Новый фрейм иногда также называют «рерайтом фрейма», потому что именно так он выглядит со стороны: пакет, заключенный во фрейм, попадает на один из ваших интерфейсов, вы принимаете решение о маршрутизации на основе назначения пакета, переписываете фрейм, чтобы указать адрес L2 (Уровень 2) следующего хопа (и все остальное, что должно быть в валидном фрейме), и отправляете его через соответствующий интерфейс к очередному хопу.

CEF решает проблему быстрого поиска информации о перезаписи фрейма и выходного интерфейса.

Действительно, CEF использует таблицу маршрутизации и таблицу ARP — но только в качестве входных данных для вычисления собственных оптимизированных структур данных. Он компилирует содержимое таблицы маршрутизации (RIB) в оптимизированную структуру данных, которая очень быстро выполняет поиск по наиболее длинному префиксу. Это то, что мы называем FIB — Forwarding Information Base (База данных пересылки). В программном обеспечении это обычно реализуется как своего рода дерево префиксов. В аппаратном обеспечении для этого используются TCAM, хэш-таблицы или фильтры Блума. В любом случае, поиск адреса назначения пакета в FIB дает указатель на таблицу соседства — а таблица соседства содержит полные подготовленные заголовки фреймов для отдельных следующих хопов, включая информацию о выходном интерфейсе. Именно здесь ARP-таблица использовалась для заполнения содержимого таблицы соседства. Поэтому поиск пункта назначения в FIB немедленно выдает указатель на полную перезапись фрейма и выходной интерфейс для пакета.

Обратите внимание, что таблицы RIB и ARP не используются CEF для маршрутизации пакетов. RIB и ARP используются только для заполнения собственных высоко оптимизированных структур данных CEF, которые затем, в свою очередь, используются CEF для маршрутизации пакетов. Да, CEF по сути делает свою собственную копию содержимого RIB и ARP (и некоторых других таблиц) и компилирует их в форму, которая ускоряет поиск и использование информации о рерайте фрейма и выходном интерфейсе.

Если вы сейчас задумаетесь об этом, то коммутация фреймов на уровне L2 не включает в себя поиск соответствия самого длинного префикса и не включает рерайт фрейма. Здесь CEF не нужен. Базовая коммутация L2 может быть реализована с помощью более простой настройки — использование CEF здесь не даст никаких преимуществ.

Итак, проще говоря, маршрутизаторы и многоуровневые коммутаторы Cisco используют CEF для операций маршрутизации третьего уровня. Для чистой коммутации L2 Ethernet коммутаторы не используют CEF, даже если они его поддерживают.

Дополнительные команды для справки: 

• n3tArk_C9300#show ip cef adjacency vlan 777 10.100.200.1 detail

IPv4 CEF is enabled for distributed and running

VRF Default

 53 prefixes (52/1 fwd/non-fwd)

 Table id 0x0

 Database epoch:        3 (53 entries at this epoch)

0.0.0.0/0, epoch 3, flags [default route]

  recursive via 10.100.200.1

    attached to Vlan777

10.0.0.1/32, epoch 3

  recursive via 10.100.200.1

    attached to Vlan777

10.100.200.1/32, epoch 3, flags [attached]

  Adj source: IP adj out of Vlan777, addr 10.100.200.1 7F200CAF3BE8

    Dependent covered prefix type adjfib, cover 10.100.200.0/24

  1 RR source [no flags]

  attached to Vlan777

• n3tArk_C9300#show ip cef adjacency vlan 777 10.100.200.1 platform

0.0.0.0/0

  Platform adj-id: 0x22, 0x0, tun_qos_dpidx:0

10.0.0.1/32

  Platform adj-id: 0x22, 0x0, tun_qos_dpidx:0

10.100.200.1/32

  Platform adj-id: 0x22, 0x0, tun_qos_dpidx:0

Также вы можете использовать эту команду на IOS-XE/C9300s. 

• n3tArk_C9300#sh ip cef platform

Примечание: вывод этой команды может занять некоторое время в зависимости от размера таблицы CEF.

Пример вывода:

0.0.0.0/0

  Platform adj-id: 0x22, 0x0, tun_qos_dpidx:0

0.0.0.0/8

0.0.0.0/32receive

10.0.0.1/32

  Platform adj-id: 0x22, 0x0, tun_qos_dpidx:0

Завтра пройдет открытый урок «Диагностика BGP-проблем: причины и выявление».

На вебинаре рассмотрим основные типы BGP инцидентов, которые могут произойти из-за ошибки в эксплуатации сети или в результате хакерской атаки. Далее сделаем обзор инструментария, который может использовать сетевой инженер для выявления проблем с глобальной маршрутизацией.

• Регистрация на открытый урок