Red de inundación de difusión ARP y alto uso de CPU

Esperando que alguien aquí pueda tener alguna idea del problema que enfrentamos. Actualmente tenemos Cisco TAC mirando el caso, pero están luchando por encontrar la causa raíz.

Aunque el título menciona la transmisión ARP y el alto uso de la CPU, no estamos seguros de si están relacionados o no en esta etapa.

El número original ha sido publicado en la comunidad en línea del INE

Hemos reducido la red a un solo enlace sin configuración de redundancia, piense en ella como una topología en estrella.

Hechos:

• Utilizamos interruptores 3750x, 4 en una pila. Versión 15.0 (1) SE3. Cisco TAC confirma que no hay problemas conocidos para errores de alta CPU o ARP para esta versión en particular.
• No hay hubs / switches no administrados conectados
• Pila del núcleo recargado
• No tenemos una ruta predeterminada "Ruta Ip 0.0.0.0 0.0.0.0 f1 / 0". Usando OSPF para el enrutamiento.
• Vemos grandes paquetes de difusión de VLAN 1, VLAN 1 utilizados para dispositivos de escritorio. Usamos 192.168.0.0/20
• Cisco TAC dijo que no ven nada malo con el uso de / 20, aparte de eso tendríamos un gran dominio de transmisión pero aún debería funcionar.
• Wifi, administración, impresoras, etc.están en diferentes VLAN
• El árbol de expansión ha sido verificado por personas calificadas por Cisco TAC y CCNP / CCIE. Cerramos todos los enlaces redundantes.
• La configuración en el núcleo se ha verificado Cisco TAC.
• Tenemos el tiempo de espera ARP predeterminado en la mayoría de los conmutadores.
• No implementamos preguntas y respuestas.
• No se han agregado nuevos conmutadores (al menos ninguno que sepamos)
• No se puede usar la inspección dinámica de arp en los interruptores de borde porque estos son 2950
• Utilizamos show interfaces | inc line | broadcast para determinar de dónde proviene la gran cantidad de transmisión, sin embargo, tanto Cisco TAC como otros 2 ingenieros (CCNP y CCIE) confirmaron que este es un comportamiento normal debido a lo que sucede en la red (como en la gran cantidad de flaps mac causando la transmisión más grande). Verificamos que el STP funcionaba correctamente en los interruptores de borde.

Síntomas en la red y conmutadores:

• Gran cantidad de solapas MAC
• Alto uso de CPU para el proceso de entrada ARP
• Gran cantidad de paquetes ARP, aumentando rápidamente y visible
• Wiresharks muestra que cientos de computadoras están inundando la red con ARP Broadcast
• Para fines de prueba, pusimos aproximadamente 80 máquinas de escritorio diferentes vlan, sin embargo, lo probamos y no hicimos ninguna diferencia visible a la entrada de CPU o ARP alta
• Se han ejecutado diferentes AV / malware / spyware, pero no hay virus visibles en la red.
• sh mac-tabla de direcciones cuenta, nos muestra aproximadamente 750 direcciones mac diferentes como se esperaba en 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

• Ran muestra la tabla de direcciones de mac en diferentes conmutadores y el núcleo mismo (en el núcleo, por ejemplo, conectado directamente por el escritorio, mi escritorio), y podemos ver las diferentes direcciones de hardware MAC registradas en la interfaz, a pesar de que esa interfaz tiene solo una computadora conectada a esto:

 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

• muestre la utilización de la plataforma 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

Ahora estamos en una etapa en la que necesitaremos una gran cantidad de tiempo de inactividad para aislar cada área a la vez, a menos que alguien más tenga algunas ideas para identificar la fuente o la causa raíz de este problema extraño y extraño.

Actualizar

Gracias @MikePennington y @RickyBeam por la respuesta detallada. Trataré de responder lo que pueda.

• Como se mencionó, 192.168.0.0/20 es un desastre heredado. Sin embargo, tenemos la intención de dividir esto en el futuro, pero desafortunadamente este problema ocurrió antes de que pudiéramos hacerlo. Personalmente, también estoy de acuerdo con la mayoría, por lo que el dominio de transmisión es demasiado grande.
• El uso de Arpwatch es definitivamente algo que podemos probar, pero sospecho que debido a que varios puertos de acceso están registrando una dirección MAC a pesar de que no pertenece a este puerto, la conclusión de arpwatch puede no ser útil.
• Estoy completamente de acuerdo con no estar 100% seguro de encontrar todos los enlaces redundantes y conmutadores desconocidos en la red, pero como lo mejor de nuestro hallazgo, este es el caso hasta que encontremos más evidencia.
• Se ha examinado la seguridad portuaria, desafortunadamente la gerencia ha decidido no usar esto por varias razones. La razón común es que constantemente movemos las computadoras (entorno universitario).
• Hemos utilizado spanf-tree portfast junto con spanning-tree bpduguard de forma predeterminada en todos los puertos de acceso (máquinas de escritorio).
• No usamos switchport no negociado en este momento en el puerto de acceso, pero no estamos recibiendo ningún ataque de salto de Vlan que rebote en Vlans múltiples.
• Le daremos una oportunidad a la notificación de la tabla de direcciones mac y veremos si podemos encontrar algún patrón.

"Dado que está obteniendo una gran cantidad de flaps MAC entre puertos de switch, es difícil encontrar dónde están los delincuentes (supongamos que encuentra dos o tres direcciones mac que envían muchos arps, pero las direcciones mac de origen siguen aleteando entre puertos)".

• Comenzamos con esto, seleccionamos cualquier solapa MAC y continuamos nuestro camino a través de todo el conmutador central para distribución para acceder al conmutador, pero lo que encontramos fue una vez más, la interfaz del puerto de acceso estaba acaparando múltiples direcciones mac, por lo tanto, solapas mac; Así que volvamos al punto de partida.
• El control de tormentas es algo que sí consideramos, pero tememos que algunos de los paquetes legítimos se eliminen causando más problemas.
• Verificará tres veces la configuración de VMHost.
• @ytti las direcciones MAC inexplicables están detrás de muchos puertos de acceso en lugar de un individuo. No he encontrado ningún bucle en estas interfaces. Las direcciones MAC también existen en otras interfaces, lo que explicaría una gran cantidad de solapas MAC
• @RickyBeam, estoy de acuerdo con por qué los hosts envían tantas solicitudes ARP; Este es uno de los problemas desconcertantes. El puente inalámbrico Rouge es interesante y no lo he pensado, hasta donde sabemos, la conexión inalámbrica está en una VLAN diferente; pero pícaro obviamente significará que puede estar en VLAN1.
• @RickyBeam, realmente no deseo desconectar todo, ya que esto causará una gran cantidad de tiempo de inactividad. Sin embargo, aquí es donde puede estar dirigiéndose. Tenemos servidores Linux pero no más de 3.
• @RickyBeam, ¿puede explicar el sondeo "en uso" del servidor DHCP?

Nosotros (Cisco TAC, CCIEs, CCNP) aceptamos globalmente que esta no es una configuración de conmutador, sino que un host / dispositivo está causando el problema.

Resuelto

El problema es con SCCM 2012 SP1, un servicio llamado: ConfigMrg Wake-Up Proxy . La 'característica' no existe SCCM 2012 RTM.

A las 4 horas de desactivar esto dentro de la política, vimos caídas constantes en el uso de la CPU. En el momento en que transcurrieron 4 horas, ¡el uso de ARP fue solo del 1-2%!

En resumen, este servicio hace suplantación de direcciones MAC. No puedo creer la cantidad de estragos que causó.

A continuación se muestra un texto completo de Microsoft Technet, ya que creo que es importante comprender cómo se relaciona esto con el problema publicado.

Para cualquiera que esté interesado, a continuación se encuentran los detalles técnicos.

Configuration Manager admite dos tecnologías de activación en la red de área local (LAN) para activar las computadoras en modo de suspensión cuando desee instalar el software requerido, como actualizaciones de software y aplicaciones: paquetes de activación tradicionales y comandos de encendido AMT.

A partir de Configuration Manager SP1, puede complementar el método tradicional de paquetes de reactivación mediante la configuración del cliente proxy de reactivación. El proxy de activación utiliza un protocolo de igual a igual y computadoras elegidas para verificar si otras computadoras en la subred están activas y para activarlas si es necesario. Cuando el sitio está configurado para Wake On LAN y los clientes están configurados para el proxy de activación, el proceso funciona de la siguiente manera:

1. Las computadoras que tienen instalado el cliente de Configuration Manager SP1 y que no están durmiendo en la subred verifican si otras computadoras en la subred están despiertas. Lo hacen enviándose entre sí un comando de ping TCP / IP cada 5 segundos.

2. Si no hay respuesta de otras computadoras, se supone que están dormidas. Las computadoras que están despiertas se convierten en computadoras administradoras de la subred.

3. Debido a que es posible que una computadora no responda debido a una razón que no sea estar dormida (por ejemplo, está apagada, eliminada de la red o ya no se aplica la configuración del cliente de activación del proxy), las computadoras están envió un paquete de despertador todos los días a las 2 PM hora local. Ya no se supondrá que las computadoras que no responden estén dormidas y no se despertarán con el proxy de activación.

Para admitir el proxy de reactivación, al menos tres computadoras deben estar activadas para cada subred. Para lograr esto, tres computadoras son elegidas de manera no determinista para ser computadoras de guardia para la subred. Esto significa que permanecen despiertos, a pesar de cualquier política de energía configurada para dormir o hibernar después de un período de inactividad. Las computadoras Guardian cumplen con los comandos de apagado o reinicio, por ejemplo, como resultado de tareas de mantenimiento. Si esto sucede, las computadoras guardianas restantes activan otra computadora en la subred para que la subred continúe teniendo tres computadoras guardianas.

Las computadoras de administrador le piden al conmutador de red que redirija el tráfico de red para las computadoras inactivas.

La redirección se logra mediante la computadora del administrador que transmite una trama de Ethernet que utiliza la dirección MAC de la computadora inactiva como la dirección de origen. Esto hace que el conmutador de red se comporte como si la computadora inactiva se hubiera movido al mismo puerto en el que se encuentra la computadora del administrador. La computadora del administrador también envía paquetes ARP para las computadoras dormidas para mantener la entrada fresca en la caché ARP. La computadora del administrador también responderá a las solicitudes de ARP en nombre de la computadora inactiva y responderá con la dirección MAC de la computadora inactiva.

Durante este proceso, la asignación de IP a MAC para la computadora inactiva permanece igual. El proxy de activación funciona informando al conmutador de red que un adaptador de red diferente está utilizando el puerto registrado por otro adaptador de red. Sin embargo, este comportamiento se conoce como una aleta MAC y es inusual para el funcionamiento estándar de la red. Algunas herramientas de monitoreo de red buscan este comportamiento y pueden asumir que algo está mal. En consecuencia, estas herramientas de monitoreo pueden generar alertas o cerrar puertos cuando usa el proxy de activación. No use el proxy de activación si las herramientas y servicios de monitoreo de su red no permiten flaps MAC.

4. Cuando una computadora administradora ve una nueva solicitud de conexión TCP para una computadora inactiva y la solicitud es a un puerto que la computadora inactiva estaba escuchando antes de irse a dormir, la computadora administradora envía un paquete de activación a la computadora inactiva y luego deja de redirigir el tráfico para esta computadora.

5. La computadora dormida recibe el paquete de activación y se despierta. La computadora que envía automáticamente reintenta la conexión y esta vez, la computadora está despierta y puede responder.

Ref: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Gracias por todos los que publicaron aquí y ayudaron con el proceso de solución de problemas, muy apreciados.

ARP / tormenta de difusión

• Vemos grandes paquetes de difusión de VLAN 1, VLAN 1 utilizados para dispositivos de escritorio. Usamos 192.168.0.0/20 ...
• Wiresharks muestra que cientos de computadoras están inundando la red con ARP Broadcast ...

Su proceso de entrada de ARP es alto, lo que significa que el conmutador está gastando mucho tiempo procesando ARP. Una causa muy común de inundación ARP es un bucle entre sus interruptores. Si tiene un bucle, también puede obtener los flaps de mac que mencionó anteriormente. Otras posibles causas de inundaciones ARP son:

• Configuraciones incorrectas de direcciones IP
• Un ataque de capa 2, como la falsificación de arp

Primero elimine la posibilidad de configuraciones erróneas o un ataque de capa 2 mencionado anteriormente. La forma más fácil de hacer esto es con arpwatch en una máquina Linux (incluso si tiene que usar un livecd en una computadora portátil). Si tiene una configuración incorrecta o un ataque de capa 2, entonces arpwatch le brinda mensajes como este en syslog, que enumeran las direcciones mac que están luchando por la misma dirección 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)

Cuando vea "flip flops", debe rastrear la fuente de las direcciones mac y descubrir por qué están peleando por la misma IP.

• Gran cantidad de solapas MAC
• El árbol de expansión ha sido verificado por personas calificadas por Cisco TAC y CCNP / CCIE. Cerramos todos los enlaces redundantes.

Hablando como alguien que ha pasado por esto más veces de lo que me gustaría recordar, no asuma que encontró todos los enlaces redundantes ... solo haga que sus puertos de conmutación se comporten en todo momento.

Dado que está obteniendo una gran cantidad de flaps mac entre puertos de conmutación, es difícil encontrar dónde están los delincuentes (suponga que encuentra dos o tres direcciones mac que envían muchos arps, pero las direcciones mac de origen siguen aleteando entre puertos). Si no está imponiendo un límite estricto en las direcciones MAC por puerto de borde, es muy difícil rastrear estos problemas sin desconectar manualmente los cables (que es lo que desea evitar). Los bucles de conmutación causan una ruta inesperada en la red, y podría terminar con cientos de equipos Mac aprendidos intermitentemente de lo que normalmente debería ser un puerto de conmutación de escritorio.

La forma más fácil de ralentizar los movimientos de mac es con port-security. En cada puerto de conmutador de acceso en Vlan 1 que esté conectado a una sola PC (sin un conmutador descendente), configure los siguientes comandos de nivel de interfaz en sus conmutadores 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

En la mayoría de los casos de inundación de mac / ARP, la aplicación de esta configuración a todos sus puertos de conmutador perimetral (especialmente cualquiera con portfast) lo llevará de regreso a un estado sano, porque la configuración cerrará cualquier puerto que exceda tres direcciones mac y deshabilitará secretamente En bucle puerto portfast. Tres macs por puerto es un número que funciona bien en mi entorno de escritorio, pero podría aumentarlo a 10 y probablemente esté bien. Una vez que haya hecho esto, los bucles de la capa 2 se romperán, las aletas mac rápidas cesarán y el diagnóstico será mucho más fácil.

Otro par de comandos globales que son útiles para rastrear puertos asociados con una tormenta de difusión (mac-move) e inundación (umbral) ...

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

Después de que termine, opcionalmente haga una clear mac address-tablepara acelerar la curación de la tabla CAM potencialmente llena.

• Ran muestra la tabla de direcciones de mac en diferentes conmutadores y el núcleo mismo (en el núcleo, por ejemplo, conectado directamente por el escritorio, mi escritorio), y podemos ver las diferentes direcciones de hardware MAC registradas en la interfaz, a pesar de que esa interfaz tiene solo una computadora conectada a esto ...

Toda esta respuesta asume que su 3750 no tiene un error que causa el problema (pero usted dijo que wireshark indicó PC que se están inundando). Lo que nos está mostrando es obviamente incorrecto cuando solo hay una computadora conectada a Gi1 / 1/3, a menos que esa PC tenga algo como VMWare.

Pensamientos misceláneos

Basado en una conversación de chat que tuvimos, probablemente no tenga que mencionar lo obvio, pero lo haré por el bien de futuros visitantes ...

• Poner a cualquier usuario en Vlan1 normalmente es una mala idea (entiendo que puede haber heredado un desastre)
• Independientemente de lo que le indique TAC, 192.168.0.0/20 es demasiado grande para administrar en un solo dominio conmutado sin riesgos de ataques de capa2. Cuanto más grande sea la máscara de subred, mayor será la exposición a ataques de capa 2 como este porque ARP es un protocolo no autenticado y un enrutador debe al menos leer un ARP válido de esa subred.
• El control de tormentas en los puertos de capa 2 también suele ser una buena idea; sin embargo, al permitir el control de tormentas en una situación como esta, eliminará el buen tráfico con el mal tráfico. Después de que la red se haya curado, aplique algunas políticas de control de tormentas en sus puertos de borde y enlaces ascendentes.

La verdadera pregunta es por qué los hosts envían tantos ARP en primer lugar. Hasta que esto se responda, los conmutadores continuarán teniendo dificultades para lidiar con la tormenta de arpa. ¿Falta de coincidencia de máscara de red? ¿Temporizadores de arp de host bajos? ¿Uno (o más) hosts que tienen una ruta de "interfaz"? ¿Un puente inalámbrico en alguna parte? ¿"arp gratuito" se ha vuelto loco? ¿Sondeo del servidor DHCP "en uso"? No parece un problema con los interruptores o la capa 2; tienes anfitriones haciendo cosas malas.

Mi proceso de depuración sería desconectar todo y observar de cerca cómo se vuelven a conectar las cosas, un puerto a la vez. (Sé que está a millas de lo ideal, pero en algún momento tienes que reducir tus pérdidas e intentar aislar físicamente cualquier posible fuente (s)) Luego trabajaría para entender por qué los puertos seleccionados están generando tantos arps.

(¿Muchos de esos hosts serían sistemas Linux? Linux ha tenido un sistema de administración de caché ARP muy estúpido. El hecho de que "volverá a verificar" una entrada en cuestión de minutos, está roto en mi libro Tiende a ser un problema menor en redes pequeñas, pero a / 20 no es una red pequeña).

Esto puede o no estar relacionado con su problema actual, sin embargo, pensé que podría ser algo que valga la pena al menos arrojar:

Actualmente tenemos bastantes 3750x apilados en algunos de nuestros sitios remotos, la mayoría ejecutando 15.0.2 (SE0 a 4, hay algunos errores de FRU con SE0 de los que estoy migrando lentamente).

Durante una actualización de rutina de IOS, pasando de 15.0.2 a 15.2-1 (SE más reciente) notamos un aumento de CPU bastante significativo, de un promedio de aproximadamente 30% a 60% y más durante los períodos de menor actividad. He revisado las configuraciones y los registros de cambio de IOS, y he estado trabajando con el TAC de Cisco. Según TAC, parecen estar en el punto en que creen que se trata de un error de IOS 15.2-1.

A medida que continuamos investigando el aumento de la CPU, comenzamos a ver cantidades masivas de tráfico ARP hasta el punto en que nuestras tablas ARP se llenaron por completo y causaron inestabilidad en la red. La muleta temporal para esto fue retroceder manualmente nuestros tiempos de espera ARP lejos del valor predeterminado (14400) a 300 en nuestros vlans de voz y datos.

Después de reducir nuestros tiempos de espera de ARP, estuvimos estables durante aproximadamente una semana, momento en el que volvimos a IOS 15.0.2-SE4 y eliminamos nuestros tiempos de espera de ARP no predeterminados. Nuestra utilización de CPU se ha reducido a ~ 30% y nuestros problemas con la tabla ARP son inexistentes.

Una muy simple pero quizás pasada por alto; ¿Sus clientes tienen una puerta de enlace predeterminada válida? ¿No está haciendo un montón de arps proxy? ¿Podría considerar negar la función arp de proxy ip en su 3750?