CCNA 3 Versión 7: Módulo 12 – Resolución de problemas de red

Última actualización: enero 30, 2022

12.0. Introducción

12.0.1. ¿Por qué debería tomar este módulo?

Bienvenido a la Resolución de problemas de red!

¿Quién es el mejor administrador de red que haya visto? ¿Por qué crees que esta persona es tan buena en eso? Probablemente, es porque esta persona es realmente buena para resolver problemas de red. Probablemente sean administradores experimentados, pero esa no es toda la historia. Los buenos solucionadores de problemas de red generalmente lo hacen de manera metódica, y utilizan todas las herramientas disponibles para ellos.

La verdad es que la única manera de convertirse en un buen solucionador de problemas de red es siempre solucionar problemas. Lleva tiempo ser bueno en esto. Pero por suerte para ti, hay muchos, muchos consejos y herramientas que puedes usar. Este módulo cubre los diferentes métodos de resolución de problemas de red y todos los consejos y herramientas que necesita para comenzar. Este módulo también tiene dos muy buenas actividades Packet Tracer para poner a prueba sus nuevas habilidades y conocimientos. Tal vez su objetivo debería ser convertirse en el mejor administrador de red que nadie jamás ha visto nunca!

12.0.2. ¿Qué aprenderé en este módulo?

Título del módulo: Resolución de problemas de red

Objetivos del módulo: Resuelva problemas de redes empresariales.

12.1. Documentación de red

12.1.1. Descripción general de la documentación

Al igual que con cualquier actividad compleja, como la resolución de problemas de red, se debe comenzar con una buena documentación. Se requiere documentación de red precisa y completa para supervisar y solucionar problemas de redes de manera eficaz.

La documentación de red común incluye lo siguiente:

• Diagramas lógicos y físicos de topología de la red
• Documentación de dispositivos de red que registra toda la información pertinente del dispositivo
• Documentación de referencia del rendimiento de la red

Toda la 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.

12.1.2. 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.

Haga clic en cada botón para ver un ejemplo y una explicación de las topologías físicas y lógicas.

12.1.3. Documentación de dispositivos de red

La documentación de red debería contener registros precisos y actualizados del hardware y el software usados en una red. La documentación debe incluir toda la información pertinente sobre los dispositivos de red.

Muchas organizaciones crean documentos con tablas u hojas de cálculo para capturar información relevante del dispositivo.

Haga clic en cada botón para ver ejemplos de documentación del router, el switch y el dispositivo final.

12.1.4. Establecer una línea de base

El monitoreo de red permite controlar el rendimiento de la red con respecto a la línea de base predeterminada. Una línea de base se utiliza para establecer el rendimiento normal de la red o del sistema, para determinar la «personalidad» de una red en condiciones normales.

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.

Una línea de base debería responder las siguientes preguntas:

• ¿Cómo funciona la red durante un día normal o promedio?
• ¿Dónde ocurre la mayoría de los errores?
• ¿Qué parte de la red se usa con más frecuencia?
• ¿Qué parte de la red se usa con menos frecuencia?
• ¿Qué dispositivos deben monitorearse? ¿Qué umbrales de alerta deben establecerse?
• ¿Puede la red cumplir con las políticas identificadas?

Medir el rendimiento y la disponibilidad inicial, de los dispositivos de red críticos, permite a los administradores determinar la diferencia entre un rendimiento normal y uno anormal, ya sea cuando la red crece, o el flujo de tráfico cambia. 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 sub-utilizando y, con bastante frecuencia, puede originar esfuerzos para rediseñar la red sobre la base de las observaciones de calidad y capacidad.

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.

12.1.5. Paso 1 – Determinar el tipo de informacion a recopilar

Al establecer la línea de base inicial, comience por seleccionar algunas variables que representen a las políticas definidas. Si se seleccionan demasiados datos, la cantidad de datos puede ser abrumadora, lo que dificulta el análisis. Comience de manera simple y realice ajustes a lo largo del proceso. Algunos puntos de inicio a considerar son la utilización de CPU e interfaces.

12.1.6. Paso 2 – Identifique los dispositvos y 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. Dispositivos y puertos de interés incluyen los siguientes:

• 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

Una topología de red logica puede ser útil para identificar los dispositivos y puertos que se deben monitorear. En la figura, el administrador de red ha sobresaltado los dispositivos y puertos de interés basado en la linea de base.

Los dispositivos de interés incluyen la PC1 (la terminal de administración) y los dos servidores (Svr1 y Svr2)el servidor web/TFTP). Los puertos de interés suelen incluir interfaces de router y puertos clave en switches.

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).

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

La duración y la información que se recolecta, debe ser lo suficientemente larga para determinar que se considera «normal» en la red. 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 largo, 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, 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. Realice un análisis anual de toda la red o bien analice la línea de base de diferentes secciones de la red, de manera rotativa. Para entender la forma en que el crecimiento y otros cambios afectan la red, el análisis se debe realizar periódicamente.

12.1.8. Medición de 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.

La tabla 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 show comandos 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 protocolos inspección 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 programas 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.

12.2. Proceso de resolución de problemas

12.2.1. Procedimientos generales de resolución de problemas

La resolución de problemas puede llevar mucho tiempo porque las redes difieren, los problemas difieren y la experiencia de solución de problemas varía. Sin embargo, los administradores experimentados saben que el uso de un método estructurado de resolución de problemas reducirá el tiempo general de resolución de problemas.

Por lo tanto, el proceso de resolución de problemas debe guiarse por métodos estructurados. Esto requiere procedimientos de resolución de problemas bien definidos y documentados, para minimizar el tiempo perdido asociado con la resolución de problemas erráticos. Sin embargo, estos métodos no son estáticos. Los pasos de resolución de problemas realizados para resolver un problema no siempre son los mismos o se ejecutan en el mismo orden.

Existen varios procesos de resolución de problemas que se pueden usar para resolver un problema. La figura muestra el diagrama de flujo lógico de un proceso simplificado de resolución de problemas de tres etapas. Sin embargo, un proceso más detallado puede ser más útil para resolver un problema de red.

12.2.2. Proceso de Siete Pasos para la Resolución de Problemas

La figura muestra un proceso de solución de problemas de siete pasos más detallado. Observe cómo se interconectan algunos pasos. Esto se debe a que algunos técnicos pueden saltar entre pasos en función de su nivel de experiencia.

Haga clic en cada botón para obtener una descripción detallada de los pasos para resolver un problema de red.

12.2.3. Hacer preguntas a usuarios finales.

Muchos problemas de red son notificados inicialmente por un usuario final. Sin embargo, la información facilitada suele ser vaga o engañosa. Por ejemplo, los usuarios suelen informar de problemas como «la red no funciona», «No puedo acceder a mi correo electrónico» o «mi equipo esta lento».

En la mayoría de los casos, se requiere información adicional para comprender completamente un problema. Esto generalmente implica interactuar con el usuario afectado para descubrir el «quién», «qué» y «cuándo» del problema.

Las siguientes recomendaciones deben emplearse al comunicarse con el usuario:

• Hablar a un nivel técnico que puedan entender y evitar el uso de terminología compleja.
• Siempre escuche o lea atentamente lo que el usuario está diciendo. Tomar notas puede ser útil a la hora de documentar un problema complejo.
• Sea siempre considerado y empatice con los usuarios mientras les hace saber que les ayudará a resolver su problema. Los usuarios que informan de un problema pueden estar sometidos a estrés y ansiosos por resolver el problema lo antes posible.

Al entrevistar al usuario, guíe la conversación y use técnicas de cuestionamiento efectivas para determinar rápidamente el problema. Por ejemplo, use preguntas abiertas (es decir, requiere una respuesta detallada) y preguntas cerradas (es decir, sí, no, o respuestas de una sola palabra) para descubrir hechos importantes sobre el problema de la red.

La tabla proporciona algunas directrices/pautas y ejemplos de preguntas para los usuarios finales.

Cuando termine de entrevistar al usuario, repítale lo que usted ha entendido, para asegurarse de que ambos están de acuerdo en el problema que se informa.

12.2.4. Recopilar información

Para recopilar los síntomas de un dispositivo de red sospechoso, use los comandos de Cisco IOS y otras herramientas como capturas de paquetes y registros de los dispositivos.

La tabla 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 tráfico (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 resolución de problemas y que el rendimiento de la red puede verse afectado. Al terminar, recuerde deshabilitar la depuración.

12.2.5. Solución de problemas con modelos en capas

Cuando se realiza la resolución de problemas, se pueden aplicar los modelos OSI y TCP/IP 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.

La figura muestra 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 ACL en los mismos para tomar decisiones de filtrado con la información de la capa 4.

12.2.6. Métodos Estructurados de Resolución de problemas

Existen varios enfoques estructurados de resolución de problemas que se pueden utilizar. Cuál usar dependerá de la situación. 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.

Haga clic en cada botón para obtener una descripción de los diferentes enfoques de solución de problemas que se pueden utilizar.

12.2.7. 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.

La figura ilustra qué método se podría utilizar cuando se descubre un cierto tipo de problema.

Por ejemplo, los problemas de software a menudo se resuelven utilizando un enfoque descendente mientras que los problemas basados en hardware se resuelven utilizando el enfoque ascendente. Los nuevos problemas pueden ser resueltos por un técnico experimentado utilizando el método de divide y vencerás. De lo contrario, se puede utilizar el enfoque ascendente.

La resolución de problemas es una habilidad que se desarrolla al hacerlo. Cada problema de red que identifique y resuelva se añade a sus habilidades.

12.3. Herramientas para la resolución de problemas

12.3.1. Software de resolución de problemas

Como usted sabe, las redes están formadas por software y hardware. Por lo tanto, tanto el software como el hardware tienen sus respectivas herramientas para la resolución de problemas. En este tema se describen las herramientas de resolución de problemas disponibles para ambas.

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.

Haga clic en cada botón para obtener una descripción detallada de las herramientas comunes de solución de problemas de software.

12.3.2. 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 datos bit físicos, la información de enlaces de datos, protocolos, 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.

12.3.3. Herramientas de solución de problemas de hardware

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

Haga clic en cada botón para obtener una descripción detallada de las herramientas comunes de solución de problemas de hardware.

12.3.4. Servidor Syslog como herramienta de resolución de problemas

Syslog es un protocolo simple usado por cualquier dispositivo IP, conocido como “cliente syslog”, 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.
• 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, que superen el 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 clasifican en uno de ocho niveles, como se muestra en la tabla.

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 se usa para limitar los mensajes registrados en el servidor syslog según la gravedad. El nivel es el nombre o número de nivel de la severidad. Solo se registran los mensajes de número igual o menor que el nivel de especificado.

En el comando de salida, los mensajes de sistema del nivel 0 (emergencias) al 5 (notificaciones) se envían al servidor de syslog en 209.165.200.225.

R1(config)# logging host 209.165.200.225 
R1(config)# logging trap notifications 
R1(config)# logging on
R1(config)#

12.4. Síntomas y causas de los problemas de red

12.4.1. Resolución de problemas de la capa física

Ahora que tiene su documentación, algunos conocimientos sobre los métodos de resolución de problemas y las herramientas de software y hardware para diagnosticar problemas, ¡está listo para comenzar a solucionar problemas! En este tema se tratan los problemas más comunes que encontrará al solucionar problemas de una red.

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 espera. 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.

La figura resume los síntomas y las causas de los problemas de red en la capa física.

La tabla enumera los síntomas comunes de los problemas de capa física.

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

12.4.2. 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 funcionales. Los problemas de capa 2 causan síntomas específicos que, al reconocerse, ayudan a identificar el problema rápidamente.

La figura resume los síntomas y las causas de los problemas de red de capa de enlace de datos.

La tabla enumera los síntomas comunes de los problemas de red de capa de enlace de datos.

La tabla enumera los problemas que suelen causar problemas de red en la capa de Enlace de datos.

12.4.3. Resolución de problemas de capa de red

Los problemas de capa de red incluyen cualquier problema que implique un protocolo de capa 3, como IPv4, IPv6, EIGRP, OSPF, etc. La figura resume los síntomas y las causas de los problemas de la capa de red.

La tabla enumera los síntomas comunes de los problemas la capa de red .

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

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

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

La tabla muestra areas a explorar cuando se diagnostica un posible problema que involucra protocolos de enrutamiento.

12.4.4. 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 borde de la red, donde se examina y se modifica el tráfico. Por ejemplo, tanto las listas de control de acceso (ACL) como la traducción de direcciones de red (NAT) funcionan en la capa de red y pueden implicar operaciones en la capa de transporte, como se muestra en la figura.

La mayoría de los problemas frecuentes con ACL se debe a una configuración incorrecta, como se muestra en la figura.

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:

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.

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

Existen varios problemas con NAT, como la falta de interacción con servicios como DHCP y tunneling. Estos pueden incluir la configuración incorrecta de NAT interno, NAT externo 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.

La figura resume areas frecuentes de interoperabilidad con NAT

La tabla enumera áreas frecuentes de interoperabilidad con NAT.

12.4.6. 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.

12.5. Resolución de problemas de conectividad IP

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

En este tema se presenta una topología única y las herramientas para diagnosticar y, en algunos casos, resolver un problema 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 unicast 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 enrutamiento.
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 deberia proveer conectividad de extremo a extremo. 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.

12.5.2. Problema de conectividad de extremo a extremo inicio de 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.

Haga clic en cada botón para revisar las utilidades ping, traceroute y tracert.

C:\ > ping 172.16.1.100
Pinging 172.16.1.100 with 32 bytes of data:
Reply from 172.16.1.100: bytes=32 time=199ms TTL=128
Reply from 172.16.1.100: bytes=32 time=193ms TTL=128
Reply from 172.16.1.100: bytes=32 time=194ms TTL=128
Reply from 172.16.1.100: bytes=32 time=196ms TTL=128
Ping statistics for 172.16.1.100:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 193ms, Maximum = 199ms, Average = 195ms
C:\ >

C:\ > tracert 172.16.1.100
Tracing route to 172.16.1.100 over a maximum of 30 hops:
  1 1 ms <1 ms <1 ms 10.1.10.1 2 2 ms 2 ms 1 ms 192.168.1.2 3 2 ms 2 ms 1 ms 192.168.1.6 4 2 ms 2 ms 1 ms 172.16.1.100 Trace complete. C:\ >

R1# ping 2001:db8:acad:4::100 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:4::100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R1#
R1# traceroute 2001:db8:acad:4::100 
Type escape sequence to abort.
Tracing the route to 2001:DB8:ACAD:4::100
1.   2001:DB8:ACAD:2::2 20 mseg 20 mseg 20 mseg 20 mseg
2.   2001:DB8:ACAD:3::2 44 mseg 40 mseg 
R1#

Note: The El comando command is commonly performed when the traceroute se utiliza cuando el comando command fails. If the ping ha fallado. Si el succeeds, the ping fue exitoso, entonces el comando traceroute no es necesario porque el técnico ya sabe que existe conectividad.

Nota: El comando traceroute se realiza comúnmente cuando falla el comando ping. Si el ping tiene éxito, el comando traceroute generalmente no es necesario porque el técnico sabe que existe conectividad.

12.5.3. 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 de Cisco IOS más utilizados para este propósito son show processes cpu, show memory, y show interfaces. En este tema, se analiza el comando show interfaces .

Cuando se trabajan en problemas relacionados al rendimiento y se sospecha del hardware, el comando show interfaces puede ser usado para revisar las interfaces por las que el trafico pasa.

Consulte el resultado del comando show interfaces .

R1# show interfaces GigabitEthernet 0/0/0
GigabitEthernet0/0/0 is up, line protocol is up 
Hardware is CN Gigabit Ethernet, address is d48c.b5ce.a0c0(bia d48c.b5ce.a0c0) 
Internet address is 10.1.10.1/24 
(Output omitted)
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo 
 Output queue: 0/40 (size/max) 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
85 packets input, 7711 bytes, 0 no buffer 
Received 25 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 
0 watchdog, 5 multicast, 0 pause input 
10112 packets output, 922864 bytes, 0 underruns 
0 output errors, 0 collisions, l interface resets 
11 unknown protocol drops 
0 babbles, 0 late collision, 0 deferred 
0 lost carrier, 0 no carrier, 0 pause output 
0 output buffer failures, 0 output buffers swapped out 
R1#

Haga clic en cada botón para obtener una explicación de la salida resaltada.

12.5.4. 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 diferencia 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 hubs.

Ejemplo de resolución de problemas

En el escenario anterior, el administrador de red tuvo que agregar usuarios adicionales a la red 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.

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

S1# show interface fa 0/20
FastEthernet0/20 is up, line protocol is up (connected) 
Hardware is Fast Ethernet, address is 0cd9.96e8.8a01 (bia 0cd9.96e8.8a01)
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
Full-duplex, Auto-speed, media type is 10/100BaseTX 
  
(Output omitted)
  
S1#

Ahora, el administrador de red examina el otro lado de la conexión: el puerto en el S2. Se muestra que este lado de la conexión se configuró como half-duplex.

S2# show interface fa 0/20
FastEthernet0/20 is up, line protocol is up (connected) 
Hardware is Fast Ethernet, address is 0cd9.96d2.4001 (bia 0cd9.96d2.4001)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
Half-duplex, Auto-speed, media type is 10/100BaseTX 
  
(Output omitted)
  
S2(config)# interface fa 0/20 
S2(config-if)# duplex auto 
S2(config-if)#

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.

12.5.5. Paso 3: Verificar el direccionamiento 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.

Haga clic en cada botón para ver un ejemplo y una explicación del comando para verificar el direccionamiento de Capa 2 y Capa 3.

C:\> arp -a
Interface: 10.1.10.100 --- 0xd
  Internet Address      Physical Address      Type
  10.1.10.1             d4-8c-b5-ce-a0-c0    dynamic
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.251           01-00-5e-00-00-fb     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static
C:\>

C:\> netsh interface ipv6 show neighbor 
Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
fe80::9657:a5ff:fe0c:5b02                     94-57-a5-0c-5b-02  Stale
fe80::1                                       d4-8c-b5-ce-a0-c0  Reachable (Router)
ff02::1                                       33-33-00-00-00-01  Permanent
ff02::2                                       33-33-00-00-00-02  Permanent
ff02::16                                      33-33-00-00-00-16  Permanent
ff02::1:2                                     33-33-00-01-00-02  Permanent
ff02::1:3                                     33-33-00-01-00-03  Permanent
ff02::1:ff0c:5b02                             33-33-ff-0c-5b-02  Permanent
ff02::1:ff2d:a75e                             33-33-ff-2d-a7-5e  Permanent

R1# show ipv6 neighbors 
IPv6 Address                        Age  Link-layer Addr   State  Interface
FE80::21E:7AFF:FE79:7A81              8  001e.7a79.7a81    STALE  Gi0/0
2001:DB8:ACAD:1:5075:D0FF:FE8E:9AD8   0  5475.d08e.9ad8    REACH  Gi0/0

S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan      Mac Address         Type     Ports
All       0100.0ccc.cccc      STATIC   CPU
All       0100.0ccc.cccd      STATIC   CPU
10        d48c.b5ce.a0c0      DYNAMIC  Fa0/4
10        000f.34f9.9201      DYNAMIC  Fa0/5
10        5475.d08e.9ad8      DYNAMIC  Fa0/13
Total Mac Addresses for this criterion: 5

12.5.6. Ejemplo de resolución de problemas de Asignación de 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 enrutamiento. 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.

Supongamos, por ejemplo, que en un esfuerzo por mejorar la gestión de cables en el armario de cableado, su empresa ha reorganizado los cables que se conectan al switch 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.

Haga clic en cada botón para obtener una explicación del proceso utilizado para solucionar este problema.

C:\> arp -a
Interfaz: 10.1.10.100 — 0xd
  Internet Address Physical Address Type
  224.0.0.22 01-00-5e-00-00-16 static
  224.0.0.251 01-00-5e-00-00-fb static
  239.255.255.250 01-00-5e-7f-ff-fa static
  255.255.255.255 ff-ff-ff-ff-ff-ff static
C:\ >

S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan Mac Address Type Ports
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
 1 d48c.b5ce.a0c0 DYNAMIC Fa0/1
10 000f.34f9.9201 DYNAMIC Fa0/5
10 5475.d08e.9ad8 DYNAMIC Fa0/13
Total Mac Addresses for this criterion: 5
S1#

S1(config)# interface fa0/1
S1(config-if)# switchport mode access
S1(config-if)# switchport access vlan 10
S1(config-if)# exit
S1# 
S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan Mac Address Type Ports
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
10 d48c.b5ce.a0c0 DYNAMIC Fa0/1
10 000f.34f9.9201 DYNAMIC Fa0/5
10 5475.d08e.9ad8 DYNAMIC Fa0/13
Total Mac Addresses for this criterion: 5
S1#

12.5.7. Paso 4: Verificar la puerta de enlace predeterminada

Si no hay una ruta detallada en el router o si el host está configurado con la puerta de enlace predeterminada incorrecta, la comunicación entre dos terminales en redes distintas no funciona.

En la figura, se muestra que la PC1 usa el R1 como puerta de enlace predeterminada. De manera similar, el R1 usa al R2 como puerta de enlance predeterminada 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 la puerta de enlace predeterminada. La puerta de enlace predeterminada 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 de puerta de enlace predeterminada IPv4

En este ejemplo, R1 tiene la puerta de enlace predeterminada correcta, que es la dirección IPv4 de 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 se 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.

Haga clic en cada botón para ver la salida del comando para R1 y PC1.

R1# show ip route | include gateway|0.0.0.0
  
Gateway of last resort is 192.168.1.2 to network 0.0.0.0 
S* 0.0.0.0/0 [1/0] via 192.168.1.2
  
R1#

C:\> route print
(Output omitted)
  
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.1.10.1      10.1.10.10      11
(Output omitted)

12.5.8. Ejemplo de solución de problemas de la puerta de enlace predeterminada de IPv6

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.

Haga clic en cada botón para ver un ejemplo y una explicación de cómo solucionar un problema de puerta de enlace predeterminada IPv6.

R1# show ipv6 route
  
(Output omitted)
  
S ::/0 [1/0]
via 2001:DB8:ACAD:2::2
R1#

C:\> ipconfig 
Windows IP Configuration
   Connection-specific DNS Suffix . :
   Link-local IPv6 Address . . . .: fe80::5075:d0ff:fe8e:9ad 8% 13
   IPv4 Address . . . . . . . . . . : 10.1.10.10 
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway. . . . . . . . . : 10.1.10.1
C:\ >

R1# show ipv6 interface GigabitEthernet 0/0/0
GigabitEthernet0/0/0 is up, line protocol is up 
  IPv6 is enabled, link-local address is FE80::1 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
  Joined group address(es):
      FF02:: 1
      FF02::1:FF00:1
  
(Output omitted)
R1#

R1(config)# ipv6 unicast-routing
R1(config)# exit
R1# show ipv6 interface GigabitEthernet 0/0/0 
GigabitEthernet0/0/0 is up, line protocol is up 
  IPv6 is enabled, link-local address is FE80::1 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
  Joined group address(es): 
      FF02:: 1
      FF02:: 2
      FF02::1:FF00:1
(Output omitted)
R1#

C:\> ipconfig 
Windows IP Configuration
   Connection-specific DNS Suffix . :
   IPv6 Address. . . . . . . . . .  : 2001:db8:acad:1:5075:d0ff:fe8e:9ad8
   Link-local IPv6 Address . . . .: fe80::5075:d0ff:fe8e:9ad8%13
   IPv4 Address . . . . . . . . . . : 10.1.10.10 
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway. . . . . . . . . : fe80::1
                                      10.1.10.1
C:\ >

12.5.9. Paso 5: Verificar la ruta correcta

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

Los routers de la ruta toman la decisión de enrutamiento en función de la información de las tablas de enrutamiento. Haga clic en cada botón para ver las tablas de enrutamiento IPv4 e IPv6 para R1.

R1# show ip route | begin Gateway
Gateway of last resort is 192.168.1.2 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:13, Serial0/1/0
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.10.0/24 is directly connected, GigabitEthernet0/0/0
L 10.1.10.1/32 is directly connected, GigabitEthernet0/0/0
      172.16.0.0/24 is subnetted, 1 subnets
O 172.16.1.0 [110/100] via 192.168.1.2, 00:01:59, Serial0/1/0
      192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.1.0/30 is directly connected, Serial0/1/0
L 192.168.1.1/32 is directly connected, Serial0/1/0
O 192.168.1.4/30 [110/99] via 192.168.1.2, 00:06:25, Serial0/1/0
R1#

R1# show ipv6 route
IPv6 Routing Table - default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
       NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       a - Application
OE2 ::/0 [110/1], tag 1
     via FE80::2, Serial0/1/0
C 2001:DB8:ACAD:1::/64 [0/0]
     via GigabitEthernet0/0/0, directly connected
L 2001:DB8:ACAD:1::1/128 [0/0]
     via GigabitEthernet0/0/0, receive
C 2001:DB8:ACAD:2::/64 [0/0]
     via Serial0/1/0, directly connected
L 2001:DB8:ACAD:2::1/128 [0/0]
     via Serial0/1/0, receive
O 2001:DB8:ACAD:3::/64 [110/99]
     via FE80: :2, Serial0/1/0
O 2001:DB8:ACAD:4::/64 [110/100]
     via FE80::2, Serial0/1/0
L FF00::/8 [0/0]
     via Null0, receive
R1#

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

• Redes conectadas directamente
• Host locales 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 enrutamiento intenta reenviar el paquete mediante una entrada en la tabla de enrutamiento 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.

La figura describe el proceso de las tablas de enrutamiento IPv4 e IPv6.

Examine los siguientes escenarios basados en el diagrama de flujo anterior. Si la dirección de destino en un paquete:

• No coincide con una entrada en la tabla de enrutamiento, 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 enrutamiento, 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 enrutamiento y las entradas de enrutamiento tienen la misma longitud de prefijo, los paquetes para este destino se pueden distribuir entre las rutas definidas en la tabla de enrutamiento.
• Coincide con más de una entrada en la tabla de enrutamientoy las entradas de enrutamiento 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 enrutamiento para la red 172.16.1.0/24. Si la tabla de enrutamiento no tiene una ruta específica a la red del SRV1, el administrador de red debe revisar la existencia de una entrada de red sumarizada o predeterminada en direccion de la red 172.16.1.0/24. Si no existe ninguna entrada, es posible que el problema esté relacionado con el enrutamiento y que el administrador deba verificar que la red esté incluida dentro de la configuración del protocolo de enrutamiento dinámico o que deba agregar una ruta estática

12.5.10. Paso 6: Verificar 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.

Ejemplo de resolución de problemas

Un administrador de red está solucionando un problema en el que no puede conectarse a un router mediante HTTP. El administrador hace ping R2 como se muestra en la salida del comando.

R1# ping 2001:db8:acad:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
R1#

R2 responde y confirma que la capa de red y todas las capas debajo de la capa de red están operativas. 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.

A continuación, el administrador verifica que pueden hacer Telnet a R2 como se muestra en el ejemplo

R1# telnet 2001:db8:acad:2::2
Trying 2001:DB8:ACAD:2::2 ... Open
User Access Verification
Password:
R2> exit
[Connection to 2001:db8:acad:2::2 closed by foreign host]
R1#

El administrador ha confirmado que los servicios Telnet se ejecutan en R2. 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. Usando un puerto diferente a TCP port 23 indica si la conexión es aceptada, rechazada o termina por falta de confirmación. 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.

Por ejemplo, el administrador intenta hacer Telnet a R2 usando el puerto 80.

R1# telnet 2001:db8:acad:2::2 80
Trying 2001:DB8:ACAD:2::2, 80 ... Open
^C
HTTP/1.1 400 Bad Request
Date: Mon, 04 Nov 2019 12:34:23 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request
[Connection to 2001:db8:acad:2::2 closed by foreign host]
R1#

Una vez más, en el resultado se verifica una conexión correcta de la capa de transporte, pero R2 rechaza la conexión mediante el puerto 80.

12.5.11. 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. Se puede visualizar una ACL específica al introducir el nombre o el número de la ACL, como una opción de este comando. Los comandos show ip interfaces y show ipv6 interfaces muestran la información de interfaz IPv4 e IPv6 que indica si 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 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.

Haga clic en cada botón para ver un ejemplo de cómo solucionar este problema.

R3# show ip access-lists
Extended IP access list 100
    10 deny ip 172.16.1.0 0.0.0.255 any (108 matches)
    20 permit ip any any (28 matches)
R3#

R3# show ip interface serial 0/1/1 | include access list
  Outgoing Common access list is not set
  Outgoing access list is not set
  Inbound Common access list is not set
  Inbound access list is not set
R3#
R3# show ip interface gig 0/0/0 | include access list
  Outgoing Common access list is not set
  Outgoing access list is not set
  Inbound Common access list is not set
  Inbound access list is 100
R3#

R3(config)# interface GigabitEthernet 0/0/0
R3(config-if)# no ip access-group 100 in
R3(config-if)# exit
R3(config)#
R3(config)# interface serial 0/1/1
R3(config-if)# ip access-group 100 in
R3(config-if)# end
R3#

12.5.12. 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. Utilice el comando ip host para introducir un nombre que se utilizará en lugar de la dirección IPv4 del switch o router, como se muestra en el ejemplo.

R1(config)# ip host ipv4-server 172.16.1.100
R1(config)# exit
R1#

Ahora se puede utilizar el nombre asignado en lugar de utilizar la dirección IP, como se muestra en el ejemplo.

R1# ping ipv4-server
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms
R1#

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

12.5.13. Packet Tracer – Resolución de problemas de redes empresariales

Esta actividad aplica una variedad de tecnologías que ha visto durante sus estudios de CCNA, incluido el enrutamiento, la seguridad de puertos, EtherChannel, DHCP, NAT, Su tarea consiste en revisar los requisitos, aislar y resolver cualquier problema, y después registrar los pasos que siguió para verificar los requisitos.

12.6. Práctica del Módulo y Cuestionario

12.6.1. Packet Tracer – Desafío de resolución de problemas – Documentación de la red

En esta actividad Packet Tracer, documentará una red desconocida para usted.

• Probará la conectividad de red.
• Compilará la información de direccionamiento del host.
• Accederá de forma remota a los dispositivos de puerta de enlace predeterminados.
• Documentará las configuraciones de dispositivos de puerta de enlace predeterminadas.
• Descubrirá dispositivos en la red.
• Dibujará la topología de la red.

12.6.2. Packet Tracer – Desafío de resolución de problemas – Uso de la documentación para resolver problemas

En esta actividad Packet Tracer, utilizará documentación de red para identificar y solucionar problemas de comunicaciones de red.

• Utilice diversas técnicas y herramientas para identificar problemas de conectividad.
• Utilice la documentación para guiar los esfuerzos de solución de problemas.
• Identificará problemas específicos de red.
• Implementará soluciones a problemas de comunicación de red.
• Verificará el funcionamiento.

12.6.3. Qué aprendí en este módulo?

Documentación de red

La documentación de red común incluye: topologías de red físicas y lógicas, documentación de dispositivos de red que registra toda la información pertinente del dispositivo y documentación de referencia del rendimiento de la red. La información que se encuentra en una topología física suele incluir el nombre del dispositivo, la ubicación del dispositivo (dirección, número de habitación, ubicación del rack, etc.), la interfaz y los puertos utilizados y el tipo de cable. La documentación del dispositivo de red para un router puede incluir la interfaz, la dirección IPv4, la dirección IPv6, la dirección MAC y el protocolo de enrutamiento. La documentación del dispositivo de red para un switch puede incluir el puerto, acceso, VLAN, troncal, EtherChannel, nativo y habilitado. La documentación de dispositivos de red para sistemas finales puede incluir nombre del dispositivo, SO, servicios, dirección MAC, direcciones IPv4 e IPv6, puerta de enlace predeterminada y DNS. Una línea de base inicial debería poder responder las siguiente preguntas:

• ¿Cómo funciona la red durante un día normal o promedio?
• ¿Dónde ocurre la mayoría de los errores?
• ¿Qué parte de la red se usa con más frecuencia?
• ¿Qué parte de la red se usa con menos frecuencia?
• ¿Qué dispositivos deben monitorearse? ¿Qué umbrales de alerta deben establecerse?
• ¿Puede la red cumplir con las políticas identificadas?

Al establecer la línea de base inicial, comience por seleccionar algunas variables que representen a las políticas definidas, como la utilización de las interfaces y el CPU. 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. La duración y la información que se recolecta, debe ser lo suficientemente larga para determinar que se considera «normal» en la red. Al documentar la red, con frecuencia es necesario recopilar información directamente de los routers y los switches. show, ping, traceroute, y los comandos telnet.

Proceso de resolución de problemas

El proceso de resolución de problemas debe guiarse por métodos estructurados. Un método es el proceso de resolución de problemas de siete pasos: 1. Defina el problema, 2. Recopile información, 3. Analice información, 4. Eliminar posibles causas, 5. Proponga una hipótesis, 6. Pruebe la hipótesis, and 7. Resuelva el problema Cuando hable con los usuarios finales sobre sus problemas de red, haga preguntas abiertas y cerradas. Utilice los comandos show,ping, traceroute, telnet para recopilar información de los dispositivos. Utilice los modelos en capas para la resolución de problemas ascendente, descendente o divide y vencerás. Otros modelos incluyen seguir la ruta, sustitución, comparación y deducciones informadas. Los problemas de software a menudo se resuelven utilizando un enfoque descendente, mientras que los problemas basados en hardware se resuelven utilizando el enfoque ascendente. Los nuevos problemas pueden ser resueltos por un técnico experimentado utilizando el método de divide y vencerás.

Herramientas para la resolución de problemas

Las herramientas comunes de solución de problemas de software incluyen herramientas NMS, bases de conocimiento y herramientas de base de linea. 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. Las herramientas para la solución de problemas de hardware incluyen NAM, multímetros digitales, comprobadores de cables, analizadores de cables y analizadores de red portátiles. El servidor Syslog también se puede utilizar como una herramienta de solución de problemas. 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 mensajes de evento se pueden enviar a una o varias de las siguientes opciones: consola, líneas de terminal, registro en búfer, capturas SNMP y syslog. Cuanto menor es el número del nivel, mayor es el nivel de gravedad. El comando logging trap level se usa para limitar los mensajes registrados en el servidor syslog según la gravedad. El nivel es el nombre o número de nivel de la severidad. Solo se registran los mensajes de número igual o menor que el nivel de especificado.

Síntomas y causas de problemas de red

Las fallas y las condiciones subóptimas en la capa física suelen provocar que las redes fallen. Los administradores de red deben tener la capacidad de aislar y corregir eficazmente los problemas en esta capa. Los síntomas incluyen un rendimiento inferior al previsto, pérdida de conectividad, congestión, alta utilización de CPU y mensajes de error de consola. Las causas suelen estar relacionadas con la alimentación, fallas de hardware, fallas de cableado, atenuación, ruido, errores de configuración de interfaz, excediendo los límites de diseño de componentes y sobrecarga de CPU.

Los problemas de capa 2 causan síntomas específicos que, al reconocerse, ayudan a identificar el problema rápidamente. Los síntomas incluyen la ausencia de funcionalidad/conectividad en la capa 2 o superior, la red que opera por debajo de los niveles de línea base, broadcast excesivos y los mensajes de consola. Las causas suelen ser errores de encapsulación, errores de asignación de direcciones, errores de trama y fallos o bucles STP.

Los problemas de la capa de red incluyen cualquier problema que comprenda a un protocolo de capa3, ya sea un protocolo de enrutado (como IPv4 o IPv6) o un protocolo de enrutamiento (como EIGRP, OSPF, entre otros). Los síntomas incluyen un fallo de red y un rendimiento inferior al óptimo. Las causas suelen ser problemas generales de red, problemas de conectividad, problemas de tabla de enrutamiento, problemas de vecinos y la base de datos de topología.

Los problemas de red pueden surgir a partir de problemas de la capa de transporte en el router, especialmente en el borde de la red, donde se examina y se modifica el tráfico. Los síntomas incluyen problemas de conectividad y acceso. Es probable que las causas sean NAT o ACL mal configuradas. Las configuraciones incorrectas de ACL suelen ocurrir en la selección del flujo de tráfico, el orden de las entradas de control de acceso, la denegación implícita, las direcciones y las máscaras wildcard IPv4, la selección del protocolo de capa de transporte, los puertos de origen y destino, el uso de la palabra clave establecida y los protocolos poco comunes. Hay varios problemas con NAT, incluyendo NAT mal configurado dentro, NAT fuera o ACL. Las áreas de interoperabilidad comunes con NAT incluyen BOOTP y DHCP, DNS, SNMP y protocolos de túnel y encripció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.

Solucionar problemas de conectividad IP

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.

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 comunes utilizadas para verificar un problema con la conectividad de extremo a extremo son ping y traceroute. El comando ping utiliza un protocolo de capa 3 que forma parte del conjunto TCP/IP denominado ICMP. El comando traceroute suele ejecutarse cuando falla el comando ping .

Paso 1. Verificar la capa física Los comandos de Cisco IOS más utilizados para este propósito son show processes cpu, show memory, y show interfaces.

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. Utilice el comando show interfaces interface para diagnosticar este problema.

Paso 3. Verifique el direccionamiento en la red local. Al resolver problemas de conectividad integral, es útil verificar las asignaciones entre las direcciones IP de destino y las direcciones Ethernet de la capa 2 en los segmentos individuales. 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. El comando netsh interface ipv6 show neighbor de Windows enumera todos los dispositivos que están actualmente en el caché de la tabla de detección de vecinos. El comando show ipv6 neighbors muestra un ejemplo de la tabla de detección de vecinos en el router Cisco IOS. Use el comando show mac address-table para visualizar la tabla de direcciones MAC en el switch.

Al resolver problemas de conectividad de extremo a extremo, otro problema que se debe considerar es la asignación de VLAN. Utilice el comando arp de Windows para ver la entrada de una puerta de enlace predeterminada. Utilice el comando show mac address-table para comprobar la tabla MAC switch. Esto puede mostrar que las asignaciones de VLAN no son correctas.

Paso 4. Verificar la puerta de enlace predeterminado. La salida del comando show ip route Cisco IOS se utiliza para verificar la puerta de enlace predeterminada de un router. En un host de Windows, el comando route print de Windows se utiliza para verificar la presencia de la puerta de enlace predeterminada IPv4.

En IPv6, el gateway predeterminado puede configurarse manualmente con la configuración automática independiente del estado (SLAAC) o con DHCPv6. El comando show ipv6 route Cisco IOS se utiliza para comprobar la ruta predeterminada IPv6 en un router. El comando ipconfig de Windows se utiliza para comprobar si un PC1 tiene una puerta de enlace predeterminada IPv6. El resultado del comando show ipv6 interface interface le indicará si un router está o no habilitado como router IPv6. Habilite un router como router IPv6 mediante el comando ipv6 unicast-routing . Para comprobar que un host tiene la puerta de enlace predeterminada establecida, utilice el comando ipconfig en el PC de Microsoft Windows o el comando netstat -r o ip route en Linux y Mac OS X.

Paso 5. Verificar la ruta correcta Los routers de la ruta toman la decisión de enrutamiento en función de la información de las tablas de enrutamiento. Utilice el comando show ip route | begin Gateway para una tabla de enrutamiento IPv4. Utilice el comando show ipv6 route para una tabla de enrutamiento IPv6.

Paso 6. Verificar la capa de transporte. 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.

Paso 7. Verificar las ACL 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. Compruebe qué interfaz tiene aplicada la ACL mediante el comando show ip interfaces .

Paso 8. Verifique el DNS. Para visualizar la información de configuración de DNS en el switch o el router, utilice el comando show running-config . Utilice el comando ip host para introducir un nombre que se utilizará en lugar de la dirección IPv4 del switch o router, como se muestra en el ejemplo.