В таблице САМ хранится вся информация о наших МАС-адресов. И вы могли бы сказать: ну, Vasyo, тогда почему бы нам не назвать это таблицей MAC? Почему таблица CAM? Это похоже на MAC в обратном направлении - CAM. Но хотите верьте, хотите нет, но есть веская причина, почему мы называем это CAM. CAM расшифровывается как Content Addressable Memory. И ключевое слово здесь - сontent.
Когда мы говорим об обычной памяти, такой как RAM (Random Access Memory), мы, в общем-то, говорим о предоставлении местонахождения данных. То есть мы знаем точно, где наши данные хранятся. Нам просто нужно вернуть эти данные. И в ответ на этот поиск мы возвращаем значение (value), которое представляет собой данные, запрошенные нами.
Когда же мы говорим о CAM, то буква С указывает нам на то, что мы предоставляем Content, а не адрес, не местонахождение данных. Так что, когда мы возвращаем данные, то основываемся на content, а не на адресе. И здесь значением будет МАС-адрес. Поиск МАС-адреса происходит в двоичной системе, что значит - поиск точного совпадения. Это работает прекрасно для МАС-адресов, но не так хорошо для IP-адресов, потому что в последнем нам нужно заботиться еще и о маске сети, выполнение которой для CAM невозможно. Зато это возможно для TCAM (Ternary CAM), но он нем в следующий раз.
CAM-таблица строится на основе высокоскоростной памяти. Нам нужен высокоскоростной ответ на запрос в отношении сетевого трафика. Поиск в таблице CAM может происходить за один цикл ЦП. Мы можем просканировать всю таблица CAM за один раз.
Что именно хранится в CAM таблице таки? Мы храним в ней три вида информации: это МАС-адреса, это интерфейсы и это VLAN ID. Таблица заполняется этими данными по ходу прохождения траффика через коммутатор.
| Приведем пример. Пусть у нас будет коммутатор с тремя интерфейсами: 1,2,3 и одним VLAN ID 10 на этих интерфейсах. На один из этих интерфейсов приходит Ethernet-frame: |
 |
| Фрейм будет иметь адрес отправления и адрес назначения. Назовем адрес назначения МАС-адресом A. Наш коммутатор, прежде всего, запомнит на какой интерфейс пришел этот фрейм и каков адрес его отправления. |
 |
И это будет первой записью в нашей CAM-таблице.
Когда мы получим другой фрейм, скажем на интерфейс 3 и МАС-адресом B, то запись будет выглядеть таким же структурированным образом. |
 |
 |
| Представим теперь интересную вещь. На интерфейс 2 поступит фрейм с МАС-адресом А, да, с тем, который уже значится за интерфейсом 1. Как поведет себя САМ-таблица в этом случае? |
 |
| Прежде всего, она добавит эту запись по тому же принципу, что и два предыдущих фрейма. |
 |
| А после удалит первую запись, потому что она дублирована и потому что мы будем думать, что устройство с МАС-адресом A переместилось, может быть в силу беспроводного роуминга, или может его просто переключили в другой порт. |
 |
| Теперь скажем, что поступает фрэйм с адресом назначения MAC:A |
 |
Нам нужно отправить этот фрейм точно к адресу назначения и вот тут-то мы и приходим к понимаю того, зачем мы строили и наполняли CAM таблицу. Мы сделаем вещь, которую сложно перевести на русский – content addressable lookup, запрос соответствующего адреса из таблицы САМ. И САМ нам ответит, что адрес А расположен за интерфейсом 1 в VLAN 10 и отправит этот фрейм соответствующим путем.
А если придет фрейм с адресом назначения, скажем, D, которого у нас нет в таблице. Что будет тогда? Тогда коммутатор отправит этот фрейм на все порты, принадлежащие VLAN 10 – широковещательная рассылка, flooding.
*Статья является переводом материалов от Jeff Kish (cbtnuggets.com)
