ARP широковещательная сеть и высокая загрузка ЦП

Надеясь, что кто-то здесь может иметь некоторое представление о проблеме, с которой мы сталкиваемся. В настоящее время у нас есть Центр технической поддержки Cisco, рассматривающий дело, но они изо всех сил пытаются найти основную причину.

Хотя в заголовке упоминается трансляция ARP и высокая загрузка ЦП, мы не уверены, связаны ли они на данном этапе или нет.

Оригинальный номер был опубликован в онлайн-сообществе INE.

Мы сократили сеть до единого канала без установки резервирования, представьте, что это топология типа «звезда».

Факты:

• Мы используем 3750x коммутаторы, 4 в одном стеке. Версия 15.0 (1) SE3. Центр технической поддержки Cisco подтверждает отсутствие известных проблем для ошибок центрального процессора или ARP для этой конкретной версии.
• Нет подключенных концентраторов / неуправляемых коммутаторов
• Перезагрузка ядра
• У нас нет маршрута по умолчанию «Ip route 0.0.0.0 0.0.0.0 f1 / 0». Использование OSPF для маршрутизации.
• Мы видим большие широковещательные пакеты от VLAN 1, VLAN 1, используемые для настольных устройств. Мы используем 192.168.0.0/20
• Центр технической поддержки Cisco сказал, что они не видят ничего плохого в использовании / 20, иначе у нас был бы большой широковещательный домен, но он все еще должен функционировать.
• Wi-Fi, управление, принтеры и т. Д. Находятся на разных VLAN
• Связующее дерево было проверено квалифицированными специалистами Cisco TAC и CCNP / CCIE. Мы отключаем все избыточные ссылки.
• Конфигурация на ядре была проверена Cisco TAC.
• У нас есть тайм-аут ARP по умолчанию на большинстве коммутаторов.
• Мы не реализуем вопросы и ответы.
• Новые переключатели не были добавлены (по крайней мере, мы не знаем о них)
• Невозможно использовать динамический контроль arp на граничных переключателях, потому что это 2950
• Мы использовали шоу интерфейсы | inc line | broadcast, чтобы выяснить, откуда поступает большое количество широковещательных сообщений, однако Cisco TAC и 2 других инженера (CCNP и CCIE) подтвердили, что это нормальное поведение из-за того, что происходит в сети (например, при большом количестве закрытий mac) вызывая большую трансляцию). Мы убедились, что STP правильно работает на граничных переключателях.

Симптомы в сети и коммутаторах:

• Большое количество закрылков MAC
• Высокая загрузка ЦП для процесса ввода ARP
• Огромное количество пакетов ARP, быстро увеличивающихся и видимых
• Wiresharks показывает, что сотни компьютеров наводняют сеть ARP Broadcast
• Для целей тестирования мы поставили около 80 настольных компьютеров с разными vlan, однако мы проверили это и не заметили никакой разницы с высоким входом процессора или arp
• Были запущены различные AV / вредоносные / шпионские программы, но в сети нет вирусов.
• sh mac address-table count показывает примерно 750 разных mac адресов, как и ожидалось в vlan 1.

#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

• Запустил show mac address-table на разных коммутаторах и на самом ядре (например, на ядре, подключенном непосредственно к рабочему столу, моему рабочему столу), и мы увидели, что несколько различных аппаратных MAC-адресов зарегистрированы на интерфейсе, даже если этот интерфейс имеет к этому подключен только один компьютер:

 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

• показать использование платформы tcam

 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 за подробный ответ. Я постараюсь ответить, что могу.

• Как уже упоминалось, 192.168.0.0/20 является унаследованным беспорядком. Тем не менее, мы намерены разделить это в будущем, но, к сожалению, эта проблема возникла до того, как мы смогли это сделать. Я лично также согласен с большинством, поэтому широковещательный домен слишком велик.
• Использование Arpwatch - это определенно то, что мы можем попробовать, но я подозреваю, что несколько портов доступа регистрируют mac-адрес, даже если он не принадлежит этому порту, заключение arpwatch может быть бесполезным.
• Я полностью согласен с тем, что я не уверен на 100% в нахождении всех избыточных каналов и неизвестных коммутаторов в сети, но, как лучше всего наш вывод, это так, пока мы не найдем дополнительные доказательства.
• Безопасность порта была рассмотрена, к сожалению, руководство решило не использовать это по разным причинам. Общая причина в том, что мы постоянно перемещаем компьютеры (среда колледжа).
• Мы использовали portfast связующего дерева вместе с связующим деревом bpduguard по умолчанию на всех портах доступа (настольных компьютерах).
• Мы не используем switchport без согласования в данный момент на порте доступа, но мы не получаем никакой прыгающей атаки Vlan, пересекающей несколько Vlan.
• Отправим уведомление по таблице MAC-адресов и посмотрим, сможем ли мы найти какие-либо шаблоны.

«Поскольку между портами коммутаторов вы получаете большое количество закрытий MAC, трудно определить, где находятся нарушители (предположим, вы найдете два или три mac-адреса, которые отправляют большое количество arps, но исходные mac-адреса продолжают колебаться между портами)».

• Мы начали с этого, выбрали все клапаны MAC и продолжили свой путь через все основные коммутаторы к распределению для коммутатора доступа, но мы снова обнаружили, что интерфейс порта доступа перегружал несколько адресов MAC, отсюда и флапы mac; Итак, вернемся к исходной точке.
• Контроль за штормом - это то, что мы рассматривали, но мы боимся, что некоторые из законных пакетов будут отброшены, что вызовет дальнейшую проблему.
• Тройная проверка конфигурации VMHost.
• @ytti необъяснимые MAC-адреса находятся за многими портами доступа, а не за отдельным человеком. На этих интерфейсах петли не найдены. MAC-адреса также существуют на других интерфейсах, что объясняет большое количество клапанов MAC
• @ RickyBeam Я согласен с тем, почему хосты отправляют так много запросов ARP; это одна из загадочных проблем. Беспроводной мост Rouge - интересный вопрос, о котором я даже не задумывался, насколько нам известно, беспроводная связь находится в другой VLAN; но жулик, очевидно, будет означать, что он вполне может быть на VLAN1.
• @RickyBeam, я действительно не хочу отключать все, потому что это вызовет огромное количество простоев. Тем не менее, это то, куда он может идти. У нас есть серверы Linux, но не более 3-х.
• @RickyBeam, можете ли вы объяснить, как DHCP-сервер "использует" зондирование?

Мы (Cisco TAC, CCIEs, CCNP) в целом согласны с тем, что это не конфигурация коммутатора, а хост / устройство вызывает проблему.

Решаемые.

Проблема связана с SCCM 2012 SP1, службой под названием: ConfigMrg Wake-Up Proxy . «Функция» не существует SCCM 2012 RTM.

В течение 4 часов после выключения в рамках политики мы увидели устойчивое снижение загрузки процессора. К тому времени, когда прошло 4 часа, использование ARP составляло всего 1-2%!

Таким образом, этот сервис делает подделку MAC-адресов! Не могу поверить, насколько это разрушительно.

Ниже приведен полный текст из Microsoft Technet, так как я чувствую, что важно понять, как это связано с опубликованной проблемой.

Для тех, кто заинтересован, ниже приведены технические детали.

Configuration Manager поддерживает две технологии пробуждения по локальной сети (LAN) для пробуждения компьютеров в спящем режиме при необходимости установки необходимого программного обеспечения, такого как обновления программного обеспечения и приложения: традиционные пакеты пробуждения и команды включения AMT.

Начиная с Configuration Manager с пакетом обновления 1 (SP1), вы можете дополнить традиционный метод пробуждения с помощью настроек прокси-клиента пробуждения. Прокси-сервер пробуждения использует одноранговый протокол и выбранные компьютеры, чтобы проверить, проснулись ли другие компьютеры в подсети, и, если необходимо, разбудить их. Когда сайт настроен для Wake On LAN, а клиенты настроены для Wake-up прокси, процесс работает следующим образом:

1. Компьютеры, на которых установлен клиент Configuration Manager с пакетом обновления 1 (SP1) и которые не спят в подсети, проверяют, активны ли другие компьютеры в подсети. Они делают это, посылая друг другу команду ping TCP / IP каждые 5 секунд.

2. Если нет ответа от других компьютеров, предполагается, что они спят. Бодрствующие компьютеры становятся управляющими компьютерами для подсети.

3. Поскольку компьютер может не отвечать по другой причине, кроме того, что он спит (например, он выключен, удален из сети или больше не применяется настройка клиента пробуждения прокси-сервера), компьютеры отправлял пакет пробуждения каждый день в 14:00 по местному времени. Компьютеры, которые не отвечают, больше не будут считаться спящими и не будут разбужены прокси пробуждения.

Для поддержки прокси пробуждения, по крайней мере три компьютера должны быть активны для каждой подсети. Чтобы достичь этого, три компьютера недетерминированно выбраны в качестве компьютеров-хранителей для подсети. Это означает, что они бодрствуют, несмотря на любую настроенную политику электропитания для сна или гибернации после периода бездействия. Компьютеры Guardian выполняют команды выключения или перезапуска, например, в результате задач по обслуживанию. Если это происходит, оставшиеся компьютеры-опекуны просыпаются от другого компьютера в подсети, так что в подсети остаются три компьютера-опекуна.

Управляющие компьютеры просят сетевой коммутатор перенаправить сетевой трафик для спящих компьютеров на себя.

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

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

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

5. Спящий компьютер получает пакет пробуждения и просыпается. Отправляющий компьютер автоматически повторяет соединение, и на этот раз компьютер не спит и может ответить.

Ссылка: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Спасибо за всех, кто разместил здесь и помог с процессом устранения неполадок, очень признателен.

ARP / широковещательный шторм

• Мы видим большие широковещательные пакеты от VLAN 1, VLAN 1, используемые для настольных устройств. Мы используем 192.168.0.0/20 ...
• Wiresharks показывает, что сотни компьютеров наводняют сеть ARP Broadcast ...

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

• Неправильная настройка IP-адреса
• Атака на уровне 2, такая как спуфинг arp

Сначала исключите возможность неправильной конфигурации или атаки на уровне 2, упомянутой выше. Самый простой способ сделать это с помощью arpwatch на машине с Linux (даже если вам нужно использовать livecd на ноутбуке). Если у вас неправильная конфигурация или атака layer2, 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-адрес.

• Большое количество закрылков MAC
• Связующее дерево было проверено квалифицированными специалистами Cisco TAC и CCNP / CCIE. Мы отключаем все избыточные ссылки.

Говоря как кто-то, кто прошел через это больше раз, чем я хотел бы вспомнить, не думайте, что вы нашли все избыточные ссылки ... просто заставьте ваши коммутационные порты вести себя постоянно.

Поскольку между портами коммутаторов вы получаете большое количество сообщений mac, трудно определить, где находятся нарушители (предположим, вы найдете два или три адреса MAC, которые отправляют большое количество arps, но адреса 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-адреса, и отключит тайно зацикленный порт-порт. Три macs на порт - это число, которое хорошо работает в моей среде рабочего стола, но вы можете увеличить его до 10 и, вероятно, все будет в порядке. После того, как вы это сделаете, все петли слоя 2 будут разорваны, быстрые мак-клапаны прекратятся, и это значительно облегчит диагностику.

Еще пара глобальных команд, которые полезны для отслеживания портов, связанных с широковещательным штормом (mac-move) и затоплением (порог) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

После того, как вы закончите, опционально сделайте, clear mac address-tableчтобы ускорить лечение из потенциально полной таблицы CAM.

• Запустил show mac address-table на разных коммутаторах и на самом ядре (например, на ядре, подключенном непосредственно к рабочему столу, моему рабочему столу), и мы увидели, что несколько различных аппаратных MAC-адресов зарегистрированы на интерфейсе, даже если этот интерфейс имеет к этому подключен только один компьютер ...

Весь этот ответ предполагает, что у вашего 3750 нет ошибки, вызывающей проблему (но вы сказали, что wireshark указал на компьютеры, которые загружаются). То, что вы показываете нам, очевидно, неверно, когда к Gi1 / 1/3 подключен только один компьютер, если только на этом компьютере не установлено что-то вроде VMWare.

Разные мысли

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

• Размещение любых пользователей в Vlan1 обычно плохая идея (я понимаю, что вы, возможно, унаследовали беспорядок)
• Независимо от того, что говорит TAC, 192.168.0.0/20 слишком велик, чтобы управлять им в одном коммутируемом домене без риска атак уровня 2. Чем больше маска вашей подсети, тем больше вероятность того, что вы подвергнетесь атакам второго уровня, потому что ARP - это протокол без аутентификации, и маршрутизатор должен по крайней мере считывать действительный ARP из этой подсети.
• Управление штормом на портах layer2 также является хорошей идеей; однако, включив шторм-контроль в подобной ситуации, вы получите хороший трафик при плохом трафике. После восстановления сети примените некоторые политики контроля шторма к пограничным портам и восходящим каналам.

Реальный вопрос заключается в том, почему хосты отправляют так много ARP. До тех пор, пока на этот вопрос не будет получен ответ, коммутатору (ам) будет по-прежнему трудно справляться со штормом арп. Сетевая маска не соответствует? Таймеры низкого уровня хоста? Один (или несколько) хостов, имеющих «интерфейсный» маршрут? Где-то беспроводной мост румян? "безвозмездный арп" сошел с ума? 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 отсутствуют.

Очень простой, но, возможно, не заметили; у ваших клиентов есть действующий шлюз по умолчанию, разве вы не используете много прокси-серверов? Вы можете отменить функцию ip proxy arp на вашем 3750?