Какие меры безопасности эффективны для предотвращения атак путем переполнения таблицы cam

Безопасность коммутатора: управление и исполнение

Базовая система безопасности коммутатора не блокирует вредоносные атаки. Система безопасности — это многоуровневый процесс, требующий непрерывного совершенствования. Чем лучше сетевые специалисты организации осведомлены об угрозах безопасности и возможных последствиях, тем выше уровень защиты. Далее описаны некоторые виды угроз безопасности, однако подробное описание принципов действия атак в рамках этого курса не представлено. Более подробную информацию можно найти в курсах CCNA «Технологии глобальных сетей» и «Информационная безопасность».

Лавинная атака таблицы МАС-адресов

Таблица МАС-адресов коммутатора содержит МАС-адреса, которые связаны с каждым физическим портом и соответствующей VLAN. Когда коммутатор 2-го уровня получает кадр, он ищет в таблице МАС-адресов МАС-адрес назначения. Все модели коммутаторов серии Catalyst используют таблицу МАС-адресов для коммутации 2-го уровня. Когда кадры прибывают на порты коммутатора, МАС-адреса источника регистрируются в таблице МАС-адресов. Если для данного МАС-адреса существует запись, коммутатор пересылает кадр в соответствующий порт. В случае если MAC-адреса нет в таблице МАС-адресов, коммутатор рассылает кадр из каждого порта, кроме того, на котором этот кадр был получен.

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

На рис. 1 узел Host A отправляет трафик на узел Host B. Коммутатор получает кадры и ищет MAC-адрес назначения в таблице МАС-адресов. Если коммутатор не может найти МАС-адрес назначения в таблице МАС-адресов, то он копирует кадр и рассылает его (широковещательная рассылка) из каждого порта коммутатора, кроме того, на котором он был получен.

На рис. 2 узел Host B получает кадр и отправляет ответ на узел Host A. Таким образом коммутатор узнаёт, что MAC-адрес узла Host B находится в порте 2 и записывает эту информацию в таблицу МАС-адресов.

Узел Host C также получает кадр, направленный от узла Host A на узел Host B, но, поскольку MAC-адресом назначения этого кадра является узел Host B, узел Host C отбрасывает этот кадр.

Как показано на рис. 3, любой кадр, отправленный узлом Host A (или любым другим узлом) на узел Host B, пересылается на порт 2 коммутатора, а не отправляется по широковещательной рассылке из всех портов.

Размер таблиц МАС-адресов ограничен. Лавинные атаки используют это ограничение, забрасывая коммутатор ложными МАС-адресами источника до тех пор, пока таблица МАС-адресов коммутатора не заполнится.

Как показано на рис. 4, злоумышленник на узле Host C может отправлять на коммутатор кадры с несуществующими, случайно сгенерированными МАС-адресами источника и назначения. Коммутатор обновляет таблицу МАС-адресов информацией из фиктивных кадров. Когда таблица МАС-адресов наполняется фиктивными МАС-адресами, коммутатор входит в так называемый режим с пропусканием трафика. В этом режиме коммутатор отправляет все кадры по широковещательной рассылке всем устройствам в сети. В результате злоумышленник может видеть все рассылаемые кадры.

Некоторые средства сетевой атаки могут генерировать до 155 000 записей в таблице МАС-адресов коммутатора в минуту. Максимальный размер таблицы МАС-адресов может различаться в зависимости от коммутатора.

Как показано на рис. 5, до тех пор пока таблица МАС-адресов коммутатора остаётся заполненной, коммутатор передаёт все полученные кадры из каждого порта по широковещательной рассылке. В этом примере кадры, отправленные с узла Host A на узел Host B, также рассылаются из порта 3 коммутатора по широковещательной рассылке и видны злоумышленнику на узле Host C.

Один из способов снизить риск от атаки переполнения таблицы МАС-адресов — настроить функцию безопасности порта.

Как запустить атаку переполнения таблицы CAM в GNS3 с использованием маршрутизаторов Cisco 3725?

В настоящее время я работаю над атаками MiTM и защитой в виртуальной среде с использованием GNS3 и образа IOS c3725 ( c3725-adventerprisek9-mz.124-15.T14 ) для эмуляции некоторой топологии.

В текущем эксперименте рассматривается переполнение таблицы CAM и отлично работает со стандартным переключателем GNS3, но когда я использую c3725, результат довольно неожиданен. Я должен иметь возможность полностью заполнить таблицу CAM на устройстве. Однако, как видно из следующего рисунка, это не так:

Всегда есть место «зарезервировано», которое я не могу заполнить. Поскольку мне нужны STP и некоторые другие протоколы, я не могу использовать обычный переключатель GNS3. На устройстве нет защиты. Есть ли встроенная функция безопасности, настройка или что-то, о чем я не знаю?

Спасибо за вашу помощь!

2 ответа

Ну, вы попадаете в это пространство, где эмуляция и физическое соединение мира.

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

Когда вы пишете «стандартный переключатель GNS3», я предполагаю, что вы имеете в виду модуль NM-16ESW, эмулируемый динамиками? Если это так, это именно тот модуль и код, которые вы используете в любом случае с 3725.

Для любого типа безопасности, в том числе CAM выхлопных атак и даже безопасности портов, я бы тестировал только в реальной среде. Эмуляция /интерпретация в настройке времени выполнения не всегда обеспечивает одинаковые (или повторяющиеся) результаты по нескольким причинам, и это ясно видно в любых связанных с временем функциях, таких как QoS и некоторые части механизмов безопасности (которые учитывают правильное время и порядок срабатывания событий в IOS).

Теперь, возвращаясь к вашему вопросу : есть две части ответа:

• Во-первых, код, управляющий выходом CLI для кода «переключения программного обеспечения» IOS, который был добавлен при введении NM-16ESW, претерпел много изменений во время жизни продукта. Один из расширений заключался в том, чтобы добавить «противодавление», чтобы ускорить старение MAC при появлении новых адресов, тот же код также присутствовал в автономных коммутаторах того времени (Catalyst 2950 и более поздние модели — 2960, 3560 и 3750). Вы можете использовать эту точную функцию, поскольку используете довольно новую IOS (12.4 (15) T). Таким образом, коммутатор может просто быстро устаревать старыми MAC-адресами, чтобы он не видел трафик в /из, и устанавливать новые записи, которые вы наводняете, — как быстро BTW является вашим потоком?
• Другая часть ответа заключается в том, что эта команда была исправлена ​​несколько раз, поскольку она не всегда давала текущую ситуацию, но некоторые старые, кэшированные, собранные из ASIC.

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

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

Я не поощряю и не одобряю использование описанных ниже методов в любой несанкционированной сети (и я действительно имею в виду это: если вы хотите узнать, как получить GNS3, вот что это за весь поток :)! ).

Извините за длину этого ответа, но, несмотря на мои исследования, мне не удалось найти какой-либо удовлетворяющий ресурс в Интернете по этой теме. Большинство «доказательств концепций» смещены либо путем остановки на таблице CAM, заполняемой этапом, либо предполагающей, но никогда не демонстрирующей реакции коммутатора, или с помощью некоторых искусственных трюков, таких как очистка таблицы MAC-переключателя перед наводнением.

Моя цель — предоставить конкретные шаги, подходящие как для симуляции, так и для реальной среды, сосредоточив внимание на вопросах, связанных с виртуализацией GNS3 и распространенными неправильными подходами, и, самое главное, предоставить достаточную справочную информацию, чтобы понять, почему все так и есть они.

Для короткого ответа: да, атаки переполнения CAM могут быть смоделированы в GNS3 , однако это связано с несколькими требованиями:

• Зная, где лежат различия с реальными передачами,
• Понимание того, что вы действительно можете ожидать,
• Используя нужные инструменты,
• Исправить ошибку, которая в настоящее время влияет на dynamips (эмулятор маршрутизаторов Cisco за GNS3).

Теперь я возьму каждую из этих точек отдельно.

Зная, где лежит различие с реальными передачами

По соображениям производительности многие вещи коммутатора фактически не являются частью кода IOS, но реализованы в аппаратном обеспечении. Это включает в себя ARL или логику разрешения адресов , который предоставляет все методы для добавления, удаления и поиска записей в таблице MAC-адресов.

Поэтому, чтобы модуль NM-16ESW работал в GNS3, Dynamips пришлось переопределять все эти обычно предоставляемые аппаратным обеспечением услуги или, по крайней мере, проталкивать их достаточно далеко, чтобы позволить немодифицированной IOS работать на нем правильно.

Печально то, что это незавершенная работа, как указано в этом исходный код модуля :

Итак, вас предупреждают: как говорится в ответе uk ukasz, забудьте о QoS и ожидайте некоторых странностей.

Надеюсь, здесь мы не имеем дело с QoS, но с переполнением CAM, и кроме финальной ошибки (из которой исправление должно быть включено в какой-то будущий выпуск GNS3, я надеюсь) есть две основные странности, которые нас беспокоят: один влияет на размер таблицы MAC-адресов, а другой — на процесс старения MAC-адреса.

Первое различие: размер таблицы MAC-адресов превышает 8189 записей

Это была основная тема вашего вопроса, но на самом деле это не проблема.

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

Скорее всего, из-за незначительной ошибки, кажется, что таблица MAC считается полной на 8189 записей вместо 8192. Однако полная по-прежнему означает полную: ARLвсе равно не сможет сохранить какую-либо дополнительную запись, и атака переполнения CAM все равно будет успешной.

Второе отличие: установка aging-time не выполняется

По умолчанию записи MAC должны оставаться таблицей MAC-адресов не менее 5 минут (= 300 секунд), как определено установкой aging-time :

Однако в реальном режиме передачи весь процесс, стоящий за этим параметром, реализуется в аппаратном обеспечении, и этот параметр в настоящее время просто игнорируется реализацией Dynamips модуля NM-16ESW.

Dynamips реализует свою собственную систему сбора мусора, которая удаляет старые MAC-записи только через 30 секунд, что делает атаки CAM-переполнения более сложными для стабилизации (но может быть хорошей тренировкой против описанной функции «противодавления» по uk ukasz).

Код, который отвечает за это, можно найти по строке 2516 Файл dev_nm_16esw.c :

Запускает функцию bcm5600_arl_ager() каждые 15 секунд. Эта функция выполняет сканирование всей таблицы CAM и проверку флажка удара, связанного с каждым MAC-адресом:

• Если флаг установлен, отмените его,
• Если флаг не установлен, удалите MAC-адрес из таблицы.

Этот флаг снова включается всякий раз, когда коммутатор получает новый пакет с соответствующего MAC-адреса, сохраняя активные адреса в таблице.

Вы будете должны учитывать это поведение, чтобы спроектировать успешную атаку переполнения CAM:

• Использование только случайных MAC-адресов не сделает этого (извините macof . ), так как это позволит коммутатору очищать все фальшивые адреса каждые 30 секунд, делая эксплойт неустойчивым,
• Каждый MAC-адрес должен использоваться как отправитель не реже одного раза в 15 секунд,
• На самом деле из-за возможных проблем, вызванных повышенной нагрузкой, чтобы избежать потери одного или последующего пакета, вы предпочтете, чтобы каждый MAC-адрес использовался два или три раза менее чем за 15 секунд. И не думайте, что больше было бы полезно, и этого должно быть достаточно, чтобы ваш поток был стабильным и надежным, а таблицы CAM последовательно и постоянно заполнялись на всех коммутаторах на всей локальной сети.

Понимание того, что вы действительно можете ожидать

Как объясняется во введении, многие источники объясняют эту атаку тем, что «делает переключатель таким же, как хаб» . Хотя это хороший обзор для непрофессионала, это упрощенное описание является неправильным с технической точки зрения.

Чтобы понять, я вспомню, как коммутаторы работают при нормальных обстоятельствах, каков алгоритм, стоящий за ними, чтобы убедиться, что мы все на одной странице:

1. Коммутатор принимает входящий пакет на каком-то порту,
2. Затем коммутатор проверяет, сохранен ли MAC-адрес источника в таблице MAC-адресов. Если это не так и есть свободный слот, он записывает этот новый MAC-адрес, связанный с его входящим портом (и, кстати, если адрес уже присутствует, но связан с другим портом, он обновит запись новым портом) , Это также случай сброса таймера старения, связанного с этой записью, независимо от того, является ли он новым или нет.
3. Затем коммутатор проверяет, сохранен ли MAC-адрес назначения в таблице MAC-адресов. Если это так, то это все хорошо, и коммутатор выводит пакет на интерфейс, связанный с соответствующей записью таблицы CAM. Если это не так, коммутатор выдает пакет на всех интерфейсах, кроме входящего (все интерфейсы, принадлежащие тем же портам VLAN +, если эта VLAN не обрезана).

Теперь давайте посмотрим, каккоммутатор работает, когда условие переполнения CAM было запущено, и он отступил в так называемый режим «hub» . На самом деле все это просто абсурд: нет режима концентратора и переполнения CAM ничего не вызвало. Коммутатор продолжает работать, как всегда:

1. При входящих пакетах тогда и только тогда, когда исходный MAC-адрес отсутствует в таблице, переполнение CAM будет иметь какой-либо эффект, поскольку у коммутатора не будет свободного слота, чтобы добавить этот новый, и будет поэтому пропустите этот шаг. Если адрес уже присутствует в таблице, коммутатор, как обычно, сбросит свой стареющий таймер.
2. В исходящих пакетах , если и только если MAC-адрес назначения отсутствует в таблице, коммутатор действительно отправит пакет через «все» его интерфейсов. Если MAC-адрес присутствует в таблице, у коммутатора нет никаких причин действовать странно: он будет просто действовать как обычно и отправлять пакет только через порт, связанный с MAC-адресом.

Основные последствия этого:

• Несмотря на то, что часто говорят, атаки переполнения CAM не являются волшебным способом превратить коммутаторы в концентраторы. Вы отправите not весь трафик, проходящий через коммутатор.
• Вы можете not прослушивать любое уже активное сообщение (то есть любое сообщение, инициированное до начала наводнения MAC). MAC-адрес устройства будет уже известен коммутатору, и законные пакеты будут регулярно перезагружать счетчики старения коммутатора. Независимо от того, насколько сильно вы наводнили его, MAC-адреса этих устройств будут оставаться в таблице CAM коммутатора, и коммутатор будет перенаправлять трафик только на соответствующие порты.
• Скорее всего, вы сможете подслушивать только одностороннее сообщение с маршрутизатора на ранее неактивные устройства (например, в выключенном режиме или в спящем режиме). В сценариях реального мира, по крайней мере, в рабочее время коммутатор почти постоянно будет иметь MAC-адрес маршрутизатора в своей таблице CAM, поскольку через него будет проходить любой трафик в сети и, следовательно, обновить таймер старения. Поэтому основной целью наводнения MAC будет сохранение ранее неактивных устройств от успешного регистрации их MAC-адреса также на коммутаторе. Чтобы дать конкретный пример результата, большинство шансов заключается в том, что вы не сможете подслушать пароль и запросы пользователя, но вы сможете получить предоставленные сервером идентификаторы сеанса и данные.
• Но для того, чтобы закончить с унылой новостью, то, что вы достигнете, состоит в том, что, если вы позаботитесь не перегружать коммутаторы, они с радостью переадресуют ваши пакеты наводнения с коммутатора на коммутатор, пока они не загрязнят целая ЛВС уровня 2. Только обрезание VLAN или устройство уровня 3 в пути ограничили бы это распространение, даже если бы даже коммутаторы, предлагающие только несвязанные порты VLAN, увидели бы, что их таблица CAM будет заполнена. Другими словами, в зависимости от сведений о топологии, запускающих атаку из VLAN 2, вы можете получить доступ к трафику VLAN 2, пересылаемому с нескольких коммутаторов, а также может повлиять на поведение переключателей VLAN 3.

Использование нужного инструмента

Инструмент, классически рекомендуемый для атак переполнения таблицы CAM, — macof (из dsniff , который не используется в течение многих лет). Однако этот инструмент делает меня результатом примитивного варвара из какой-то фантастической истории: жестокой, неэффективной и ненадежной.

Этот инструмент генерирует пакеты, используя полностью случайные MAC-адреса, созданные на лету. Это неверно по двум причинам:

Как мы видели выше, каждый неактивный MAC-адрес автоматически удаляется из таблицы CAM, временно освобождая большое количество слотов, доступных для записи подлинных MAC-адресов, пока нам не удастся снова заполнить таблицу (что может занять несколько раз, если цель — несколько отключений). И, как мы также видели, достаточно одного подлинного пакета для обновлениятаблицу CAM с достоверной информацией и окончательно положить конец нашему подслушиванию этой конкретной цели.

Статистически половина случайных сгенерированных MAC-адресов имеет набор бит I /G группы . Однако в качестве отправителя запрещено использовать групповой MAC-адрес, как указано в IEEE 802.3 -2002, раздел 3.2.3 (b) :

В поле «Исходный адрес» первый бит зарезервирован и установлен в 0.

Коммутаторы Cisco (как минимум) знают об этом и рассматривают такие пакеты как неверные и отбрасывают их. Это означает, что половина пакетов, сгенерированных с помощью macof , отбрасывается первым переключателем, с которым они сталкиваются.

macof также использует стратегию грубой силы, отправляя свои вредоносные пакеты так же быстро, как это делает устройство злоумышленника и сеть. Это вызывает ряд проблем:

• В процессе наводнения могут возникать сбои или даже сбой в работе (я столкнулся с несколькими сообщениями о том, что во время такого наводнения была заблокирована плоскость управления коммутатором),
• Из-за нагрузки, вызванной со стороны коммутатора, эти пакеты не могут быть надежно переданы от коммутатора к коммутатору, в результате чего только первый переключатель с переключателем-злоумышленником может эффективно перекрыть свою таблицу CAM,
• Из-за нагрузки на стороне злоумышленника либо сетевая связь полностью перегружена, либо использование ЦП полностью отключается. Во всех случаях невозможно захватить какой-либо трафик с того же устройства, что печально, так как захват трафика является целью этой атаки. Обычным советом является прекращение наводнения при захвате и чередование между наводнениями и захватом на регулярной основе (каждую минуту, например, с учетом старения по умолчанию в течение 5 минут на реальных передачах, а в отношении 30 минут Dynamips это становится просто безнадежным). Я бы также посоветовал иметь достаточно удачи, чтобы действительно захватить, когда была обменяна интересная информация, и достаточно удачи, чтобы иметь возможность правильно противостоять периодической очистке таблицы MAC, которая кажется довольно неосуществимой в таких условиях.

Хороший инструмент атаки переполнения CAM должен:

• Не используйте больше ресурсов, чем необходимо, чтобы обеспечить надежную подслушивание,
• Создавайте хорошо сформированные пакеты (т. е. бесполезные пакеты, которые все равно будут упакованы, и никакие пакеты, которые заставят Wireshark (или IDS . ) жаловаться),
• Убедитесь, что таблицы CAM остаются постоянными, поэтому новые устройства не смогут зарегистрировать свой MAC-адрес.

macof не работает по этим трем требованиям и поэтому не является подходящим инструментом. Быстрый поиск не выявил какой-либо подходящей альтернативы, поэтому я отправил маршрут Scapy (Scapy — это Python и интерактивный инструмент, позволяющий свободно создавать и управлять сетевыми пакетами).

Вот код, который я использовал для успешного тестирования переполнения таблицы CAM в среде GNS3:

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

Исправить ошибку, влияющую на динамику

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

Это связано с ошибкой, влияющей на функцию bcm5600_handle_rx_pkt() , отвечающую за обработку полученных пакетов и расположенную по строке 2170 dev_nm_16esw.c файл:

В настоящее время, когда ARL не удалось сохранить новый MAC-адрес, обработка входящего прерывается, что фактически приводит к падению пакета. Исправление состоит в том, чтобы просто игнорировать статус ARL и продолжать обработку пакета в любом случае, так как это реально делает реальная передача:

Я поднял эту проблему на команды GNS3, чтобы его можно было зафиксировать в GNS3 будущие обновления. Я также отстаивал повышение тайм-аута сбора мусора таблицы MAC с текущих 15 секунд до 5 минут чтобы быть ближе к реальному поведению механизма.

До тех пор, пока это не будет исправлено вверху, оно требует ручной модификации и перекомпиляции исходного кода Dynamips, но это очень быстрый и простой процесс (нет необходимости перекомпилировать весь GNS3, только dynamips бинарный, и я предоставил патчи в упомянутых выше билетах).

После этого вы сможете протестировать и повторить атаки переполнения MAC-адресов в GNS3 с помощью переключателей на основе маршрутизатора стабильным и предсказуемым образом.

Вот две последние заметки:

В то время как коммутаторы на основе маршрутизатора позволяют тестировать атаки переполнения CAM, они не позволят протестировать надлежащие методы смягчения, поскольку они не реализуют безопасность портов. Я думаю, что это ограничение от IOS, а не GNS3, поскольку соответствующие опции даже не предотвращают в оболочке. IOU предлагает эти варианты, однако из-за таблицы CAM, позволяющей почти 200 миллионов записей (по сравнению с 8192 реальной IOS), это кажется недоступным для традиционной атаки переполнения CAM. Таким образом, IOU находится напротив коммутаторов на основе маршрутизаторов: их можно использовать для тестирования методов смягчения, но не для воспроизведения атаки. Имейте в виду также, что реализация IOU протокола Spanning Tree Protocol (STP) сильно затруднена, и избегать циклов топологии.

Говоря о STP и в зависимости от топологии, став STP Root ( yersinia stp -attack 4 )должен вызывать очистку большинства динамических записей таблиц MAC из-за изменения топологии и может обеспечить более эффективный процесс наводнения и перехвата;).

Какие меры безопасности эффективны для предотвращения атак путем переполнения таблицы cam

В данном документе представлены сведения об устранении проблем, связанных с протоколом разрешения адресов (ARP) и таблицами ассоциативно-запоминающего устройства (CAM) коммутаторов Catalyst 6500/6000.

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к устройству или какой-либо версии ПО.

Условные обозначения

Дополнительную информацию об используемых в документе обозначениях см. в разделе Условные обозначения, используемые в технической документации Cisco.

Общие сведения

Коммутаторы Catalyst поддерживают несколько типов таблиц для коммутации уровня 2 и многоуровневой коммутации (MLS), которые хранятся в очень быстрой памяти, благодаря чему возможно параллельное сравнение нескольких полей внутри одного кадра или пакета.

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

CAM — во всех моделях коммутаторов Catalyst используется таблица CAM для коммутации уровня 2. Когда кадры поступают на порты коммутатора, MAC-адрес источника запоминается и записывается в таблицу CAM. Порт, на который были получены кадры, и сеть VLAN записываются в таблице вместе с меткой времени. Если MAC-адрес, изученный одним портом коммутатора, был перемещен на другой порт, записывается MAC-адрес и метка времени того порта, который получил кадры последним. Предыдущая запись удаляется. Если MAC-адрес для правильного приемного порта уже содержится в таблице, то обновляется только метка времени.

Троичное ассоциативное запоминающее устройство (TCAM) — в многоуровневой коммутации все процессы, использующие списки управления доступом (ACLs), работающие для обычной маршрутизации, такие как согласование, фильтрация или управление специальным трафиком, работают на аппаратном уровне. TCAM позволяет выполнить оценку пакета в отношении всего списка доступа при поиске в одной таблице. В большинстве коммутаторов имеется несколько устройств TCAM, таким образом, безопасность входящего и исходящего трафика и QoS на базе списков ACL могут оцениваться одновременно или параллельно с принятием решения о передаче на уровне 2 или 3.

Устранение проблем, связанных с ARP и CAM

Потеря динамических MAC-адресов при распределенной коммутации

При распределенной коммутации каждая плата распределенных функций (DFC; Distributed Feature Card) отвечает за управление собственной таблицей CAM. Это означает, что каждая DFC запоминает MAC-адрес и определяет время устаревания адресов, которое зависит от времени устаревания CAM и согласования трафика с конкретной записью. При распределенной коммутации модуль supervisor engine некоторое время не видит трафик для конкретного MAC-адреса и адрес может устареть. Существует два механизма для сохранения согласованности таблиц CAM разных модулей, таких как DFC (встроенных в линейные модули) и плат функций политики PFC; Policy Feature Card (встроенных в модули supervisor):

Лавинная передача на матрицу (Flood-to-Fabric, FF)

MAC-уведомление (MAC Notification, MN)

Если запись MAC-адреса на PFC устарела, обнаружить DFC или PFC, на которых она содержится, можно с помощью команды show mac-address address <MAC-адрес> all.

Чтобы предотвратить устаревание записи на DFC и PFC даже при отсутствии трафика на эти MAC-адреса, необходимо включить синхронизацию MAC-адресов. Для включения синхронизации воспользуйтесь командой глобальной конфигурации mac-address-table synchronize.

Внимание. Команда mac-address-table synchronize удаляет маршрутизируемые MAC-записи. Чтобы избежать этого, отключите удаление маршрутизируемых MAC с помощью команды глобальной конфигурации mac-address-table aging-time 0 routed-mac. Маршрутизируемые MAC-записи представляют собой MAC-адреса, которые запоминаются коммутатором на уровне физического маршрутизируемого интерфейса.

CEF отбрасывает пакеты через определенные промежутки времени

Скоростная маршрутизация Cisco (Cisco Express Forwarding, CEF) представляет собой технологию коммутации IP уровня 3, которая обеспечивает более высокую производительность по сравнению с другими технологиями коммутации, особенно в сетях с изменяющимися потоками трафика. CEF управляет структурами данных: базой данных передачи (Forwarding Information Base, FIB) и таблицами смежности. Таблица FIB зеркально отражает данные таблицы маршрутизации и используется для принятия решений о передаче. В таблице смежности содержится предварительно вычисленный заголовок канального уровня для устройства на следующем узле. На основании интерфейса следующего узла, записи в таблице FIB сопоставляются с записями таблицы смежности. Устройство не сможет выполнить CEF-коммутацию пакетов, если необходимые данные не внесены в таблицу смежности.

Если при CEF наблюдается отбрасывание пакетов через равные промежутки времени, в течение которых сохраняется нормальная функциональность, то, скорее всего, причиной является периодическое удаление всех данных в таблице смежности. Это происходит из-за устаревания записи ARP. Во время повторного внесения данных следующего узла в таблицу смежности, пересылка пакетов в режиме CEF не выполняется. Поскольку записи ARP по умолчанию обновляются каждые четыре часа, установка слишком малого значения для времени ожидания ARP может иметь отрицательные последствия для выполнения CEF.

Чтобы изменить значение времени, в течение которого запись сохраняется в кэше ARP, воспользуйтесь командой arp timeout в режиме конфигурации интерфейса.

Дополнительные сведения см. в описании ошибки CSCeb53542 ( только для зарегистрированных пользователей ). Дополнительные сведения о смежности CEF см. в разделе Устранение неполных смежностей в CEF.

Фильтрация коммутатором нулевых MAC-адресов таблицы CAM

Коммутатор фильтрует кадры, полученные от источника с MAC-адресом 00-00-00-00-00-00, который является недопустимым исходным MAC, для таблицы CAM. Ниже приведен пример выходных данных системного журнала в случае появления данной ошибки:

Эти данные сообщают об обнаружении кадра, полученного от источника с MAC-адресом 00-00-00-00-00-00 и о том, что данный адрес ни при каких условиях не будет добавлен в таблицу CAM. Тем не менее, коммутатор будет продолжать пересылку трафика, полученного из источника с нулевым MAC-адресом.

В качестве временного решения проблемы можно определить конечную станцию, которая генерирует кадры с нулевым исходным MAC-адресом. Обычно одно из этих устройств передает подобные кадры:

Генератор трафика, такой как Spirent SmartBits

Некоторые типы серверов, такие как распределяющие нагрузку серверы IBM WebSphere

Неправильно настроенный маршрутизатор или оконечная рабочая станция, т.е. устройство, передающее нулевые пакеты

Возникновение одноадресной лавинной передачи в сети каждые 5 минут

Коммутаторы LAN используют таблицы пересылки, такие как таблицы уровня 2 и таблицы CAM, для направления трафика к определенным портам на основании номеров VLAN и MAC-адреса назначения кадра. Если нет ни одной записи, которая относится к MAC-адресу назначения кадра во входящей VLAN, (одноадресный) кадр направляется на все порты пересылки в пределах соответствующей VLAN. В результате возникает лавинная передача. Истинная причина лавинной передачи заключается в том, что MAC-адрес назначения пакета не содержится в таблице пересылки уровня 2 коммутатора. В этом случае происходит лавинная передача пакетов со всех портов пересылки в пределах его VLAN, кроме порта, на котором он был получен.

Время устаревания таблицы ARP по умолчанию равно 4 часам, в то время как таблица CAM хранит записи только 5 минут. Коммутатор отправляет кадр всем портам пересылки в пределах соответствующей VLAN тогда, когда MAC-адрес назначения в таблице CAM устарел. Чтобы предотвратить одноадресную лавинную передачу, необходимо установить значение таймера устаревания CAM больше или равное времени таймаута ARP. Для решения данной проблемы используйте одну из перечисленных ниже команд, чтобы увеличить время устаревания CAM для той сети VLAN, в которой наблюдается несоответствие времени ожидания ARP:

Примечание. Рекомендуется синхронизировать таймеры CAM и ARP в любой среде Catalyst, использующей протокол маршрутизатора горячего резервирования (Hot Standby Router Protocol, HSRP).

Дополнительные сведения о возможных причинах и следствиях одноадресной лавинной передачи в коммутируемых сетях см. в разделе Одноадресная лавинная передача в коммутируемых кампусных сетях.

Проблемы при использовании ARP в гибридной CatOS

В гибридном режиме модуль управления Supervisor Engine работает под CatOS, а плата с функцией многоуровневого коммутатора (Multilayer Switch Feature Card, MSFC) управляется Cisco IOS. CatOS работает на уровне 2 и создает таблицу адресов CAM для хранения данных о VLAN, MAC-адресах и номерах портов. Cisco IOS на MSFC работает на уровне 3 и создает таблицу ARP, в которой содержится IP-адрес для разрешения MAC-адреса. При изменении IP-адреса любого устройства, например, принтера или сервера, не всегда удается успешно отправить запрос "ICMP-эхо" этому устройству по новому IP-адресу. Тем не менее, сохраняется возможность отправить запрос "ICMP-эхо" по новому IP-адресу из той же VLAN. Такая ситуация является результатом проблемы с ARP на плате MSFC.

В качестве временного решения можно сделать следующее:

Удалить все данные из таблицы ARP на плате MSFC.

Проверить время таймаута ARP. Его значение по умолчанию — 4 часа. Если время таймаута ARP в данной VLAN большое, измените его значение на используемое по умолчанию или другое оптимальное значение.

Ошибка EARL-2-EARL4LOOKUPRAMERROR при выполнении поиска в таблице CAM

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки:

Это происходит при выполнении поиска в таблице CAM. Причиной данного явления является ошибка четности при получении доступа к памяти. Ошибка обычно происходит после ввода команды show cam с целью получения доступа к таблице CAM. В некоторых случаях выполнение команды show cam приводит к перезапуску коммутатора.

Это сообщение об ошибке свидетельствует об обнаружении ошибки четности при поиске в ОЗУ. Адрес, который отображается в поле [hex] — это адрес в таблице пересылки, где была обнаружена ошибка. Данные поля [hex]-[hex]-[hex]-[hex] — это данные ОЗУ word0, word1, word2 и word3, которые вызвали ошибку четности. Значение счетчика в поле [dec] показывает количество всех ошибок четности.

Ситуация, о которой сигнализирует данное сообщение об ошибке, не является угрожающей и не приведет к падению производительности сети, тем более, если возникает от случая к случаю. Если данное сообщение об ошибке появляется постоянно, это свидетельствует о попытках коммутатора произвести новую запись в таблице CAM в неисправном секторе динамического ОЗУ. В этом случае необходимо заменить динамическое ОЗУ или весь модуль управления.

Потеря статических записей CAM после переключения модуля управления

При быстром переключении модуля управления происходит потеря статических записей CAM, сформированных в активном модуле управления. Данную проблему можно обойти с помощью повторного формирования записей CAM после быстрого переключения.

Дополнительные сведения см. в описании ошибки CSCed87627 ( только для зарегистрированных пользователей ) и CSCee27955 ( только для зарегистрированных пользователей ).

%ACL-5-TCAMFULL: Переполнение таблицы TCAM модуля acl

При попытке добавить новые списки управления доступом (ACL) или внести записи управления доступом (ACE) в уже существующие ACL, не удается выполнить фиксацию или отображение, если таблица TCAM заполнена. Функциональность любой предыдущей конфигурации сохраняется. Если используются списки управления доступом маршрутизатора (Router Access Control List, RACL), то программное обеспечение платы MSFC принудительно использует ACL, что вызывает соответствующее снижение производительности.

Если на коммутаторе установлено гибридное ПО, то при настройке списка управления доступом VLAN (VACL) или записей ACE в списках ACL QoS, которые превышают размер шаблона или маски TCAM, на консоли отображается следующее сообщение системного журнала:

В системах Supervisor IOS или на плате MSFC в гибридной системе при выполнении конфигурации записей ACE в списках RACL, превышающих вместимость TCAM, на консоли отображается примерно следующее сообщение системного журнала:

В системах IOS Supervisor или на плате MSFC в гибридной системе выполните команду show fm summary, чтобы просмотреть, какие именно интерфейсы принуждают ACL в аппаратном обеспечении (ACTIVE), а какие — в программном обеспечении (INACTIVE).

В качестве временного решения проблемы удалите неиспользуемые списки ACL или QoS в конфигурации коммутатора. Дополнительные сведения см. в разделе Общие сведения об ACL в коммутаторах серии Catalyst 6500.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.