Capítulo 9:
Resolució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.
En este capítulo, se describe la documentación de red que se debe mantener así como los procedimientos, los métodos y las herramientas generales de resolución de problemas.
También se analizan los síntomas y las causas típicos en distintas capas del modelo OSI. En este capítulo, también se incluye información sobre la resolución de problemas de rutas y ACL.
9.0.1.2 Actividad de clase: Falla de la red
Falla de la red
Acaba de mudarse a una nueva oficina, y la red es muy pequeña. Después de un largo fin de semana dedicado a configurar la nueva red, advierte que esta no funciona correctamente.
Algunos dispositivos no tienen acceso entre ellos y algunos no pueden acceder al router que se conecta al ISP.
Su responsabilidad consiste en llevar a cabo la resolución y la reparación de problemas. Para identificar las posibles áreas de resolución de problemas, decide comenzar con los comandos básicos.
Actividad de clase: Falla de la red
9.1.1.1 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
- Un nivel de rendimiento de línea de base
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 la documentación de red se debe conservar en una única ubicación, ya sea en forma impresa o en la red, en un servidor protegido. 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. En la figura 1, se muestran ejemplos de tablas de configuración de red para dos routers. En la figura 2, se 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)
- En caso de dispositivo modular, todos los tipos de módulos y en qué ranura de módulo se ubican
- 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
- Máscara de subred y longitud de prefijo
- Gateway predeterminado, servidor DNS y direcciones del servidor WINS
- Cualquier aplicación de red de ancho de banda elevado que se ejecute en el sistema final
9.1.1.2 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:
- Versión del sistema operativo
- Tipo de cable e identificador
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
- DLCI para circuitos virtuales
- 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.
9.1.1.3 Establecimiento de una línea de base de red
Nivel de rendimiento de línea de base
El propósito de la supervisión de la red es vigilar el rendimiento de la red en comparación con una 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. En la ilustración, se muestran varias preguntas que se responden mediante una 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.
9.1.1.4 Establecimiento de una línea de base de red (cont.)
Es importante planificar cuidadosamente la línea de base de rendimiento de la red inicial, ya que establece el marco para medir los efectos de los cambios de la red y los esfuerzos posteriores para resolver problemas.
Para planificar la primera línea de base, siga estos pasos:
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. En la figura 1, se muestran capturas de pantalla de los datos de uso de CPU, según los muestra el software de servicios de aplicaciones de área amplia (WAAS) de Cisco.
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
- 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 2, 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 3, 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.
Planificación de la primera línea de base
9.1.1.5 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 yshow 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 neighbor detail se usa para obtener información detallada sobre los dispositivos vecinos Cisco conectados directamente.
En la figura 1, se indican algunos de los comandos más comunes del IOS de Cisco que se usan para la recolecció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.
Con frecuencia, para establecer la línea de base de redes grandes y complejas se utiliza un software de administración de red sofisticado. Por ejemplo, como se muestra en la figura 2, el módulo SuperAgent de Fluke Network permite que los administradores creen y revisen informes automáticamente mediante la característica de líneas de base inteligentes. Esta característica compara los niveles de rendimiento actuales con observaciones históricas y puede identificar automáticamente los problemas de rendimiento y las aplicaciones que no proporcionan los niveles de servicio esperados.
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.
9.1.2.1 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. Recolección de síntomas: la resolución de problemas comienza con la recolección y el registro de los síntomas de la red, los sistemas finales y los usuarios. 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. Aislamiento del problema: el aislamiento es el proceso mediante el que se eliminan variables hasta que se identifica como la causa a un único problema o a un conjunto de problemas relacionados. 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 la medida correctiva: una vez que se identificó la causa del problema, el administrador de red trabaja para corregir el problema mediante la implementación, la puesta a prueba y el registro de posibles soluciones. 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. Por lo general, esto forma parte de los procedimientos de control de cambios de una red.
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.
Para cada etapa, se debe establecer una política de resolución de problemas que incluya procedimientos de control de 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.
Nota: comunique que el problema se resolvió a los usuarios y a cualquier persona involucrada en el proceso de resolución de problemas. 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.
9.1.2.2 Recolecció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.
Existen cinco pasos en la recolección de información:
Paso 1. Recolectar información: para formar una definición del problema, recolecte la información en las solicitudes de soporte y de los usuarios o los sistemas finales afectados por el problema.
Paso 2. Determinar a quién corresponde:si el problema está dentro del ámbito de control de la organización, continúe con 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. Reducir el ámbito: determine si el problema está en la capa de 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. Recolectar síntomas de los dispositivos sospechosos: mediante un método de resolución de problemas en capas, recolecte los síntomas del hardware y el 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. Registrar los síntomas: a veces, el problema se puede resolver sobre la base de los síntomas registrados. De lo contrario, inicie la etapa de aislamiento del proceso general de resolución de problemas.
Para recolectar síntomas de la red, use los comandos del IOS de Cisco y otras herramientas, por ejemplo:
- ping, traceroute y telnet(comandos)
- Registros de dispositivos
En la tabla de la ilustración, se describen los comandos comunes del IOS de Cisco usados para recolectar los síntomas de un problema de red.
Nota: si bien el comando debug es una herramienta importante para recolectar síntomas, genera una gran cantidad de tráfico de mensajes de la consola y puede afectar considerablemente el rendimiento de un dispositivo de red. Si la depuración con el
comando debug se debe realizar durante el horario de trabajo normal, advierta a los usuarios de la red que se está realizando un esfuerzo para resolver problemas y que el rendimiento de la red se puede ver afectado. Al terminar, recuerde deshabilitar la depuración.
9.1.2.3 Preguntas a usuarios finales
En muchos casos, un usuario final informa del problema. Con frecuencia, la información puede ser vaga o confusa, por ejemplo, “la red está inactiva” o “no puedo acceder a mi correo electrónico”. En estos casos, el problema se debe definir mejor. Esto puede requerir hacer preguntas a los usuarios finales.
Al preguntarles a los usuarios finales acerca del problema de red que tal vez experimenten, use técnicas de interrogación eficaces. Esto lo ayudará a obtener la información necesaria para registrar los síntomas de un problema. En la tabla de la ilustración, se proporcionan algunas pautas y ejemplos de preguntas para los usuarios finales.
9.1.3.1 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 de colocar los mensajes en un formato fijo para que los dispositivos los administren.
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.
9.1.3.2 Métodos de resolución de problemas
Mediante los modelos en capas, existen tres métodos principales para resolver problemas de red:
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 del modelo OSI no funciona correctamente, el administrador puede trabajar en el modelo de capas OSI de manera descendente.
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.
9.1.3.3 Métodos de resolución de problemas (cont.)
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:
- 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.
9.1.3.4 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 comience a probar las funciones asociadas con TCP/IP en la capa superior siguiente del modelo OSI, es decir, la capa de red.
9.2.1.1 Herramientas para la solució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. En la figura 1, se muestra un ejemplo del software NMS “WhatsUp Gold”. Estas herramientas se pueden usar para investigar y corregir los problemas de red. El software de supervisión de red muestra de manera gráfica una vista física de los dispositivos de red, lo que permite a los administradores supervisar los dispositivos remotos sin revisarlos físicamente. El software de administración de dispositivos proporciona datos dinámicos sobre el estado, las estadísticas y la información de configuración de productos conmutados. Algunas otras herramientas de administración de red que se usan frecuentemente son CiscoView, HPBTO Software (antes OpenView) y SolarWinds.
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.
En la figura 2, se muestra la página Tools & Resources (Herramientas y recursos) de Cisco, que se encuentra enhttp://www.cisco.com. Esta es una herramienta gratuita que proporciona información sobre el hardware y el software relacionados 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. Estas herramientas están disponibles para los sistemas operativos Windows, Linux y AUX. En la figura 3, se muestra una captura de pantalla de los softwares SolarWinds LANsurveyor y CyberGauge. 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.
9.2.1.2 Herramientas para la solución de problemas de software (cont.)
Analizadores de protocolos basados en host
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 nivel de conocimiento sobre cómo usar el analizador de protocolos y TCP/IP. Para adquirir más conocimientos y habilidades relacionados con el uso de Wireshark, un excelente recurso eshttp://www.wiresharkbook.com.
Captura de paquetes integrada del IOS de Cisco
La captura de paquetes integrada (EPC) del IOS de Cisco constituye una potente herramienta de rastreo y resolución de problemas. Esta característica permite que los administradores de red capturen los paquetes IPv4 e IPv6 que circulan hacia y desde un router Cisco, así como a través de él. La característica EPC del IOS de Cisco se usa principalmente en situaciones de
resolución de problemas en las que es útil ver los datos que se envían desde o hacia el dispositivo de red, o a través de él.
Por ejemplo, el personal de soporte técnico necesita establecer por qué un dispositivo determinado no puede acceder a la red o a alguna aplicación. Para detectar el problema, es probable que sea necesario realizar capturas de los paquetes de datos IP y examinarlos. Otro ejemplo consistiría en determinar la firma del atacante en una amenaza de red o una infracción de seguridad del sistema de servidores. EPC del IOS de Cisco puede ayudar a capturar los paquetes que circulan hacia la red en el origen o en el perímetro.
EPC del IOS de Cisco es útil siempre que se puede usar un analizador de protocolos de red para depurar un problema pero no resulta práctico instalar un dispositivo tal.
Para obtener más información sobre el uso y la configuración de EPC de Cisco, consulte la Guía de configuración de la captura de paquetes integrada.
9.2.1.3 Herramientas para la solución de problemas de hardware
Algunas herramientas para la solución de problemas de hardware incluyen las siguientes:
- Módulo de análisis de redes: como se muestra en la figura 1, se puede instalar un módulo de análisis de redes (NAM) en los switches Cisco Catalyst de la serie 6500 y los routers Cisco de la serie 7600. Los NAM proporcionan una representación gráfica del tráfico desde los switches y routers locales y remotos. El NAM es una interfaz integrada basada en el explorador que genera informes sobre el tráfico que consume los recursos de red fundamentales. Además, el NAM puede capturar y decodificar paquetes y rastrear los tiempos de respuesta para localizar un problema de aplicación en la red o el servidor.
- Multímetros digitales: los multímetros digitales (DMM), por ejemplo, el Fluke 179 que se muestra en la figura 2, son instrumentos de prueba que se usan para medir directamente los valores eléctricos de voltaje, corriente y resistencia. En la resolución de problemas de red, la mayoría de las pruebas multimedia implican revisar los niveles de voltaje de la fuente de alimentación y verificar que los dispositivos de red reciban energía.
- Comprobadores de cables: son dispositivos de mano especializados que están diseñados para probar los diversos tipos de cables de comunicación de datos. En la figura 3, se muestran dos comprobadores de cables Fluke diferentes. Los comprobadores de cables se pueden usar para detectar hilos dañados, hilos cruzados, conexiones en cortocircuito y pares de conexiones incorrectos. 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 analizador de cable Fluke DTX que se muestra en la figura 4, son dispositivos de mano con varias funciones que se usan para probar y para certificar los cables de cobre y fibra para los diferentes servicios y estándares. Las herramientas más sofisticadas incluyen un diagnóstico avanzado de resolución de problemas que mide la distancia al defecto de rendimiento (NEXT, RL), identifica las acciones correctivas y muestra gráficamente el comportamiento de crosstalk e impedancia. Los analizadores de cables también suelen incluir software basado en computadora. Después de que se recolectan los datos de campo, el dispositivo de mano puede subir los datos para crear informes actualizados.
- Analizadores de red portátiles: los dispositivos portátiles, como Fluke OptiView en la figura 5, se usan para resolver 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.
9.2.1.4 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 se pueden ver al modificar o probar el router o el switch mediante el software de emulación de terminal, mientras se esté conectado al puerto de consola del router.
- 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. De manera similar al registro de la consola, el router no almacena este tipo de registro y, por lo tanto, solo es valioso para el usuario en esa línea.
- Registro almacenado en búfer: este registro es un poco más útil como herramienta de resolución de problemas porque los mensajes de registro se almacenan en la memoria durante cierto 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. El router puede procesar los eventos de router, como superar un umbral, y reenviarlos como traps de SNMP a un servidor SNMP externo. 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 comandologging trap level limita los mensajes registrados en el servidor de syslog según la gravedad. El nivel es el nombre o el número del level de gravedad. Solo se registran los mensajes iguales o numéricamente inferiores al levelespecificado.
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.
9.2.2.1 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 la consola: los mensajes de error que se muestran en la consola de un dispositivo indican un problema de 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, busque cables dañados, tipos de cables inadecuados y RJ-45 con engarces deficientes. 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 entre sí los bits que componen el flujo correctamente.
- 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.
- Límites de diseño excedidos: un componente puede operar de manera deficiente en la capa física porque se usa a una tasa promedio superior a la que está configurado para funcionar. 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 porcentajes elevados de uso de CPU, descartes de la cola de entrada, rendimiento lento, lentitud o falta de respuesta de los servicios de router como Telnet y ping o falta de actualizaciones de routing. Una de las causas de sobrecarga de CPU en un router es un volumen de tráfico elevado. Si algunas interfaces están regularmente sobrecargadas con tráfico, considere rediseñar el flujo de tráfico en la red o actualizar el hardware.
9.2.2.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 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, Frame Relay o Ethernet de difusión, es fundamental darle a la trama una dirección de destino de capa 2 correcta. 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 debido a que los dispositivos pueden estar configurados de manera específica para no responder a las solicitudes de ARP o de ARP inverso, a que la información de capa 2 y capa 3 almacenada en caché puede haber cambiado físicamente o a que se reciben respuestas de ARP no válidas debido a una configuración incorrecta o un ataque de 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 entramado pueden ser el resultado de una línea serial ruidosa, un cable diseñado de manera incorrecta (demasiado largo o blindado en forma inadecuada) o un reloj de línea de unidad de servicio de canal (CSU) configurado de manera incorrecta.
- 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.
9.2.2.3 Resolución de problemas de la 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 generalmente se debe a que estos problemas abarcan varias capas o, incluso, al equipo 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.
- 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.
- Tabla de routing: revise la tabla de routing para ver si existe algo inesperado, como rutas faltantes o imprevistas. Use los comandos debugpara ver las actualizaciones de routing y el mantenimiento de la tabla de routing.
9.2.2.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 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 del flujo de tráfico: la configuración incorrecta del router más frecuente es aplicar la ACL al tráfico incorrecto. El tráfico se define por la interfaz del router a través de la que viaja y el sentido en el que viaja. 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 rechazó. 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.
- Instrucción implícita de denegar todo el tráfico: cuando no se requiere un nivel de seguridad elevado en la ACL, este elemento implícito de control de acceso puede ser la causa de una configuración incorrecta de la 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 que se proporciona mediante 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.
9.2.2.5 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 y WINS: debido a que un router que ejecuta una NAT dinámica cambia la relación entre las direcciones internas y externas periódicamente, a medida que las entradas de la tabla se vencen y se vuelven a crear, un servidor DNS o WINS 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.
Nota: el router puede reenviar DHCPv6 de un cliente IPv6 mediante el comando ipv6 dhcp relay.
9.2.2.6 Resolución de problemas de la 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.
9.2.3.1 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.
9.2.3.2 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
sonping 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 comandoping, se puede usar el comandotraceroute 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 ytraceroute en el router R1 que se usa para probar la conectividad IPv6.
9.2.3.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 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. La observación sistemática de descartes de salida puede indicar que es necesario implementar un mecanismo de cola avanzado para proporcionar una buena QoS para cada aplicación.
- 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.
9.2.3.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. En la figura 1, se indican las pautas para la configuración de 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. Sin embargo, si esto no funciona, es preferible ejecutar half-duplex en ambos extremos a experimentar una incompatibilidad de dúplex.
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 2.
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 3. Ahora, el administrador de red examina el otro lado de la conexión: el puerto en el S2. En la figura 4, 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.
9.2.3.5 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
Un switch reenvía una trama solamente al puerto donde se conecta el destino. 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. En la figura 4, se muestra un ejemplo del switch local de la 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 un host en una VLAN envía una trama de Ethernet de difusión, como una solicitud de ARP, todos los hosts en la misma VLAN reciben la trama, mientras que los hosts en otras VLAN no la reciben. 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.
9.2.3.6 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 direccionamiento IPv4 se obtuvo automáticamente de un servidor de DHCPv4, se debe examinar la configuración en el servidor de DHCP. Por lo general, un problema de configuración en un servidor de DHCP puede ser detectado por varios clientes.
Ejemplo de resolución de problemas 2
En IPv6, el gateway predeterminado se puede configurar manualmente o mediante la configuración automática sin estado (SLAAC) o 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, el comando show ipv6 route del IOS de Cisco muestra la ruta predeterminada IPv6 en el R1, y el comando ipconfig de Windows se usa para verificar la presencia del 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 envía mensajes RA ICMPv6 por 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/0revela que el R1 forma parte de FF02::2, el grupo de multidifusión de todos los routers IPv6.
Para verificar que la PC1 tenga establecido el gateway predeterminado, use el comando ipconfig en una computadora con Microsoft Windows o el comando ifconfig en los sistemas operativos 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 establece en la dirección link-local del router R1, FE80::1
9.2.3.7 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
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 comandoshow 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.
9.2.3.8 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.
Si bien la aplicación del servidor telnet se ejecuta en su propio número de puerto bien conocido 23, y los clientes Telnet se conectan 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 se deba probar. Esto indica si la conexión se acepta (como se indica mediante la palabra “Open” [Abierta] en el resultado), se rechaza 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.
9.2.3.9 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 comandoshow ip access-lists muestra que la ACL está configurada correctamente. Sin embargo, el comando show ip interfaces serial 0/0/1 revela que la ACL nunca se aplicó a la interfaz de entrada s0/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.
Después de colocar de manera correcta la ACL de IPv4 en la interfaz de entrada s0/0/1, como se muestra en la figura 3, los dispositivos se pueden conectar correctamente al servidor.
9.2.3.10 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 otelnet.
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 hostpara 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
El resultado de la figura 2 indica que el cliente no pudo llegar al servidor DNS o que el servicio DNS en 10.1.1.1 no funcionaba. 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 comandonslookup. 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.
9.3.1.1 Actividad de clase: Elaboración del registro
Elaboración del registro
Como administrador de red de una pequeña empresa, desea implementar un sistema de registro para usar en la resolución de problemas de red.
Después de pensar mucho, decide recopilar información simple de documentación de red en un archivo que se utilizará cuando surjan problemas de red. También sabe que si la empresa crece en el futuro, se puede usar este archivo para exportar la información a un sistema de software de red computarizado.
Para comenzar el proceso de documentación de red, incluye lo siguiente:
- Un diagrama físico de la red de su pequeña empresa.
- Un diagrama lógico de la red de su pequeña empresa.
- Información de configuración de red para los dispositivos importantes, incluidos routers y switches.
Actividad de clase: Elaboración del registro
9.3.1.2 Resumen
Para que los administradores de red puedan monitorear y resolver problemas en una red, deben tener un conjunto completo de documentación de red precisa y actual que incluya los archivos de configuración, diagramas de topología física y lógica y un nivel de rendimiento de línea de base.
Las tres etapas principales en la resolución de problemas son la recolección de síntomas, el aislamiento del problema y la corrección del problema. A veces, es necesario implementar temporalmente una solución alternativa al problema. Si la medida correctiva deseada no soluciona el problema, se debe eliminar el cambio. El administrador de red debe registrar todos los pasos del proceso. Para cada etapa, se debe establecer una política de resolución de problemas que incluya procedimientos de control de cambios. Una vez que se resuelve el problema, es importante comunicárselo a los usuarios, a cualquier persona que participe en el proceso de resolución de problemas y a los otros miembros del equipo de TI.
El modelo OSI o el modelo TCP/IP se puede aplicar a un problema de red. Los administradores de red pueden usar el método ascendente, el método descendente o el método divide y vencerás. Otros métodos menos estructurados incluyen prueba y error, detección de las diferencias y sustitución.
Las herramientas de software comunes que pueden ayudar con la resolución de problemas incluyen herramientas de administración de red del sistema, bases de conocimientos, herramientas de línea de base, analizadores de protocolo basados en host y EPC del IOS de Cisco. 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. La información de registro del IOS de Cisco también se puede usar para identificar problemas potenciales.
Existen síntomas y problemas característicos de la capa física, la capa de enlace de datos, la capa de red, la capa de transporte y la capa de aplicación que el administrador de red debe reconocer. Es posible que el administrador necesite prestar especial atención a la conectividad física, los gateways predeterminados, las tablas de direcciones MAC, la NAT y la información de routing.
|
![Cuadro de texto: Realice los pasos de la resolución de problemas según lo indicado. El router R1 debe configurarse con los siguientes parámetros: • S0/0/0 es la interfaz DCE. • Frecuencia de reloj establecida en 64000. • Encapsulación HDLC Introduzca el comando show para verificar el tipo de cable conectado a S0/0/0. R1# show controllers s0/0/0 Interface Serial0/0/0 Hardware is PowerQUICC MPC860 DCE V.35, clock rate 64000 idb at 0x81081AC4, driver data structure at 0x81084AC0 SCC Registers: General [GSMR]=0x2:0x00000000, Protocol-specific [PSMR]=0x8 Events [SCCE]=0x0000, Mask [SCCM]=0x0000, Status [SCCS]=0x00 Transmit on Demand [TODR]=0x0, Data Sync [DSR]=0x7E7E < Resultado omitido > Introduzca el comando show para verificar la configuración de la encapsulación para S0/0/0. R1# show interfaces s0/0/0 Serial0/0/0 is up, line protocol is down (disabled) Hardware es HD64570 Internet address is 172.16.0.1/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) LCP Closed Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP Last input never, output never, output hang never Last clearing of 'show interface' counters never < Resultado omitido > Configure la interfaz S0/0/0 para que utilice la encapsulación predeterminada. R1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)# interface s0/0/0 R1(config-if)# encapsulation hdlc %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed state to up Introduzca el comando “do show” para verificar la configuración de la encapsulación para S0/0/0. R1(config-if)# do show interfaces s0/0/0 Serial0/0/0 is up, line protocol is up (connected) Hardware es HD64570 Internet address is 172.16.0.1/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input never, output never, output hang never Last clearing of 'show interface' counters never < Resultado omitido > Realizó correctamente los pasos de la resolución de problemas para la interfaz serial.](mod3_ccna4/index_clip_image002_0000.png)
