Solución de problemas de una red "lenta"

Todos hemos tenido una queja de que la "red" es "lenta" en algún momento: podría estar ubicada en una habitación (conmutador) o una computadora, podría ser solo Internet (¿DNS? ¿Problema del navegador?), Podría ser solo una aplicación (¿consultas SQL de larga duración? ¿Exploración AV en ejecución?).

Cuando ha descartado problemas obvios del sistema y / o la aplicación, ¿cómo hace para probar una red en busca de lentitud o comportamiento errático? ¿Trabajas para subir las capas OSI? Si es así, ¿cómo hacemos para verificar cada capa? ¿Qué haces para asegurarte de que la red física esté bien en un entorno desconocido? ¿Qué pasa con demasiadas transmisiones o una tormenta de difusión? Capa 3 y superior? traceroute? ¿Algún otro consejo, método, idea? ¿Funciones y herramientas imprescindibles (duplicación de puertos, SNMP, monitoreo, etc.) para todos los tamaños de redes?

tcpdump y wireshark son tus amigos.

Encuentro que mirar paquetes en el cable de una red 'lenta' frente a una red 'buena' suele ser lo que señala un problema.

Hay muchos tipos de 'lento'.

Puede realizar un seguimiento de la latencia a sitios locales y de Internet utilizando una herramienta como SmokePing. (SmokePing se puede configurar para rastrear la latencia ICMP, así como la latencia del servicio de los servicios TCP)

Sus conmutadores deben rastrear los paquetes de difusión frente a los paquetes de unidifusión. Grafica esa razón.

También me gusta monitorear traceroutes (verificar nombres de dominio de saltos de ISP entre sitios "importantes").

Espero que estos comentarios ayuden.

Es difícil dar respuestas específicas, ya que el 90% de este trabajo es una experiencia que le enseña dónde buscar qué tipo de problema, y ​​el otro 90% sabe dónde buscar en Google para obtener pistas sobre dónde comenzar.

Por lo general, pruebo cosas de bolsas de papel, como hacer que el cliente demuestre el problema (principalmente para descartar problemas con los dedos y cualquier problema que el cliente pueda tener al describir su problema), y luego intentar duplicar el problema en otra computadora. Hacer eso a menudo te da una idea de dónde mirar.

No olvide el problema correctivo de un reinicio, especialmente para sistemas Windows, incluso hoy. Solía ​​ser así tanto que le preguntaba a la gente "¿Has reiniciado? Bueno, inténtalo y avísame si el problema persiste", esto solucionó un gran porcentaje de los problemas que me preguntaron.

Con frecuencia también hay problemas de resolución DNS y conectividad básica (ACL en enrutadores, espacios de aire en la red, pings / traceroutes / mtrs a sitios remotos, etc.).

Para los servicios sobre los que tiene control directo, ejecutar nagios o algo para garantizar que el servicio se esté ejecutando con frecuencia puede hacer que solucione problemas antes de que los clientes le informen sobre ellos. Probablemente también desee ejecutar la recopilación de estadísticas, ya sea directamente a través de munin o algo, o mediante SNMP a algo como Cacti.

Por lo general, trato de hacer que Cacti se ejecute contra al menos todos mis conmutadores centrales y firewalls; donde sea posible, ejecuto Cacti contra todo lo que puedo. En estos casos, generalmente busco cosas como conteos de errores de puerto o tráfico excesivo. Los gráficos de firewall de algunos dispositivos pueden mostrarle el uso de la CPU y las sesiones concurrentes; aprenderá a qué umbrales su dispositivo de firewall comienza a tener problemas.

Su cortafuegos puede iniciar sesión en un dispositivo syslog; si es así, registre todo lo que pueda y revise las pistas. Esto será más fácil si ejecuta algo como syslog-ng o rsyslog o splunk que le permite dividir sus registros en lugar de tratar con un archivo monolítico.

También trato de ejecutar nfsen contra al menos el interior de mi firewall y el enlace ascendente al proveedor de Internet cuando sea posible. Esto le permite retroceder en el tiempo para mirar las sesiones y ver quién estaba haciendo qué; Esto a veces puede detectar comportamientos interesantes.

Aquí hay un par de herramientas útiles para solucionar problemas de latencia y otros problemas de red:

• el modo OSI l: comienza desde abajo y avanza hacia arriba
• ping: verifique su RTT (es decir, latencia)
• Ping HTTP : útil si su firewall bloquea los ICMP normales
• ping -r 9: útil para identificar situaciones de enrutamiento asimétrico
• traceroute: ¿cómo llegan mis paquetes allí y cómo responden los enrutadores en el camino? Tenga en cuenta que los enrutadores a menudo procesan estos paquetes con baja prioridad, por lo que el rendimiento real puede ser mejor.
• Wireshark : requiere algo de experiencia, pero no se puede obtener un nivel mucho más bajo
• SpeedGuide.net TCP / IP Analyzer : verifique la configuración TCP de su PC
• SG TCP Optimizer : (solo Windows) sugiere formas de optimizar la configuración de su NIC
• IP Chicken : ¿cuál es su dirección IP de origen (sin NAT)?
• http://downforeveryoneorjustme.com/ - tal vez eres tú ...
• Prueba de velocidad de ancho de banda : compruebe sus velocidades de descarga / carga
• Herramientas de red : ejecute herramientas / pruebas desde fuera de su red
• verifique los puertos de su red en busca de errores / CRC / etc. -
• Verifique su red en busca de sobreutilización (monitores de ancho de banda) y tormentas de difusión
• compruebe si hay inundaciones de unidifusión: use wireshark y controle el tráfico de unidifusión que no esté destinado a su estación de trabajo.
• Verifique que el puente raíz del árbol de expansión esté colocado correctamente

Si está ejecutando una red inalámbrica, una de las ralentizaciones frecuentes es la interferencia de canal. Un montón de SSID en un área realmente puede ralentizar el tráfico de red. (Piense: la demostración del iPhone 4 en WWDC '10).

Resolver este problema es bastante fácil si con un software que puede mostrarle los patrones de tráfico inalámbrico en el área. Hay uno bueno gratuito y basado en la web en: http://meraki.com/tools/stumbler . (divulgación: trabajo para Meraki)

Para reducir la interferencia, es mejor estar en los canales 1, 6 u 11. También puede ayudar el uso de equipos 802.11n con la frecuencia de 5 GHz.

Siempre comienzo con el monitoreo de las cosas de la capa 2 usando Cacti . Eso le dará una buena cantidad de datos que puede usar para buscar patrones y puede comparar sus gráficos Cacti cuando todo funcione bien y cuando los usuarios vean lentitud.

Probablemente no va a encontrar el problema exacto, pero le dará un buen punto de partida para ayudar a reducir el problema.

Comienzo en el enrutador más externo y avanzo hacia abajo, y mido el rendimiento de la manera más primitiva: use un sitio de prueba de ancho de banda o un sitio FTP externo conocido que le dará su velocidad de carga / descarga, y siga bajando hasta que encuentre el nivel donde reside el problema.

Una vez que sepa dónde está el problema, implemente sus sofisticadas herramientas y monitores. Pero no pierdas el tiempo haciendo esas cosas en cada capa. Tomará una eternidad.

También debe conocer sus servidores y su entorno de escritorio / cliente, en lugar de simplemente asumir que el usuario es correcto cuando dice "la red es lenta". Debe solucionar metódicamente cada problema; como han dicho otros, primero debe poder ver e idealmente reproducir el error, y luego trabajar desde allí de una manera que tenga sentido para el escenario.

Sin embargo, tener una buena administración y monitoreo en la red y los servidores puede ahorrarle mucho tiempo, ya que no está tratando de encontrar instrumentación sobre la marcha mientras posiblemente también intenta mitigar o corregir los síntomas, y tratar con usuarios que se quejan. /clientes.

Las respuestas para tcpdump y wireshark no son incorrectas, pueden ser piezas vitales de su kit de herramientas. Pero a menos que estés completamente seguro de que en realidad es la red, no deberían ser lo primero que buscas.

La red lenta es un fenómeno común. La velocidad lenta de la red puede ser causada por varias cosas. solucionar problemas de red lenta es uno de los trabajos más comunes y problemáticos en la administración diaria de la red.

Según el análisis, las principales razones de la red lenta son:

Loopback
Broadcast/Multicast storm
Virus attack
Server slow response
Too many clients
Application slow response
Error client mask

¿Cómo podemos descubrir rápidamente la causa de la red lenta? Es una buena idea capturar y analizar paquetes con un analizador de red (Ax3soft Unicorn, wireshark, etc.).

También lee el artículo "Buscar razones para una red lenta", haciendo clic en la URL ( http://www.ids-sax2.com//Unicorn/Tutorials/Find-Reasons-for-Slow-Network-with-Ax3soft-Unicorn .htm ) para visitarlo.