Коммутация и маршрутизация на коммутаторах CISCO

Скомпилировано себе на память из нескольких источников. Основные источники:
http://twistedminds.ru/
http://xgu.ru/

Раньше перед тем как отправить сообщение в сеть устройство должно было убедиться что в данный момент никто не вещает. Для этого существовал протокол CSMA/CD – Carrier Sense Multiple Access with Collision Detect. Устройства работали только в half duplex, то есть в один момент времени устройство могло только передавать или только принимать данные. Все устройства работали в одном Collision Domain и если одно из устройств создавало фрейм с ошибкой, то такой фрейм принимали все устройства в Collisions Domain.
В настоящий момент Collisions Domain выродился до двух участников - порта коммутатора и устройства, сетевые устройства могут работать в режиме full duplex, а ошибки в фреймах теперь фильтруются непосредственно на ASIC, к которому подключен порт(ы) и не распространяются на всю сеть. ASIC application-specific integrated circuit, «интегральная схема специального назначения») — интегральная схема, специализированная для решения конкретной задачи. Специализированные интегральные схемы применяются в конкретном устройстве и выполняют строго ограниченные функции, характерные только для данного устройства; вследствие этого выполнение функций происходит быстрее и, в конечном счёте, дешевле. Ты хороший пакет, у тебя годный CRC? Значит мы повторим тебя на исходящем порту (store-and-forward метод – пакеты приходят на входящий порт, поступают на хранения для инспекции и только затем перенаправляются на исходящий).

CAM (Content Addressable Memory)

CAM (Content Addressable Memory) или L2 Forwarding Table, таблица в которой хранятся MAC-адреса. Весь процесс коммутации на втором уровне полностью основан на MAC адресах, поэтому коммутатору необходимо знать информацию не только о тех устройствах, которые подключены непосредственно к его портам, но и знать информацию о устройствах, находящихся за соседними коммутаторами. Как только коммутатор получает фрейм на входящий порт, он тут же помещает его в очередь до тех пор пока не решит через какой порт этот фрейм нужно отправить. Решение коммутатор принимает после процедуры поиска MAC адреса получателя в таблице CAM. Для заполнения таблицы MAC-адресов (CAM) коммутаторы изучают Source MAC полученного фрейма и создают запись, в которой фигурирует порт, на который пришел фрейм, MAC и VLAN. Такая запись заносится в CAM таблицу. Помимо Source MAC имеет место еще и Destination MAC – адрес того устройства, которому фрейм должен быть доставлен. Коммутатор заглядывает в список записей, в надежде найти за каким портом и в каком VLAN находится получатель фрейма и в том случае если такой записи не существует, то коммутатор рассылает фрейм на все порты за исключением того, с которого этот фрейм пришел. Этот процесс носит название unknown unicast flooding.
Noch einmal. Когда кадры поступают на порты коммутатора, MAC-адрес источника запоминается и записывается в таблицу CAM. Порт, на который были получены кадры, и сеть VLAN записываются в таблице вместе с меткой времени. Если MAC-адрес, изученный одним портом коммутатора, был перемещен на другой порт, записывается MAC-адрес и метка времени того порта, который получил кадры последним. Предыдущая запись удаляется. Если MAC-адрес для правильного приемного порта уже содержится в таблице, то обновляется только метка времени.

Так как MAC адрес является уникальным идентификатором устройства, то коммутатор, получив тот же Source MAC на другом порту заменит эту информацию в CAM таблице. Такая ситуация называется address flapping.

По-умолчанию время жизни записи в таблице CAM составляет 300 секунд, то есть если устройство не давало о себе знать в течении 300 секунд, то запись о нем стирается. Это сделано для того, чтобы таблица CAM не переполнялась.

Изменить время жизни по-умолчанию можно командой: 

SWG(config)#mac address-table aging-time ? 

<0-0>         Enter 0 to disable aging  <10-1000000>  Aging time in secon

Можно создать и статическую запись в таблице CAM:

SWG(config)#mac address-table static d8cb.8a9c.ffe8 vlan 19 interface gigabitEthernet3/1

Посмотреть содержимое CAM таблицы можно командой:

SWG#sh mac address-table dynamic

Посмотреть размер CAM таблицы:

SWG_PoE_4510#sh mac address-table count 
MAC Entries for all vlans:
Dynamic Unicast Address Count:                  656
Static Unicast Address (User-defined) Count:    0
Static Unicast Address (System-defined) Count:  9
Total Unicast MAC Addresses In Use:             665
Total Unicast MAC Addresses Available:          55000
Multicast MAC Address Count:                    41
Total Multicast MAC Addresses Available:        32768

Вычислить путь до устройства,layer 2 traceroute (работает только внутри одного vlan):

SWG_PoE_4510#traceroute mac d8cb.8a9c.ffe8 001d.71dd.69c1
Source d8cb.8a9c.ffe8 found on SWG_PoE_4510
1 SWG_PoE_4510 (10.100.10.254) : Gi3/1 => Te6/1
2 SWT1_PLK (10.100.18.89) : Gi1/1/3 => Gi1/0/24
Destination 001d.71dd.69c1 found on SWT1_PLK
Layer 2 trace completed

TCAM (Ternary Content-Addressable Memory)

TCAM (Ternary Content-Addressable Memory) Троичное ассоциативное запоминающее устройство — в многоуровневой коммутации все процессы, использующие списки управления доступом (ACLs), работающие для обычной маршрутизации, такие как согласование, фильтрация или управление специальным трафиком, работают на аппаратном уровне.
ACL состоит из нумерованного списка правил, цель которых определить что делать с тем или иным типом трафика базируясь на наборе атрибутов. Каждое правило в списке называется Access Control Entity – ACE. Если бы шла сверка ACE для каждого пакета, то о маршрутизации на скорости интерфейса и не пришлось бы мечтать. Представьте развесистые ACL-ы, висящие и для входящего и для исходящего трафика, а также ACL-ы, маркирующие трафик согласно политике QOS. Поэтому существование способа сделать поиск по всем ACE одновременно и параллельно с layer 2/layer 3 forwarding просто жизненно необходимо.
TCAM позволяет выполнить оценку пакета в отношении всего списка доступа при поиске в одной таблице. В большинстве коммутаторов имеется несколько устройств TCAM, таким образом, безопасность входящего и исходящего трафика и QoS на базе списков ACL могут оцениваться одновременно или параллельно с принятием решения о передаче на уровне 2 или 3.

Операционная система Cisco IOS обладает двумя автономными компонентами по работе с TCAM:

• Feature Manager (FM) – процесс, компилирующий ACE в TCAM.
• Switching Database Manager (SDM) – процесс, позволяющий распределить TCAM на различные области иначе, чем это предполагается в некой усредненной конфигурации из коробки при помощи Cisco SDM templates. Других механизмов управления TCAM в IOS нет.

TCAM, так же как и CAM позволяет за одну операцию производить поиск по всей таблице целиком. Тогда как CAM использует в качестве индекса MAC адрес, а в результате ожидает увидеть порт. С TCAM все немного сложнее. Бинарная природа CAM прекрасно работает там, где нужны четкие запросы, тогда как ACL куда абстрактнее MAC адресов. Нет проблем, когда существует ACE конструкция типа:

Switch(config)# access-list 100 permit ip host 1.1.1.1 host 2.2.2.2

но что делать, когда на поле врываются маски подсети, определяющие какие биты имеют смысл, а какие можно опустить? Поэтому к бинарным 1, 0 в CAM добавляется третье значение – X и она становится TCAM.

• Значения (values) – 134 битное поле, содержащее адрес отправителя, адрес получателя и другие значения, на основании которых можно производить выборки.
• Маски – 134 битное поле, использующее тот же формат, что и значения. Маски выбирают только те значения, которые могут быть интересными.
• Результат – результатом может стать как простое решение разрешить или запретить обработку пакета (если мы говорим о обычных Security ACL), так и указатель на индекс QOS политики или, даже, указатель на адрес next hop устройства в таблицы маршрутизации в случае с PBR.

ARP таблица

ARP таблица хранит соответствие  IP-адреса с MAC-адресом, чтобы обеспечить передачу IP-данных на уровне 2 домена широковещательной рассылки. Например, узел B должен отправить данные в узел A, но в его кэше ARP отсутствует MAC-адрес узла A. Узел B генерирует широковещательное сообщение для всех узлов, принадлежащих домену широковещательной рассылки, чтобы получить MAC-адрес, соответствующий IP-адресу узла A. ARP-запрос получают все узлы домена широковещательной рассылки, но ответ, содержащий требуемый MAC-адрес, отправляется только из узла А.

Процесс коммутации/маршрутизации в MLS

Пакет забирается с одной из входящих очередей и происходит исследование L2 и L3 адресов получателей. Решение о том куда направить пакет происходит на основании CAM и FIB таблиц. Решение о том как отправить пакет (и отправлять ли вообще) принимается на основании ACL и QOS политик. Стоит отметить, что поиск по CAM, FIB, QOS, ACL происходит одновременно.

Cisco Express Forwarding (CEF)

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

Функционал, который поддерживает CEF:

• QoS
• ACL
• Zone Based Firewall
• NAT
• Netflow
• IPSec
• GRE
• PBR

CEF не работает в следующих случаях:

• Включен ACL Logging (в конце ACL добавлено слово log, например deny ip any any log)
• Пакеты предназначены для самого маршрутизатора/коммутатора.
• Нет L2 Adjacency

Forwarding Information Base (FIB)

Forwarding Information Base (FIB) или CEF Table — таблица для быстрой пересылки пакетов. Строится на основе Routing Table и Adjacency Table. Adjacency Table в свою очередь строится на основе ARP Table. Различают 2 вида CEF - Software CEF (можно увидеть на ISR G1/G2 и 7200) и Hardware CEF (можно увидеть на 6500/7600, Nexus 7000 и ASR9000). Hardware CEF - это когда построенная FIB хранится в быстрой памяти TCAM (Ternary Content Addressable Memory). Итого FIB - это таблица, содержащая маршрут, исходящий интерфейс и L2 destination.
Layer 3 engine (фактически маршрутизатор) формирует таблицу маршрутизации, поддерживает ее в актуальном состоянии и, что самое главное, форматирует и компилирует ее в новый формат – Forward Information Base. FIB строится согласно следующей логике: таблица маршрутизации форматируется в упорядоченный список, где для каждой сети существует один или несколько маршрутов. Первым, понятное дело, идет наиболее длинный префикс (longest prefix match). Одновременно с этим FIB содержит next-hop адрес устройства для каждой записи. Помимо информации из таблицы маршрутизации в FIB попадают маршруты до directly conntect хостов.
Любая актуализация таблицы маршрутизации тут же отражается в FIB благодаря стараниям Layer 3 engine, так же как изменения next-hop и ARP записей.
После того, как FIB скомпилирована, загружена в TCAM/SRAM за дело берется layer 3 forwarding engine, занимаясь маршрутизацией данных с помощью аппаратного обеспечения, исключая случаи описанные выше.

Посмотреть информацию о данных, расположенных в FIB таблицы можно с помощью команды:
SWG_PoE_4510#sh ip cef 
Prefix               Next Hop             Interface 
0.0.0.0/0            no route
0.0.0.0/8            drop
0.0.0.0/32           receive              
10.0.0.20/30         10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.4/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.5/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.6/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.7/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.8/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.9/32        10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.10/32       10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.11/32       10.100.0.170         Vlan704
                     10.100.0.173         Vlan711
10.10.10.12/32       10.100.0.170         Vlan704
                     10.100.0.173         Vlan711

Adjacency Table

Эта таблица содержит и Layer 3 адреса и MAC адреса в записях о всех next-hop и directly connected устройствах.

R1#show adjacency detail

Protocol Interface                 Address

IP       FastEthernet0/0           100.0.0.2(7)

                                   0 packets, 0 bytes

                                   epoch 0

                                   sourced in sev-epoch 0

                                   Encap length 14

                                   CA0111480008CA00114800080800

                                   ARP

Строка CA0111480008CA00114800080800 читается следующим образом:

• CA0011480008 - это source мак-адрес интерфейса, через который будет отправляться пакет на 100.0.0.2
• CA0111480008 - это destenation мак-адрес ca01.1148.0008
• 0800 - это EtherType (в данному случае у нас это IPv4 0x0800).

CEF epoch

В FIB и adjacency table есть понятие версии, которая называется epoch. Диапазон значений epoch от 0 до 255.
Значение epoch увеличивается, при инициации перестроения таблицы. Это можно сделать вручную, очистив информацию CEF.
На практике epoch используется, например, при переключении между supervisor engine в технологии NSF:
Во время переключения, в таблицах CEF увеличивается значение epoch.
После того как протоколы маршрутизации обновили информацию в RIB, соответственно обновляются и записи в таблицах CEF. Обновленным записям назначается новое значение epoch.
После завершения обновления, все записи в FIB и adjacency table, у которых значение epoch меньше текущего, удаляются.

Состояние CEF glean

Adjacency table строится Layer 3 engine из ARP таблицы. В том случае если нет записи о next-hop адресе в ARP таблице CEF помечает такую FIB запись как “CEF glean”. Это означает, что Layer 3 forwarding engine стоит дернуть Layer 3 engine, которые должен в свою очередь генерировать ARP request и справедливо ожидать на него ARP reply.
Мониторится это следующим образом:

Switch# show ip cef adjacency glean Switch#show ip cef 172.16.20.2 255.255.255.255 internal

В adjacency table помимо соответствия layer 3 – layer 2 адресов хранятся другие типы данных:
Null adjacency – используется для коммутации пакетов, которые направляются в blackhole, null интерфейс. Это логический интерфейс присутствующий на коммутаторах и маршрутизаторах, функция которого состоит в тихом убиение пакетов без какой-либо обработки и генерации пакетов.
Drop adjacency – используется для коммутации пакетов, которые невозможно перенаправить в нормальном режиме. Такое может случиться по разным причинам – ошибки CRC, неподдерживаемый протокол, отсутствие маршрута и т.д.
Отслеживать количество отброшенных пакетов можно так:

SwitchA#show cef drop

Discard adjacency – используется тогда, когда пакеты должны быть отброшены по причине правила в Security ACL или по другим соображениям (QOS, PBR).
Punt adjacency – используется тогда, когда пакет должен быть отправлен на layer 3 engine для дальнейшей обработки. См. тот же CEF glean state выше.