La pequeña universidad donde trabajo tiene algunos problemas de red muy extraños. Estoy buscando algún consejo o idea aquí. Estuvimos bien durante el verano, pero el problema comenzó pocos días después de que los estudiantes regresaron al campus en vigencia para el período de otoño.
Síntomas
El síntoma principal es que el acceso a Internet funcionará, pero es muy lento ... a menudo hasta el punto de espera. Como ejemplo, un resultado típico de Speedtest.net devolverá una descarga de .4Mbps, pero permitirá una velocidad de carga de 3 a 8 Mbps. Los síntomas menores pueden incluir un rendimiento muy limitado al transferir datos hacia y desde nuestro servidor de archivos, o incluso en algunos casos la imposibilidad de iniciar sesión en la computadora (no puede llegar al controlador de dominio). El problema cruza múltiples vlans y ha afectado a los dispositivos en casi todas las vlan que operamos.
El problema no afecta a todas las máquinas en la red. Una máquina no afectada generalmente verá una descarga de al menos 11Mbps de speedtest.net, y quizás mucho más dependiendo de los patrones de tráfico más grandes del campus en ese momento.
Hay una variación en el tema más amplio. Tenemos una vlan donde los usuarios no pudieron iniciar sesión en casi todas las máquinas. El personal de TI iniciaría sesión con una cuenta de administrador local (o, en algunos casos, con credenciales almacenadas en caché) y, a partir de ahí, liberar / renovar o hacer ping a la puerta de enlace permitiría que la máquina funcione ... por un tiempo. Para complicar este problema, este vlan cubre nuestros laboratorios de computadoras, que usan un software llamado Deep Freeze para restablecer completamente los discos duros después de un reinicio. Podría ser el mismo problema que se manifiesta de manera diferente debido a los datos obsoletos en las máquinas que no han alterado permanentemente la información de bajo nivel durante semanas. Sin embargo, pudimos resolver esto creando un nuevo vlan y trasladando los laboratorios al nuevo vlan al por mayor.
Instigations
Eventualmente notamos que todas las máquinas afectadas tenían arriendos recientes de dhcp. Podemos predecir cuándo una máquina se volverá "lenta" observando cuándo se presentará un contrato de arrendamiento de dhcp para su renovación. Jugamos con establecer el tiempo de arrendamiento muy corto para una prueba vlan, pero todo lo que hizo fue eliminar nuestra capacidad de predecir cuándo la máquina se volvería lenta. Las máquinas con IP estáticas casi siempre han funcionado normalmente. Liberar / renovar manualmente una dirección nunca hará que una máquina se vuelva lenta. De hecho, en algunos casos este proceso ha solucionadoUna máquina en ese estado. Sin embargo, la mayoría de las veces no ayuda. También notamos que es probable que las máquinas móviles como las computadoras portátiles se vuelvan lentas cuando se cruzan a nuevas vlans. La conexión inalámbrica en el campus se divide en "zonas", donde cada zona se asigna a un pequeño conjunto de edificios. Mudarse a un nuevo edificio puede ubicarlo en una zona y, por lo tanto, obtener una nueva dirección. Es muy probable que una máquina que se reanuda desde el modo de suspensión sea lenta.
Mitigaciones
A veces, pero no siempre, limpiar el caché de arp en una máquina afectada permitirá que vuelva a funcionar normalmente. Como ya se mencionó, liberar / renovar la dirección IP de una máquina local puede reparar esa máquina, pero no está garantizado. Hacer ping a la puerta de enlace predeterminada también a veces puede ayudar con una máquina lenta.
Lo que parece ayudar más a mitigar el problema es borrar el caché de arp en nuestro conmutador core layer-3. Este interruptor se usa para nuestro sistema dhcp como la puerta de enlace predeterminada en todos los vlans, y maneja el enrutamiento entre vlan. El modelo es un 3Com 4900SX. Para tratar de mitigar el problema, tenemos el tiempo de espera de caché configurado en el switch hasta el tiempo más bajo posible, pero no ha ayudado. También armé un script que se ejecuta cada pocos minutos para conectarse automáticamente al conmutador y restablecer la memoria caché. Desafortunadamente, esto no siempre funciona, e incluso puede causar que algunas máquinas terminen en el estado lento por un corto tiempo (aunque parece que se corrigen después de unos minutos). Actualmente tenemos un trabajo programado que se ejecuta cada 10 minutos para forzar al interruptor central a borrar su caché ARP, pero esto está lejos de ser perfecto o deseable.
Reproducción
Ahora tenemos una máquina de prueba que podemos forzar en el estado lento a voluntad. Está conectado a un conmutador con puertos configurados para cada uno de nuestros vlans. Hacemos que la máquina sea lenta conectándose a diferentes vlans, y después de una o dos conexiones nuevas será lenta.
También vale la pena señalar en esta sección que esto ha sucedido antes al comienzo de los términos anteriores, pero en el pasado el problema desapareció por sí solo después de unos días. Se resolvió por sí solo antes de que tuviéramos la oportunidad de hacer mucho trabajo de diagnóstico ... por eso hemos permitido que se demore tanto en el término esta vez; la expectativa era que esta sería una situación de corta duración.
Otros factores
Vale la pena mencionar que hemos tenido alrededor de media docena de interruptores que fallaron en el último año. Estos son principalmente 3Coms de la era 2003/2004 (en su mayoría 4200) que se colocaron aproximadamente al mismo tiempo. Todavía deben estar cubiertos por la garantía, comprar HP ha dificultado un poco el servicio. Principalmente en las fuentes de alimentación que han fallado, pero en un par de casos hemos utilizado una fuente de alimentación de un interruptor con una placa base defectuosa para volver a la vida a un interruptor con una fuente de alimentación defectuosa. Ahora tenemos dispositivos UPS en todos menos tres de los cuatro conmutadores, pero ese no era el caso cuando comencé hace dos años y medio. Las restricciones presupuestarias severas (estábamos en la lista de instituciones con dificultades financieras del Departamento de Ed hace un par de años) me han obligado a buscar reemplazos en Netgear y TrendNet,
También vale la pena mencionar que el gran cambio en nuestra red este verano fue la migración de un único SSID inalámbrico entre campus al enfoque por zonas mencionado anteriormente. No creo que esta sea la fuente del problema, como he dicho: hemos visto esto antes. Sin embargo, es posible que esto esté exacerbando el problema, y puede ser una de las razones por las que ha sido tan difícil de aislar.
Diagnóstico
Al principio nos pareció claro, dado el momento y la naturaleza persistente del problema, que la fuente del problema era una máquina de estudiante infectada (o maliciosa) que envenenaba el caché ARP. Sin embargo, los intentos repetidos de aislar la fuente han fallado. Esos intentos incluyen numerosos rastros de paquetes de Wirehark e incluso desconectar edificios enteros durante breves períodos. Ni siquiera hemos podido encontrar una pistola humeante con una entrada ARP mala. Mi mejor suposición actual es un interruptor central sobrecargado o defectuoso, pero no estoy seguro de cómo probar esto, y el costo de reemplazarlo a ciegas es elevado.
De nuevo, cualquier idea apreciada.
Actualización:
se reemplaza el interruptor central. Después de 4 días, todo está funcionando bien ... pero esperaré la marca de dos semanas antes de resolver el problema.
fuente
mtrpuede ser útil aquíRespuestas:
Joel
Dado que tiene la configuración de troncales y puede duplicar el problema a voluntad. Instale Wireshark en una computadora portátil y refleje / abarque un puerto de enlace ascendente. Si ve una tasa de paquetes superior a 10.000 o la utilización del puerto cerca de la velocidad máxima, tiene un problema.
Es posible que tenga un problema de hardware / árbol de expansión incorrecto. Normalmente he encontrado usuarios que conectan ambas unidades de red en su máquina "para obtener más rendimiento".
Normalmente, para problemas de árbol de expansión, puede activar la detección de bucle o la limitación de transmisión por puerto de su proveedor. Esto matará cualquier puerto con un bucle encontrado. También puede activar la "protección bpdu", lo que significa deshabilitar el puerto en el que se recibió bpdu y lanzar un error a los receptores syslog / snmp trap.
Joe
fuente
He visto problemas similares a esto antes y ha sido un bucle en la LAN, lo que causa el caos y la saturación de toda la subred (presumiblemente por el tráfico de transmisión debido a que el conmutador ve su propio MAC en un puerto adicional).
EDITAR: Además, esto es común en los establecimientos educativos (dos de mis trabajos anteriores de administrador de sistemas) ya que a los pequeños les gusta jugar con cables de conexión / enchufes ...
fuente
Me parece que tienes un hardware defectuoso que causa tormentas de transmisión. Usa Wireshark para ver transmisiones y encontrar un anfitrión que te dé problemas ...
fuente
La idea de Joe es buena, pero dado que no es probable que sea una tormenta de difusión que genere su problema (creo que está en el camino correcto con el envenenamiento de caché ARP o un problema similar; incluso podría ser un conflicto de dirección IP), probablemente no resolverá el problema.
Una técnica relacionada para utilizar la inspección dinámica de ARP y DHCP, si sus conmutadores lo admiten. Si activa esta opción, los conmutadores verán las transacciones DHCP y solo permitirán entradas ARP que coincidan con las entradas conocidas en la base de datos DHCP o las que haya especificado manualmente.
Si sus conmutadores no tienen esta función, otra opción para rastrearla es la utilidad arpwatch de Linux: realiza un seguimiento de todas las solicitudes ARP y le informa cuándo nota un cambio de mapeo IP-MAC.
fuente