9 de febrero de 2007

10 causas frecuentes de baja performance de la red

Una red "lenta" o de baja performance es un verdadero problema, no sólo para el Administrador, sino también para la empresa: mal humor en los usuarios, pérdidas de productividad, sobrecarga de trabajo para el personal de soporte...

Como Administradores suele ocurrirnos que cuando esto ocurre (sobre todo si estamos en medio de un proyecto nuevo o una implementación) pensemos inmediatamente que se trata de un problema de alto nivel. Pero no siempre es así y muchas veces se puede obtener una mejora importante son sólo resolver (y si es posible prevenir) algunos de los elementos que suelen contribuir más frecuentemente a generar problemas o congestión en la red.

Por eso es importante que antes de apuntar a problemas de configuración o implementación más serios revisemos la la siguiente lista de problemas que afectan con mayor frecuencia la performance de la red:

  • Placas de red defectuosas.
    Un problema frecuente es la presencia de nodos con placas de red defectuosas. Cuando se detectan errores intermitentes, sobre todo cuando están relacionados con una estación de trabajo o servidor en particular, suelen deberse generalmente a este problema.
    En este caso el primer paso es verificar el LED de la placa de red. Un LED que está fijo en verde indica en general una placa de red con una conexión física en buen estado. Un LED que parpadea suele indicar que la conexión está activa y procesando tráfico de la red.
    Si el LED no se ilumina en verde, nos está indicando que la placa está deshabilitada en Windows o que no tiene una conexión activa con la red. Puede ser que el cable de conexión esté defectuoso, no sea el correcto, o está conectado a una boca de switch que está deshabilitada.
    Si la conexión a la red es correcta (se puede verificar fácilmente conectando en el mismo cable una terminal que sabemos funciona correctamente), y la placa está adecuadamente habilitada y configurada en Windows, el paso siguiente es reemplazar la placa de red.
  • Fallas en switches o routers.
    En algunos casos los problemas de la red pueden parecer inconsistentes. Por ejemplo, mientras no perdemos navegación web en la red, el servicio de correo electrónico "se pierde", o falla otro tipo de servicios como el de https. En otros casos, aún cuando mantenemos una buena conexión de red el acceso a Internet es imposible.
    Si tenemos conectividad local pero se ha perdido parcial o totalmente el acceso a recursos de Internet, el problema puede solucionarse frecuentemente reiniciando el equipo de acceso a Internet.
    Cuando los problemas son de conectividad local, o simplemente se trata de una red switcheada pero excesivamente lenta, el problema puede solucionarse reiniciando el switch de acceso.
    Si estos problemas son consistentes y frecuentes, es necesario revisar ante todo la calidad del suministro eléctrico, las fluctuaciones en el suministro de energía puede provocar errores e incluso daños en el hardware de routers y switches. Si no se trata de un problema de suministro eléctrico, la solución más cierta será el reemplazo del dispositivo defectuoso.
  • Conexión de dispositivos en "daisy chaining".
    Aún en redes corporativas importantes, el crecimiento de los requisitos de conectividad suele ser "causa de problemas": para dar lugar a una nueva conexión la solución más simple para el usuario suele ser conectar un hub o pequeño switch a una boca de red ya existente.
    Cuando esto ocurre, las tramas de datos deben recorrer cada vez mayor cantidad de saltos para alcanzar su destino. Cada salto que se agrega puede ser un problema potencial. No sólo porque agrega uno o varios puntos de fallos nuevos, sino también porque introduce mayor delay en la transacción. En muchos casos el agregado de uno o dos saltos en una comunicación es una diferencia notable en la performance.
    Hay que resistirse a "cascadear" o "encadenar" switches o hubs. Hay que reemplazar esta mala práctica por una adecuada planificación de los recursos en función del crecimiento. Y si el crecimiento explosivo produce este efecto no querido, reorganizar la red procurando consolidar lo que está disperso en varios dispositivos pequeños en un único dispositivo más potente y escalable.
  • Conflictos de NetBIOS.
    NetBIOS es aún un protocolo implementado en muchas redes para administrar algunos recursos. Sin embargo frecuentemente no trabaja adecuadamente provocando que algunos recursos como los archivos compartidos se vuelvan inaccesibles provocando congestión en la red y a veces cortes de servicio.
    Comportamientos extraños en los recursos de red se pueden producir cuando dos sistemas tienen el mismo nombre o cuando cumplen el mismo rol. Deshabilitar el servicio de resolución de nombres WINS/NetBT (cuando no es necesario) puede solucionar este problema.
    Si no es posible deshabilitar el servicio, se deberá entonces identificar cuáles son los dispositivos en conflicto para poder renombrar a uno de ellos.
  • Conflictos de IP.
    Los servicios de DHCP en general, implemetan sistemas que les permiten prevenir que 2 nodos utilicen la misma dirección IP (en el caso de Cisco IOS, antes de asignar una dirección IP verifica que no se encuentra activa en la red utilizando ping). Sin embargo, ocasionalmente puede ocurrir que 2 dispositivos tengan asignada la misma dirección IP, por ejemplo porque uno de ellos ha sido configurado estáticamente. Este conflicto provoca una caída de performance de la red.
    Para solucionar este problema ante todo es conveniente asegurarse de que no se haya conectado un servidor DHCP clandestinamente en la red. A continuación es necesario verificar la configuración de DHCP para asegurarse de que no haya superposición de rangos de direcciones IP con aquellas direcciones IP que se asignan estáticamente a servidores y demás dispositivos.
  • Exceso de aplicaciones que operan sobre la red.
    En muchos casos se corren aplicaciones que requieren recursos superiores a los que puede proporcionar la red y que no han sido adecuadamente previstos.
    Por ejemplo, es frecuente que en empresas que utilizan sistemas de información que realizan consultas frecuentes sobre bases de datos, no se haya previsto adecuadamente el modo en que opera la aplicación, y que las consultas a la base de datos generen congestión sobre la red en los horarios pico.
    Adicionalmente hay que tener presente que en la actualidad hay múltiples aplicaciones (desde los sistemas de VoIP hasta aplicaciones de audio y video sobre Internet) que generan tráfico de cadenas de paquetes sobre UDP que tienden a ocupar todo el ancho de banda disponible. Una combinación de estos elementos puede volver excesivamente lenta aún una red FastEthernet de 100Mbps.
    En estos casos la definición de políticas, y en algunos casos la implementación de filtros basados en hardware, son necesarios para preservar la performance de la red y reservar los recursos necesarios para las aplicaciones que son críticas para el desenvolvimiento de la empresa. Cuando se trabaja con sistemas de Telefonía IP es preciso asegurarse antes que se cuenta con los recursos necesarios para manejar el tráfico de voz y el de datos.
  • Infecciones con spyware.
    El spyware es ciertamente un problema creciente en aquellas redes que tienen algún tipo de acceso a los servicios de Intenet.
    La implementación de políticas de uso en la empresa, a la par que la implementación de herramientas anti-spyware son necesarios para reducir el impacto de este tipo de ataque sobre el desenvolvimiento de la red.
  • Infecciones de virus.
    No por conocido está suficiente previsto este riesgo.
    Hay múltiples posibilidades de infección con virus, sobre todo en redes que operan conectadas a Internet (lo que hoy es casi regla).
    En este punto la insistencia sobre el respecto estricto de las políticas de uso, y la permanente actualización de la infraestructura de seguridad de la red son elementos necesarios.
    Ante un problema de performance que irrumpe de un momento a otro, nunca está de más un escaneo de virus en las temrinales de la red. Una sola terminal infectada accidentalmente puede estar generando miles de correos electrónicos que congestinan todos nuestros recursos.
  • Insuficiente ancho de banda.
    A veces, ciertamente se trata sólo de que el comportamiento actual de la red requiere mayor ancho de banda. Sobre todo cuando se han revisado las aplicaciones de red en uso, y se acuerda en que es necesario mantenerlas en su uso actual, entonces es evidente que el ancho de banda actual es insuficiente.
    Dependiendo de la estructura y uso de la red, en este caso suele ser recomendable un rediseño que considere tanto los accesos WAN o a Internet, como la expansión de ancho de banda en distintos puntos del backbone y el reemplazo de hubs y switches genéricos. Muchas veces un rediseño con una mejor asignación de subredes y VLANs permite un mejor aprovechamiento de los recursos de ancho de banda existentes.
  • Errores de configuración de DNS.
    Los errores en la configuración de DNS pueden provocar numerosos herreres y una baja de performance generalizada.
    Cuando no hay un servidor DNS local, o cuando el servidor está ubicada a varios saltos dentro de la red, las estaciones de trabajo pueden experimentar un delay importante en el acceso a algunos recursos por la demora que se introduce en el proceso de resolución de nombres.
    Lo ideal es que el servidor DNS esté ubicado tan próximo como sea posible a los recursos de red.
    Es importante verificar periódicametne que las terminales cuentan con la configuración adecuada y que se servidor DNS primario es el que puede alcanzar con mayor facilidad y rapidez.

Estos son algunos puntos, quizás los más recurrentes. Si de tu experiencia se desprenden otras recomendaciones o ítems a tener encuenta, agregalos en forma de comentario en el presente post.

Muchas gracias.

Oscar Gerometta

10 comentarios:

  1. Muy buen post, lamentablemente para las cosas importantes nadie postea.
    Gracias Oscar muy importante la data que pusiste.

    ResponderEliminar
  2. Si, la verdad esta bastante buena la información, como para iniciar una revision completa del estado de la red. un tema que frecuentemente se deja de lado en las empresas.

    saludos.

    ResponderEliminar
  3. Excelente post. EN realidad es impresionante el tiempo que le dedicas al apoyo del resto de personas, si tuvieras un correo para compartir datos, o experiencias seria fenomelas. Muy agradecido.

    ResponderEliminar
    Respuestas
    1. Amigo.
      En la columna de la derecha tienes los accesos a las comunidades de Facebook y Google+ donde encontrarás una comunidad muy amplia que debate y comparte experiencias y conocimientos.
      Te esperamos.

      Eliminar
  4. Muy buen aporte, ,,, Tengo una red de con internet de 10 mb , y en siertas ocasiones la red se pone muy lenta , tal es el punto que llega a bajar a 2.3 mb/s alguna idea de que podria ser ,, ahh en la red existen 15 pc mas el servidor , pero solo las terminales usan internet en el dia entre ellas 6 pc usan RDP conexion remoto a servicio en la nube. gracias de antemano por la ayuda que puedan aportar.

    ResponderEliminar
    Respuestas
    1. Estimado.
      En este caso estás hablando de 10 Mbps de acceso a Internet, no de performance de tu red interna.
      En el acceso a Internet los factores que impactan son múltiples y diferentes, dependiendo en mucho de la tecnología de última milla a la vez que el recorrido que se debe hacer desde origen hasta destino. Nadie tiene control de la ruta completa, sino solamente de una parte de esa ruta.
      Consecuentemente, tu medición de 2,3 Mbps puede deberse a múltiples factores diferentes, incluyendo que seguramente estás haciendo esa medición desde una terminal mientras tienes otras 14 operando sobre el mismo acceso.

      Eliminar
  5. Manuel Santillanmayo 08, 2016 6:21 p.m.

    Excelente material, gracias por compartir conocimiento.

    ResponderEliminar
  6. Tengo una red LAN corporativa con diferentes marcas de switches... Entre ellas Cisco. SIEMPRE cuando hemos tenido una falla en la red... Hemos aislado las fibras (áreas) y se identifica el área hasta tener el dispositivo que genera los problemas y desconectarlo. ... En esta oportunidad (por primera vez luego de anos) casi toda la red se congestiono y al aislar... No se logro identificar de donde vienen los saltos en algunos switches... Luego de muchas pruebas se identifico que los switches principales (Cisco 4506) estaban de alguna manera desestabilizando red (por lo menos eso se concluyo)... Ellos eran los que más afectaban realmente porque su inestabilidad alteraba el funcionamiento de los servidores directamente conectados a ellos... Luego de varios proveedores y semanas... Se decidió actualizar el IOS del los dos switches principales 4506..(los trabajadores hacían sus labores pero con problemas... Y algunos dispositivos eran mucho más sensibles que otros(normal)... Los AP... Solo funciona la banda de 5 Ghz en la de 2 Ghz dice "conectando..." pero no conecta o si lo hace se desconecta de inmediato)... Lo cual corrigió la inestabilidad en al menos de esos dos equipos principales 4506... Pero algunas áreas seguían con perdidas de paquetes...

    Al día de hoy... Estamos por actualizar también el IOS de estos switches 3500 que están por debajo de los dos 4506... Para ver si con eso se corrige también la perdida de paquetes de estos switches 3500. Se descarto totalmente los hilos de fibra, conectores, módulos... Hasta ahora es un tema de los IOS... Que por alguna razón en un momento muy especifico comenzaron a dar problemas... Lo extraño es que unos 15 router inalámbricos (configurados como AP) están totalmente inhibidos..(no responden sus LAN IP) y los que están conectados a switches que NO son marca Cisco si responden

    (Y navegan los dispositivos) ... Aun estando esos switches conectados a los cisco en cascada...

    Es primera vez que veo algo como esto... Se observa un alto ARP Input y alto consumo de procesador 60-95% en los equipos que más perdida de paquetes tienen... Es como si algo se hubiese actualizado solo en todos estos equipos Cisco y hubiesen iniciado los problemas... Prácticamente esta descartado cualquier dispositivo en la red generado la intermitencia... Porque hasta dejando los dos 4506 frente a frente sin los 3500 nos daban perdidas y alto procesador antes de la actualización de sus IOS.

    ¿Mi pregunta es... Que pudo haber generado que casi todos los switches Cisco... Comenzaran a dar problemas de forma inesperada...? ¿Hay otra manera de corregir?...

    Luego de la actualización de los 4506 ya los trabajadores pueden ver los servidores con normalidad... Pero aun los inalámbricos están muertos casi todos... Sobre todo a 2.4 Ghz.

    ResponderEliminar
    Respuestas
    1. Carlos.
      Con la descripción que haces es muy difícil siquiera pensar cuál es la causa real del problema.
      Los switches no se actualizan solos (no son Windows) y si nada cambió en la red, eso indica que algo cambio. Lo que quiero decir es que los inconvenientes no aparecen sin razón alguna de un día para otro. Y si desde la gestión de la red no se hizo ninguna modificación... lo más probable sería un problema de seguridad.
      Hay cosas muy extrañas en tu relato, como la referencia que haces a la operación de los APs que sólo ven afectada su radio de 2,4 GHz. Normalmente la operación del switch no impacta de esa forma en la del AP. Hay algo más.
      Claro que si hacen cambios sin un diagnóstico claro del problema, se vuelve más difícil detectar el problema inicial y resolverlo... y lo que es peor, si es una falla de seguridad y no se atiende, persiste.
      Lo único que me atrevo a decir es que busquen alguien que los ayude a hacer un diagnóstico preciso del problema, para tener claro qué es lo que hay que corregir; y no hacer cambios o actualizaciones sin conocer el problema, ya que podría simplemente empeorarlo o no tener efecto alguno.

      Eliminar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.