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


Esperando que alguien aquí pueda tener alguna idea del problema que estamos enfrentando. Actualmente, tenemos un TAC de Cisco que analiza el caso, pero están luchando para encontrar la causa raíz.

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

La edición 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, considérela como una topología en estrella.

Hechos:

  • Utilizamos interruptores 3750x, 4 en una pila. Versión 15.0 (1) SE3. Cisco TAC no confirma problemas conocidos de errores de cpu alta o ARP para esta versión en particular.
  • No hay hubs / switches no gestionados conectados
  • Pila de pila recargada
  • No tenemos una ruta predeterminada "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Utilizando OSPF para enrutamiento.
  • Vemos grandes paquetes de transmisión desde VLAN 1, VLAN 1 utilizados para dispositivos de escritorio. Utilizamos 192.168.0.0/20
  • Cisco TAC dijo que no veían nada incorrecto en el uso de / 20, aparte de que 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 individuos calificados de Cisco TAC & CCNP / CCIE. Cerramos todos los enlaces redundantes.
  • La configuración en el núcleo ha sido verificada por Cisco TAC.
  • Tenemos el tiempo de espera de ARP predeterminado en la mayoría de los switches.
  • No implementamos Q & Q.
  • No se han agregado nuevos conmutadores (al menos ninguno que nosotros sepamos)
  • No se puede usar la inspección dinámica de arp en los interruptores de borde porque son 2950
  • Utilizamos interfaces de show | Sin embargo, tanto Cisco TAC como otros 2 ingenieros (CCNP y CCIE) confirmaron que este es un comportamiento normal debido a lo que está sucediendo en la red (como en un gran número de flaps mac). causando la emisió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 flaps MAC
  • Alto uso de la CPU para el proceso de entrada ARP
  • Gran cantidad de paquetes ARP, que aumentan rápidamente y son visibles.
  • Wiresharks muestra que cientos de computadoras están inundando la red con ARP Broadcast
  • Para propósitos de prueba, pusimos aproximadamente 80 máquinas de escritorio diferentes vlan, sin embargo, probamos esto y no hicimos ninguna diferencia visible a la entrada alta de cpu o arp
  • Han ejecutado diferentes AV / malware / spyware, pero no hay virus visibles en la red.
  • sh mac address-table count, 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
  • Ejecutamos show mac address-table en diferentes switches y el núcleo mismo (en el núcleo, por ejemplo, conectado directamente al escritorio, mi escritorio), y podemos ver las diferentes direcciones de hardware MAC registradas en la interfaz, a pesar de que esa interfaz tiene Sólo 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
  • Mostrar plataforma de utilización de 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 a @MikePennington y @RickyBeam por la respuesta detallada. Intentaré y responderé lo que pueda.

  • Como se mencionó, 192.168.0.0/20 es un lío 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 intentar, pero sospecho que debido a que varios puertos de acceso están registrando una dirección mac, aunque 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 los conmutadores desconocidos en la red, pero como mejor de nuestro descubrimiento, este es el caso hasta que encontremos más evidencia.
  • Se ha investigado la seguridad portuaria, desafortunadamente la administración ha decidido no usar esto por varias razones. La razón común es que movemos constantemente las computadoras (entorno universitario).
  • Hemos usado spanning-tree portfast junto con spanning-tree bpduguard de forma predeterminada en todos los puertos de acceso (máquinas de escritorio).
  • No utilizamos switchport no negociado en este momento en el puerto de acceso, pero no estamos obteniendo ningún ataque de salto de Vlan que rebote en varios Vlans.
  • Le daré una notificación a mac-address-table, y veremos si podemos encontrar algún patrón.

"Dado que está obteniendo una gran cantidad de fallas 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 la fuente mac   direcciones siguen batiendo entre puertos) ".

  • Comenzamos con esto, seleccionamos cualquiera de las solapas MAC y continuamos nuestro camino a través de todo el interruptor central a la distribución para acceder al interruptor, pero lo que encontramos fue una vez más, la interfaz del puerto de acceso estaba acaparando múltiples direcciones mac, por lo tanto, mac flaps; Así que de vuelta a la plaza uno.
  • El control de tormentas es algo que consideramos, pero tememos que se eliminen algunos paquetes legítimos que causen más problemas.
  • Se triplica 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 un gran número de fallas MAC
  • @RickyBeam estoy de acuerdo con por qué los hosts envían tantas solicitudes ARP; Este es uno de los temas desconcertantes. El puente inalámbrico de Rouge es interesante y, por lo que sabemos, la tecnología inalámbrica está en una VLAN diferente; pero el pícaro obviamente significa 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 ir simplemente. 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 esto no es una configuración de conmutador, pero un host / dispositivo está causando el problema.


18
2017-10-26 14:26


origen


Me gustaría señalar: a menos que haya bucles en la red, mac flaps no deberían ocurrir. La única otra razón lógica sería que las máquinas virtuales utilicen el mismo MAC. (o algún bonehead tiene varios nics configurados para usar el mismo MAC)
@ColdT, actualicé mi respuesta porque leí mal algunas cosas en mi respuesta original. - Mike Pennington
¿Experimenta un gran número de direcciones MAC inexplicables detrás de muchos puertos o solo un puerto? ¿Podría el puerto estar en bucle? ¿Las direcciones MAC se quedan detrás de ese puerto o aparecen detrás de otros puertos también? ¿Tenemos PCAP para el ARP? Un gran número de fallas MAC ciertamente no es normal en absoluto, implica que la topología cambia constantemente o tiene un bucle no administrado en la red.
@ColdT, creo que debería volver a comprometerse con la administración sobre seguridad de puertos; Específicamente te di configuraciones que permiten a las PC moverse entre puertos de conmutación. switchport port-security aging time 5 y switchport port-security aging type inactivity significa que puede mover estaciones entre puertos después de 5 minutos de inactividad, o si borra manualmente la entrada de seguridad de puerto. Sin embargo, esta configuración evita las fallas de mac entre los puertos de acceso del conmutador porque los puertos no pueden obtener la misma dirección mac desde un puerto diferente. - Mike Pennington
También vale la pena mencionar que arpwatch no registra un flip flop a menos que haya diferentes ARP para la misma dirección IP. Independientemente de la razón, necesita saber cuándo sucede eso. Las simples inundaciones de mac no son suficientes para confundir a arpwatch - Mike Pennington


Respuestas:


Resuelto

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

Dentro de las 4 horas de desactivar esto dentro de la política, vimos caídas constantes en el uso de la CPU. Para cuando terminaron las 4 horas, ¡el uso de ARP fue de solo 1-2%!

En resumen, este servicio hace la falsificació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 quien esté interesado, a continuación están los detalles técnicos.

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

A partir de Configuration Manager SP1, puede complementar la   método tradicional de paquete de activación mediante el uso del cliente proxy de activación   ajustes El proxy de reactivación utiliza un protocolo de igual a igual y elegido   computadoras para verificar si otras computadoras en la subred están activas,   Y despertarlos si es necesario. Cuando el sitio está configurado para Wake On   La LAN y los clientes están configurados para el proxy de reactivación, el proceso funciona como   sigue:

  1. Los equipos que tienen instalado el cliente Configuration Manager SP1 y que no están inactivos en la subred comprueban si otros equipos están   la subred esta despierta Lo hacen enviándose mutuamente un ping TCP / IP.   comando cada 5 segundos

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

  3. Debido a que es posible que una computadora no responda debido a una razón diferente a la que está dormida (por ejemplo, está apagada,   eliminado de la red, o la configuración del cliente de activación del proxy es no   aplicado durante más tiempo), a las computadoras se les envía un paquete de activación todos los días a las   2 P.M. hora local. Las computadoras que no respondan ya no serán   Se supone que está dormido y no se activará con el proxy de activación.

Para admitir el proxy de activación, al menos tres computadoras deben estar despiertas durante   cada subred Para lograr esto, tres computadoras son   elegido de forma no determinista para ser ordenadores guardianes de 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. Computadoras guardianas   comandos de apagado o reinicio de honor, por ejemplo, como resultado de   tareas de mantenimiento. Si esto sucede, las computadoras guardianes restantes   active otra computadora en la subred para que la subred continúe   tener tres computadoras guardianes

Las computadoras del administrador piden al conmutador de red que redirija el tráfico de la red   Para los ordenadores durmientes a sí mismos.

El redireccionamiento se realiza por el administrador informático que emite un   La trama de Ethernet que usa la dirección MAC de la computadora durmiente como   Dirección de la fuente. Esto hace que el conmutador de red se comporte como si el   La computadora durmiente se ha movido al mismo puerto que la computadora del administrador   Está encendido. La computadora del administrador también envía paquetes ARP para dormir   Computadoras para mantener la entrada fresca en el caché ARP. El gerente   La computadora también responderá a las solicitudes de ARP en nombre de la persona que duerme.   Computadora y responda con la dirección MAC de la computadora dormida.

Durante este proceso, la asignación de IP a MAC para la computadora durmiente permanece igual. El proxy de reactivación funciona informando al conmutador de red   que un adaptador de red diferente está utilizando el puerto que se registró   por otro adaptador de red. Sin embargo, este comportamiento se conoce como MAC   solapa y es inusual para la operación de red estándar. Alguna red   Las herramientas de monitoreo buscan este comportamiento y pueden asumir que algo   Está Mal. En consecuencia, estas herramientas de monitoreo pueden generar alertas o   Apague los puertos cuando use el proxy de reactivación. No utilice el proxy de activación   Si sus herramientas y servicios de monitoreo de red no permiten flaps MAC.

  1. Cuando una computadora del administrador ve una nueva solicitud de conexión TCP para una computadora durmiente y la solicitud es a un puerto que   La computadora estaba escuchando antes de que se durmiera, el gerente   la computadora envía un paquete de activación a la computadora que está durmiendo, y luego   Deja de redireccionar el tráfico para esta computadora.

  2. La computadora durmiente recibe el paquete de despertador y se despierta. El ordenador remitente reintenta automáticamente la conexión y esta vez,   La computadora está despierta y puede responder.

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

Gracias por todos los que han publicado aquí y han ayudado con el proceso de solución de problemas, muy apreciado.


12
2017-11-14 14:04





ARP / Broadcast Storm

  • Vemos grandes paquetes de transmisión desde VLAN 1, VLAN 1 utilizados para dispositivos de escritorio. Utilizamos 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 los ARP. Una causa muy común de la inundación de ARP es un bucle entre los conmutadores. Si tiene un bucle, también puede obtener los flaps de mac que mencionó anteriormente. Otras posibles causas de inundaciones ARP son:

  • Configuraciones erróneas de direcciones IP
  • Un ataque de capa 2, como arp spoofing

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 layer2, entonces arpwatch le ofrece mensajes como este en syslog, que enumera las direcciones mac que luchan 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 ves "flip flops", debes rastrear la fuente de las direcciones mac y descubrir por qué se están peleando por la misma IP.

  • Gran cantidad de flaps MAC
  • El árbol de expansión ha sido verificado por individuos calificados de Cisco TAC & CCNP / CCIE. Cerramos todos los enlaces redundantes.

Hablando como alguien que ha pasado por esto más veces de las que me gustaría recordar, no suponga que ha encontrado todos los enlaces redundantes ... solo haga que sus puertos automáticos se comporten en todo momento.

Ya que está obteniendo una gran cantidad de fallas de mac entre puertos de conmutación, es difícil encontrar dónde están los delincuentes (suponga que encuentra dos o tres direcciones de mac que envían muchos arps, pero las direcciones de mac de origen siguen alternando entre los puertos). Si no está aplicando un límite rígido en las direcciones Mac por puerto de borde, es muy difícil rastrear estos problemas sin desconectar manualmente los cables (que es lo que quiere evitar). Los bucles de conmutación causan una ruta inesperada en la red, y podría terminar con cientos de macs aprendidos de forma intermitente de lo que normalmente debería ser un puerto de conmutador de escritorio.

La forma más fácil de ralentizar los movimientos de mac es con port-security. En cada puerto de conmutación 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 los puertos de su conmutador de borde (especialmente cualquiera con portfast) lo devolverá a un estado normal, ya que la configuración cerrará cualquier puerto que exceda de tres direcciones MAC y deshabilitará un secreto puerto portfast en bucle. Tres mac por puerto es un número que funciona bien en mi entorno de escritorio, pero podría subirlo a 10 y probablemente esté bien. Después de hacer esto, se rompen todos los bucles de la capa 2, las fallas rápidas de mac se detendrán y el diagnóstico será mucho más sencillo.

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

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

Después de que termines, opcionalmente haz una clear mac address-table para acelerar la curación de la tabla de CAM potencialmente completa.

  • Ejecutamos show mac address-table en diferentes switches y el núcleo mismo (en el núcleo, por ejemplo, conectado directamente al escritorio, mi escritorio), y podemos ver las diferentes direcciones de hardware MAC registradas en la interfaz, a pesar de que esa interfaz tiene Sólo una computadora conectada a este ...

Toda esta respuesta asume que su 3750 no tiene un error que cause el problema (pero usted dijo que Wirehark indicó que las PC están inundadas). 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.

Mis pensamientos

Basándonos 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 es normalmente una mala idea (entiendo que puede haber heredado un desastre)
  • Independientemente de lo que le diga TAC, 192.168.0.0/20 es demasiado grande para administrarlo en un solo dominio conmutado sin riesgos de ataques de capa 2. Cuanto más grande sea la máscara de subred, mayor será la exposición a los ataques de layer2, ya que ARP es un protocolo no autenticado y el enrutador debe leer al menos un ARP válido de esa subred.
  • El control de tormentas en los puertos layer2 también suele ser una buena idea; sin embargo, al habilitar el control de tormentas en una situación como esta, eliminará el tráfico bueno con el tráfico malo. Una vez que la red se haya recuperado, aplique algunas políticas de control de tormentas en sus puertos y enlaces ascendentes.

10
2017-10-26 15:41



En realidad, su tcam no está al máximo. La primera columna es el máximo, la segunda es el uso actual. Puede ignorar la parte de máscaras vs valores. Desde aquí, suena como una "simple" tormenta de arp, pero sin el conocimiento de su topología y el tráfico real, no puedo adivinar por qué.
Punto justo Ricky, gracias por destacarlo. - Mike Pennington


La pregunta real es por qué los hosts envían tantos ARP en primer lugar. Hasta que se responda esto, los interruptores continuarán teniendo dificultades para lidiar con la tormenta de arp. Desajuste de la máscara de red? ¿Temporizadores de arp de host bajo? Uno o mas) Hospedadores Tener una ruta de "interfaz"? ¿Un puente inalámbrico de colorete en alguna parte? ¿"Arpa gratuita" se ha vuelto loca? ¿Servidor DHCP "en uso" sondeo? No suena como 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 cuando las cosas se vuelven a unir, un puerto a la vez. (Sé que está a muchos kilómetros de lo ideal, pero en algún momento tendrá que reducir sus pérdidas e intentar aislar físicamente cualquier fuente posible). Luego trabajaría para comprender por qué los puertos seleccionados generan muchos arp's.

(¿Sucederá que muchos de estos hosts sean sistemas Linux? Linux ha tenido un sistema de administración de caché ARP muy estúpido con ***. . Tiende a ser un problema menor en redes pequeñas, pero a / 20 no es una red pequeña.)


2
2017-10-26 19:29





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

Actualmente tenemos unos cuantos 3750x apilados en algunos de nuestros sitios remotos, en su mayoría con una versión de 15.0.2 (SE0 a 4, hay algunos errores de FRU con SE0 de los cuales estoy migrando lentamente).

Durante una actualización de rutina del IOS, pasando del 15.0.2 al 15.2-1 (SE más reciente), notamos un aumento bastante significativo de la CPU, de un promedio de alrededor del 30% al 60% y más durante las horas de poca 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 el que creen que esto es un error de IOS 15.2-1.

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

Después de reducir nuestros tiempos de espera de ARP, nos mantuvimos estables durante aproximadamente una semana, momento en el que regresamos a IOS 15.0.2-SE4 y eliminamos nuestros tiempos de espera de ARP no predeterminados. La utilización de nuestra CPU se redujo a un ~ 30% y los problemas de nuestra tabla ARP no existen.


1
2017-10-29 13:29



historia interesante ... gracias por compartir, aunque podría ayudar agregar un error para que sea más fácil discernir si el OP está expuesto. Para su información, a menudo es una buena idea mantener su tiempo de espera de ARP más bajo que su temporizador CAM. - Mike Pennington
Gracias por el comentario, pero a la luz del problema original, actualmente estamos usando una versión más baja de IOS en la pila y hemos estado bastante estables durante algún tiempo. @MikePennington de forma predeterminada, el tiempo de espera de ARP se establece en 4 horas y el tiempo de espera de CAM es de 5 minutos. ¿No es este el caso? - Cold T
@ColdT, por eso mencioné esto. Para algunos casos de HSRP, Los temporizadores CAM / ARP de Cisco rompen las cosas por defecto. A menos que haya una razón convincente de lo contrario, establezco mi arp timeout 240 en todas las interfaces SVI / L3 que están frente a un conmutador. - Mike Pennington


Uno sencillo pero tal vez pasado por alto; ¿Sus clientes tienen una puerta de enlace predeterminada válida? ¿No está haciendo muchos arps proxy? ¿Podría considerar la posibilidad de anular la función arp del proxy de IP en su 3750?


0
2017-10-28 21:58