Capítulo 35: Solución de problemas de red

Si una red o una parte de una red queda fuera de servicio, esto puede tener un impacto negativo importante en la empresa. Cuando ocurren problemas en la red, los administradores deben usar un enfoque sistemático de resolución de problemas a fin de que la red vuelva a funcionar completamente lo antes posible.

La capacidad de un administrador de red para resolver problemas de red de manera rápida y eficaz es una de las habilidades más buscadas en TI. Las empresas necesitan personas con habilidades sólidas de resolución de problemas de red, y la única forma de obtener estas habilidades es a través de la experiencia práctica y el uso de métodos sistemáticos de resolución de problemas.

Este capítulo describe los procedimientos generales de solución de problemas, los métodos, las herramientas y la documentación de red que deben conservarse. También se analizan los síntomas y las causas típicos en distintas capas del modelo OSI.

Documentación de la red

Para que los administradores de red puedan monitorear y resolver problemas de red, deben tener un conjunto completo de documentación de red precisa y actual. Esta documentación incluye:

Archivos de configuración, incluidos los de la red y los del sistema final

Diagramas de topología física y lógica

Niveles de rendimiento de referencia

La documentación de red permite que los administradores de red diagnostiquen y corrijan de manera eficaz los problemas de la red, según el diseño y el rendimiento esperado de la red en condiciones de operación normales. Toda la información de documentación de red debe guardarse en una misma ubicación, ya sea como copia local o en un servidor protegido de la red. Debe realizarse una copia de seguridad del registro, la que se debe conservar en una ubicación diferente.

Archivos de configuración de red

Los archivos de configuración de red contienen registros precisos y actualizados del hardware y el software usados en una red. En los archivos de configuración de la red, debe existir una tabla para cada dispositivo de red utilizado con toda la información relevante sobre ese dispositivo.

Por ejemplo, la figura 1 muestra una tabla de configuración de red de ejemplo para dos routers, mientras que la figura 2 muestra una tabla similar para un switch LAN.

La información que se podría reunir en una tabla de dispositivo incluye lo siguiente:

Tipo de dispositivo, designación de modelo

Nombre de la imagen del IOS

Nombre de host de red del dispositivo

Ubicación del dispositivo (edificio, piso, sala, rack, panel)

Si es modular, incluya todos los tipos de módulo y números de ranura.

Direcciones de la capa de enlace de datos

Direcciones de la capa de red

Cualquier información adicional importante sobre los aspectos físicos del dispositivo

Archivos de configuración del sistema final

Los archivos de configuración del sistema final se centran en el hardware y el software usados en los dispositivos del sistema final, como servidores, consolas de administración de red y estaciones de trabajo de los usuarios. Un sistema final configurado incorrectamente puede tener un impacto negativo en el rendimiento general de una red. Por este motivo, para resolver problemas, puede ser muy útil tener un registro de línea de base de muestra del hardware y del software usado en los dispositivos incluido en el registro del sistema final, como se muestra en la figura 3.

Para resolver problemas, se podría registrar la siguiente información en la tabla de configuración del sistema final:

Nombre del dispositivo (propósito)

Sistema operativo y versión

Direcciones IPv4 e IPv6

Máscara de subred y longitud de prefijo

Gateway predeterminado y servidor DNS

Todas las aplicaciones de red con uso intensivo de ancho de banda utilizadas en el sistema terminal

Diagramas de topología de la red

Diagramas de topología de la red

Los diagramas de topología de la red mantienen un registro de la ubicación, la función y el estado de los dispositivos en la red. Hay dos tipos de diagramas de topología de la red: la topología física y la topología lógica.

Topología física

Una topología física de la red muestra la distribución física de los dispositivos conectados a la red. Para resolver problemas de la capa física, es necesario conocer la forma en que los dispositivos están conectados físicamente. La información registrada en el diagrama generalmente incluye:

Tipo de dispositivo

Modelo y fabricante

Versión del sistema operativo

Tipo de cable e identificador

Especificación del cable

Tipo de conector

Extremos de cables

En la figura 1, se muestra un ejemplo de un diagrama de topología física de la red.

Topología lógica

La topología lógica de la red ilustra la forma en que los dispositivos se conectan a la red de manera lógica, es decir, cómo los dispositivos transfieren datos a través de la red al comunicarse con otros dispositivos. Los símbolos se usan para representar los elementos de la red, como routers, servidores, hosts, concentradores VPN y dispositivos de seguridad. De manera adicional, se pueden mostrar conexiones entre varios sitios, pero no representan ubicaciones físicas reales. La información registrada en un diagrama de red lógico puede incluir lo siguiente:

Identificadores de dispositivos

Dirección IP y longitudes de prefijos

Identificadores de interfaz

Tipo de conexión

DLCI de retransmisión de tramas para circuitos virtuales (si corresponde)

VPN de sitio a sitio

Protocolos de enrutamiento

Rutas estáticas

Protocolos de enlace de datos

Tecnologías WAN utilizadas

En la figura 2, se muestra un ejemplo de topología lógica de red IPv4. Si bien las direcciones IPv6 también se podrían mostrar en la misma topología, puede resultar más claro crear un diagrama separado de topología lógica de red IPv6.

Establecimiento de una línea de base de red

El monitoreo de red permite controlar el rendimiento de la red con respecto a la línea de base predeterminada. Para establecer el rendimiento normal de una red o un sistema, se usa una línea de base. Para establecer una línea de base de rendimiento de la red, es necesario reunir datos sobre el rendimiento de los puertos y los dispositivos que son esenciales para el funcionamiento de la red. La figura muestra varias preguntas que deberían responderse con la línea de base.

Medir el rendimiento y la disponibilidad iniciales de los dispositivos y enlaces de red fundamentales permite que un administrador de red determine la diferencia entre un comportamiento anormal y un rendimiento correcto de la red, a medida que esta crece o cambian los patrones de tráfico. Una línea de base también proporciona información sobre si el diseño actual de la red puede satisfacer los requisitos comerciales. Sin una línea de base, no existe ningún estándar para medir la naturaleza óptima de los niveles de tráfico y congestión de la red.

Un análisis después de establecer una línea de base inicial también tiende a revelar problemas ocultos. Los datos reunidos muestran la verdadera naturaleza de la congestión, o la congestión potencial, en una red. También puede revelar las áreas de la red que están infrautilizadas y, con bastante frecuencia, puede originar esfuerzos para rediseñar la red sobre la base de las observaciones de calidad y capacidad.

Pasos para establecer una línea de base de red

La línea de base inicial de rendimiento de la red prepara el terreno para medir los efectos de los cambios en la red y de las tareas de solución de problemas posteriores. Por lo tanto, es importante planificarla cuidadosamente.

Para establecer y capturar una referencia de red inicial, haga lo siguiente:

Paso 1. Determine qué tipos de datos se deben reunir.

Al establecer la línea de base inicial, comience por seleccionar algunas variables que representen a las políticas definidas. Si se seleccionan demasiados puntos de datos, la cantidad de datos puede ser abrumadora, lo que dificulta el análisis de los datos reunidos. Comience de manera simple y realice ajustes a lo largo del proceso. Para comenzar, algunas medidas útiles son el uso de interfaz y el uso de CPU.

Paso 2. Identifique los dispositivos y los puertos de interés.

Use la topología de la red para identificar aquellos dispositivos y puertos para los que se deben medir los datos de rendimiento. Los dispositivos y los puertos de interés incluyen:

Puertos de dispositivos de red que se conectan a otros dispositivos de red

Servidores

Usuarios principales

Cualquier otro elemento que se considere fundamental para las operaciones

Un diagrama de topología lógica de la red puede ser útil en la identificación de los dispositivos y los puertos principales que se van a supervisar. Por ejemplo, en la figura 1, el administrador de red resaltó los dispositivos y los puertos de interés que se supervisarán durante la prueba de la línea de base. Los dispositivos de interés incluyen la PC1 (la terminal de administración) y el SRV1 (el servidor web/TFTP). Los puertos de interés incluyen aquellos puertos en los routers R1, R2 y R3 que se conectan a otros routers o a los switches y, en el R2, el puerto que se conecta al SRV1 (G0/0).

Al reducir la lista de puertos que se sondean, los resultados son concisos, y se minimiza la carga de administración de la red. Recuerde que una interfaz en un router o un switch puede ser una interfaz virtual, como una interfaz virtual de switch (SVI).

Paso 3. Determine la duración de la línea de base.

Para establecer una imagen típica de la red, la duración y la información de la línea de base que se reúne deben ser suficientes. Es importante que se monitoreen las tendencias diarias del tráfico de la red. También es importante monitorear las tendencias que se producen durante un período más prolongado, como semanas o meses. Por este motivo, al capturar datos para su análisis, el período especificado debe tener, como mínimo, una duración de siete días.

En la figura 2, se muestran ejemplos de varias capturas de pantalla de las tendencias del uso de CPU obtenidas durante un día, una semana, un mes o un año. En este ejemplo, observe que las tendencias de la semana de trabajo son demasiado cortas para revelar el pico de uso recurrente que se produce el sábado por la noche, cada fin de semana, cuando una operación de copia de seguridad de la base de datos consume ancho de banda de la red. Este patrón recurrente se revela en la tendencia mensual. Una tendencia anual, como la que se muestra en el ejemplo, puede ser demasiado prolongada para proporcionar detalles significativos sobre el rendimiento de línea de base. Sin embargo, puede ayudar a identificar patrones a largo plazo que se deben analizar en profundidad. Generalmente, las líneas de base no se deben extender durante más de seis semanas, salvo que se deban medir tendencias específicas a largo plazo. Por lo general, una línea de base de dos a cuatro semanas es adecuada.

Las mediciones de una línea de base no se deben realizar durante momentos de patrones de tráfico únicos, dado que los datos proporcionarían una representación imprecisa de las operaciones normales de la red. El análisis de línea de base de la red se debe realizar periódicamente. De manera rotativa, realice un análisis anual de toda la red o analice la línea de base de diferentes secciones de la red. Para entender la forma en que el crecimiento y otros cambios afectan la red, el análisis se debe realizar periódicamente.

Medición de los datos

Al documentar la red, con frecuencia es necesario reunir información directamente de los routers y los switches. Los comandos obvios y útiles para la documentación de red incluyen ping, traceroute y telnet, así como los siguientes comandos show:

Los comandos show ip interface brief y show ipv6 interface brief se usan para mostrar el estado activo o inactivo y la dirección IP de todas las interfaces en un dispositivo.

Los comandos show ip route y show ipv6 route se usan para mostrar la tabla de routing de un router a fin de detectar los vecinos conectados directamente, los dispositivos remotos adicionales (a través de las rutas detectadas) y los protocolos de routing que se configuraron.

El comando show cdp neighbors detail sirve para obtener información detallada sobre los dispositivos vecinos de conexión directa de Cisco.

La figura detalla algunos de los comandos más comunes de Cisco IOS para la recopilación de datos.

La recolección manual de datos mediante los comandos show en dispositivos de red individuales puede tomar muchísimo tiempo y no es una solución escalable. Por esa razón, la recolección manual de datos se debe reservar para las redes más pequeñas o aquellas que se limitan a los dispositivos de red esenciales. Para diseños de red más simples, en las tareas de línea de base por lo general se combinan la recolección manual de datos con inspectores de protocolos de red simples.

Suele usarse software sofisticado de administración de redes para establecer los valores de referencia de las redes grandes y complejas. Estos paquetes de software permiten que los administradores creen y revisen automáticamente los informes, comparen los niveles de rendimiento actuales con las observaciones históricas, identifiquen automáticamente los problemas de rendimiento y creen alertas para las aplicaciones que no proporcionan los niveles esperados de servicio.

Establecer una línea de base inicial o realizar un análisis de monitoreo del rendimiento puede requerir muchas horas o muchos días para reflejar el rendimiento de la red con precisión. Con frecuencia, el software de administración de red o los inspectores y analizadores de protocolos se ejecutan continuamente a lo largo del proceso de recolección de datos.

Procedimientos generales de resolución de problemas

La resolución de problemas ocupa gran parte del tiempo de los administradores de red y del personal de soporte. Al trabajar en un entorno de producción, el uso de técnicas eficaces de resolución de problemas reduce el tiempo total dedicado a esta tarea.

Hay tres etapas principales en el proceso de resolución de problemas:

Etapa 1. Recopilación de síntomas: la solución de problemas comienza con la recopilación y documentación de síntomas de la red, los sistemas terminales y los usuarios (figura 1). Además, el administrador de red determina qué componentes de la red se vieron afectados y de qué forma cambió la funcionalidad de la red en comparación con la línea de base. Los síntomas pueden aparecer de distintas maneras, que incluyen alertas del sistema de administración de red, mensajes de la consola y quejas de los usuarios. Mientras se recolectan los síntomas, es importante que el administrador de red realice preguntas e investigue el problema para restringirlo a una variedad de posibilidades más reducida. Por ejemplo, ¿el problema se limita a un único dispositivo, un grupo de dispositivos, una subred completa o una red de dispositivos?

Etapa 2. Aislación del problema: la aislación es el proceso de eliminar variables hasta identificar la causa, que puede ser un único problema o un conjunto de problemas relacionados (figura 2). Para realizar esto, el administrador de red examina las características de los problemas en las capas lógicas de la red para poder seleccionar la causa más probable. En esta etapa, el administrador de red puede recopilar y registrar más síntomas, según las características que se identifiquen.

Etapa 3. Implementación de medidas correctivas: una vez identificada la causa del problema, el administrador de redes intenta corregirlo mediante la implementación, prueba y documentación de posibles soluciones (figura 3). Después de encontrar el problema y determinar una solución, es posible que el administrador de red deba decidir si la solución se puede implementar inmediatamente o si se debe posponer. Esto depende del impacto de los cambios en los usuarios y en la red. La gravedad del problema se debe ponderar en comparación con el impacto de la solución. Por ejemplo, si un servidor o un router fundamentales deben permanecer sin conexión durante una cantidad significativa de tiempo, tal vez sea mejor esperar hasta el final del día de trabajo para implementar la solución. A veces, se puede crear una solución alternativa hasta que se resuelva el problema real. Esto suele formar parte de los procedimientos de control de cambios de la empresa.

Si la medida correctiva no soluciona el problema o genera otro nuevo, se registra la solución probada, se eliminan los cambios y el administrador de red vuelve a recolectar síntomas y a aislar el problema.

Estas etapas no son mutuamente excluyentes. En cualquier parte del proceso, es posible que sea necesario volver a las etapas anteriores. Por ejemplo, es posible que el administrador de red necesite recolectar más síntomas mientras aísla un problema. Además, cuando se intenta corregir un problema, se puede generar otro. En este caso, se deben eliminar los cambios y comenzar la resolución de problemas nuevamente.

Se debe establecer una política de solución de problemas en cada etapa, que incluya procedimientos de control de cambios que documenten los cambios realizados y al autor de los cambios. Una política proporciona una forma coherente de llevar a cabo cada etapa. Parte de la política debe incluir el registro de cada dato importante.

Comunique a los usuarios y a todos los involucrados en el proceso de solución de problemas que el problema ya está resuelto. La solución se debe informar a los otros miembros del equipo de TI. El registro adecuado de la causa y la solución ayudan a otros técnicos de soporte a prevenir y resolver problemas similares en el futuro.

Recopilación de síntomas

Al recolectar síntomas, es importante que el administrador reúna datos y evidencia para eliminar de manera progresiva posibles causas y, finalmente, identificar la causa raíz del problema. Al analizar la información, el administrador de red formula una hipótesis para proponer posibles causas y soluciones y, al mismo tiempo, eliminar otras.

Como se muestra en la figura 1, hay cinco pasos de recopilación de información.

Paso 1. Recopilación de información: recopile información del informe de problema, los usuarios y los sistemas terminales afectados para definir el problema.

Paso 2. Determinación de propiedad: si el problema está dentro del alcance de la organización, pase a la etapa siguiente. Si el problema está fuera del límite de control de la organización (por ejemplo, pérdida de conectividad a Internet fuera del sistema autónomo), comuníquese con un administrador del sistema externo antes de recolectar más síntomas de la red.

Paso 3. Limitación del alcance: determine si el problema está en la capa del núcleo, de distribución o de acceso de la red. En la capa identificada, analice los síntomas existentes y use su conocimiento de la topología de la red para determinar qué equipo es la causa más probable.

Paso 4. Recopilación de síntomas de dispositivos sospechosos: aplique un enfoque de solución de problemas por capas para recopilar los síntomas de hardware y software de los dispositivos sospechosos. Comience por la posibilidad más probable y use sus conocimientos y experiencia para determinar si es más probable que el problema sea de configuración del hardware o del software.

Paso 5: Documentación de los síntomas: en ocasiones, el problema puede resolverse a partir de los síntomas documentados. De lo contrario, inicie la etapa de aislamiento del proceso general de resolución de problemas.

Para recopilar los síntomas de un dispositivo de red sospechoso, use los comandos de Cisco IOS y otras herramientas como:

los comandos ping, traceroute y telnet

los comandos show ydebug

Capturas de paquetes

Registros de dispositivos

La tabla de la figura 2 describe los comandos de Cisco IOS más comunes que se usan para recopilar los síntomas de un problema de red.

Nota: El comando debug es una herramienta importante para recopilar síntomas, pero genera mucho tráfico de mensajes de consola y puede afectar notablemente el rendimiento del dispositivo de red. Si el comando debug debe ejecutarse en el horario de trabajo normal, avise a los usuarios de la red que se está ejecutando una medida de solución de problemas y que el rendimiento de la red puede verse afectado. Al terminar, recuerde deshabilitar la depuración.

Uso de modelos en capas para la resolución de problemas

Una vez que se recopilan todos los síntomas, y si no se identifica una solución, el administrador de red compara las características del problema con las capas lógicas de la red para aislar y resolver el problema.

Los modelos lógicos de tecnología de redes, como los modelos OSI y TCP/IP, dividen la funcionalidad de la red en capas modulares. Cuando se realiza la resolución de problemas, se pueden aplicar estos modelos en capas a la red física para aislar los problemas de la red. Por ejemplo, si los síntomas sugieren un problema de conexión física, el técnico de red puede concentrarse en la resolución de problemas del circuito que funciona en la capa física. Si ese circuito funciona según lo esperado, el técnico observa las áreas en otra capa que podrían estar causando el problema.

Modelo de referencia OSI

El modelo de referencia OSI proporciona un lenguaje común para los administradores de red y se usa frecuentemente para resolver problemas de red. Por lo general, los problemas se describen en términos de una determinada capa del modelo OSI.

El modelo de referencia OSI describe la forma en que la información de una aplicación de software en una computadora se desplaza a través de un medio de red hasta una aplicación de software en otra computadora.

Las capas superiores (de 5 a 7) del modelo OSI se ocupan de los problemas de aplicación y, generalmente, se implementan solo en el software. La capa de aplicación es la más cercana al usuario final. Los usuarios y los procesos de la capa de aplicación interactúan con las aplicaciones de software que contienen un componente de comunicaciones.

Las capas inferiores (de 1 a 4) del modelo OSI se ocupan de los problemas de transporte de datos. Las capas 3 y 4 por lo general se implementan solo en el software. La capa física (capa 1) y la capa de enlace de datos (capa 2) se implementan en el hardware y el software. La capa física es la más cercana al medio físico de red, como el cableado de la red, y es responsable de colocar efectivamente la información en el medio.

En la figura 1, se muestran algunos dispositivos comunes y las capas del modelo OSI que se deben examinar durante el proceso de resolución de problemas de cada dispositivo. Observe que los routers y los switches multicapa se muestran en la capa 4, la capa de transporte. Si bien los routers y los switches multicapa generalmente toman decisiones de reenvío en la capa 3, se pueden usar las ACL en esos dispositivos para tomar decisiones de filtrado con la información de la capa 4.

Modelo TCP/IP

Similar al modelo de red OSI, el modelo de red TCP/IP también divide la arquitectura de red en capas modulares. En la figura 2, se muestra la relación entre el modelo de red TCP/IP y las capas del modelo de red OSI. Esta es una asignación estrecha que permite que la suite de protocolos TCP/IP se comunique correctamente con muchas tecnologías de red.

La capa de aplicación en la suite TCP/IP combina las funciones de las tres capas del modelo OSI: sesión, presentación y aplicación. La capa de aplicación proporciona comunicación entre aplicaciones tales como FTP, HTTP y SMTP en hosts separados.

Las capas de transporte de TCP/IP y de OSI se corresponden directamente en cuanto a su función. La capa de transporte es responsable del intercambio de segmentos entre dispositivos en una red TCP/IP.

La capa de Internet de TCP/IP se relaciona con la capa de red del modelo OSI. La capa de Internet es responsable del direccionamiento que se utiliza para la transferencia de datos de origen a destino.

La capa de acceso a Internet de TCP/IP corresponde a las capas física y de enlace de datos de OSI. La capa de acceso a la red se comunica directamente con los medios de red y proporciona una interfaz entre la arquitectura de la red y la capa de Internet.

Métodos de resolución de problemas

Mediante los modelos en capas, existen tres métodos principales para resolver problemas de red:

Ascendente

Descendente

Divide y vencerás

Cada método tiene sus ventajas y desventajas. En este tema, se describen los tres métodos y se proporcionan pautas para elegir el mejor método para una situación específica.

Método de resolución de problemas ascendente

En la resolución de problemas ascendente, se comienza por los componentes físicos de la red y se atraviesan las capas del modelo OSI de manera ascendente hasta que se identifica la causa del problema, como se muestra en la figura 1. La resolución de problemas ascendente es un buen método para usar cuando se sospecha que el problema es físico. La mayoría de los problemas de red residen en los niveles inferiores, de modo que, con frecuencia, la implementación del método ascendente es eficaz.

La desventaja del método de resolución de problemas ascendente es que requiere que revise cada dispositivo e interfaz en la red hasta que detecte la posible causa del problema. Recuerde que se debe registrar cada conclusión y cada posibilidad, de modo que es posible que haya mucho papeleo asociado a este enfoque. Otro desafío es determinar qué dispositivos se deben examinar primero.

Método de resolución de problemas descendente

En la figura 2, la resolución de problemas descendente comienza por las aplicaciones de usuario final y atraviesa las capas del modelo OSI de manera descendente hasta que se identifica la causa del problema. Antes de abordar las partes más específicas de la red, se prueban las aplicaciones de usuario final de un sistema final. Use este método para los problemas más simples o cuando crea que el problema está en un software.

La desventaja del enfoque descendente es que requiere que se revise cada aplicación de red hasta que se detecte la posible causa del problema. Se debe registrar cada conclusión y cada posibilidad. El desafío es determinar qué aplicación se debe examinar primero.

Método de resolución de problemas divide y vencerás

En la figura 3, se muestra el enfoque divide y vencerás para resolver un problema de red. El administrador de red selecciona una capa y hace pruebas en ambos sentidos desde esa capa.

En el método de resolución de problemas divide y vencerás, comienza por reunir las experiencias que el usuario tiene del problema, documenta los síntomas y, después, con esa información, hace una deducción fundamentada sobre la capa del modelo OSI en la que se debe comenzar la investigación. Cuando se verifica que una capa funciona correctamente, se puede suponer que las capas por debajo de ella funcionan. El administrador puede trabajar en las capas del modelo OSI en sentido ascendente. Si una capa de OSI no funciona correctamente, el administrador puede descender por el modelo de capas de OSI.

Por ejemplo, si los usuarios no pueden acceder al servidor web, pero pueden hacer ping al servidor, entonces el problema se encuentra por encima de la capa 3. Si el ping al servidor falla, es probable que el problema esté en una capa inferior del modelo OSI.

Otros métodos de solución de problemas

Además del enfoque sistemático de resolución de problemas en capas, también existen otros enfoques menos estructurados.

Un enfoque de resolución de problemas se basa en una deducción fundamentada del administrador de red, según los síntomas del problema. Los administradores de red experimentados implementan este método con mayor éxito porque se apoyan en sus amplios conocimientos y experiencia para aislar y resolver problemas de red con determinación. En el caso de un administrador de red menos experimentado, es muy posible que este método sea más parecido a una resolución de problemas fortuita.

Otro método consiste en comparar una situación de funcionamiento con una en la que no hay funcionamiento y detectar las diferencias significativas, que incluyen:

Configuración

Versiones de software

Propiedades del hardware y de otros dispositivos

Si bien este método puede proporcionar una solución que funcione, no revela con claridad la causa del problema. Este método puede ser útil cuando al administrador de red le falta un área de conocimientos o cuando es necesario resolver el problema rápidamente. Después de que se implementa la corrección, el administrador de red puede continuar la investigación para determinar la causa real del problema.

La sustitución es otra metodología rápida de resolución de problemas, que implica cambiar el dispositivo problemático por uno que se sepa que funciona. Si se corrige el problema, el administrador de red sabe que el problema está en el dispositivo que quitó. Si el problema permanece, la causa puede estar en cualquier otro lugar. En situaciones específicas, este puede ser un método ideal para la resolución rápida de un problema, por ejemplo, cuando queda inactivo un único punto de error crítico, como un router de frontera. En vez de resolver el problema, puede resultar más beneficioso reemplazar el dispositivo y restaurar el servicio.

Pautas para seleccionar un método de resolución de problemas

Para resolver rápidamente los problemas de una red, tómese el tiempo para seleccionar el método más eficaz de resolución de problemas de red. En la ilustración, se muestra este proceso.

El siguiente es un ejemplo de cómo elegir un método de resolución de problemas según un problema específico:

Dos routers IP no intercambian información de routing. La última vez que ocurrió este tipo de problema se trató de un problema de protocolo. Por lo tanto, elija el método de resolución de problemas divide y vencerás. Un análisis revela que hay conectividad entre los routers. Comience el proceso de resolución de problemas en la capa física o de enlace de datos. Confirme la conectividad y empiece a probar las funciones relacionadas con TCP/IP en la siguiente capa ascendente del modelo de OSI, la capa de red.

Conceptos de IP SLA

Los administradores de redes deben ser proactivos; deben monitorear y probar continuamente la red. El objetivo es descubrir las fallas de red lo antes posible. Una herramienta útil para esta tarea son los acuerdos de nivel de servicio (SLA) por IP de Cisco IOS.

Los IP SLA generaron el tráfico para medir el rendimiento de la red entre dos dispositivos de red, ubicaciones de red múltiples, o en varias rutas de red. En el ejemplo de la figura, R1 es el origen de IP SLA que monitorea la conexión al servidor DNS enviando periódicamente solicitudes ICMP al servidor.

Los ingenieros de redes utilizan IP SLA para simular los datos de red y los servicios IP para recopilar información de rendimiento de la red en tiempo real. La supervisión del rendimiento puede realizarse en cualquier momento, en cualquier lugar, sin implementar una sonda física.

Nota: ping y traceroute son herramientas de sondeo. Una sonda física es diferente. Es un dispositivo que puede insertarse en algún lugar en la red para recopilar y monitorear el tráfico. El uso de sondas físicas excede el alcance de este curso.

Las mediciones obtenidas de las diversas operaciones de IP SLA pueden usarse para solucionar problemas de red con mediciones confiables y uniformes que ayudan a identificar inmediatamente los problemas y a ahorrar tiempo en su solución.

El uso de IP SLA tiene otras ventajas:

Supervisión, medición y verificación del acuerdo de nivel de servicio

Monitoreo de rendimiento de la red para proporcionar mediciones continuas, rápidas, confiables y predecibles de las fluctuaciones, la latencia o la pérdida de paquetes en la red

Evaluación del estado de la red de servicio IP para verificar que la QoS existente es suficiente para nuevos servicios IP

Supervisión de contorno contra contorno de disponibilidad de red para la verificación de la conectividad dinámica de los recursos de red

Puede haber varias operaciones de IP SLA en ejecución en una red o dispositivo a la vez. La información de IP SLA se puede ver mediante los comandos de CLI o con SNMP.

Nota: Las notificaciones de SNMP basadas en los datos recopilados por una operación de IP SLA están fuera del alcance de este curso.

Configuración de IP SLA

En vez de usar el comando ping manualmente, los ingenieros de red pueden usar la operación de eco de ICMP de IP SLA para probar la disponibilidad de los dispositivos de red. Un dispositivo de red puede ser cualquier dispositivo con las funcionalidades de IP (router, switch, PC, servidor, etc.). La operación de eco ICMP de IP SLA proporciona las siguientes mediciones:

Supervisión de disponibilidad (estadísticas de pérdida de paquetes)

Supervisión de rendimiento (latencia y tiempo de respuesta)

Operación de red (conectividad completa)

Para verificar que la operación deseada de IP SLA sea compatible con el dispositivo de origen, use el comando del modo EXEC con privilegios show ip sla application. El resultado generado en la figura confirma que R1 es capaz de admitir SLA IP. Sin embargo, en este momento no hay sesiones configuradas.

Para crear una operación de IP SLA e ingresar al modo de configuración de IP SLA, use el comando de configuración global ip sla operation-number . El número de operación es un número exclusivo que se usa para identificar la operación que se está configurando.

En el modo de configuración de IP SLA, se puede configurar la operación de IP SLA como operación de eco de ICMP e ingresar al modo de configuración de eco de ICMP con el siguiente comando:

Router(config-ip-sla)# icmp-echo { dest-ip-address | dest-hostname } [ source-ip { ip-address | Nombre de host } | source-interface interface-id ]

A continuación, configure la frecuencia con la que se repetirá la operación especificada de IP SLA con el comando frequency seconds . El intervalo es de 1 a 604800 segundos; el valor predeterminado es 60 segundos.

Para programar la operación de IP SLA, use el siguiente comando de configuración global:

Router(config)# ip sla schedule operation-number [ life { forever | seconds }] [ start-time { h : m [: seg ] [ month day | day month ] | pendiente | ahora | después hh:mm:ss ] [ ageout seconds ] [ recurring ]

Configuración de IP SLA de ejemplo

Para entender cómo se configura un IP SLA simple, consulte la topología de la figura 1.

La configuración de la figura 2 establece un número de operación de 1 para la operación de IP SLA. Se pueden configurar varias operaciones de IP SLA en un dispositivo. Cada operación se identifica con su número de operación. El comando icmp-echo identifica la dirección de destino que se supervisará. En el ejemplo, está configurado para monitorear la interfaz S1 de R3. El comando frequency establece la frecuencia de IP SLA a intervalos de 30 segundos.

El comando ip sla schedule programa la operación número 1 de IP SLA para que empiece de inmediato (ahora) y continúe hasta que se cancele manualmente (para siempre).

Nota: Use el comando no ip sla schedule operation-number para cancelar la operación de SLA. La configuración de la operación de SLA se preserva y se puede reprogramar cuando sea necesario.

Verificación de la configuración de IP SLA

Use el comando show ip sla configuration operation-number para mostrar los valores de configuración, incluidos todos los valores predeterminados para las operaciones de IP SLA o para una operación específica.

En la figura 1, el comando show ip sla configuration muestra la configuración de eco de ICMP de IP SLA.

Use el comando show ip sla statistics [operation-number] para ver las estadísticas de monitoreo de operaciones de IP SLA, como se muestra en la figura 2.

Herramientas de resolución de problemas de software

Para facilitar la resolución de problemas, hay disponible una amplia variedad de herramientas de hardware y software. Estas herramientas se pueden usar para recolectar y analizar los síntomas de los problemas de red. Con frecuencia, proporcionan funciones de monitoreo y generación de informes que se pueden usar para establecer la línea de base de red.

Algunas herramientas para la solución de problemas de software incluyen las siguientes:

Herramientas del sistema de administración de red (NMS)

Las herramientas del sistema de administración de red (NMS) incluyen herramientas de monitoreo en el nivel de los dispositivos, de configuración y de administración de fallas. La figura 1 muestra una pantalla de ejemplo del software de NMS WhatsUp Gold. Estas herramientas se pueden usar para investigar y corregir los problemas de red. El software de monitoreo de redes ofrece una vita física de los dispositivos de red, lo que permite que los administradores de red monitoreen los dispositivos remotos de manera continua y automática. El sofftware de administración de dispositivos proporciona información dinámica sobre el estado del dispositivo, las estadísticas y la configuración de los principales dispositivos de red.

Base de conocimientos

Las bases de conocimientos en línea de los proveedores de dispositivos de red se volvieron fuentes de información indispensables. Cuando las bases de conocimientos de los proveedores se combinan con motores de búsqueda de Internet como Google, los administradores de red tienen acceso a una vasta fuente de información fundada en la experiencia.

La figura 2 muestra la página Tools & Resources (herramientas y recursos) de Cisco en http://www.cisco.com. Esta página proporciona información sobre el hardware y software relacionado con Cisco. Incluye procedimientos de resolución de problemas, guías de implementación y notas de producto originales sobre la mayoría de los aspectos de la tecnología de red.

Herramientas de línea de base

Hay numerosas herramientas disponibles para automatizar la documentación de red y el proceso de línea de base. La figura 3 muestra una captura de pantalla de la vista de línea de base de Network Performance Monitor 12 de SolarWinds. Las herramientas de establecimiento de línea de base ayudan con las tareas de registro frecuentes. Por ejemplo, pueden generar diagramas de red, ayudar a conservar actualizado el registro del software y el hardware de una red y ayudar a medir de forma rentable la línea de base de uso de ancho de banda de la red.

Analizador de protocolos

Los analizadores de protocolos sirven para examinar el contenido de los paquetes que atraviesan la red. Un analizador de protocolos decodifica las diversas capas del protocolo en una trama registrada y presenta esa información en un formato relativamente fácil de usar. En la ilustración, se muestra una captura de pantalla del analizador de protocolos Wireshark.

Los analizadores de protocolos muestran información sobre los componentes físicos, los enlaces de datos y el protocolo, así como descripciones para cada trama. La mayoría de los analizadores de protocolos pueden filtrar el tráfico que cumple con ciertos criterios, por ejemplo, se puede captar todo el tráfico hacia y desde un dispositivo determinado. Los analizadores de protocolos como Wireshark pueden ayudar a resolver problemas de rendimiento de la red. Es importante tener un buen manejo de TCP/IP y del uso de un analizador de protocolos para examinar la información en cada capa de TCP/IP.

Nota: Para obtener más conocimientos y habilidades relacionados con el uso de Wireshark, un excelente recurso es http://www.wiresharkbook.com.

Herramientas para la solución de problemas de hardware

Hay varios tipos de herramientas de solución de problemas de hardware.

Algunas herramientas para la solución de problemas de hardware incluyen las siguientes:

Multímetros digitales: los multímetros digitales (DMM), como el Fluke 179 que se muestra en la figura 1, son instrumentos de prueba que sirven para medir directamente los valores eléctricos de voltaje, corriente y resistencia. En la solución de problemas de red, la mayoría de las pruebas que conllevan el uso de un multímetro implican el control de los niveles de voltaje de la fuente de alimentación y la verificación de recepción de alimentación en los dispositivos de red.

Probadores de cables: los probadores de cables son dispositivos portátiles especializados diseñados para probar los diversos tipos de cables de comunicación de datos. La figura 2 muestra el probador automático de redes Fluke LinkRunner AT Network Auto-Tester. Los analizadores de cables se pueden utilizar para detectar cables rotos, cables cruzados, conexiones cortas y conexiones puestas en par incorrectamente. Estos dispositivos pueden ser económicos comprobadores de continuidad, comprobadores de cables de datos de precio moderado o costosos reflectómetros de dominio de tiempo (TDR). Los TDR se usan para identificar la distancia a una ruptura en un cable. Estos dispositivos envían señales a lo largo del cable y esperan a que estas se reflejen. El tiempo entre el envío y la recepción de la señal se convierte en una medida de distancia. Normalmente, la función de TDR viene incluida en los comprobadores de cables de datos. Los TDR que se usan para probar los cables de fibra óptica se conocen como “reflectómetros ópticos de dominio de tiempo” (OTDR).

Analizadores de cables: los analizadores de cables, como el Fluke DTX Cable Analyzer de la figura 3, son dispositivos portátiles polifuncionales que sirven para probar y certificar los cables de cobre y de fibra óptica para los distintos servicios y estándares. Las herramientas más sofisticadas incluyen diagnósticos avanzados de solución de problemas que miden la distancia a un defecto de rendimiento como paradiafonía (NEXT) o pérdida de retorno (RL), identifican las medidas correctivas y muestran gráficamente los estados de diafonía e impedancia. Los analizadores de cables también suelen incluir software basado en computadora. Una vez recopilados los datos de campo, los datos del dispositivo portátil pueden cargarse para que el administrador de red genere informes actualizados.

Analizadores de red portátiles: los dispositivos portátiles como Fluke OptiView de la figura 4 sirven para solucionar problemas en redes conmutadas y VLAN. Al conectar el analizador de red en cualquier parte de la red, un ingeniero de red puede ver el puerto de switch al que se conecta el dispositivo, así como el uso promedio y el uso pico. El analizador también se puede usar para conocer la configuración de la VLAN, identificar los participantes principales de la red, analizar el tráfico de la red y ver los detalles de la interfaz. Para un análisis y una resolución de problemas más profundos, el dispositivo conectarse a una computadora que tenga instalado un software de supervisión de red.

Network Analysis Module: Cisco NAM puede ser un dispositivo o un software, como se muestra en la figura 5. Proporciona una interfaz integrada basada en navegador que genera informes sobre el tráfico que consume recursos de red vitales. Muestra una representación gráfica del tráfico de los switches y routers locales y remotos, como se ve en la figura 6. Además, NAM puede capturar y decodificar paquetes, y medir los tiempos de respuesta para identificar en qué red o servidor en particular se genera el problema de aplicaciones.

Resolución de problemas con un servidor de syslog

Syslog es un protocolo simple que un dispositivo IP, conocido como “cliente syslog”, usa para enviar mensajes de registro basados en texto a otro dispositivo IP, el servidor de syslog. Actualmente, Syslog se define en RFC 5424.

Implementar una instalación de registro es una parte importante de la seguridad y la resolución de problemas de red. Los dispositivos de Cisco pueden registrar información relacionada con cambios de configuración, infracciones de ACL, estado de interfaces y muchos otros tipos de eventos. Los dispositivos de Cisco pueden enviar mensajes de registro a varias instalaciones. Los mensajes de eventos se pueden enviar a uno o varios de los siguientes componentes:

Consola: el registro de la consola está activado de manera predeterminada. Los mensajes se registran en la consola y pueden verse al modificar o probar el router o switch con el software de emulación de terminales conectado al puerto de consolas del dispositivo de red.

Líneas de las terminales: las sesiones de EXEC habilitadas se pueden configurar para recibir mensajes de registro en cualquiera de las líneas de las terminales. Al igual que el registro de consolas, este tipo de registros no se almacena en el dispositivo de red, por lo que solo sirve al usuario en esa línea.

Registro con búfer: el registro con búfer es un poco más útil como herramienta de solución de problemas porque los mensajes de registro se almacenan en la memoria por un tiempo. Sin embargo, cuando se reinicia el dispositivo, se borran los mensajes de registro.

Traps de SNMP: ciertos umbrales se pueden configurar previamente en los routers y otros dispositivos. Los eventos de router, como la superación de un umbral, se pueden procesar en el router y reenviar como notificaciones de SNMP a una estación de administración de redes SNMP externa. Las traps de SNMP son una instalación de registro de seguridad viable, pero requieren la configuración y el mantenimiento de un sistema SNMP.

Syslog: los routers y los switches Cisco se pueden configurar para reenviar mensajes de registro a un servicio de syslog externo. Este servicio puede residir en cualquier número de servidores o estaciones de trabajo, incluidos los sistemas basados en Microsoft Windows y Linux. Syslog es la instalación de registro de mensajes más popular, ya que proporciona capacidades de almacenamiento de registro a largo plazo y una ubicación central para todos los mensajes del router.

Los mensajes de registro del IOS de Cisco se ubican en uno de ocho niveles, como se muestra en la figura 1. Cuanto menor es el número del nivel, mayor es el nivel de gravedad. De manera predeterminada, todos los mensajes del nivel 0 al 7 se registran en la consola. Si bien la capacidad para ver los registros en un servidor central de syslog es útil para resolver problemas, examinar una gran cantidad de datos puede ser una tarea abrumadora. El comando logging trap level limita los mensajes registrados en el servidor syslog según la gravedad. El nivel es el nombre o número de nivel de gravedad. Solo se registran los mensajes de número igual o menor que el nivel de gravedad especificado.

En el ejemplo de la figura 2, los mensajes de sistema del nivel 0 (emergencias) al 5 (notificaciones) se envían al servidor de syslog en 209.165.200.225

Resolución de problemas de la capa física

La capa física transmite bits desde una computadora a otra y regula la transmisión de un flujo de bits a través del medio físico. La capa física es la única con propiedades físicamente tangibles, como cables, tarjetas y antenas.

Los problemas en una red con frecuencia se presentan como problemas de rendimiento. Los problemas de rendimiento indican que existe una diferencia entre el comportamiento esperado y el comportamiento observado y que el sistema no funciona como se podría esperar razonablemente. Las fallas y las condiciones por debajo del nivel óptimo en la capa física no solo presentan inconvenientes para los usuarios sino que pueden afectar la productividad de toda la empresa. Las redes en las que se dan estos tipos de condiciones por lo general se desactivan. Dado que las capas superiores del modelo OSI dependen de la capa física para funcionar, el administrador de red debe tener la capacidad de aislar y corregir los problemas en esta capa de manera eficaz.

Los síntomas frecuentes de los problemas de red en la capa física incluyen los siguientes:

Rendimiento inferior a la línea de base: las razones más frecuentes de un rendimiento lento o deficiente incluyen servidores sobrecargados o con alimentación insuficiente, configuraciones de router o switch inadecuadas, congestión del tráfico en un enlace de baja capacidad y pérdida crónica de tramas.

Pérdida de la conectividad: si un cable o un dispositivo fallan, el síntoma más evidente es una pérdida de la conectividad entre los dispositivos que se comunican a través de ese enlace o con el dispositivo o la interfaz que presenta la falla. Esto se indica por medio de una simple prueba de ping. La pérdida intermitente de la conectividad puede indicar una conexión floja u oxidada.

Cuellos de botella o congestión de la red: si un router, una interfaz o un cable fallan, es probable que los protocolos de routing redirijan el tráfico hacia otras rutas que no estén diseñadas para transportar la capacidad adicional. Esto puede provocar congestión o cuellos de botella en esas partes de la red.

Tasas de uso de CPU elevadas: las tasas de uso de CPU elevadas son un síntoma de que un dispositivo, como un router, un switch o un servidor, funciona en el límite admitido por su diseño o lo supera. Si no se aborda rápidamente, la sobrecarga de CPU puede ocasionar que un dispositivo falle o se desactive.

Mensajes de error de consola: los mensajes de error notificados en la consola de dispositivos podrían indicar un problema en la capa física.

Los incidentes que comúnmente causan problemas de red en la capa física incluyen los siguientes:

Problemas relacionados con la alimentación: estos son el motivo principal de una falla de la red. Además, debe revisarse el funcionamiento de los ventiladores y asegurarse de que los orificios de entrada y salida de ventilación del bastidor no estén obstruidos. Si en otras unidades cercanas también se produce una pérdida de potencia, considere la posibilidad de que haya un corte de energía en la fuente de alimentación principal.

Fallas de hardware: las tarjetas de interfaz de red (NIC) defectuosas pueden ser la causa de errores de transmisión de la red debido a colisiones tardías, tramas cortas y jabber. Con frecuencia, “jabber” se define como la condición en la que un dispositivo de red transmite continuamente datos aleatorios, sin sentido, a la red. Otras causas probables de jabber son archivos de controlador de la NIC defectuosos o dañados, cables defectuosos o problemas de conexión a tierra.

Fallas del cableado: se pueden corregir numerosos problemas simplemente por medio de volver a asentar cables que se desconectaron de manera parcial. Al realizar una inspección física, se debe controlar que no haya cables dañados, tipos de cable inadecuados ni conectores RJ-45 mal engarzados. Los cables sospechosos se deben probar o cambiar por un cable que se sepa que funcione.

Atenuación: la atenuación puede ocurrir cuando la longitud de un cable supera el límite de diseño para los medios o cuando hay una conexión deficiente que se debe a un cable flojo o a contactos sucios u oxidados. Si la atenuación es grave, el dispositivo receptor no siempre puede distinguir bien entre uno y otro bit del flujo de datos.

Ruido: la interferencia electromagnética (EMI) local se conoce comúnmente como “ruido”. El ruido se puede generar a partir de muchas fuentes, como estaciones de radio FM, radio de la policía, seguridad de edificios, aviónica para aterrizaje automático, crosstalk (ruido inducido por otros cables en la misma ruta o por cables adyacentes), cables eléctricos cercanos, dispositivos con motores eléctricos grandes o cualquier elemento que cuente con un transmisor más potente que el de un teléfono celular.

Errores de configuración de la interfaz: muchos elementos se pueden configurar incorrectamente en una interfaz y ocasionar que se desactive, por ejemplo, una frecuencia de reloj incorrecta, un origen de reloj incorrecto y que la interfaz no esté encendida. Esto provoca la pérdida de la conectividad a los segmentos de red conectados.

Superación de límites de diseño: un componente puede funcionar de manera imperfecta en la capa física porque su uso excedió las especificaciones o la capacidad configurada. Al resolver este tipo de problema, es evidente que los recursos del dispositivo funcionan a la capacidad máxima, o cerca de ella, y hay un aumento en el número de errores de interfaz.

Sobrecarga de CPU: los síntomas incluyen procesos con altos porcentajes de uso de CPU, descartes de cola de entrada, rendimiento lento, tiempos de espera de SNMP, falta de acceso remoto o respuesta lenta o fallida de servicios como DHCP, Telnet y ping. En un switch puede pasar lo siguiente: reconvergencia del árbol de expansión, rebote de enlaces EtherChannel, UDLD intermitente, fallas de IP SLA. En los routers, se puede producir una interrupción de actualizaciones de routing, o intermitencia de routing o HSRP. Una de las causas de la sobrecarga de CPU en un router o switch es el alto nivel de tráfico. Si una o más de las interfaces se sobrecarga regularmente de tráfico, se debe considerar la posibilidad de rediseñar el flujo de tráfico de la red o de actualizar el hardware.

Resolución de problemas de la capa de enlace de datos

La resolución de problemas de capa 2 puede ser un proceso desafiante. La configuración y el funcionamiento de estos protocolos son fundamentales para crear redes con ajustes precisos y en condiciones de funcionamiento. Los problemas de capa 2 causan síntomas específicos que, al reconocerse, ayudan a identificar el problema rápidamente.

Los síntomas frecuentes de los problemas de red en la capa de enlace de datos incluyen los siguientes:

Falta de funcionalidad o conectividad en la capa de red o en las capas superiores: algunos problemas de capa 2 pueden detener el intercambio de tramas a través de un enlace, mientras que otros solo provocan un deterioro del rendimiento de la red.

Funcionamiento de la red por debajo de los niveles de rendimiento de línea de base: en una red, pueden ocurrir dos tipos de funcionamiento deficiente en la capa 2. En primer lugar, que las tramas elijan una ruta deficiente al destino, pero lleguen. En este caso, la red podría experimentar un uso de ancho de banda elevado en enlaces que no deberían tener ese nivel de tráfico. En segundo lugar, que se descarten algunas tramas. Estos problemas se pueden identificar mediante las estadísticas del contador de errores y los mensajes de error de la consola en el switch o el router. En un entorno Ethernet, un ping extendido o continuo también revela si se descartan tramas.

Difusiones excesivas: los sistemas operativos usan difusiones y multidifusiones ampliamente para detectar los servicios de red y otros hosts. Por lo general, las difusiones excesivas son el resultado de una de las siguientes situaciones: aplicaciones programadas o configuradas incorrectamente, grandes dominios de difusión de capa 2 o problemas de red subyacentes, como bucles de STP o rutas inestables.

Mensajes de la consola: a veces, un router reconoce que se produjo un problema de capa 2 y envía mensajes de alerta a la consola. Generalmente, un router hace esto cuando detecta un problema con la interpretación de las tramas entrantes (problemas de encapsulación o entramado) o cuando se esperan keepalives pero no llegan. El mensaje de la consola más común que indica que existe un problema de Capa 2 es un mensaje que indica que el protocolo de línea está desactivado.

Los problemas en la capa de enlace de datos que con frecuencia provocan problemas de conectividad o rendimiento de la red incluyen los siguientes:

Errores de encapsulación: un error de encapsulación ocurre porque los bits que el emisor coloca en un campo determinado no son los que el receptor espera ver. Esta condición se produce cuando la encapsulación en un extremo de un enlace WAN está configurada de manera diferente de la encapsulación que se usa en el otro extremo.

Errores de asignación de direcciones: en las topologías, como punto a multipunto o Ethernet de transmisión, es vital asignar una dirección de destino de capa 2 correcta a la trama. Esto asegura su llegada al destino correcto. Para lograr esto, el dispositivo de red debe encontrar la coincidencia entre una dirección de destino de capa 3 y la dirección de capa 2 correcta mediante mapas estáticos o dinámicos. En un entorno dinámico, la asignación de información de capa 2 y capa 3 puede fallar porque los dispositivos pueden haber estado configurados específicamente para no responder a las solicitudes de ARP, la información de capa 2 o capa 3 almacenada en caché puede haber cambiado físicamente, o las respuestas de ARP no válidas se reciben por un error de configuración o un ataque a la seguridad.

Errores de entramado: las tramas generalmente operan en grupos de bytes de 8 bits. Cuando una trama no termina en un límite de bytes de 8 bits, se produce un error de entramado. Cuando sucede esto, el receptor puede tener problemas para determinar dónde termina una trama y dónde comienza la otra. Un número excesivo de tramas no válidas puede impedir el intercambio de keepalives válidos. Los errores de encuadre pueden deberse al ruido en la línea serial, un cable mal diseñado (demasiado largo o mal blindado), una falla de NIC, una diferencia entre dúplex o un error de configuración de reloj de línea de unidad de servicio de canal (CSU).

Fallas o bucles de STP: el objetivo del protocolo de árbol de expansión (STP) es convertir una topología física redundante en una topología de árbol mediante el bloqueo de los puertos redundantes. La mayoría de los problemas de STP se relacionan con el reenvío de bucles, que se produce cuando no se bloquean puertos en una topología redundante y el tráfico se reenvía en círculos indefinidamente, lo que implica una saturación excesiva provocada por una tasa elevada de cambios en la topología STP. En una red configurada correctamente, un cambio de topología debería ser un evento inusual. Cuando un enlace entre dos switches se activa o se desactiva, llegado el momento se produce un cambio de topología cuando el estado de STP del puerto cambia por hacia reenvío o desde reenvío. Sin embargo, cuando un puerto es inestable (oscila entre los estados activo y inactivo), provoca cambios de topología repetitivos y saturación, u ocasiona la convergencia lenta o reiterada de STP. Esto puede ser el resultado de una incompatibilidad entre la topología real y la topología registrada, un error de configuración, como una configuración incoherente de los temporizadores de STP, una sobrecarga de CPU de switch durante la convergencia o un defecto de software.

Solución de problemas de capa de red

Los problemas de la capa de red incluyen cualquier problema que comprenda a un protocolo de capa 3, ya sea un protocolo de routing (como IPv4 o IPv6) o un protocolo de routing (como EIGRP, OSPF, entre otros).

Los síntomas frecuentes de los problemas de red en la capa de red incluyen los siguientes:

Falla de red: una falla de red se produce cuando esta no funciona o funciona parcialmente, lo que afecta a todos los usuarios y a todas las aplicaciones en la red. Los usuarios y los administradores de red normalmente detectan estas fallas en seguida, las que sin dudas son fundamentales para la productividad de la empresa.

Rendimiento por debajo del nivel óptimo: los problemas de optimización de la red por lo general comprenden a un subconjunto de usuarios, aplicaciones, destinos o un determinado tipo de tráfico. Es difícil detectar los problemas de optimización, y es incluso más difícil aislarlos y diagnosticarlos. Esto se debe a que varias capas suelen verse involucradas o incluso una sola computadora de host. Puede llevar tiempo determinar que el problema se encuentra en la capa de red.

En la mayoría de las redes, se usan rutas estáticas junto con protocolos de routing dinámico. La configuración incorrecta de las rutas estáticas puede provocar un routing deficiente. En algunos casos, las rutas estáticas configuradas incorrectamente pueden generar bucles de routing que hacen que algunas partes de la red se vuelvan inalcanzables.

La resolución de problemas de protocolos de routing dinámico requiere una comprensión profunda de cómo funciona el protocolo de routing específico. Algunos problemas son comunes a todos los protocolos de routing, mientras que otros son específicos de un protocolo de routing particular.

No existe una única plantilla para resolver problemas de capa 3. Los problemas de routing se resuelven con un proceso metódico, por medio de una serie de comandos para aislar y diagnosticar el problema.

Las siguientes son algunas áreas que se deben explorar al diagnosticar un posible problema que involucre protocolos de routing:

Problemas de red generales: con frecuencia, un cambio en la topología, como un enlace inactivo, puede tener efectos en otras áreas de la red que tal vez no sean evidentes en ese momento. Esto puede implicar instalar nuevas rutas, estáticas o dinámicas, o eliminar otras. Determine si algún elemento de la red cambió de manera reciente y si hay alguna persona trabajando en la infraestructura de la red en ese momento.

Problemas de conectividad: revise si existe algún problema de conectividad o en los equipos, incluidos problemas de alimentación como cortes de energía y problemas ambientales (por ejemplo, recalentamiento). También revise si hay problemas de capa 1, como problemas de cableado, puertos defectuosos y problemas del ISP.

Tabla de routing: revise la tabla de routing para ver si existe algo inesperado, como rutas faltantes o imprevistas. Use los comandos debug para ver las actualizaciones de routing y el mantenimiento de la tabla de routing.

Problemas de vecinos: si el protocolo de routing establece una adyacencia con un vecino, revise si hay algún problema con los routers en lo que respecta a la formación de adyacencias de vecinos.

Base de datos de topología: si el protocolo de routing usa una tabla o base de datos de topología, revíselas para ver si existe algo inesperado, como entradas faltantes o imprevistas.

Resolución de problemas de la capa de transporte: ACL

Los problemas de red pueden surgir a partir de problemas de la capa de transporte en el router, especialmente en el perímetro de la red, donde se examina y se modifica el tráfico. Dos de las tecnologías de capa de transporte que se implementan con más frecuencia son las listas de control de acceso (ACL) y la traducción de direcciones de red (NAT), que se muestran en la figura 1.

La mayoría de los problemas frecuentes con las ACL se debe a una configuración incorrecta, como se muestra en la figura 2. Los problemas con las ACL pueden provocar fallas en sistemas que, por lo demás, funcionan correctamente. Comúnmente, las configuraciones incorrectas ocurren en varias áreas:

Selección de flujo de tráfico: el tráfico se define según la interfaz de router por la que viaja y según la dirección en la que viaja el tráfico. Para que funcione de manera adecuada, se debe aplicar la ACL a la interfaz correcta y se debe seleccionar el sentido de tráfico apropiado.

Orden de entradas de control de acceso: el orden de las entradas en una ACL debe ir de lo específico a lo general. Si bien una ACL puede tener una entrada para permitir específicamente un flujo de tráfico en particular, los paquetes nunca coincidirán con esa entrada si una entrada anterior en la lista ya los denegó. Si el router ejecuta las ACL y la NAT, es importante el orden en que se aplica cada una de estas tecnologías a un flujo de tráfico. La ACL de entrada procesa el tráfico entrante antes de que lo procese la NAT de afuera hacia dentro. La ACL de salida procesa el tráfico saliente después de que lo procesa la NAT de adentro hacia fuera.

Deny any implícito: cuando la ACL no requiere un alto nivel de seguridad, este elemento de control de acceso implícito puede ser la causa de un error de configuración de ACL.

Direcciones y máscaras wildcard IPv4: las máscaras wildcard IPv4 complejas proporcionan mejoras importantes en términos de eficiencia, pero están más sujetas a errores de configuración. Un ejemplo de una máscara wildcard compleja consiste en usar la dirección IPv4 10.0.32.0 y la máscara wildcard 0.0.32.15 para seleccionar las primeras 15 direcciones host en la red 10.0.0.0 o 10.0.32.0.

Selección del protocolo de la capa de transporte: al configurar las ACL, es importante que se especifiquen solo los protocolos de la capa de transporte correctos. Cuando no están seguros de si un flujo de tráfico determinado usa un puerto TCP o un puerto UDP, muchos administradores de red configuran ambos. Especificar ambos puertos provoca una abertura a través del firewall, lo que posibilita a los intrusos un camino dentro la red. También introduce un elemento adicional en la ACL, de modo que el procesamiento de esta toma más tiempo, lo que imprime mayor latencia a las comunicaciones de la red.

Puertos de origen y destino: controlar el tráfico entre dos hosts de manera adecuada requiere elementos simétricos de control de acceso para las ACL de entrada y de salida. La información de dirección y de puerto del tráfico generado por un host que responde es el reflejo de la información de dirección y puerto del tráfico generado por el host de origen.

Uso de la palabra clave established: la palabra clave established aumenta la seguridad provista por una ACL. Sin embargo, si la palabra clave se aplica incorrectamente, pueden tener lugar resultados imprevistos.

Protocolos poco frecuentes: las ACL configuradas incorrectamente suelen causar problemas en protocolos distintos de TCP y UDP. Los protocolos poco frecuentes que están ganando popularidad son VPN y los protocolos de cifrado.

La palabra clave log es un comando útil para ver la operación de las ACL en las entradas de ACL. Esta palabra clave le ordena al router que coloque una entrada en el registro del sistema cada vez que haya una coincidencia con esa condición de entrada. El evento registrado incluye los detalles del paquete que coincidió con el elemento de la ACL. La palabra clave log es especialmente útil para resolver problemas y también proporciona información sobre los intentos de intrusión que la ACL bloquea.

Resolución de problemas de la capa de transporte: NAT para IPv4

Existen varios problemas con la NAT, como la falta de interacción con servicios como DHCP y tunneling. Estos pueden incluir la configuración incorrecta de la NAT interna, la NAT externa o la ACL. Otros problemas incluyen interoperabilidad con otras tecnologías de red, especialmente con aquellas que contienen o derivan información de direccionamiento de red del host en el paquete. Algunas de estas tecnologías incluyen las siguientes:

BOOTP y DHCP: ambos protocolos administran la asignación automática de direcciones IPv4 a los clientes. Recuerde que el primer paquete que un nuevo cliente envía es un paquete IPv4 de difusión de solicitud de DHCP. El paquete de solicitud de DHCP tiene la dirección IPv4 de origen 0.0.0.0. Debido a que la NAT requiere direcciones IPv4 de origen y de destino válidas, BOOTP y DHCP pueden tener dificultades para operar a través de un router que ejecuta una NAT estática o dinámica. La configuración de la característica de aplicación auxiliar IPv4 puede contribuir a la resolución de este problema.

DNS: como un router que ejecuta NAT dinámica cambia regularmente la relación entre las direcciones internas y externas a medida que las entradas de la tabla caducan y se recrean, un servidor DNS fuera del router NAT no tiene una representación precisa de la red dentro del router. La configuración de la característica de aplicación auxiliar IPv4 puede contribuir a la resolución de este problema.

SNMP: de manera similar a los paquetes DNS, la NAT no puede alterar la información de direccionamiento almacenada en el contenido de datos del paquete. Debido a esto, es posible que una estación de administración SNMP en un lado de un router NAT no pueda comunicarse con los agentes SNMP del otro lado del router NAT. La configuración de la característica de aplicación auxiliar IPv4 puede contribuir a la resolución de este problema.

Protocolos de cifrado y tunneling: los protocolos de cifrado y tunneling suelen requerir que el tráfico se origine en un puerto UDP o TCP específico o usan un protocolo en la capa de transporte que la NAT no puede procesar. Por ejemplo, la NAT no puede procesar los protocolos de tunneling IPsec y los protocolos de encapsulación de routing genérico usados por las implementaciones de VPN.

Resolución de problemas de capa de aplicación

La mayoría de los protocolos de la capa de aplicación proporcionan servicios para los usuarios. Los protocolos de la capa de aplicación normalmente se usan para la administración de red, la transferencia de archivos, los servicios de archivos distribuidos, la emulación de terminal y el correo electrónico. Con frecuencia, se agregan nuevos servicios para usuarios, como VPN y VoIP.

En la ilustración, se muestran los protocolos de capa de aplicación de TCP/IP más conocidos e implementados, que incluyen los siguientes:

SSH/Telnet: permite a los usuarios establecer conexiones de sesión de terminal a los hosts remotos.

HTTP: admite el intercambio de texto, gráficos, sonido, video y otros archivos multimedia en la Web.

FTP: realiza transferencias interactivas de archivos entre los hosts.

TFTP: realiza transferencias interactivas básicas de archivos, generalmente, entre hosts y dispositivos de red.

SMTP: admite servicios básicos de entrega de mensajes.

POP: conecta a los servidores de correo electrónico y descarga correo electrónico.

Protocolo simple de administración de red (SNMP): recopila información de administración de los dispositivos de red.

DNS: asigna direcciones IP a los nombres asignados a los dispositivos de red.

Sistema de archivos de red (NFS): habilita las computadoras para montar unidades en hosts remotos y operarlas como si fueran unidades locales. Desarrollado originalmente por Sun Microsystems, se combina con otros dos protocolos de capa de aplicación, la representación externa de datos (XDR) y la llamada a procedimiento remoto (RPC), para permitir un acceso transparente a los recursos de la red remota.

Los tipos de síntomas y causas dependen de la aplicación real propiamente dicha.

Los problemas de la capa de aplicación impiden la provisión de servicios a los programas de aplicación. Cuando la capa física, la capa de enlace de datos, la capa de red y la capa de transporte funcionan, un problema en la capa de aplicación puede tener como consecuencia recursos inalcanzables o inutilizables. Es posible que, teniendo una conectividad de red plena, la aplicación simplemente no pueda proporcionar datos.

Otro tipo de problema en la capa de aplicación ocurre cuando las capas física, de enlace de datos, de red y de transporte funcionan, pero la transferencia de datos y las solicitudes de servicios de red de un único servicio o aplicación de red no cumplen con las expectativas normales de un usuario.

Un problema en la capa de aplicación puede hacer que los usuarios se quejen de que, al transferir datos o solicitar servicios de red, la red o la aplicación específica con la que trabajan está inactiva o más lenta de lo normal.

Componentes de la resolución de problemas de conectividad de extremo a extremo

Diagnosticar y resolver problemas es una aptitud esencial para los administradores de red. No existe una única receta para la resolución de problemas, y un problema en particular se puede diagnosticar de muchas maneras diferentes. Sin embargo, al emplear un enfoque estructurado para el proceso de resolución de problemas, un administrador puede reducir el tiempo que tarda en diagnosticar y resolver un problema.

En este tema, se usa la siguiente situación. El host cliente PC1 no puede acceder a las aplicaciones en el servidor SRV1 o el servidor SRV2. En la ilustración, se muestra la topología de esta red. Para crear su dirección IPv6 de unidifusión global, la PC1 usa SLAAC con EUI-64. Para crear la ID de interfaz, EUI-64 usa la dirección MAC de Ethernet, inserta FFFE en el medio e invierte el séptimo bit.

Cuando no hay conectividad de extremo a extremo y el administrador elige resolver problemas con un enfoque ascendente, estos son los pasos frecuentes que el administrador puede seguir:

Paso 1. Revisar la conectividad física en el punto donde se detiene la comunicación de red. Esto incluye los cables y el hardware. El problema podría estar relacionado con un cable o una interfaz defectuosos o con un componente de hardware defectuoso o configurado incorrectamente.

Paso 2. Revisar las incompatibilidades de dúplex.

Paso 3. Revisar el direccionamiento de las capas de enlace de datos y de red en la red local. Esto incluye las tablas ARP de IPv4, las tablas de vecinos IPv6, las tablas de direcciones MAC y las asignaciones de VLAN.

Paso 4. Verificar que el gateway predeterminado sea correcto.

Paso 5: Asegurarse de que los dispositivos determinen la ruta correcta del origen al destino. Si es necesario, se debe manipular la información de routing.

Paso 6: Verificar que la capa de transporte funcione correctamente. También se puede usar Telnet desde la línea de comandos para probar las conexiones de la capa de transporte.

Paso 7: Verificar que no haya ACL que bloqueen el tráfico.

Paso 8: Asegurarse de que la configuración del DNS sea correcta. Debe haber un servidor DNS accesible.

El resultado de este proceso es una conectividad de extremo a extremo en condiciones de funcionamiento. Si se siguieron todos los pasos sin obtener resolución alguna, es posible que el administrador de red desee repetir los pasos anteriores o elevar el problema a un administrador más experimentado.

Problema de conectividad de extremo a extremo que inicia la resolución de problemas

Generalmente, lo que da inicio a un esfuerzo de resolución de problemas es la detección de un problema con la conectividad de extremo a extremo. Dos de las utilidades más comunes que se utilizan para verificar un problema con la conectividad de extremo a extremo son ping y traceroute, que se muestran en la figura 1.

Es probable que ping sea la utilidad de prueba de conectividad más popular en el ámbito de la tecnología de redes y siempre formó parte del software IOS de Cisco. Esta herramienta envía solicitudes de respuesta desde una dirección host especificada. El comando ping usa un protocolo de capa 3 que forma parte de la suite TCP/IP llamada ICMP. Ping usa la solicitud de eco ICMP y los paquetes de respuesta de eco ICMP. Si el host en la dirección especificada recibe la solicitud de eco ICMP, responde con un paquete de respuesta de eco ICMP. Se puede usar ping para verificar la conectividad de extremo a extremo tanto en IPv4 como en IPv6. En la figura 2, se muestra un ping satisfactorio de la PC1 al SRV1, en la dirección 172.16.1.100.

El comando traceroute en la figura 3 muestra la ruta que los paquetes IPv4 toman para llegar al destino. De manera similar a lo que sucede con el comando ping, se puede usar el comando traceroute del IOS de Cisco para IPv4 e IPv6. El comando tracert se usa con el sistema operativo Windows. El rastreo genera una lista de saltos, direcciones IP de router y la dirección IP de destino final a las que se llega correctamente a través de la ruta. Esta lista proporciona información importante sobre la verificación y la resolución de problemas. Si los datos llegan al destino, el rastreo indica la interfaz de cada router de la ruta. Si los datos fallan en algún salto de la ruta, se conoce la dirección del último router que respondió al rastreo. Esta dirección es un indicio de dónde se encuentran el problema o las restricciones de seguridad.

Según lo indicado, al proporcionar la dirección IPv6 como dirección de destino, las utilidades ping y traceroute se pueden usar para probar y diagnosticar la conectividad IPv6 de extremo a extremo. Al usarlas, las utilidades del IOS de Cisco reconocen si la dirección en cuestión es IPv4 o IPv6 y usan el protocolo apropiado para probar la conectividad. En la figura 4, se muestran los comandos ping y traceroute en el router R1 que se usa para probar la conectividad IPv6.

Nota: El comando traceroute suele ejecutarse cuando falla el comando ping. Si el comando ping se ejecuta correctamente, el comando traceroute generalmente no es necesario porque el técnico ya sabe que existe conectividad.

Paso 1: Verificar la capa física

Todos los dispositivos de red son sistemas de computación especializados. Como mínimo, estos dispositivos constan de una CPU, RAM y espacio de almacenamiento, que permiten que el dispositivo arranque y ejecute el sistema operativo y las interfaces. Esto permite la recepción y la transmisión del tráfico de la red. Cuando un administrador de red determina que existe un problema en un dispositivo determinado y que el problema puede estar relacionado con el hardware, vale la pena verificar el funcionamiento de estos componentes genéricos. Los comandos del IOS de Cisco usados con más frecuencia son show processes cpu, show memory y show interfaces. En este tema, se analiza el comando show interfaces.

Al resolver problemas relacionados con el rendimiento en los que se sospecha que el hardware es el culpable, se puede usar el comando show interfaces para verificar las interfaces que atraviesa el tráfico.

En el resultado del comando show interfaces en la ilustración, se indican varias estadísticas importantes que se pueden revisar:

Descartes de la cola de entrada: los descartes de la cola de entrada (y los contadores ignorados y de limitación relacionados) indican que, en algún momento, se entregó al router más tráfico del que podía procesar. Esto no indica necesariamente un problema. Podría ser normal durante los picos de tráfico. Sin embargo, podría ser una indicación de que la CPU no puede procesar los paquetes a tiempo, por lo que, si este número es permanentemente alto, vale la pena tratar de detectar en qué momentos aumentan estos contadores y cómo se relaciona eso con el uso de CPU.

Descartes de la cola de salida: los descartes de la cola de salida indican que se descartaron paquetes debido a la congestión en la interfaz. Es normal ver descartes de salida en cualquier punto donde la agregación de tráfico de entrada es superior al tráfico de salida. Durante los picos de tráfico, si el tráfico se entrega a la interfaz más rápidamente de que lo que se puede enviar, se descartan paquetes. Sin embargo, incluso si esto se considera un comportamiento normal, provoca el descarte de paquetes y retrasos en la cola, de modo que es posible que las aplicaciones afectadas por esas situaciones, como VoIP, tengan problemas de rendimiento. Los descartes de salidas frecuentes pueden ser indicio de que se debe implementar un mecanismo de puesta en cola avanzado para aplicar o modificar QoS.

Errores de entrada: los errores de entrada (input errors) indican errores que se experimentan durante la recepción de la trama, como errores de CRC. Una cantidad elevada de errores de CRC podría indicar problemas de cableado, problemas de hardware de interfaz o, en una red basada en Ethernet, incompatibilidades de dúplex.

Errores de salida: los errores de salida (output errors) indican errores durante la transmisión de una trama, por ejemplo, colisiones. En la actualidad, en la mayoría de las redes basadas en Ethernet, la transmisión full-duplex es la norma y la transmisión half-duplex es la excepción. En la transmisión full-duplex, no pueden ocurrir colisiones en las operaciones; por lo tanto, las colisiones (especialmente las colisiones tardías) indican con frecuencia incompatibilidades de dúplex.

Paso 2: Revisar las incompatibilidades de dúplex

Otra causa común de los errores de interfaz es un modo de dúplex incompatible entre los dos extremos de un enlace Ethernet. Actualmente, en numerosas redes basadas en Ethernet, las conexiones punto a punto son la norma, y el uso de hubs y la operación half-duplex asociadas se están volviendo menos frecuentes. Esto significa que, en la actualidad, la mayoría de los enlaces Ethernet operan en modo full-duplex y que, si bien se consideraba que las colisiones eran normales en un enlace Ethernet, hoy en día las colisiones suelen indicar que la negociación de dúplex falló y que el enlace no opera en el modo de dúplex correcto.

El estándar Gigabit Ethernet IEEE 802.3ab exige el uso de la autonegociación para velocidad y dúplex. Además, si bien no es estrictamente obligatorio, casi todas las NIC Fast Ethernet también usan la autonegociación de manera predeterminada. En la actualidad, la práctica recomendada es la autonegociación para velocidad y dúplex.

Sin embargo, si la negociación de dúplex falla por algún motivo, podría ser necesario establecer la velocidad y el dúplex manualmente en ambos extremos. Por lo general, esto conllevaría configurar el modo dúplex en full-duplex en ambos extremos de la conexión. Si esto no funciona, es preferible ejecutar semidúplex en ambos extremos para evitar una diiferencia entre dúplex.

Las pautas de configuración de dúplex incluyen:

Se recomienda la autonegociación de velocidad y dúplex.

Si la autonegociación falla, configure manualmente la velocidad y el dúplex en los extremos interconectados.

Los enlaces Ethernet de punto a punto siempre se deben ejecutar en modo full-duplex.

El semidúplex es inusual y solo suele encontrarse cuando se usan concentradores heredados.

Ejemplo de resolución de problemas

El administrador de red tuvo que agregar usuarios adicionales a la red de la situación anterior. Para incorporar a estos nuevos usuarios, el administrador de red instaló un segundo switch y lo conectó al primero. Poco después de que se agregó el S2 a la red, los usuarios en ambos switches comenzaron a experimentar importantes problemas de rendimiento al conectarse con los dispositivos en el otro switch, como se muestra en la figura 1.

El administrador de red observa un mensaje de la consola en el switch S2:

*Mar 1 00:45:08.756: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/20 (not half duplex), with Switch FastEthernet0/20 (half duplex).

Mediante el comando show interfaces fa 0/20, el administrador de red examina la interfaz en el S1 usada para conectarse al S2 y observa que está establecida en full-duplex, como se muestra en la figura 2. Ahora, el administrador de red examina el otro lado de la conexión: el puerto en el S2. En la figura 3, se muestra que este lado de la conexión se configuró como half-duplex. El administrador de red corrige la configuración y la establece en duplex auto, para que el dúplex se negocie automáticamente. Debido a que el puerto en el S1 se establece en full-duplex, el S2 también usa full-duplex.

Los usuarios informan que ya no existe ningún problema de rendimiento.

Paso 3: Verificar el direccionamiento de capa 2 y capa 3 en la red local

Al resolver problemas de conectividad de extremo a extremo, es útil verificar las asignaciones entre las direcciones IP de destino y las direcciones Ethernet de capa 2 en segmentos individuales. En IPv4, ARP proporciona esta funcionalidad. En IPv6, la funcionalidad de ARP se reemplaza por el proceso de detección de vecinos e ICMPv6. La tabla de vecinos almacena en caché las direcciones IPv6 y sus direcciones físicas de Ethernet (MAC) resueltas.

Tabla ARP de IPv4

El comando arp de Windows muestra y modifica las entradas en la caché ARP que se usan para almacenar las direcciones IPv4 y sus direcciones físicas de Ethernet (MAC) resueltas. Como se muestra en la figura 1, el comando arp de Windows enumera todos los dispositivos que actualmente están en la caché ARP. La información que se muestra para cada dispositivo incluye la dirección IPv4, la dirección física (MAC) y el tipo de direccionamiento (estático o dinámico).

Si el administrador de red desea volver a llenar la caché con información actualizada, se puede borrar la caché mediante el comando arp -d de Windows.

Nota: los comandos arp en Linux y MAC OS X tienen una sintaxis similar.

Tabla de vecinos de IPv6

Como se muestra en la figura 2, el comando netsh interface ipv6 show neighbor de Windows enumera todos los dispositivos que actualmente están en la tabla de vecinos. La información que se muestra para cada dispositivo incluye la dirección IPv6, la dirección física (MAC) y el tipo de direccionamiento. Al examinar la tabla de vecinos, el administrador de red puede verificar que las direcciones IPv6 de destino se asignen a las direcciones Ethernet correctas. Las direcciones IPv6 link-local se configuraron manualmente en todas las interfaces del R1 como FE80::1. De manera similar, se configuró el R2 con la dirección link-local FE80::2 en sus interfaces, y se configuró el R3 con la dirección link-local FE80::3 en sus interfaces. Recuerde que las direcciones link-local solo tienen que ser exclusivas en el enlace o la red.

Nota: en los sistemas operativos Linux y MAC OS X, se puede mostrar la tabla de vecinos mediante el comando ip neigh show.

En la figura 3, se muestra un ejemplo de la tabla de vecinos en un router con IOS de Cisco mediante el comando show ipv6 neighbors.

Nota: los estados de los vecinos en IPv6 son más complejos que los estados de la tabla ARP en IPv4. RFC 4861 contiene información adicional.

Tabla de direcciones MAC del switch

Cuando se encuentra una dirección MAC de destino en la tabla de direcciones MAC del switch, el switch reenvía la trama solo al puerto con el dispositivo que tiene esa dirección MAC específica. Para hacer esto, el switch consulta su tabla de direcciones MAC. La tabla de direcciones MAC indica la dirección MAC conectada a cada puerto. Use el comando show mac address-table para visualizar la tabla de direcciones MAC en el switch. La figura 4 muestra un ejemplo de tabla de direcciones MAC de switch. Vale notar que la dirección MAC de PC1, un dispositivo en VLAN 10, se detectó junto con el puerto de switch S1 al que se conecta PC1. Recuerde que la tabla de direcciones MAC de un switch solo contiene información de capa 2, que incluye la dirección MAC de Ethernet y el número de puerto. No se incluye información de dirección IP.

Asignación de red VLAN

Al resolver problemas de conectividad de extremo a extremo, otro problema que se debe considerar es la asignación de VLAN. En una red conmutada, cada puerto en un switch pertenece a una VLAN. Cada VLAN se considera una red lógica independiente, y los paquetes destinados a las estaciones que no pertenecen a la VLAN se deben reenviar a través de un dispositivo que admita el routing. Si el host de una VLAN envía una trama de Ethernet de transmisión, como una solicitud de ARP, todos los host de la misma VLAN recibirán la trama; los host de otras VLAN no la recibirán. Incluso si dos hosts están en la misma red IP, no se podrán comunicar si están conectados a puertos asignados a dos VLAN separadas. Además, si se elimina la VLAN a la que pertenece el puerto, este queda inactivo. Ninguno de los hosts conectados a los puertos que pertenecen a la VLAN que se eliminó se puede comunicar con el resto de la red. Los comandos como show vlan se pueden usar para validar las asignaciones de VLAN en un switch.

Ejemplo de resolución de problemas

Consulte la topología en la Figura 5. Para mejorar la administración de los cables en el armario de cableado, se reorganizaron los cables que se conectan al S1. Casi inmediatamente después de hacerlo, los usuarios comenzaron a llamar al soporte técnico con el comentario de que ya no tenían posibilidad de conexión a los dispositivos fuera de su propia red. Un examen de la tabla ARP de la PC1 mediante el comando arp de Windows muestra que la tabla ARP ya no contiene una entrada para el gateway predeterminado 10.1.10.1, como se muestra en la figura 6. No hubo cambios de configuración en el router, de modo que la resolución de problemas se centra en el S1.

La tabla de direcciones MAC para el S1, que se muestra en la figura 7, muestra que la dirección MAC del R1 está en una VLAN diferente que el resto de los dispositivos en 10.1.10.0/24, incluida la PC1. Mientras se volvían a conectar los cables, se trasladó el cable de conexión del R1 de Fa0/4 en la VLAN 10 a Fa0/1 en la VLAN 1. El problema se resolvió después de que el administrador de red configuró el puerto FA 0/1 del S1 para que estuviera en la VLAN 10, como se muestra en la figura 8. Como se muestra en la figura 9, ahora la tabla de direcciones MAC muestra la VLAN 10 para la dirección MAC del R1 en el puerto Fa0/1.

Paso 4: Verificar el gateway predeterminado

Si no hay una ruta detallada en el router o si el host está configurado con el gateway predeterminado incorrecto, la comunicación entre dos terminales en redes distintas no funciona. En la figura 1, se muestra que la PC1 usa el R1 como gateway predeterminado. De manera similar, el R1 usa al R2 como gateway predeterminado o como gateway de último recurso.

Si un host necesita acceso a recursos que se encuentran más allá de la red local, se debe configurar el gateway predeterminado. El gateway predeterminado es el primer router en la ruta a los destinos que se encuentran más allá de la red local.

Ejemplo de resolución de problemas 1

En la figura 2, se muestran el comando show ip route del IOS de Cisco y el comando route print de Windows para verificar la presencia del gateway predeterminado IPv4.

En este ejemplo, el router R1 tiene el gateway predeterminado correcto, que es la dirección IPv4 del router R2. Sin embargo, la PC1 tiene el gateway predeterminado incorrecto. La PC1 debería tener el gateway predeterminado 10.1.10.1 del router R1. Si la información de direccionamiento IPv4 se configuró en forma manual en la PC1, esto se debe configurar manualmente. Si la información de asignación de direcciones IPv4 s obtuvo automáticamente de un servidor DHCPv4, se deberá examinar la configuración del servidor DHCP. Los problemas de configuración de un servidor DHCP suelen afectar a varios clientes.

Ejemplo de resolución de problemas 2

En IPv6, el gateway predeterminado puede configurarse manualmente con la configuración automática independiente del estado (SLAAC) o con DHCPv6. Con SLAAC, el router anuncia el gateway predeterminado a los hosts mediante los mensajes de anuncio de router (RA) ICMPv6. El gateway predeterminado en el mensaje RA es la dirección IPv6 link-local de una interfaz del router. Si el gateway predeterminado se configura manualmente en el host, lo que es muy poco probable, se puede establecer el gateway predeterminado en la dirección IPv6 global o en la dirección IPv6 link-local.

Como se muestra en la figura 3, se debe usar el comando show ipv6 route de Cisco IOS para comprobar la ruta predeterminada de IPv6 en R1 y el comando de Windows ipconfig para verificar si una PC tiene un gateway predeterminado IPv6.

El R1 tiene una ruta predeterminada a través del router R2, pero observe que el comando ipconfig revela la ausencia de una dirección IPv6 de unidifusión global y un gateway predeterminado IPv6. La PC1 está habilitada para IPv6 debido a que tiene una dirección IPv6 link-local. El dispositivo crea automáticamente la dirección link-local. Al revisar la documentación de red, el administrador de red confirma que los hosts en esta LAN deberían recibir la información de dirección IPv6 del router que usa SLAAC.

Nota: en este ejemplo, otros dispositivos que usen SLAAC en la misma LAN también experimentarían el mismo problema al recibir la información de dirección IPv6.

Mediante el comando show ipv6 interface GigabitEthernet 0/0 en la figura 4, se puede observar que, si bien la interfaz tiene una dirección IPv6, no forma parte del grupo de multidifusión de todos los routers IPv6, FF02::2. Esto significa que el router no está habilitado como router IPv6. Por eso no envía RA de ICMPv6 en esta interfaz. En la figura 5, el R1 se habilita como router IPv6 mediante el comando ipv6 unicast-routing. Ahora, el comando show ipv6 interface GigabitEthernet 0/0 revela que el R1 forma parte de FF02::2, el grupo de multidifusión de todos los routers IPv6.

Para verificar que la PC1 tenga configurado el gateway predeterminado, use el comando ipconfig en la PC con Microsoft Windows o el comando ifconfig en Linux y Mac OS X. En la figura 6, la PC1 tiene una dirección IPv6 de unidifusión global y un gateway predeterminado IPv6. El gateway predeterminado se configura en la dirección de enlace local del router R1, FE80::1.

Paso 5: Verificar la ruta correcta

Resolución de problemas de la capa de red

Al resolver problemas, con frecuencia es necesario verificar la ruta hacia la red de destino. En la figura 1, se muestra la topología de referencia que indica la ruta deseada para los paquetes de la PC1 al SRV1.

En la figura 2, se usa el comando show ip route para examinar la tabla de routing IPv4.

Las tablas de routing IPv4 e IPv6 se pueden llenar con los siguientes métodos:

Redes conectadas directamente

Host local o rutas locales

Rutas estáticas

Rutas dinámicas

Rutas predeterminadas

El proceso de reenvío de paquetes IPv4 e IPv6 se basa en la coincidencia más larga de bits o de prefijos. El proceso de la tabla de routing intenta reenviar el paquete mediante una entrada en la tabla de routing con el máximo número de bits coincidentes en el extremo izquierdo. La longitud de prefijo de la ruta indica el número de bits coincidentes.

En la figura 3, se muestra una situación similar con IPv6. Para verificar que la ruta IPv6 actual coincide con la ruta deseada para llegar a los destinos, use el comando show ipv6 route en el router para examinar la tabla de routing. Después de examinar la tabla de routing IPv6, el R1 tiene una ruta a 2001:DB8:ACAD:4::/64 mediante el R2 en FE80::2.

La siguiente lista, junto con la figura 4, describe el proceso de las tablas de routing IPv4 e IPv6. Si la dirección de destino en un paquete:

No coincide con una entrada en la tabla de routing, se usa la ruta predeterminada. Si no hay una ruta predeterminada que esté configurada, se descarta el paquete.

Coincide con una única entrada en la tabla de routing, el paquete se reenvía a través de la interfaz definida en esta ruta.

Coincide con más de una entrada en la tabla de routing y las entradas de routing tienen la misma longitud de prefijo, los paquetes para este destino se pueden distribuir entre las rutas definidas en la tabla de routing.

Coincide con más de una entrada en la tabla de routing y las entradas de routing tienen longitudes de prefijo diferentes, los paquetes para este destino se reenvían por la interfaz que está asociada a la ruta que tiene la coincidencia de prefijos más larga.

Ejemplo de resolución de problemas

Los dispositivos no se pueden conectar al servidor SRV1 en 172.16.1.100. Mediante el comando show ip route, el administrador debe revisar si existe una entrada de routing en la red 172.16.1.0/24. Si la tabla de routing no tiene una ruta específica a la red del SRV1, el administrador de red debe revisar la existencia de una entrada de ruta resumida o predeterminada en el sentido de la red 172.16.1.0/24. Si no existe ninguna entrada, es posible que el problema esté relacionado con el routing y que el administrador deba verificar que la red esté incluida dentro de la configuración del protocolo de routing dinámico o que deba agregar una ruta estática.

Paso 6: Verificar la capa de transporte

Resolución de problemas de la capa de transporte

Si la capa de red parece funcionar como se esperaba, pero los usuarios aún no pueden acceder a los recursos, el administrador de red debe comenzar a resolver problemas en las capas superiores. Dos de los problemas más frecuentes que afectan la conectividad de la capa de transporte incluyen las configuraciones de ACL y de NAT. Una herramienta frecuente para probar la funcionalidad de la capa de transporte es la utilidad Telnet.

Precaución: si bien se puede usar Telnet para probar la capa de transporte, por motivos de seguridad se debe usar SSH para administrar y configurar los dispositivos en forma remota.

Un administrador de red trabaja en la resolución de un problema en el que una persona no puede enviar correo electrónico a través de un servidor SMTP determinado. El administrador hace ping al servidor, y este responde. Esto significa que la capa de red y todas las capas inferiores a esta entre el usuario y el servidor están en condiciones de funcionamiento. El administrador sabe que el problema está en la capa 4 o en las capas superiores y que debe comenzar a resolver problemas en esas capas.

Aunque la aplicación de servidor Telnet se ejecute en su propio número de puerto 23 conocido y los clientes de Telnet se conecten a este puerto de manera predeterminada, se puede especificar un número de puerto diferente en el cliente para conectarse a cualquier puerto TCP que deba probarse. Esto indica si la conexión se acepta (como se indica mediante la palabra “Open” [Abierta] en el resultado), se deniega o si excede el tiempo de espera. A partir de cualquiera de estas respuestas, se pueden obtener otras conclusiones relacionadas con la conectividad. En ciertas aplicaciones, si usan un protocolo de sesión basado en ASCII (incluso pueden mostrar un aviso de la aplicación), es posible desencadenar algunas respuestas desde el servidor al escribir ciertas palabras clave, como con SMTP, FTP y HTTP.

Dada la situación anterior, el administrador accede mediante Telnet al servidor HQ desde la PC1, a través de IPv6, y la sesión Telnet es correcta, como se muestra en la figura 1. En la figura 2, el administrador intenta acceder mediante Telnet al mismo servidor, a través del puerto 80. En el resultado, se verifica que la capa de transporte se conecta correctamente de la PC1 a HQ. Sin embargo, el servidor no acepta conexiones en el puerto 80.

En el ejemplo de la figura 3, se muestra una conexión Telnet correcta del R1 al R3, a través de IPv6. En la figura 4, se observa un intento similar de acceder mediante Telnet a través del puerto 80. Una vez más, en el resultado se verifica una conexión correcta de la capa de transporte, pero el R3 rechaza la conexión mediante el puerto 80.

Paso 7: Verificar las ACL

En los routers, puede haber ACL configuradas que prohíben a los protocolos atravesar la interfaz en sentido entrante o saliente.

Use el comando show ip access-lists para visualizar el contenido de todas las ACL de IPv4 y el comando show ipv6 access-list para visualizar el contenido de todas las ACL de IPv6 configuradas en un router. Como una opción de este comando, se puede visualizar una ACL específica al introducir el nombre o el número de la ACL. Los comandos show ip interfaces y show ipv6 interfaces muestran la información de interfaz IPv4 e IPv6 que indica hay alguna ACL de IP establecida en la interfaz.

Ejemplo de resolución de problemas

Para prevenir los ataques de suplantación de identidad, el administrador de red decidió implementar una ACL para evitar que los dispositivos con la dirección de red de origen 172.16.1.0/24 ingresen a la interfaz de entrada S0/0/1 en el R3, como se muestra en la figura 1. Se debe permitir el resto del tráfico IP.

Sin embargo, poco después de implementar la ACL, los usuarios en la red 10.1.10.0/24 no podían conectarse a los dispositivos en la red 172.16.1.0/24, incluido el SRV1. Como se ve en la figura 2, el comando show ip access-lists muestra que la ACL está configurada correctamente. El comando show ip interfaces serial 0/0/1 indica que la ACL nunca se aplicó a la interfaz entrante del puerto Serial 0/0/1. Una investigación más profunda revela que la ACL se aplicó accidentalmente a la interfaz G0/0, lo que bloqueó todo el tráfico saliente de la red 172.16.1.0/24.

Una vez ubicada correctamente la ACL IPv4 en la interfaz entrante del puerto Serial 0/0/1, como se muestra en la figura 3, los dispositivos podrán conectarse con éxito al servidor.

Paso 8: Verificar DNS

El protocolo DNS controla el DNS, una base de datos distribuida mediante la cual se pueden asignar nombres de host a las direcciones IP. Cuando configura el DNS en el dispositivo, puede reemplazar el nombre de host por la dirección IP con todos los comandos IP, como ping o telnet.

Para visualizar la información de configuración de DNS en el switch o el router, utilice el comando show running-config. Cuando no hay instalado un servidor DNS, es posible introducir asignaciones de nombres a direcciones IP directamente en la configuración del switch o del router. Use el comando ip host para introducir una asignación de nombre a dirección IPv4 en el switch o el router. El comando ipv6 host se usa para realizar las mismas asignaciones en IPv6. En la figura 1, se demuestran estos comandos. Dado que los números de red IPv6 son largos y difíciles de recordar, el DNS es incluso más importante para IPv6 que para IPv4.

Para visualizar la información de asignación de nombre a dirección IP en una computadora con Windows, use el comando nslookup.

Ejemplo de resolución de problemas

La salida de la figura 2 indica que el cliente no pudo comunicarse con el servidor DNS o que el servicio de DNS del dispositivo 10.1.1.1 no estaba en ejecución. En este momento, la resolución de problemas se debe centrar en las comunicaciones con el servidor DNS o en verificar que el servidor DNS funcione correctamente.

Para visualizar la información de configuración de DNS en una computadora con Microsoft Windows, use el comando nslookup. Debe haber un DNS configurado para IPv4, para IPv6 o para ambos. El DNS puede proporcionar direcciones IPv4 e IPv6 al mismo tiempo, independientemente del protocolo que se use para acceder al servidor DNS.

Debido a que los nombres de dominio y el DNS son un componente fundamental para acceder a los servidores en una red, muchas veces el usuario piensa que “la red está inactiva” cuando, en realidad, el problema se encuentra en el servidor DNS.

Etiquetas

lunes, 24 de diciembre de 2018