Честно скажу, не сразу решился писать вторую часть, так как она будет, в какой-то степени, дублировать мою предыдущую статью – http://twistedminds.ru/2012/12/tcam/, однако здравый смысл победил лень. Ну и повторение – мать учения, ага. В этой части мы более подробно поговорим про CAM и TCAM таблицы и их структуру, выясним что такое LOU, не забыв снабдить все это дело сочным примером. So, let’s go.
Content-Addressable Memory
Из пакета/фрейма только-только упавшего на входящий порт в CAM таблицу попадает доселе неизвестный коммутатору MAC адреса источника. Это мы знаем из предыдущей статьи. Вместе с этим MAC адресом в таблицу попадает еще и timestamp, указывающий на то, когда этот адрес был заучен. CAM таблицы довольное большие, но не бесконечные, по этому через 300 секунд (значение по умолчанию) данные из CAM таблицы будут удалены в том случае, если данное устройство не давало о себе знать.
Переопределить значение по умолчанию можно с помощью команды:
Switch(config)# mac address-table aging-time #_seconds
Процесс заполнения CAM, как видно, полностью автоматизирован, однако нам никто не мешает создать статическую запись с помощью команды:
Switch(config)# mac address-table static mac-address vlan #_vlan interface #_iface
Что может быть полезно если вы соберетесь настроить у себя Microsoft NLB Cluster, например (http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml).
Так как MAC адрес является уникальным идентификатором устройства, то коммутатор, получив тот же Source MAC на другом порту заменит эту информацию в CAM таблицы. Такая ситуация называется address flapping. На практике такие события возникают в результате ошибок конфигурации LAG или при возникновении петель.
В CAM таблице хранятся бинарные данные. Эта таблица позволяет в ответ на запрос с данными (MAC адрес) получить адрес ячейки в которой эти данные хранятся. В обычной RAM все происходит с точностью до наоборот – вы отдаете адрес ячейки и получаете данные.
Посмотреть содержимое CAM таблицы можно с помощью:
Switch# show mac address-table dynamic
Вычислить местонахождение устройства:
Switch#show mac address-table dynamic address F46D.04AD.3BF3 Unicast Entries vlan mac address type protocols port -------+---------------+--------+---------------------+-------------------- 1 f46d.04ad.3bf3 dynamic ip,ipx,assigned,other TenGigabitEthernet1/51
Проверить размер CAM таблицы:
Switch#show mac address-table count MAC Entries for all vlans: Dynamic Unicast Address Count: 126 Static Unicast Address (User-defined) Count: 0 Static Unicast Address (System-defined) Count: 8 Total Unicast MAC Addresses In Use: 134 Total Unicast MAC Addresses Available: 55000 Multicast MAC Address Count: 9 Total Multicast MAC Addresses Available: 32768
Вычислить путь до устройства (layer 2 traceroute):
CoreSwitchA#traceroute mac 7081.0553.2ef2 f46d.04ad.3bf3 detail
Source 7081.0553.2ef2 found on CoreSwitchA[WS-C4948E] (192.168.1.254)
1 CoreSwitchA / WS-C4948E / 192.168.1.254 :
Gi1/47 [auto, auto] => Te1/51 [full, auto]
2 C2960S-24-B02 / WS-C2960S-24TS-L / 172.16.99.22 :
Gi1/0/27 [auto, auto] => Gi1/0/24 [auto, auto]
Destination f46d.04ad.3bf3 found on C2960S-24-B02[WS-C2960S-24TS-L] (172.16.99.22)
Layer 2 trace completed.
Ternary Content-Addressable Memory
Для фильтрации и контроля определенного трафика мы склонны использовать ACL. ACL состоит из нумерованного списка правил, цель которых определить что делать с тем или иным типом трафика базируясь на наборе атрибутов. Каждое правило в списке называется Access Control Entity – ACE. Если бы мы сверялись с каждым ACE для каждого пакета, то о маршрутизации на скорости интерфейса и не пришлось бы мечтать. Представьте развесистые ACL, висящие и для входящего и для исходящего трафика, добавьте к ним соус из ACL, маркирующий трафик согласно политике QOS. В результате вместо заветных 1gbit/s мы получим блюдо 2mbit/s. Срамота, а не process switching.
По этому существование способа сделать поиск по всем ACE одновременно и параллельно с layer 2/layer 3 forwarding просто жизненно необходимо. Here comes TCAM.
Операционная система Cisco IOS обладает двумя автономными компонентами по работе с TCAM:
- Feature Manager (FM) – процесс, компилирующий ACE в TCAM.
- Switching Database Manager (SDM) – процесс, позволяющий распределить TCAM на различные области иначе, чем это предполагается в некой усредненной конфигурации из коробки. Например, таким образом можно “перебросить” не используемые QOS ACE на PBR ACE (см. SDM Templates).
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.
Рассмотрим простой ACL:
access-list 100 permit tcp host 10.0.0.1 172.16.20.0 0.0.0.255 eq 80 access-list 100 permit udp host 10.0.1.1 192.168.100.0 0.0.0.255 eq domain access-list 100 deny ip any 10.100.0.0 0.0.63.255 access-list 100 deny udp any 10.100.64.0 0.0.63.255 range 100 1000
И скомпилируем его в TCAM:
Самые внимательные из вас наверняка заметили новый термин – LOU или Logical Operation Unit. Выборка на основе значения и маски работает только тогда, когда были переданы конкретные значения Layer 4 информации (например eq domain) или их не было передано вообще. Однако TCAM предоставляет механизм поиска по вхождениям, включая различные логические операции с layer 4 информацией, такие как gt, lt, neq, range. Такие выборки портов размещаются в LOU и могут использоваться несколькими ACE.
IOS не предоставляет никаких механизмов по манипуляцией с TCAM за исключением SDM.
Ну и the last, but not the least – TCAM – это не обязательный компонент MLS. Вместо него может использоваться SRAM, но это уже совсем другая история.