Switch operations – часть 2

cable-nightmareЧестно скажу, не сразу решился писать вторую часть, так как она будет, в какой-то степени, дублировать мою предыдущую статью – 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.

tcam structure

  • Значения (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:
tcam example
Самые внимательные из вас наверняка заметили новый термин – 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, но это уже совсем другая история.

  • Delphin

    Спасибо!

  • Олег

    Спасибо. Готовлюсь к 642-813. Цикл ваших статей открыл мне глаза на MLS =)

  • Всегда пожалуйста, удачи на экзамене :)

  • Ivan Smirnov

    Было бы совсем здорово, если бы присутствовали ссылки на первоисточники.

  • Большей частью это official certification guide, nil.com и ipspace.net. Проблема в том, что некоторая часть информации копипастится в evernote и разбирается сильно позже.