Надеюсь, что кто-то из присутствующих может иметь представление о проблеме, с которой мы сталкиваемся. В настоящее время у нас есть центр технической поддержки Cisco, изучающий этот случай, но они не могут найти первопричину.
Хотя в названии упоминается широковещательная передача ARP и высокая загрузка ЦП, мы не уверены, связаны они или не связаны на данном этапе.
Первоначальный выпуск был размещено в Интернет-сообществе INE
Мы сократили сеть до одного канала без резервирования, представьте это как звездообразную топологию.
Факты:
Симптомы в сети и коммутаторах:
#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
12 111438973 18587995 5995 44.47% 43.88% 43.96% 0 ARP Input
174 59541847 5198737 11453 22.39% 23.47% 23.62% 0 Hulc LED Process
221 7253246 6147816 1179 4.95% 4.25% 4.10% 0 IP Input
86 5459437 1100349 4961 1.59% 1.47% 1.54% 0 RedEarth Tx Mana
85 3448684 1453278 2373 1.27% 1.04% 1.07% 0 RedEarth I2C dri
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 001c.c06c.d620 DYNAMIC Gi1/1/3
1 001c.c06c.d694 DYNAMIC Gi1/1/3
1 001c.c06c.d6ac DYNAMIC Gi1/1/3
1 001c.c06c.d6e3 DYNAMIC Gi1/1/3
1 001c.c06c.d78c DYNAMIC Gi1/1/3
1 001c.c06c.d7fc DYNAMIC Gi1/1/3
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 6364/6364 1165/1165
IPv4 IGMP groups + multicast routes: 1120/1120 1/1
IPv4 unicast directly-connected routes: 6144/6144 524/524
IPv4 unicast indirectly-connected routes: 2048/2048 77/77
IPv4 policy based routing aces: 452/452 12/12
IPv4 qos aces: 512/512 21/21
IPv4 security aces: 964/964 45/45
Сейчас мы находимся на стадии, когда нам потребуется огромное количество времени простоя, чтобы изолировать каждую область за раз, если только у кого-то еще не появятся идеи для определения источника или основной причины этой странной и причудливой проблемы.
Спасибо @MikePennington и @RickyBeam за подробный ответ. Я постараюсь ответить, что смогу.
«Так как вы получаете большое количество MAC-адресов между портами коммутатора, трудно найти, где находятся нарушители (предположим, вы найдете два или три MAC-адреса, которые отправляют много arps, но исходные MAC-адреса продолжают колебаться между портами)».
Мы (Cisco TAC, CCIEs, CCNP) во всем мире согласны с тем, что проблема возникает не из-за конфигурации коммутатора, а из-за хоста / устройства.
Проблема связана с SCCM 2012 SP1, службой под названием: Прокси-сервер пробуждения ConfigMrg. Эта «функция» не существует в SCCM 2012 RTM.
В течение 4 часов после отключения этого параметра в рамках политики мы наблюдали устойчивое снижение использования ЦП. К тому времени, когда прошло 4 часа, использование ARP составило всего 1-2%!
Таким образом, эта служба выполняет подделку MAC-адресов! Не могу поверить, сколько разорения это вызвало.
Ниже приводится полный текст из Microsoft Technet, так как я считаю важным понять, как это связано с опубликованной проблемой.
Для всех, кому интересно, ниже приведены технические подробности.
Configuration Manager поддерживает две технологии пробуждения по локальной сети (LAN) для вывода компьютеров из спящего режима, когда вы хотите установить необходимое программное обеспечение, например обновления программного обеспечения и приложения: традиционные пакеты пробуждения и команды включения питания AMT.
Начиная с Configuration Manager SP1, вы можете дополнить традиционный метод пакета пробуждения, используя настройки клиента прокси-сервера пробуждения. Прокси-сервер пробуждения использует протокол одноранговой сети и выбранные компьютеры, чтобы проверить, активны ли другие компьютеры в подсети, и при необходимости разбудить их. Когда сайт настроен для пробуждения по локальной сети, а клиенты настроены для пробуждения прокси, процесс работает следующим образом:
Компьютеры, на которых установлен клиент Configuration Manager с пакетом обновления 1 (SP1) и которые не находятся в спящем режиме в подсети, проверяют, активны ли другие компьютеры в подсети. Они делают это, отправляя друг другу команду ping TCP / IP каждые 5 секунд.
Если нет ответа от других компьютеров, предполагается, что они спят. Компьютеры, которые не спят, становятся управляющими компьютерами для подсети.
Поскольку компьютер может не отвечать по другой причине, кроме того, что он спит (например, он выключен, удален из сети или настройка прокси-клиента пробуждения больше не применяется), компьютеры не работают. отправлял пакет будильника каждый день в 14:00 местное время. Компьютеры, которые не отвечают, больше не будут считаться спящими и не будут разбужены прокси-сервером пробуждения.
Для поддержки пробуждающего прокси-сервера в каждой подсети должны быть активны не менее трех компьютеров. Для этого три компьютера недетерминированно выбираются в качестве компьютеров-хранителей для подсети. Это означает, что они не спят, несмотря на любую настроенную политику энергопотребления для перехода в спящий или спящий режим после периода бездействия. Компьютеры Guardian соблюдают команды выключения или перезапуска, например, в результате задач обслуживания. Если это произойдет, оставшиеся компьютеры-хранители активируют другой компьютер в подсети, чтобы в подсети по-прежнему было три компьютера-хранителя.
Компьютеры-менеджеры просят сетевой коммутатор перенаправить сетевой трафик для спящих компьютеров на себя.
Перенаправление осуществляется управляющим компьютером, транслирующим кадр Ethernet, который использует MAC-адрес спящего компьютера в качестве адреса источника. Это заставляет сетевой коммутатор вести себя так, как если бы спящий компьютер переместился на тот же порт, что и управляющий компьютер. Управляющий компьютер также отправляет пакеты ARP для спящих компьютеров, чтобы сохранить запись в кэше ARP. Управляющий компьютер также будет отвечать на запросы ARP от имени спящего компьютера и сообщать MAC-адрес спящего компьютера.
Во время этого процесса сопоставление IP-адресов и MAC-адресов спящего компьютера остается прежним. Прокси-сервер пробуждения информирует сетевой коммутатор о том, что другой сетевой адаптер использует порт, зарегистрированный другим сетевым адаптером. Однако такое поведение известно как сброс MAC-адресов и необычно для стандартных сетевых операций. Некоторые инструменты сетевого мониторинга ищут такое поведение и могут предположить, что что-то не так. Следовательно, эти инструменты мониторинга могут генерировать предупреждения или отключать порты при использовании прокси-сервера пробуждения. Не используйте прокси-сервер пробуждения, если ваши инструменты и службы сетевого мониторинга не допускают сброса MAC-адресов.
Когда управляющий компьютер видит новый запрос на TCP-соединение для спящего компьютера, и этот запрос направлен на порт, который спящий компьютер прослушивал перед переходом в спящий режим, управляющий компьютер отправляет пакет пробуждения спящему компьютеру, а затем перестает перенаправлять трафик для этого компьютера.
Спящий компьютер получает пакет пробуждения и просыпается. Передающий компьютер автоматически повторяет попытку подключения, и на этот раз компьютер не спит и может ответить.
Спасибо всем, кто разместил здесь и помогал в процессе устранения неполадок, очень признателен.
- Мы видим большие широковещательные пакеты из VLAN 1, VLAN 1, используемых для настольных устройств. Используем 192.168.0.0/20 ...
- Wiresharks показывает, что сотни компьютеров наводняют сеть широковещательной передачей ARP ...
У вас высокий процесс ввода ARP, что означает, что коммутатор тратит много времени на обработку ARP. Одна из очень частых причин лавинной передачи ARP - это петля между вашими коммутаторами. Если у вас есть петля, вы также можете получить откидные створки Mac, о которых вы упомянули выше. Другие возможные причины ARP-наводнений:
Во-первых, устраните возможность неправильной конфигурации или упомянутой выше атаки уровня 2. Самый простой способ сделать это - использовать arpwatch на Linux-машине (даже если вам нужно использовать livecd на ноутбуке). Если у вас неправильная конфигурация или атака на уровне 2, то arpwatch выдает вам подобные сообщения в системном журнале, в которых перечислены MAC-адреса, которые борются за один и тот же IP-адрес ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)
Когда вы видите «шлепки», вам нужно отследить источник MAC-адресов и выяснить, почему они борются из-за одного и того же IP-адреса.
- Большое количество откидных створок МАП
- Связующее дерево было проверено специалистами Cisco TAC и CCNP / CCIE. Мы отключаем все избыточные ссылки.
Говоря как человек, который проходил через это больше раз, чем мне хотелось бы вспомнить, не думайте, что вы нашли все избыточные ссылки ... просто заставьте ваши коммутаторы работать постоянно.
Поскольку вы получаете большое количество клапанов Mac между портами коммутатора, трудно найти, где находятся нарушители (предположим, вы найдете два или три MAC-адреса, которые отправляют много arps, но исходные MAC-адреса продолжают колебаться между портами). Если вы не устанавливаете жесткое ограничение для MAC-адресов на граничный порт, очень сложно отследить эти проблемы, не отключая кабели вручную (чего вы хотите избежать). Петли коммутатора вызывают неожиданный путь в сети, и вы можете столкнуться с сотнями компьютеров Mac, которые периодически обучаются через порт коммутатора рабочего стола.
Самый простой способ замедлить движение Mac - это port-security. На каждом порте коммутатора доступа в Vlan 1, который подключен к одному ПК (без коммутатора нисходящего потока), настройте следующие команды уровня интерфейса на коммутаторах cisco ...
switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!! Beware of people with VMWare / hubs under their desk, because
!! "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a
!! couple of desktop ports
spanning-tree bpduguard enable
В большинстве случаев лавинной рассылки Mac / ARP применение этой конфигурации ко всем портам вашего граничного коммутатора (особенно с портами portfast) вернет вас в нормальное состояние, потому что конфигурация отключит любой порт, который превышает три MAC-адреса, и тайно отключит замкнутый порт Portfast. Три Mac на порт - это число, которое хорошо работает в моей среде рабочего стола, но вы можете увеличить его до 10 и, вероятно, все будет в порядке. После того, как вы это сделаете, любые петли слоя 2 будут разорваны, быстрые лоскуты Mac прекратятся, и это значительно облегчит диагностику.
Еще пара глобальных команд, которые полезны для отслеживания портов, связанных с широковещательным штормом (mac-move) и наводнением (порог) ...
mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900
После того как вы закончите, при желании выполните clear mac address-table для ускорения исцеления от потенциально полной таблицы CAM.
- Ran показывает таблицу MAC-адресов на разных коммутаторах и самом ядре (например, на ядре, подключенном напрямую к рабочему столу, на моем рабочем столе), и мы можем видеть несколько разных аппаратных MAC-адресов, зарегистрированных в интерфейсе, даже если этот интерфейс имеет к этому подключен только один компьютер ...
Весь этот ответ предполагает, что на вашем 3750 нет ошибки, вызывающей проблему (но вы сказали, что wirehark указывал на компьютеры, которые переполняются). То, что вы показываете нам, очевидно, неверно, если к Gi1 / 1/3 подключен только один компьютер, если только на этом ПК не установлено что-то вроде VMWare.
Судя по нашему чату, мне, вероятно, не нужно упоминать очевидное, но я сделаю это для будущих посетителей ...
Настоящий вопрос заключается в том, почему хосты вообще отправляют так много ARP. До тех пор, пока на него не будет дан ответ, коммутатору (-ам) по-прежнему будет трудно справляться с arp storm. Несоответствие сетевой маски? Таймеры low host arp? Один или больше) хозяева имея "интерфейсный" маршрут? Беспроводной мост Rouge где-нибудь? "беспричинный арп" сошел с ума? Зондирование «используемого» DHCP-сервера? Это не похоже на проблему с переключателями или уровнем 2; у вас есть хозяева, которые делают плохие вещи.
Мой процесс отладки будет отключать все и внимательно следить за тем, как что-то снова подключается, по одному порту за раз. (Я знаю, что это далеко от идеала, но в какой-то момент вам придется сократить свои потери и попытаться физически изолировать любой возможный источник (-ы)) Затем я буду работать над тем, чтобы понять, почему выбранные порты генерируют много arp.
(Многие из этих хостов оказываются системами Linux? У Linux была чертовски глупая система управления кешем ARP. Тот факт, что она будет «повторно проверять» запись за считанные минуты, в моей книге нарушен. В небольших сетях это обычно не проблема, но / 20 - это не маленькая сеть.)
Это может быть связано или не быть связано с вашей проблемой, однако я подумал, что это может быть что-то, что стоит хотя бы выбросить туда:
В настоящее время у нас есть довольно много стеков 3750x на некоторых из наших удаленных сайтов, в основном работающих под управлением 15.0.2 (с SE0 по 4, есть некоторые ошибки FRU с SE0, с которых я медленно ухожу).
Во время обычного обновления IOS, переходящего с 15.0.2 на 15.2-1 (самая последняя версия SE), мы заметили довольно значительное увеличение ЦП, в среднем с 30% до 60% и выше в непиковое время. Я просмотрел конфигурации и журналы изменений IOS и работал с Центром технической поддержки Cisco. Согласно TAC, они, похоже, достигли той точки, где считают, что это какая-то ошибка IOS 15.2-1.
По мере того как мы продолжали исследовать увеличение ЦП, мы начали замечать огромные объемы ARP-трафика до точки, когда наши ARP-таблицы полностью заполнялись и вызывали нестабильность сети. Временный костыль для этого заключался в том, чтобы вручную вернуть время ожидания ARP с значения по умолчанию (14400) до 300 в наших виртуальных локальных сетях для голоса и данных.
После сокращения времени ожидания ARP мы были стабильны около недели, после чего вернулись к IOS 15.0.2-SE4 и удалили нестандартные значения времени ожидания ARP. Наша загрузка ЦП снова снизилась до ~ 30%, и проблем с нашей таблицей ARP не существует.
Довольно простой, но его можно упустить; есть ли у ваших клиентов действующий шлюз по умолчанию, разве вы не делаете много прокси-аргументов. Вы могли бы подумать об отключении функции arp ip proxy на вашем 3750?