Tema 12

TEMA 12.
- RESOLUCION DE PROBLEMAS DE RED
Bienvenido a la Resolución de problemas de red!
¿Quién es el mejor administrador de red que haya visto? ¿Por qué crees que esta
persona es tan buena en eso? Probablemente, es porque esta persona es
realmente buena para resolver problemas de red. Probablemente sean
administradores experimentados, pero esa no es toda la historia. Los buenos
solucionadores de problemas de red generalmente lo hacen de manera metódica,
y utilizan todas las herramientas disponibles para ellos.
La verdad es que la única manera de convertirse en un buen solucionador de

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

Título del módulo: Resolución de problemas de red
Objetivos del módulo: Resuelva problemas de redes empresariales.
Título del tema Objetivo del tema

Explique la forma en que se elabora y se utiliza la
Documentación de red documentación de red para resolver problemas de
red.
Proceso de resolución de Compare los métodos de resolución de problemas
problemas que usan un enfoque sistemático, en capas.
Herramientas para la resolución Describa las diferentes herramientas para la
de problemas resolución de problemas de redes.
Síntomas y causas de los Determine los síntomas y las causas de los
problemas de red problemas de red mediante un modelo en capas.
Resolución de problemas de Solucione problemas de una red mediante un
conectividad IP modelo en capas.
Documentación de red
12.1.1
Descripción general de la
documentación
Al igual que con cualquier actividad compleja, como la resolución de problemas de red,
se debe comenzar con una buena documentación. Se requiere documentación de red
precisa y completa para supervisar y solucionar problemas de redes de manera eficaz.
La documentación de red común incluye lo siguiente:
 Diagramas lógicos y físicos de topología de la red

 Documentación de dispositivos de red que registra toda la información pertinente del
dispositivo
 Documentación de referencia del rendimiento de la red
Toda la documentación de red debe guardarse en una misma ubicación, ya sea como
copia local o en un servidor protegido de la red. Debe realizarse una copia de seguridad
del registro, la que se debe conservar en una ubicación diferente.
12.1.2
Diagramas de topología de la red

Los diagramas de topología de la red mantienen un registro de la ubicación, la
función y el estado de los dispositivos en la red. Hay dos tipos de diagramas de
topología de la red: la topología física y la topología lógica.
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 la topología física suele incluir lo siguiente:
 Nombre del dispositivo

 Ubicación del dispositivo (dirección, número de habitación, ubicación del rack)
 Interfaces y puertos usados
 Tipo de cable
En la figura 1, se muestra un ejemplo de un diagrama de topología física de la red.

Topología lógica IPv4
Los diagramas de red de topología lógica muestran la conexión lógica de los

dispositivos a la red. Esto se refiere a cómo los dispositivos transfieren datos a
través de la red cuando se comunican con otros dispositivos. Los símbolos se usan
para representar los elementos de la red, como routers, switches, servidores,
hosts. 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
 Protocolos de enrutamiento / rutas estáticas
 Información de Capa 2 (VLAN, enlaces troncales, EtherChannels)
En la figura 2, se muestra un ejemplo de topología lógica de red IPv4.

Topología lógica IPv6
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.
La figura muestra un ejemplo de topología lógica IPv6
Documentación de dispositivos de red

La documentación de red debería contener registros precisos y actualizados del
hardware y el software usados en una red. La documentación debe incluir toda la
información pertinente sobre los dispositivos de red.
Muchas organizaciones crean documentos con tablas u hojas de cálculo para capturar
información relevante del dispositivo
Documentación del router
La tabla muestra un ejemplo de la documentación de dos routers interconectados
Documentación del Switch LAN
Esta tabla muestra un ejemplo de la documentación de un Switch LAN.

Registro de dispositivos finales
Los archivos de configuración del sistema finales se centran en el hardware y el

software usados en los dispositivos, 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 esta razón, tener acceso a la documentación del dispositivo del sistema
final puede ser muy útil a la hora de solucionar problemas.
En esta tabla se muestra un ejemplo de información que podría grabarse en un

documento de dispositivo del sistema final.
Establecer una línea de base

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

datos sobre el rendimiento de los puertos y los dispositivos que son esenciales
para el funcionamiento de la red.
Una línea de base debería responder las siguientes preguntas:
 ¿Cómo funciona la red durante un día normal o promedio?

 ¿Dónde ocurre la mayoría de los errores?
 ¿Qué parte de la red se usa con más frecuencia?
 ¿Qué parte de la red se usa con menos frecuencia?
 ¿Qué dispositivos deben monitorearse? ¿Qué umbrales de alerta deben
establecerse?
 ¿Puede la red cumplir con las políticas identificadas?
Medir el rendimiento y la disponibilidad inicial, de los dispositivos de red críticos,

permite a los administradores determinar la diferencia entre un rendimiento normal
y uno anormal, ya sea cuando la red crece, o el flujo de tráfico cambia. Una línea
de base también proporciona información sobre si el diseño actual de la red puede
satisfacer los requisitos comerciales. Sin una línea de base, no existe ningún
estándar para medir la naturaleza óptima de los niveles de tráfico y congestión de
la red.
Un análisis después de establecer una línea de base inicial también tiende a

revelar problemas ocultos. Los datos reunidos muestran la verdadera naturaleza
de la congestión, o la congestión potencial, en una red. También puede revelar las
áreas de la red que están sub-utilizando y, con bastante frecuencia, puede originar
esfuerzos para rediseñar la red sobre la base de las observaciones de calidad y
capacidad.
La línea de base inicial de rendimiento de la red prepara el terreno para medir los
efectos de los cambios en la red y de las tareas de solución de problemas
posteriores. Por lo tanto, es importante planificarla cuidadosamente.
12.1.5
Paso 1 - Determinar el tipo de

informacion a recopilar
Al establecer la línea de base inicial, comience por seleccionar algunas variables
que representen a las políticas definidas. Si se seleccionan demasiados datos, la
cantidad de datos puede ser abrumadora, lo que dificulta el análisis. Comience de
manera simple y realice ajustes a lo largo del proceso. Algunos puntos de inicio a
considerar son la utilización de CPU e interfaces.
12.1.6
Paso 2 - Identifique los dispositvos y
puertos de interés
Use la topología de la red para identificar aquellos dispositivos y puertos para los
que se deben medir los datos de rendimiento. Dispositivos y puertos de interés
incluyen los siguientes:
 Puertos de dispositivos de red que se conectan a otros dispositivos de red

 Servidores
 Usuarios principales
 Cualquier otro elemento que se considere fundamental para las operaciones
Una topología de red logica puede ser útil para identificar los dispositivos y puertos
que se deben monitorear. En la figura, el administrador de red ha sobresaltado los
dispositivos y puertos de interés basado en la linea de base.
Los dispositivos de interés incluyen la PC1 (la terminal de administración) y los dos
servidores (Svr1 y Svr2)el servidor web/TFTP). Los puertos de interés suelen
incluir interfaces de router y puertos clave en switches.
Al reducir la lista de puertos que se sondean, los resultados son concisos, y se

minimiza la carga de administración de la red. Recuerde que una interfaz en un
router o un switch puede ser una interfaz virtual, como una interfaz virtual de switch
(SVI).
Paso 3: Determine la duración de la
línea de base
La duración y la información que se recolecta, debe ser lo suficientemente larga
para determinar que se considera "normal" en la red. Es importante que se
monitoreen las tendencias diarias del tráfico de la red. También es importante
monitorear las tendencias que se producen durante un período más largo, como
semanas o meses. Por este motivo, al capturar datos para su análisis, el período
especificado debe tener, como mínimo, una duración de siete días.
En la figura, se muestran ejemplos de varias capturas de pantalla de las

tendencias del uso de CPU obtenidas durante un día, una semana, un mes o un
año.
En este ejemplo, observe que las tendencias de la semana de trabajo son

demasiado cortas para revelar el pico de uso recurrente que se produce el
sábado por la noche, cada fin de semana, cuando una operación de copia de
seguridad de la base de datos consume ancho de banda de la red. Este patrón
recurrente se revela en la tendencia mensual. Una tendencia anual, como la
que se muestra en el ejemplo, puede ser demasiado prolongada para
proporcionar detalles significativos sobre el rendimiento de línea de base. Sin
embargo, puede ayudar a identificar patrones a largo plazo que se deben
analizar en profundidad.
Generalmente, las líneas de base no se deben extender durante más de seis

semanas, salvo que se deban medir tendencias específicas a largo plazo. Por
lo general, una línea de base de dos a cuatro semanas es adecuada.
Las mediciones de una línea de base no se deben realizar durante momentos

de patrones de tráfico únicos, dado que los datos proporcionarían una
representación imprecisa de las operaciones normales de la red. Realice un
análisis anual de toda la red o bien analice la línea de base de diferentes
secciones de la red, de manera rotativa. Para entender la forma en que el
crecimiento y otros cambios afectan la red, el análisis se debe realizar
periódicamente.
12.1.8
Medición de datos
Al documentar la red, con frecuencia es necesario reunir información
directamente de los routers y los switches. Los comandos obvios y útiles para
la documentación de red incluyen ping, traceroute, y telnet, así como los
siguientes comandos show.
La tabla detalla algunos de los comandos más comunes de Cisco IOS para la
recopilación de datos.
Comando Descripción
Muestra el tiempo de actividad, información sobre la versión del
show version
software y del hardware del dispositivo.
Muestra todas las opciones de configuración establecidas en una
show ip interface [brief] interfaz.
show ipv6 interface [brief] Utilice brief para mostrar la dirección IP y el estado de cada interfaz.
Muestra la salida detallada de cada interfaz.

Para mostrar una salida detallada para una única interfaz, incluya el tipo
show interfaces y el número de interfaz en el comando (por ejemplo, Gigabit Ethernet
0/0/0).
Muestra el de contenido de la tabla de enrutamiento de redes

show ip route directamente conectadas y redes remotas aprendidas.
show ipv6 route Agregar static, eigrp o ospf para mostrar sólo esas rutas.
show cdp neighbors Muestre información detallada acerca del dispositivo Cisco conectado
detail directamente.
show arp
Muestra el contenido de la tabla ARP (IPv4) y la tabla de vecinos (IPv6).
show ipv6 neighbors
show running-config Muestre la configuración actual.
show vlan Muestra el estado de las VLAN en un switch.
show port Muestra el estado de los puertos en un switch.
Este comando es útil para recopilar una gran cantidad de información
sobre el dispositivo para solucionar problemas.
show tech-support Ejecuta múltiples comandos show que se pueden proporcionar a
representantes de soporte técnico cuando se reporta un problema
La recolección manual de datos mediante los show comandos en dispositivos

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

los valores de referencia de las redes grandes y complejas. Estos programas
permiten que los administradores creen y revisen automáticamente los
informes, comparen los niveles de rendimiento actuales con las observaciones
históricas, identifiquen automáticamente los problemas de rendimiento y creen
alertas para las aplicaciones que no proporcionan los niveles esperados de
servicio.
Establecer una línea de base inicial o realizar un análisis de monitoreo del

rendimiento puede requerir muchas horas o muchos días para reflejar el
rendimiento de la red con precisión. Con frecuencia, el software de
administración de red o los inspectores y analizadores de protocolos se
ejecutan continuamente a lo largo del proceso de recolección de datos.
PROCESO DE RESOLUCION DE PROBLEMAS
Procedimientos generales de resolución

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

estructurados. Esto requiere procedimientos de resolución de problemas bien
definidos y documentados, para minimizar el tiempo perdido asociado con la
resolución de problemas erráticos. Sin embargo, estos métodos no son estáticos.
Los pasos de resolución de problemas realizados para resolver un problema no
siempre son los mismos o se ejecutan en el mismo orden.
Existen varios procesos de resolución de problemas que se pueden usar para

resolver un problema. La figura muestra el diagrama de flujo lógico de un proceso
simplificado de resolución de problemas de tres etapas. Sin embargo, un proceso
más detallado puede ser más útil para resolver un problema de red.
Proceso de Siete Pasos para la

Resolución de Problemas
La figura muestra un proceso de solución de problemas de siete pasos más
detallado. Observe cómo se interconectan algunos pasos. Esto se debe a que
algunos técnicos pueden saltar entre pasos en función de su nivel de experiencia.
Definir el problema
El objetivo de esta etapa es verificar que existe un problema y luego definir
correctamente cuál es el problema. Los problemas generalmente se identifican por
un síntoma (por ejemplo, la red es lenta o ha dejado de funcionar). 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?
En una organización, los problemas suelen asignarse a los técnicos de red

mediante tickets de problemas. Estos tickets se crean utilizando software de tickets
de problemas que permiten realizar un seguimiento del progreso de cada ticket. El
software de creación de tickets de problemas también puede incluir un portal de
usuario de autoservicio para enviar tickets, acceso a una base de conocimientos
de tickets de problemas, los cuales se pueda buscar, brinda capacidades de
control remoto para resolver problemas de los usuarios finales, y mucho más.
Recopilar información
En este paso, se deben identificar los dispositivos que se van a investigar, se debe
obtener acceso a los dispositivos y se debe recopilar información. En esta etapa, el
administrador de red puede recopilar y registrar más síntomas, según las
características que se identifiquen.
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.
Analizar la información
Las posibles causas deben ser identificadas. La información recopilada se

interpreta y analiza utilizando documentación de red, líneas de base de red,
búsquedas en bases de conocimiento organizacionales, búsquedas en Internet y
conversaciones con otros técnicos
Eliminar posibles causas
Si se identifican múltiples causas, entonces la lista debe reducirse eliminando

progresivamente las causas posibles, para finalmente identificar la causa más
probable La experiencia es extremadamente valiosa para eliminar rápidamente las
causas e identificar la causa más probable
Proponer hipótesis
Cuando se ha identificado la causa más probable, se debe formular una solución.

En esta etapa, la experiencia de solución de problemas es muy valiosa a la hora
de proponer un plan.
Probar la hipótesis
Antes de probar la solución, es importante evaluar el impacto y la urgencia del

problema. Por ejemplo, ¿podría la solución tener un efecto adverso en otros
sistemas o procesos? La gravedad del problema se debe contrastar 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.
Cree un plan de respaldo que identifique cómo invertir rápidamente una solución.
Esto puede resultar necesario si la solución falla.
Implementar la solución y verificar que haya resuelto el problema. A veces, una

solución introduce un problema inesperado. Por lo tanto, es importante que una
solución se verifique a fondo antes de pasar al siguiente paso.
Si la solución falla, se documenta la solución intentada y se eliminan los cambios.

Ahora, el técnico debe volver al paso de "recopilar información y eliminar posibles
causas"
Resolver el problema
Comunique a los usuarios y a todos los involucrados en el proceso de resolución

que el problema ya está resuelto. La solución se debe informar a los otros
miembros del equipo de TI. La documentación adecuada acerca de la causa y la
solución ayudan a otros técnicos de soporte a prevenir y resolver problemas
similares en el futuro.
Hacer preguntas a usuarios finales.

Muchos problemas de red son notificados inicialmente por un usuario final. Sin
embargo, la información facilitada suele ser vaga o engañosa. Por ejemplo, los
usuarios suelen informar de problemas como "la red no funciona", "No puedo
acceder a mi correo electrónico" o "mi equipo esta lento".
En la mayoría de los casos, se requiere información adicional para comprender

completamente un problema. Esto generalmente implica interactuar con el usuario
afectado para descubrir el "quién", "qué" y "cuándo" del problema.
Las siguientes recomendaciones deben emplearse al comunicarse con el usuario:
 Hablar a un nivel técnico que puedan entender y evitar el uso de terminología

compleja.
 Siempre escuche o lea atentamente lo que el usuario está diciendo. Tomar notas
puede ser útil a la hora de documentar un problema complejo.
 Sea siempre considerado y empatice con los usuarios mientras les hace saber que
les ayudará a resolver su problema. Los usuarios que informan de un problema
pueden estar sometidos a estrés y ansiosos por resolver el problema lo antes
posible.
Al entrevistar al usuario, guíe la conversación y use técnicas de cuestionamiento

efectivas para determinar rápidamente el problema. Por ejemplo, use preguntas
abiertas (es decir, requiere una respuesta detallada) y preguntas cerradas (es
decir, sí, no, o respuestas de una sola palabra) para descubrir hechos importantes
sobre el problema de la red.
La tabla proporciona algunas directrices/pautas y ejemplos de preguntas para los

usuarios finales.
Cuando termine de entrevistar al usuario, repítale lo que usted ha entendido, para

asegurarse de que ambos están de acuerdo en el problema que se informa.
Directrices Preguntas de ejemplo para los usuarios finales

¿Qué no esta funcionando?
Hacerpreguntas pertinentes. ¿Cuál es exactamente el problema?
¿Qué intenta lograr?
Determinar el alcance del ¿A quién afecta este problema? ¿Solo a usted u otros también?
problema. ¿En qué dispositivo está pasando esto?
Determine cuándo y con qué ¿Cuándo se produjo exactamente el problema?
frecuencia ocurre u ocurrió el ¿Cuándo notó el problema por primera vez?
problema. ¿Se han mostrado mensajes de error?
¿Puede reproducir el problema?
Determine si el problema es
¿Puedes enviarme una captura de pantalla o un video del
constante o intermitente.
problema?
Determine si algo ha cambiado. ¿Qué se ha modificado desde la última vez que funcionó?
Utilizar cada pregunta como un
¿Que está funcionando?
medio para eliminar o descubrir
¿Qué no está funcionando?
posibles problemas.
12.2.4
Recopilar información
Para recopilar los síntomas de un dispositivo de red sospechoso, use los
comandos de Cisco IOS y otras herramientas como capturas de paquetes y
registros de los dispositivos.
La tabla describe los comandos de Cisco IOS más comunes que se usan para
recopilar los síntomas de un problema de red.
Envía un paquete de solicitud de eco a una dirección y
ping {host | ip-address}
espera una respuesta.
La variable host o ip-address es el alias o la dirección IP del
sistema objetivo.
Identifica la ruta que recorre un paquete a través de las redes.
traceroute destination La variable destination es el nombre de host o la dirección IP
del sistema objetivo.
telnet {host | ip-address}

Se conecta con una dirección IP usando la aplicación Telnet.
Utilice SSH siempre que sea posible en lugar de Telnet.
ssh -l user-id ip-address

Se conecta a una dirección IP con SSH.
SSH es más seguro que Telnet.
Muestra un resumen del estado de todas las interfaces en un
show ip interface brief dispositivo.
show ipv6 interface brief Útil para identificar rápidamente el direccionamiento IP en
todas las interfaces.
show ip route Muestra las tablas de routing IPv4 e IPv6 actuales, que
show ipv6 route contienen las rutas a todos los destinos de red conocidos
Muestra los protocolos configurados y muestra los valores
show protocols globales y estado específico de la interfaz de cualquier
protocolo configurado de Capa 3
debug
Muestra una lista de opciones para habilitar o deshabilitar
eventos de depuración.
Nota: El comando debug es una herramienta importante para recopilar síntomas,

pero genera tráfico (mensajes de consola) y puede afectar notablemente el
rendimiento del dispositivo de red. Si el comando debug debe ejecutarse en el
horario de trabajo normal, avise a los usuarios de la red que se está ejecutando
una medida de resolución de problemas y que el rendimiento de la red puede
verse afectado. Al terminar, recuerde deshabilitar la depuración.
12.2.5
Solución de problemas con modelos en

capas
Cuando se realiza la resolución de problemas, se pueden aplicar los modelos OSI
y TCP/IP para aislar los problemas de la red. Por ejemplo, si los síntomas sugieren
un problema de conexión física, el técnico de red puede concentrarse en la
resolución de problemas del circuito que funciona en la capa física.
La figura muestra algunos dispositivos comunes y las capas del modelo OSI que
se deben examinar durante el proceso de resolución de problemas de cada
dispositivo.
Métodos Estructurados de Resolución

de problemas
Existen varios enfoques estructurados de resolución de problemas que se pueden
utilizar. Cuál usar dependerá de la situación. Cada método tiene sus ventajas y
desventajas. En este tema, se describen los tres métodos y se proporcionan
pautas para elegir el mejor método para una situación específica.
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.
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.
Descendente
En la figura, 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. 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
Divide y vencerás
En la figura, se muestra el enfoque divide y vencerás para resolver un problema de
red.
El administrador de red selecciona una capa y hace pruebas en ambos sentidos

desde esa capa.
En el método de resolución de problemas divide y vencerás, comienza por reunir

las experiencias que el usuario tiene del problema, documenta los síntomas y,
después, con esa información, hace una deducción fundamentada sobre la capa
del modelo OSI en la que se debe comenzar la investigación. Cuando se verifica
que una capa funciona correctamente, se puede suponer que las capas por debajo
de ella funcionan. El administrador puede trabajar en las capas del modelo OSI en
sentido ascendente. Si una capa de OSI no funciona correctamente, el
administrador puede descender las capas de OSI.
Por ejemplo, si los usuarios no pueden acceder al servidor web, pero pueden
hacer ping al servidor, entonces el problema se encuentra por encima de la capa 3.
Si el ping al servidor falla, es probable que el problema esté en una capa inferior
del modelo OSI
Seguimiento de la ruta
Esta es una de las técnicas de solución de problemas más básicas. El enfoque

descubre primero la ruta de tráfico real desde el origen hasta el destino. El alcance
de la solución de problemas se reduce solo a los enlaces y dispositivos que se
encuentran en la ruta de reenvío. El objetivo es eliminar los enlaces y dispositivos
que son irrelevantes para la tarea de resolución de problemas. Este enfoque
generalmente complementa uno de los otros enfoques
Sustitución
Este enfoque también se denomina intercambio del componente porque se cambia

físicamente el dispositivo problemático por uno conocido y funcional. 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. Por ejemplo, un router de borde que falla. En vez de resolver el problema,
puede resultar más beneficioso reemplazar el dispositivo y restaurar el servicio.
Si el problema se encuentra en varios dispositivos, es posible que no sea posible

aislar correctamente el problema.
Comparación
Este enfoque también se denomina Encontrar las diferencias e intenta resolver el

problema modificando los elementos que no funcionan, para que sean coherentes
con los que si funcionan. Puede comparar configuraciones, versiones de software,
hardware u otras propiedades de dispositivos, vínculos o procesos entre
situaciones que funcionan y no funcionan y detectar diferencias significativas entre
ellas.
Si bien este método puede proporcionar una solución que funcione, no revela con
claridad la causa del problema
Deducción informada
Este enfoque también se denomina enfoque de resolución de problemas de

disparo desde la cadera. Este es un método de solución de problemas menos
estructurado que utiliza una conjetura educada basada en los síntomas del
problema. El éxito de este método varía en función de su experiencia y capacidad
de solución de problemas. Los técnicos experimentados tienen más éxito porque
pueden confiar en su amplio conocimiento y experiencia para aislar y resolver
problemas de red de manera decisiva. 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 al azar.
Pautas para seleccionar un método de

resolución de problemas
Para resolver rápidamente los problemas de una red, tómese el tiempo para
seleccionar el método más eficaz de resolución de problemas de red.
La figura ilustra qué método se podría utilizar cuando se descubre un cierto tipo de
problema
Por ejemplo, los problemas de software a menudo se resuelven utilizando un
enfoque descendente mientras que los problemas basados en hardware se
resuelven utilizando el enfoque ascendente. Los nuevos problemas pueden ser
resueltos por un técnico experimentado utilizando el método de divide y vencerás.
De lo contrario, se puede utilizar el enfoque ascendente.
La resolución de problemas es una habilidad que se desarrolla al hacerlo. Cada

problema de red que identifique y resuelva se añade a sus habilidades
HERRAMIENTAS PARA LA RESOLUCION DE PROBLEMAS
Software de resolución de problemas

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

herramientas de hardware y software. Estas herramientas se pueden usar para
recolectar y analizar los síntomas de los problemas de red. Con frecuencia,
proporcionan funciones de monitoreo y generación de informes que se pueden
usar para establecer la línea de base de red
Network Management System Tools
Las herramientas de administración de sistemas de red (NMS) incluyen

herramientas de monitoreo a nivel de los dispositivos, de configuración y de
administración de fallas. Estas herramientas se pueden usar para investigar y
corregir los problemas de red. El software de monitoreo de redes ofrece una vista
gráfica de los dispositivos de red, lo que permite que los administradores de red
monitoreen los dispositivos remotos de manera continua y automática. El sofftware
de administración de dispositivos proporciona información dinámica sobre el
estado del dispositivo, las estadísticas y la configuración de los principales
dispositivos de red. Busque en Internet "Herramientas NMS" para obtener más
información
Bases 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, los administradores de red tienen acceso a una vasta fuente de
información fundada en la experiencia.
Por ejemplo, la página Cisco Tools & Resources se puede encontrar

en http://www.cisco.com bajo el menú Support . Esta página proporciona
herramientas que se pueden utilizar para el hardware y el software de Cisco
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. 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. Busque en Internet «Herramientas de supervisión de
rendimiento de red» para obtener más información
Analizador de protocolos
Los analizadores de protocolos sirven para examinar el contenido de los paquetes
que atraviesan la red. Un analizador de protocolos decodifica las diversas capas
del protocolo en una trama registrada y presenta esa información en un formato
relativamente fácil de usar. En la ilustración, se muestra una captura de pantalla
del analizador de protocolos Wireshark
Los analizadores de protocolos muestran información sobre los datos bit físicos, la
información de enlaces de datos, protocolos, así como descripciones para cada
trama. La mayoría de los analizadores de protocolos pueden filtrar el tráfico que
cumple con ciertos criterios, por ejemplo, se puede captar todo el tráfico hacia y
desde un dispositivo determinado. Los analizadores de protocolos como Wireshark
pueden ayudar a resolver problemas de rendimiento de la red. Es importante tener
un buen manejo de TCP/IP y del uso de un analizador de protocolos para examinar
la información en cada capa de TCP/IP.
Herramientas de solución de problemas
de hardware
Hay varios tipos de herramientas de solución de problemas de hardware
Multímetro digital
Los multímetros digitales, como el Fluke 179, 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 que conllevan el

uso de un multímetro implican el control de los niveles de voltaje de la fuente de
alimentación y la verificación de recepción de energia por parte de los dispositivos
de red
Probadores de cables
Los comprobadores de cables son dispositivos portátiles especializados que están

diseñados para probar los diversos tipos de cables de comunicación de datos. La
figura muestra el probador automático de redes Fluke LinkRunner AT Network
Auto-Tester.
Los comprobadores de cables se pueden utilizar para detectar cables rotos, cables
cruzados, conexiones cortas y conexiones incorrectas. Estos dispositivos pueden
ser comprobadores de continuidad (económicos), comprobadores de cables de
datos (moderados) o bien reflectómetros de dominio de tiempo (TDR - costosos).
Los TDR se usan para identificar la distancia a una ruptura en un cable. Estos
dispositivos envían señales a lo largo del cable y esperan a que estas se reflejen.
El tiempo entre el envío y la recepción de la señal se convierte en una medida de
distancia. Normalmente, la función de TDR viene incluida en los comprobadores de
cables de datos. Los TDR que se usan para probar los cables de fibra óptica se
conocen como “reflectómetros ópticos de dominio de tiempo” (OTDR).
Analizadores de cables
Los analizadores de cables, como el Fluke DTX Cable Analyzer, son dispositivos
portátiles con varias funciones que se usan para probar y certificar los cables de
cobre y de fibra para los diferentes servicios y estándares.
Las herramientas más sofisticadas incluyen diagnósticos avanzados de solución

de problemas que miden la distancia a un defecto de rendimiento como
paradiafonía (NEXT) o pérdida de retorno (RL), identifican las medidas correctivas
y muestran gráficamente los estados de diafonía e impedancia. Los analizadores
de cables también suelen incluir software basado en computadora. Una vez
recopilados los datos de campo, los datos del dispositivo portátil pueden cargarse
para que el administrador de red genere informes actualizados
Analizadores de red portátiles
Los dispositivos portátiles, como Fluke OptiView, sirven para solucionar problemas
en redes conmutadas y VLAN.
Al conectar el analizador de red en cualquier parte de la red, un ingeniero de red

puede ver el puerto de switch al que se conecta el dispositivo, así como el uso
promedio y el uso pico. El analizador también se puede usar para conocer la
configuración de la VLAN, identificar los participantes principales de la red, analizar
el tráfico de la red y ver los detalles de la interfaz. Para un análisis y una resolución
de problemas más profundos, el dispositivo debe conectarse a una computadora
que tenga instalado un software de supervisión de red
Módulo de análisis de red Cisco Prime (CISCO Prime NAM)
La cartera de Módulo de análisis de red Cisco Prime (CISCO Prime NAM) (NAM),
que se muestra en la figura, incluye hardware y software para el análisis del
rendimiento en entornos de switches y routers. Proporciona una interfaz integrada
basada en navegador que genera informes sobre el tráfico que consume recursos
de red críticos. Además, NAM puede capturar y decodificar paquetes, y medir los
tiempos de respuesta para identificar en qué red o servidor en particular se genera
el problema de aplicaciones
Servidor Syslog como herramienta de

resolución de problemas
Syslog es un protocolo simple usado por cualquier dispositivo IP, conocido como
“cliente syslog”, para enviar mensajes de registro basados en texto a otro
dispositivo IP, el servidor de syslog. Actualmente, Syslog se define en RFC 5424.
Implementar una instalación de registro es una parte importante de la seguridad y
la resolución de problemas de red. Los dispositivos de Cisco pueden registrar
información relacionada con cambios de configuración, infracciones de ACL,
estado de interfaces y muchos otros tipos de eventos. Los dispositivos de Cisco
pueden enviar mensajes de registro a varias instalaciones. Los mensajes de
eventos se pueden enviar a uno o varios de los siguientes componentes:
 Consola - el registro de la consola está activado de manera predeterminada. Los

mensajes se registran en la consola y pueden verse al modificar o probar el router o
switch con el software de emulación de terminales, conectado al puerto de consolas
del dispositivo de red.
 Líneas de las terminales - las sesiones de EXEC habilitadas se pueden configurar
para recibir mensajes de registro en cualquiera de las líneas de las terminales. Al
igual que el registro de consolas, este tipo de registros no se almacena en el
dispositivo de red, por lo que solo sirve al usuario en esa línea.
 El registro con búfer - es un poco más útil como herramienta de solución de
problemas porque los mensajes de registro se almacenan en la memoria por un
tiempo. Sin embargo, cuando se reinicia el dispositivo, se borran los mensajes de
registro.
 Traps de SNMP - ciertos umbrales se pueden configurar previamente en los routers
y otros dispositivos. Los eventos de router, que superen el umbral, se pueden
procesar en el router y reenviar como notificaciones de SNMP a una estación de
administración de redes SNMP externa. Las traps de SNMP son una instalación de
registro de seguridad viable, pero requieren la configuración y el mantenimiento de
un sistema SNMP.
 Syslog - los routers y los switches Cisco se pueden configurar para reenviar
mensajes de registro a un servicio de syslog externo. Este servicio puede residir en
cualquier número de servidores o estaciones de trabajo, incluidos los sistemas
basados en Microsoft Windows y Linux. Syslog es la instalación de registro de
mensajes más popular, ya que proporciona capacidades de almacenamiento de
registro a largo plazo y una ubicación central para todos los mensajes del router.
Los mensajes de registro del IOS de Cisco se clasifican en uno de ocho niveles,
como se muestra en la tabla.
Nivel Palabra clave Descripción Definición

0 Emergencias No se puede utilizar el sistema LOG_EMERG
1 Alertas Se necesita una acción inmediata. LOG_ALERT
Nivel más
2 Crítico Existen condiciones críticas. LOG_CRIT
alto
3 Errores Existen condiciones de error. LOG_ERR
4 Advertencias Existen condiciones de advertencia. LOG_WARNING
5 Notificaciones Condición normal (pero importante). LOG_NOTICE
Nivel más
6 Informativos Solo mensajes informativos. LOG_INFO
bajo
7 Depuración Mensajes de depuración LOG_DEBUG
Cuanto menor es el número del nivel, mayor es el nivel de gravedad. De manera
predeterminada, todos los mensajes del nivel 0 al 7 se registran en la consola. Si
bien la capacidad para ver los registros en un servidor central de syslog es útil para
resolver problemas, examinar una gran cantidad de datos puede ser una tarea
abrumadora. El comando logging trap level se usa para limitar los mensajes
registrados en el servidor syslog según la gravedad. El nivel es el nombre o
número de nivel de la severidad. Solo se registran los mensajes de número igual o
menor que el nivel de especificado.
En el comando de salida, los mensajes de sistema del nivel 0 (emergencias) al 5

(notificaciones) se envían al servidor de syslog en 209.165.200.225.
SINTOMAS Y CAUSAS DE LOS PROBLEMAS DE RED
Resolución de problemas de la capa

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

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

Leyenda de la tabla
Síntoma Descripción
Requiere líneas base anteriores para la comparación.
Las razones más comunes para un rendimiento lento o deficiente incluyen
Rendimiento
servidores sobrecargados o con bajo suministro de energía, switches o
menor a la línea
routers con configuraciones inadecuadas, congestión del tráfico en un
de base
enlace de baja capacidad y pérdida crónica de tramas.
La pérdida de conectividad podría deberse a un cable fallido o

desconectado.
Pérdida de Se puede verificar mediante una simple prueba de ping.
conectividad La pérdida intermitente de la conectividad puede indicar una conexión floja
u oxidada.
Si falla un router, interfaz o cable, los protocolos de enrutamiento pueden

Cuellos de
redirigir el tráfico a otras rutas que no están diseñadas para transportar la
botella o
capacidad adicional.
congestión en
Esto puede provocar congestión o cuellos de botella en partes de la red.
la red
Las altas tasas de utilización de la CPU son un síntoma de que un

Altos dispositivo, como un router, switch o servidor, está operando a o
porcentajes de sobreexcediendo sus limites de diseño.
utilización de Si no se aborda rápidamente, la sobrecarga de CPU puede ocasionar que
CPU un dispositivo falle o se desactive.
Los mensajes de error notificados en la consola del dispositivo podrían

Mensajes de
indicar un problema de capa física.
error de la
Los mensajes de la consola deben registrarse en un servidor syslog central.
consola
La tabla enumera los incidentes que comúnmente causan problemas de red en la

capa física incluyen los siguientes:
Causa del
Descripción
problema
Esta es la razón más básica para la 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
Relacionadas con bastidor no estén obstruidos.
la alimentación Si en otras unidades cercanas también se produce una pérdida de
energía, 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
que en la red se observen errores de transmisión debidos a colisiones
Causa del
Descripción
problema
tardías, tramas cortas y jabber.
Jabber a menudo se define como la condición en la que un dispositivo de
red transmite continuamente datos aleatorios y sin sentido a la red.
Otras causas probables de jabber son controladores de NIC defectuosos
o dañados, cables defectuosos o problemas de conexión a tierra.
Muchos problemas se pueden corregir simplemente volviendo a colocar

los cables que están parcialmente desconectados.
Al realizar una inspección física, busque cables dañados, cables
Fallas de cableado incorrectos y conectores RJ-45 mal rizados.
Los cables sospechosos se deben probar o cambiar por un cable que se
sepa que funcione.
La atenuación puede producirse si la longitud de un cable supera el

límite de diseño o cuando hay una conexión deficiente como resultado de
un cable suelto o contactos sucios u oxidados.
Atenuación
Si la atenuación es grave, el dispositivo receptor no siempre puede
distinguir correctamente un bit en el flujo de datos de otro bit.
La interferencia electromagnética local (EMI) se conoce comúnmente

como “ruido”.
El ruido puede ser generado por muchas fuentes, como estaciones de
radio FM, la radio policial, la seguridad de los edificios y la aviónica para
Ruido el aterrizaje automático, crosstalk (ruido inducido por otros cables en la
misma vía o cables adyacentes), cables eléctricos cercanos, dispositivos
con grandes motores eléctricos, o cualquier cosa que incluya un
transmisor más potente que un teléfono celular.
Muchas cosas pueden estar mal configuradas en una interfaz que hacen
que esta deje de funcionar, como por ejemplo frecuencia de reloj
Errores de
incorrecta, fuente de reloj incorrecta y que la interfaz no está activada.
configuración de
Esto provoca la pérdida de la conectividad a los segmentos de red
interfaz
conectados.
Un componente puede estar operando de manera subóptima en la capa

física porque se utiliza más allá de las especificaciones o su capacidad
configurada.
Límites de diseño
Al solucionar este tipo de problema, se hace evidente que los recursos
excedidos
del dispositivo están funcionando en o cerca de la capacidad máxima y
hay un aumento en el número de errores en la interfaz.
Sobrecarga de Los síntomas incluyen procesos con altos porcentajes de utilización de la

CPU CPU, caídas de cola de entrada, rendimiento lento, sin acceso remoto o
servicios como DHCP, Telnet y ping son lentos o fallan en responder.
En un switch podría ocurrir lo siguiente: reconversión del árbol de
Causa del
Descripción
problema
extensión, Enlaces EtherChannel que rebotan, intermitencia UDLD, fallos
de IP SLAs.
En los routers, se puede producir una interrupción de actualizaciones de
routing, o intermitencia de rutas o intermitencia de HSRP.
Una de las causas de la sobrecarga de CPU en un router o switch es el
alto nivel de tráfico.
Si una o más interfaces están sobrecargadas regularmente de tráfico,
considerar rediseñar el flujo de tráfico en la red o actualizar el hardware.
Resolución de problemas de la capa de

Enlace de datos
La resolución de problemas de capa 2 puede ser un proceso desafiante. La
configuración y el funcionamiento de estos protocolos son fundamentales para
crear redes con ajustes precisos y funcionales. Los problemas de capa 2 causan
síntomas específicos que, al reconocerse, ayudan a identificar el problema
rápidamente.
La figura resume los síntomas y las causas de los problemas de red de capa de
enlace de datos
La tabla enumera los síntomas comunes de los problemas de red de capa de

enlace de datos.
Falta de funcionalidad o Algunos problemas de la capa 2 pueden detener el intercambio
conectividad en la capa de red de tramas a través de un enlace, mientras que otros solo causan
o en capas superiores que el rendimiento de la red se deteriore.
Hay dos tipos distintos de operaciones subóptimas de capa 2 que
puede ocurrir en una red.
En primer lugar, que las tramas elijan una ruta deficiente al
destino, pero llegan, haciendo que la red experimente un uso de
La red funciona por debajo de ancho de banda alto e inesperado en esos enlaces.
los niveles de rendimiento de En segundo lugar, algunas tramas se eliminan, debido a los
línea de base contadores de errores y mensajes de error de consola que
aparecen en el switch o router.
Un ping extendido o continuo puede ayudar a revelar si las
tramas están siendo descartadas.
Los sistemas operativos utilizan ampliamente broadcast y

multicast para descubrir servicios de red y otros hosts.
En general, las emisiones excesivas son el resultado de una mal
Broadcast excesivos configuración o programación de las aplicaciones, un gran
dominio broadcast de Capa 2 o un problema de red subyacente
(por ejemplo, bucles STP o ruta inestable).
Un router reconoce que se ha producido un problema de Capa 2

y envía mensajes de alerta a la consola.
Normalmente, un router hace esto cuando detecta un problema al
interpretar tramas entrantes (problemas de encapsulación) o
Mensajes de la consola 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.
La tabla enumera los problemas que suelen causar problemas de red en la capa
de Enlace de datos.
Causa del problema Descripción

Se produce un error de encapsulación porque los bits colocados
en un campo por el remitente no es lo que el receptor espera
ver.
Errores de encapsulación Esta condición se produce cuando la encapsulación en un
extremo de una WAN se configura de manera diferente a la
encapsulación utilizada en el otro extremo.
Errores de asignación de En topologías, como punto a multipunto o broadcast Ethernet,

direcciones es esencial que una dirección de destino de Capa 2 sea asignada
a una trama. Esto asegura su llegada de manera correcta al
destino.
Para lograr esto, debe coincidir la direccion de destino de capa
3 con la dirección de destino correcta de la capa 2, ya sea
usando mapeo estático o dinámico.
En un entorno dinámico, la asignación de capa 2 y capa 3
puede fallar porque los dispositivos pueden haber sido
específicamente configurado para no responder a las solicitudes
ARP, la información de capa 2 o la de capa 3 almacenada en
caché puede haber cambiado físicamente, o respuesta inválidas
de ARP se reciben debido a una configuración incorrecta o a un
ataque.
Las tramas generalmente operan en grupos de bytes de 8-bit.

Un error de entramado se produce cuando una trama no respeta
los 8-bit byte como límite.
Cuando sucede esto, el receptor puede tener problemas para
determinar donde termina una trama y donde comienza otra
trama.
Un número excesivo de tramas no válidas puede impedir a los
Errores de entramado
keepalives válidos ser entregados.
Los errores de entramado pueden ser causados por una línea de
serie ruidosa, el diseño incorrecto de un cable (demasiado largo
o no blindado adecuadamente), una NIC defectuosa,
discordancia dúplex, o un reloj de línea configurado
incorrectamente en la unidad de servicio de canal (CSU)
El propósito de STP es resolver una topología física redundante

de manera similar a un árbol, mediante el bloqueo de puertos
redundantes.
La mayoría de los problemas STP están relacionados con
bucles de reenvío que se producen cuando no se bloquean
puertos redundantes, por ende el tráfico se reenvía en círculos
indefinidamente. Esto causa inundaciones debido a una alta
tasa de cambios de topología STP.
Un cambio de topología debería ser un evento inusual, si se
configuró de manera correcta la red.
Cuando un enlace entre dos switches se habilita o deshabilita,
Fallas o bucles de STP
hay eventualmente un cambio de topología cuando el estado
STP del puerto está cambiando hacia o desde Forwarding.
Sin embargo, cuando el estado de un puerto es intermitente esto
provoca cambios repetitivos de topología e inundaciones, o una
convergencia lenta de STP.
Esto puede ser causado por un diferencia entre la realidad y la
documentación de la topología, un error de configuración,
como inconsistencia en la configuración de temporizadores
STP, una CPU de switch sobrecargada durante la convergencia,
o un defecto de software.
12.4.3
Resolución de problemas de capa de red
Los problemas de capa de red incluyen cualquier problema que implique un
protocolo de capa 3, como IPv4, IPv6, EIGRP, OSPF, etc. La figura resume los
síntomas y las causas de los problemas de la capa de red.
La tabla enumera los síntomas comunes de los problemas la capa de red .
Error de red es cuando la red está casi o completamente no funcional, que
afecta a todos los usuarios y aplicaciones de la red.
Estos fallos suelen ser detectados rápidamente por los usuarios y
Falla de red
administradores, y obviamente son críticos para la productividad de una
empresa.
Los problemas de optimización de red suelen involucrar un subconjunto de

usuarios, aplicaciones, destinos o un tipo de tráfico.
Es difícil detectar los problemas de optimización, y son incluso más difíciles
de aislar y diagnosticar.
Rendimiento inferior
Esto se debe a que varias capas suelen verse involucradas o incluso una única
al óptimo
computadora host.
Determinar que el problema se encuentra en la capa de red puede llevar
tiempo.
En la mayoría de las redes, se usan rutas estáticas junto con protocolos de

enrutamiento dinámico. La configuración incorrecta de las rutas estáticas puede
provocar un enrutamiento deficiente. En algunos casos, las rutas estáticas
configuradas incorrectamente pueden generar bucles de enrutamiento, que
hacen que algunas partes de la red se vuelvan inalcanzables.
La resolución de problemas de protocolos de enrutamiento dinámico requiere
una comprensión profunda de cómo funciona el protocolo de enrutamiento
específico. Algunos problemas son comunes a todos los protocolos de
enrutamiento, mientras que otros son específicos de un protocolo.
No existe una única plantilla para resolver problemas de capa 3. Los problemas
de enrutamiento se resuelven con un proceso metódico, por medio de una serie
de comandos para aislar y diagnosticar el problema.
La tabla muestra areas a explorar cuando se diagnostica un posible problema

que involucra protocolos de enrutamiento.

A menudo, un cambio en la topología, como un enlace que falla, puede tener
efectos en otras áreas de la red que podrían no ser obvios en el momento.
Esto puede implicar instalar nuevas rutas, estáticas o dinámicas, o la
Problemas generales
eliminación de otras rutas.
de red
Determine si algo en la red ha cambiado recientemente y si hay alguien
trabajando actualmente en la infraestructura de red.
Compruebe si hay problemas de equipo y conectividad, incluida la

alimentación, problemas como cortes de energia y problemas ambientales
Problemas de (por ejemplo, sobrecalentamiento).
conectividad También revise si hay problemas de capa 1, como problemas de cableado,
daño de puertos y problemas de ISP.
Compruebe si hay algo inesperado en la tabla de enrutamiento, como rutas

faltantes o rutas no identificadas.
Tabla de
Use los comandos debug para ver las actualizaciones de enrutamiento y dar
enrutamiento
mantenimiento a la tabla de enrutamiento.
Si el protocolo de enrutamiento establece una adyacencia con un vecino,

Problemas de vecinos marque para ver si hay algún problema con los routers que forman esa
adyacencia.
Si el protocolo de enrutamiento utiliza una tabla de topología o una base de
Base de datos de
datos, revise la tabla por cualquier cosa inesperada, como entradas faltantes o
topología
inesperadas entradas.
12.4.4

transporte: ACL
Los problemas de red pueden surgir a partir de problemas de la capa de
transporte en el router, especialmente en el borde de la red, donde se examina
y se modifica el tráfico. Por ejemplo, tanto las listas de control de acceso (ACL)
como la traducción de direcciones de red (NAT) funcionan en la capa de red y
pueden implicar operaciones en la capa de transporte, como se muestra en la
figura.
La mayoría de los problemas frecuentes con ACL se debe a una configuración

incorrecta, como se muestra en la figura.
Los problemas con las ACL pueden provocar fallas en sistemas que, por lo demás,
funcionan correctamente. Comúnmente, las configuraciones incorrectas ocurren en
varias áreas:
Configuraciones
Descripción
incorrectas
El tráfico se define tanto por la interfaz del router a través de la cual el
el tráfico está viajando y la dirección en la que este tráfico se mueve.
Selección del flujo de
Se debe aplicar una ACL a la interfaz correcta y la direccion correcta
tráfico
debe seleccionarse para que funcione correctamente.
Configuraciones
Descripción
incorrectas
El orden de las entradas en una ACL debe ir de lo específico a lo
general.
Aunque una ACL puede tener una entrada para permitir
específicamente un tipo de trafico, los paquetes nunca coinciden con
esa entrada si están siendo denegado por otra entrada anterior en la
lista.
Orden de las entradas
Si el router está ejecutando ACL y NAT, el orden en que cada una de
de control de acceso
estas tecnologías se aplica es importante.
La ACL de entrada procesa el tráfico entrante antes de que lo procese la
NAT de afuera hacia dentro.
El trafico saliente es procesado por el ACL de salida luego de ser
procesados por NAT adentro hacia afuera.
Cuando no se requiere alta seguridad en la ACL, esta accesp implícito

Deny any implícito
puede ser la causa de una configuración incorrecta de ACL.
Las máscaras complejas wildcard IPv4 proporcionan mejoras
significativas en eficiencia, pero están más sujetos a errores de
configuración.
Dirección y máscaras
Un ejemplo de una máscara wildcard compleja es el uso de la dirección
wildcard IPv4
IPv4 10.0.32.0 y máscara wildcard 0.0.32.15 para seleccionar las
primeras 15 direcciones en la red 10.0.0.0 o en la red 10.0.32.0.
Al configurar ACLs, es importante selecciona de manera correcta el

protocolos de capa de transporte.
Muchos administradores de red, cuando no están seguros de si un tipo
de tráfico usa un puerto TCP o un puerto UDP, configure ambos.
Selección del protocolo
Especificar ambos provoca una abertura a través del firewall, lo que
de la capa de
posibilita a los intrusos un ingreso la red.
transporte
También introduce un elemento adicional en la ACL, por lo que la ACL
toma más tiempo en procesar, introduciendo más latencia en la red de
comunicaciones.
Controlar correctamente el tráfico entre dos hosts requiere elementos de

control de acceso simétricos para ACL entrantes y salientes.
Puertos de origen y Información de dirección y puerto para el tráfico generado por una
destino respuesta de un host es la imagen reflejada de la información de
dirección y puerto para el tráfico generado por el host iniciador.
La palabra clave establecida aumenta la seguridad proporcionado por

una ACL.
Uso de la palabra clave
Sin embargo, si la palabra clave se aplica incorrectamente, resultados
established
imprevistos. pueden surgir.
Protocolos poco Las ACL configuradas incorrectamente suelen causar problemas en

frecuentes protocolos distintos a TCP y UDP.
Configuraciones
Descripción
incorrectas
Los protocolos poco frecuentes que están ganando popularidad son
VPN y protocolos de encriptación.
La palabra clave log es un comando útil para ver la operación de las ACL en las
entradas de ACL. Esta palabra clave le ordena al router que coloque una entrada
en el registro del sistema cada vez que haya una coincidencia con esa condición
de entrada. El evento registrado incluye los detalles del paquete que coincidió con
el elemento de la ACL. La palabra clave log es especialmente útil para resolver
problemas y también proporciona información sobre los intentos de intrusión que la
ACL bloquea.
12.4.5

transporte: NAT para IPv4
Existen varios problemas con NAT, como la falta de interacción con servicios como
DHCP y tunneling. Estos pueden incluir la configuración incorrecta de NAT interno,
NAT externo o la ACL. Otros problemas incluyen interoperabilidad con otras
tecnologías de red, especialmente con aquellas que contienen o derivan
información de direccionamiento de red del host en el paquete.
La figura resume areas frecuentes de interoperabilidad con NAT
La tabla enumera áreas frecuentes de interoperabilidad con NAT.

Ambos protocolos administran la asignación automática de direcciones IPv4 a
clientes.
Recuerde,el primer paquete que un nuevo cliente envía es un paquete IPv4 de
broadcast de solicitud de DHCP..
El paquete de solicitud de DHCP tiene la dirección IPv4 de origen 0.0.0.0.
BOOTP y DHCP Debido a que NAT requiere tanto un destino válido como un IPv4 de origen BOOTP
y DHCP pueden tener dificultades para operar a través de un router ejecutando NAT
estático o dinámico.
La configuración de ip-helper IPv4 puede contribuir a la resolución de este
problema.
Debido a que un router que ejecuta NAT dinámico está cambiando la relación entre
direcciones internas y externas regularmente, ya que las entradas de tabla caducan y
se vuelven a crear, un servidor DNS fuera del router NAT no tienen una
DNS representación precisa de la red dentro del router.
La configuración de ip-helper IPv4 puede contribuir a la resolución de este
problema.
Al igual que los paquetes DNS, NAT no puede alterar la información de

direccionamiento almacenados en los datos del paquete.
Debido a esto, una estación de administración SNMP en un lado de una NAT podria
SNMP presentar problemas para ponerse en contacto con los agentes SNMP del otro lado
de el router NAT.
La configuración deip-helper IPv4 puede contribuir a la resolución de este problema.
Los protocolos de cifrado y túnel a menudo requieren que el tráfico sea procedente
de un puerto UDP o TCP específico, o utilice un protocolo en el capa de transporte
que NAT no puede procesar.
Protocolos de tunneling
Por ejemplo, los protocolos de túnel IPSec y los protocolos enrutamiento de
y cifrado
encapsulacion genéricos utilizados por las implementaciones VPN no pueden ser
procesado por NAT.
12.4.6
Resolución de problemas de capa de Aplicación

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

conocidos e implementados.
La tabla proporciona una breve descripción de estos protocolos de capa de
aplicación.
Leyenda de la tabla
Aplicaciones Descripción
Permite a los usuarios establecer conexiones de sesión de terminal de
SSH/Telnet
manera remota con hosts.
Admite el intercambio de texto, gráficos, sonido, video y otros archivos
HTTP
multimedia en la web.
FTP Realiza transferencias interactivas de archivos entre los hosts.
Realiza transferencias interactivas básicas de archivos, generalmente, entre
TFTP
hosts y dispositivos de red.
SMTP Admite servicios básicos de entrega de mensajes.
Conecta a los servidores de correo electrónico y descarga correo
POP
electrónico.
SNMP Recopila información de administración de dispositivos de red.
DNS Relaciona direcciones IP a los nombres asignados a los dispositivos de red.
Habilita las computadoras para montar unidades en hosts remotos y
Sistema de operarlas como si fueran unidades locales. Originalmente desarrollado por
archivos de red Sun Microsystems, se combina con otros dos protocolos de capa de
(NFS) aplicación XDR y RPC, para permitir acceso transparente a recursos de red
remotos.
Los tipos de síntomas y causas dependen de la aplicación como tal.
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 aún 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.
RESOLUCION DE PROBLEMAS DE CONECTIVIDAD IP
Componentes de la resolución de
problemas de conectividad de extremo a
extremo
En este tema se presenta una topología única y las herramientas para diagnosticar
y, en algunos casos, resolver un problema de conectividad de extremo a extremo.
Diagnosticar y resolver problemas es una aptitud esencial para los administradores
de red. No existe una única receta para la resolución de problemas, y un problema
en particular se puede diagnosticar de muchas maneras diferentes. Sin embargo,
al emplear un enfoque estructurado para el proceso de resolución de problemas,
un administrador puede reducir el tiempo que tarda en diagnosticar y resolver un
problema.
En este tema, se usa la siguiente situación. El host cliente PC1 no puede acceder
a las aplicaciones en el servidor SRV1 o el servidor SRV2. En la ilustración, se
muestra la topología de esta red. Para crear su dirección IPv6 unicast global, la
PC1 usa SLAAC con EUI-64. Para crear la ID de interfaz, EUI-64 usa la dirección
MAC de Ethernet, inserta FFFE en el medio e invierte el séptimo bit.
Cuando no hay conectividad de extremo a extremo y el administrador elige
resolver problemas con un enfoque ascendente, estos son los pasos frecuentes
que el administrador puede seguir:
Paso 1. Revisar la conectividad física en el punto donde se detiene la

comunicación de red. Esto incluye los cables y el hardware. El problema podría
estar relacionado con un cable o una interfaz defectuosos o con un componente de
hardware defectuoso o configurado incorrectamente.
Paso 2. Revisar las incompatibilidades de dúplex.
Paso 3. Revisar el direccionamiento de las capas de enlace de datos y de red en
la red local. Esto incluye las tablas ARP de IPv4, las tablas de vecinos IPv6, las
tablas de direcciones MAC y las asignaciones de VLAN.
Paso 4. Verificar que el gateway predeterminado sea correcto.
Paso 5. Asegurarse de que los dispositivos determinen la ruta correcta del origen
al destino. Si es necesario, se debe manipular la información de enrutamiento.
Paso 6. Verificar que la capa de transporte funcione correctamente. También se
puede usar Telnet desde la línea de comandos para probar las conexiones de la
capa de transporte.
Paso 7. Verificar que no haya ACL que bloqueen el tráfico.
Paso 8. Asegurarse de que la configuración del DNS sea correcta. Debe haber un
servidor DNS accesible.
El resultado de este proceso es deberia proveer conectividad de extremo a

extremo. Si se siguieron todos los pasos sin obtener resolución alguna, es posible
que el administrador de red desee repetir los pasos anteriores o elevar el problema
a un administrador más experimentado.
12.5.2
Problema de conectividad de extremo a
extremo inicio de la resolución de
problemas
Generalmente, lo que da inicio a un esfuerzo de resolución de problemas es la
detección de un problema con la conectividad de extremo a extremo. Dos de las
utilidades más comunes que se utilizan para verificar un problema con la
conectividad de extremo a extremo son ping y traceroute, que se muestran en la
figura.
IPv4 ping
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 llamado 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. Se muestra un ping satisfactorio de la PC1 al SRV1, en la dirección
172.16.1.100.
IPv4 traceroute
Al igual que el comando ping, el comando traceroute Cisco IOS se puede utilizar
tanto para IPv4 como para 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.
El ejemplo tracert muestra la ruta que los paquetes IPv4 toman para llegar al
destino.
IPv6 ping and traceroute
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. El resultado
del comando muestra los comandos ping y traceroute en el router R1 utilizados
para probar la conectividad IPv6.
Note: The El comando command is commonly performed when the traceroute se

utiliza cuando el comando command fails. If the ping ha fallado. Si el succeeds,
the ping fue exitoso, entonces el comando traceroute no es necesario porque el
técnico ya sabe que existe conectividad.
Nota: El comando traceroute se realiza comúnmente cuando falla el

comando ping. Si el ping tiene éxito, el comando traceroute generalmente no es
necesario porque el técnico sabe que existe conectividad.
12.5.3
Paso 1: Verificar la capa física

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

hardware, el comando show interfaces puede ser usado para revisar las
interfaces por las que el trafico pasa.
Consulte el resultado del comando show interfaces .
Input queue drops
Input queue drops (y los ignored and throttle counters) 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.
Output queue drops
Output queue drops 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 sensibles a esas situaciones, como
VoIP, tengan problemas de rendimiento. Output queue drops frecuentes pueden
ser indicio de que se debe implementar un mecanismo de puesta en cola
avanzado para aplicar o modificar QoS.
Input errors
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 incompatibilidades
de dúplex.
Output errors
Output errors indican errores, como colisiones, durante la transmisión de una

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

de dúplex
Otra causa común de los errores de interfaz es un modo de dúplex incompatible
entre los dos extremos de un enlace Ethernet. Actualmente, en numerosas redes
basadas en Ethernet, las conexiones punto a punto son la norma, y el uso de hubs
y la operación half-duplex asociadas se están volviendo menos frecuentes. Esto
significa que, en la actualidad, la mayoría de los enlaces Ethernet operan en modo
full-duplex y que, si bien se consideraba que las colisiones eran normales en un
enlace Ethernet, hoy en día las colisiones suelen indicar que la negociación de
dúplex falló y que el enlace no opera en el modo de dúplex correcto.
El estándar Gigabit Ethernet IEEE 802.3ab exige el uso de la autonegociación para
velocidad y dúplex. Además, si bien no es estrictamente obligatorio, casi todas las
NIC Fast Ethernet también usan la autonegociación de manera predeterminada.
En la actualidad, la práctica recomendada es la autonegociación para velocidad y
dúplex.
Sin embargo, si la negociación de dúplex falla por algún motivo, podría ser
necesario establecer la velocidad y el dúplex manualmente en ambos extremos.
Por lo general, esto conllevaría configurar el modo dúplex en full-duplex en ambos
extremos de la conexión. Si esto no funciona, es preferible ejecutar semidúplex en
ambos extremos para evitar una diferencia entre dúplex.
Las pautas de configuración de dúplex incluyen:
 Se recomienda la autonegociación de velocidad y dúplex.

 Si la autonegociación falla, configure manualmente la velocidad y el dúplex en los
extremos interconectados.
 Los enlaces Ethernet de punto a punto siempre se deben ejecutar en modo full-
duplex.
 El semidúplex es inusual y solo suele encontrarse cuando se usan hubs.
Ejemplo de resolución de problemas
En el escenario anterior, el administrador de red tuvo que agregar usuarios

adicionales a la red Para incorporar a estos nuevos usuarios, el administrador de
red instaló un segundo switch y lo conectó al primero. Poco después de que se
agregó el S2 a la red, los usuarios en ambos switches comenzaron a experimentar
importantes problemas de rendimiento al conectarse con los dispositivos en el otro
switch, como se muestra en la figura.
El administrador de red observa un mensaje de la consola en el switch S2:
*Mar 1 00:45:08.756: %CDP-4-DUPLEX_MISMATCH: duplex mismatch

discovered on FastEthernet0/20 (not half duplex), with Switch
FastEthernet0/20 (half duplex).
Mediante el comando show interfaces fa 0/20 , el administrador de red examina la

interfaz en el S1 usada para conectarse al S2 y observa que está establecida en
full-duplex, como se muestra en la figura
Ahora, el administrador de red examina el otro lado de la conexión: el puerto en el
S2. Se muestra que este lado de la conexión se configuró como half-duplex.
El administrador de red corrige la configuración y la establece en duplex auto , para

que el dúplex se negocie automáticamente. Debido a que el puerto en el S1 se
establece en full-duplex, el S2 también usa full-duplex.
Los usuarios informan que ya no existe ningún problema de rendimiento.
Paso 3: Verificar el direccionamiento 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 Windows
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, el resultado del 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 IPv6 de Windows
El comando netsh interface ipv6 show neighbor de Windows enumera todos los
dispositivos que están actualmente en el caché de la tabla de detección de
vecinos.
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 una dirección link-local debe ser única solo en ese
enlace o red.
Nota: en los sistemas operativos Linux y MAC OS X, se puede mostrar la tabla de

vecinos mediante el comando ip neigh show .
Tabla de vecinos IPv6 de IOS
El comando show ipv6 neighbors muestra un ejemplo de la tabla de detección de

vecinos en el router Cisco IOS.
Nota: Los estados de los vecinos en IPv6 son más complejos que los estados de
la tabla ARP en IPv4. RFC 4861 contiene información adicional.
Tabla de direcciones MAC del switch
Cuando se encuentra una dirección MAC de destino en la tabla de direcciones

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

Asignación de VLAN
Al resolver problemas de conectividad de extremo a extremo, otro problema que se
debe considerar es la asignación de VLAN. En una red conmutada, cada puerto en
un switch pertenece a una VLAN. Cada VLAN se considera una red lógica
independiente, y los paquetes destinados a las estaciones que no pertenecen a la
VLAN se deben reenviar a través de un dispositivo que admita el enrutamiento. Si
el host de una VLAN envía una trama de Ethernet de transmisión, como una
solicitud de ARP, todos los host de la misma VLAN recibirán la trama; los host de
otras VLAN no la recibirán. Incluso si dos hosts están en la misma red IP, no se
podrán comunicar si están conectados a puertos asignados a dos VLAN
separadas. Además, si se elimina la VLAN a la que pertenece el puerto, este
queda inactivo. Ninguno de los hosts conectados a los puertos que pertenecen a la
VLAN que se eliminó se puede comunicar con el resto de la red. Los comandos
como show vlan se pueden usar para validar las asignaciones de VLAN en un
switch.
Supongamos, por ejemplo, que en un esfuerzo por mejorar la gestión de cables en
el armario de cableado, su empresa ha reorganizado los cables que se conectan al
switch S1. Casi inmediatamente después de hacerlo, los usuarios comenzaron a
llamar al soporte técnico con el comentario de que ya no tenían posibilidad de
conexión a los dispositivos fuera de su propia red.
Revise la tabla ARP
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
Compruebe la tabla MAC del switch
No hubo cambios de configuración en el router, de modo que la resolución de

problemas se centra en el S1.
La tabla de direcciones MAC para el S1, muestra que la dirección MAC del R1 está
en una VLAN diferente que el resto de los dispositivos en 10.1.10.0/24, incluida la
PC1.
Corrija la asignación de VLAN
Mientras se volvían a conectar los cables, se trasladó el cable de conexión del R1

de Fa0/4 en la VLAN10 a Fa0/1 en la VLAN 1. El problema se resolvió después de
que el administrador de red configuró el puerto FA 0/1 del S1 para que estuviera
en la VLAN, como se muestra en la figura. Ahora la tabla de direcciones MAC
muestra la VLAN 10 para la dirección MAC del R1 en el puerto Fa 0/1.
Paso 4: Verificar la puerta de enlace
predeterminada
Si no hay una ruta detallada en el router o si el host está configurado con la puerta
de enlace predeterminada incorrecta, la comunicación entre dos terminales en
redes distintas no funciona.
En la figura, se muestra que la PC1 usa el R1 como puerta de enlace

predeterminada. De manera similar, el R1 usa al R2 como puerta de enlance
predeterminada o como gateway de último recurso. Si un host necesita acceso a
recursos que se encuentran más allá de la red local, se debe configurar la puerta
de enlace predeterminada. La puerta de enlace predeterminada es el primer router
en la ruta a los destinos que se encuentran más allá de la red local.
Ejemplo de Resolución de problemas de puerta de enlace predeterminada

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

puerta de enlace predeterminada de IPv6
En IPv6, el gateway predeterminado puede configurarse manualmente con la
configuración automática independiente del estado (SLAAC) o con DHCPv6. Con
SLAAC, el router anuncia el gateway predeterminado a los hosts mediante los
mensajes de anuncio de router (RA) ICMPv6. El gateway predeterminado en el
mensaje RA es la dirección IPv6 link-local de una interfaz del router. Si el gateway
predeterminado se configura manualmente en el host, lo que es muy poco
probable, se puede establecer el gateway predeterminado en la dirección IPv6
global o en la dirección IPv6 link-local
Tabla de enrutamiento de R1
Como se muestra en la salida del comando, el comando show ipv6 route Cisco
IOS se utiliza para comprobar la ruta predeterminada IPv6 en R1. R1 tiene una
ruta predeterminada a través de R2
Direccionamiento PC1
El comando ipconfig de Windows, se utiliza para comprobar que un PC1 tiene una
puerta de enlace predeterminada IPv6. En el resultado del comando, a PC1 le falta
una dirección unicast global IPv6 y una puerta de enlace predeterminada 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.
Revise la configuración de interfaz de R1
La salida del comando show ipv6 interface GigabitEthernet 0/0/0 en R1 revela

que aunque la interfaz tiene una dirección IPv6, no es miembro del grupo multicast
All-IPv6-Routers FF02::2. Esto significa que el router no está habilitado como
router IPv6. Por eso no envía RA de ICMPv6 en esta interfaz.
Enrutamiento Ipv6 en R1 correcto
R1 está habilitado como un router IPv6 mediante el comando ipv6 unicast-

routing . El comando show ipv6 interface GigabitEthernet 0/0/0 verifica que R1
sea miembro de ff02::2, el grupo multicast All-IPV6-Routers.
Verifique que PC1 tiene un gateway predeterminado IPv6
Para verificar que la PC1 tenga configurado el gateway predeterminado, use el

comando ipconfig en la PC con Microsoft Windows o el comando netstat -r o ip
route en Linux y Mac OS X. La PC1 tiene una dirección IPv6 unicast global y un
gateway predeterminado IPv6. El gateway predeterminado se configura en la
dirección de enlace local del router R1, FE80::1.
Paso 5: Verificar la ruta correcta

Al resolver problemas, con frecuencia es necesario verificar la ruta hacia la red de
destino. En la figura, se muestra la topología de referencia que indica la ruta
deseada para los paquetes de la PC1 al SRV1.
Las tablas de enrutamiento IPv4 e IPv6 se pueden llenar con los siguientes
métodos:
 Redes conectadas directamente

 Host locales o rutas locales
 Rutas estáticas
 Rutas dinámicas
 Rutas predeterminadas
El proceso de reenvío de paquetes IPv4 e IPv6 se basa en la coincidencia más

larga de bits o de prefijos. El proceso de la tabla de enrutamiento intenta reenviar
el paquete mediante una entrada en la tabla de enrutamiento con el máximo
número de bits coincidentes en el extremo izquierdo. La longitud de prefijo de la
ruta indica el número de bits coincidentes.
La figura describe el proceso de las tablas de enrutamiento IPv4 e IPv6.
Examine los siguientes escenarios basados en el diagrama de flujo anterior. Si la dirección de destino en un
paquete:
 No coincide con una entrada en la tabla de enrutamiento, se usa la ruta predeterminada. Si no hay una ruta
predeterminada que esté configurada, se descarta el paquete.
 Coincide con una única entrada en la tabla de enrutamiento, el paquete se reenvía a través de la interfaz
definida en esta ruta.
 Coincide con más de una entrada en la tabla de enrutamiento y las entradas de enrutamiento tienen la misma
longitud de prefijo, los paquetes para este destino se pueden distribuir entre las rutas definidas en la tabla de
enrutamiento.
 Coincide con más de una entrada en la tabla de enrutamientoy las entradas de enrutamiento tienen longitudes
de prefijo diferentes, los paquetes para este destino se reenvían por la interfaz que está asociada a la ruta que
tiene la coincidencia de prefijos más larga.

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

Si la capa de red parece funcionar como se esperaba, pero los usuarios aún no
pueden acceder a los recursos, el administrador de red debe comenzar a resolver
problemas en las capas superiores. Dos de los problemas más frecuentes que
afectan la conectividad de la capa de transporte incluyen las configuraciones de
ACL y de NAT. Una herramienta frecuente para probar la funcionalidad de la capa
de transporte es la utilidad Telnet.
Precaución: Si bien se puede usar Telnet para probar la capa de transporte, por
motivos de seguridad se debe usar SSH para administrar y configurar los
dispositivos en forma remota.
Un administrador de red está solucionando un problema en el que no puede

conectarse a un router mediante HTTP. El administrador hace ping R2 como se
muestra en la salida del comando.
R1# ping 2001:db8:acad:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:2::2, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
R1#
R2 responde y confirma que la capa de red y todas las capas debajo de la capa de
red están operativas. El administrador sabe que el problema está en la capa 4 o en
las capas superiores y que debe comenzar a resolver problemas en esas capas.
A continuación, el administrador verifica que pueden hacer Telnet a R2 como se

muestra en el ejemplo
R1# telnet 2001:db8:acad:2::2
Trying 2001:DB8:ACAD:2::2 ... Open
User Access Verification
Password:
R2> exit
[Connection to 2001:db8:acad:2::2 closed by foreign host]
R1#
El administrador ha confirmado que los servicios Telnet se ejecutan en R2. Aunque

la aplicación de servidor Telnet se ejecute en su propio número de puerto 23
conocido y los clientes de Telnet se conecten a este puerto de manera
predeterminada, se puede especificar un número de puerto diferente en el cliente
para conectarse a cualquier puerto TCP que deba probarse. Usando un puerto
diferente a TCP port 23 indica si la conexión es aceptada, rechazada o termina por
falta de confirmación. A partir de cualquiera de estas respuestas, se pueden
obtener otras conclusiones relacionadas con la conectividad. En ciertas
aplicaciones, si usan un protocolo de sesión basado en ASCII (incluso pueden
mostrar un aviso de la aplicación), es posible desencadenar algunas respuestas
desde el servidor al escribir ciertas palabras clave, como con SMTP, FTP y HTTP.
Por ejemplo, el administrador intenta hacer Telnet a R2 usando el puerto 80.
R1# telnet 2001:db8:acad:2::2 80
Trying 2001:DB8:ACAD:2::2, 80 ... Open
^C
HTTP/1.1 400 Bad Request

Date: Mon, 04 Nov 2019 12:34:23 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request
[Connection to 2001:db8:acad:2::2 closed by foreign host]
R1#
Una vez más, en el resultado se verifica una conexión correcta de la capa de

transporte, pero R2 rechaza la conexión mediante el puerto 80.
Paso 7: Verificar las ACL

En los routers, puede haber ACL configuradas que prohíben a los protocolos
atravesar la interfaz en sentido entrante o saliente.
Use el comando show ip access-lists para visualizar el contenido de todas las

ACL de IPv4 y el comando show ipv6 access-list para visualizar el contenido de
todas las ACL de IPv6 configuradas en un router. Se puede visualizar una ACL
específica al introducir el nombre o el número de la ACL, como una opción de este
comando. Los comandos show ip interfaces y show ipv6 interfaces muestran la
información de interfaz IPv4 e IPv6 que indica si hay alguna ACL de IP establecida
en la interfaz.
Para prevenir los ataques de suplantación de identidad, el administrador de red

decidió implementar una ACL para evitar que los dispositivos con la dirección de
red de origen 172.16.1.0/24 ingresen a la interfaz de entrada S0/0/1 en el R3,
como se muestra en la figura Se debe permitir el resto del tráfico IP.
Sin embargo, poco después de implementar la ACL, los usuarios en la red
10.1.10.0/24 no podían conectarse a los dispositivos en la red 172.16.1.0/24,
incluido el SRV1
Paso 8: Verificar DNS
El protocolo DNS controla el DNS, una base de datos distribuida mediante la cual
se pueden asignar nombres de host a las direcciones IP. Cuando configura el DNS
en el dispositivo, puede reemplazar el nombre de host por la dirección IP con todos
los comandos IP, como ping o telnet.
Para visualizar la información de configuración de DNS en el switch o el router,

utilice el comando show running-config . Cuando no hay instalado un servidor
DNS, es posible introducir asignaciones de nombres a direcciones IP directamente
en la configuración del switch o del router. Utilice el comando ip host para
introducir un nombre que se utilizará en lugar de la dirección IPv4 del switch o
router, como se muestra en el ejemplo.
R1(config)# ip host ipv4-server 172.16.1.100
R1(config)# exit
R1#
Ahora se puede utilizar el nombre asignado en lugar de utilizar la dirección IP,

como se muestra en el ejemplo.
R1# ping ipv4-server
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms
R1#
Para visualizar la información de asignación de nombre a dirección IP en una

computadora con Windows, use el comando nslookup .
Qué aprendí en este módulo?

Documentación de red
La documentación de red común incluye: topologías de red físicas y lógicas,

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

 ¿Dónde ocurre la mayoría de los errores?
 ¿Qué parte de la red se usa con más frecuencia?
 ¿Qué parte de la red se usa con menos frecuencia?
 ¿Qué dispositivos deben monitorearse? ¿Qué umbrales de alerta deben
establecerse?
 ¿Puede la red cumplir con las políticas identificadas?
Al establecer la línea de base inicial, comience por seleccionar algunas variables

que representen a las políticas definidas, como la utilización de las interfaces y el
CPU. Un diagrama de topología lógica de la red puede ser útil en la identificación
de los dispositivos y los puertos principales que se van a supervisar. La duración y
la información que se recolecta, debe ser lo suficientemente larga para determinar
que se considera "normal" en la red. Al documentar la red, con frecuencia es
necesario recopilar información directamente de los routers y los
switches. show, ping, traceroute, y los comandos telnet.
Proceso de resolución de problemas

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

herramientas NMS, bases de conocimiento y herramientas de base de linea. Un
analizador de protocolos decodifica las diversas capas del protocolo en una trama
registrada y presenta esa información en un formato relativamente fácil de usar.
Las herramientas para la solución de problemas de hardware incluyen NAM,
multímetros digitales, comprobadores de cables, analizadores de cables y
analizadores de red portátiles. El servidor Syslog también se puede utilizar como
una herramienta de solución de problemas. Implementar una instalación de
registro es una parte importante de la seguridad y la resolución de problemas de
red. Los dispositivos de Cisco pueden registrar información relacionada con
cambios de configuración, infracciones de ACL, estado de interfaces y muchos
otros tipos de eventos. Los mensajes de evento se pueden enviar a una o varias
de las siguientes opciones: consola, líneas de terminal, registro en búfer, capturas
SNMP y syslog. Cuanto menor es el número del nivel, mayor es el nivel de
gravedad. El comando logging trap level se usa para limitar los mensajes
registrados en el servidor syslog según la gravedad. El nivel es el nombre o
número de nivel de la severidad. Solo se registran los mensajes de número igual o
menor que el nivel de especificado.
Síntomas y causas de problemas de red
Las fallas y las condiciones subóptimas en la capa física suelen provocar que las
redes fallen. Los administradores de red deben tener la capacidad de aislar y
corregir eficazmente los problemas en esta capa. Los síntomas incluyen un
rendimiento inferior al previsto, pérdida de conectividad, congestión, alta utilización
de CPU y mensajes de error de consola. Las causas suelen estar relacionadas con
la alimentación, fallas de hardware, fallas de cableado, atenuación, ruido, errores
de configuración de interfaz, excediendo los límites de diseño de componentes y
sobrecarga de CPU.
Los problemas de capa 2 causan síntomas específicos que, al reconocerse,

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

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

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

transporte funcionan, un problema en la capa de aplicación puede tener como
consecuencia recursos inalcanzables o inutilizables. Es posible que, teniendo una
conectividad de red plena, la aplicación simplemente no pueda proporcionar datos.
Otro tipo de problema en la capa de aplicación ocurre cuando las capas física, de
enlace de datos, de red y de transporte funcionan, pero la transferencia de datos y
las solicitudes de servicios de red de un único servicio o aplicación de red no
cumplen con las expectativas normales de un usuario.
Solucionar problemas de conectividad IP
Diagnosticar y resolver problemas es una aptitud esencial para los administradores

de red. No existe una única receta para la resolución de problemas, y un problema
en particular se puede diagnosticar de muchas maneras diferentes. Sin embargo,
al emplear un enfoque estructurado para el proceso de resolución de problemas,
un administrador puede reducir el tiempo que tarda en diagnosticar y resolver un
problema.
Generalmente, lo que da inicio a un esfuerzo de resolución de problemas es la

detección de un problema con la conectividad de extremo a extremo. Dos de las
utilidades comunes utilizadas para verificar un problema con la conectividad de
extremo a extremo son ping y traceroute. El comando ping utiliza un protocolo de
capa 3 que forma parte del conjunto TCP/IP denominado ICMP. El
comando traceroute suele ejecutarse cuando falla el comando ping .
Paso 1. Verificar la capa física Los comandos de Cisco IOS más utilizados para
este propósito son show processes cpu, show memory, y show interfaces.
Paso 2. Revisar las incompatibilidades de dúplex. Otra causa común de los errores
de interfaz es un modo de dúplex incompatible entre los dos extremos de un
enlace Ethernet. Actualmente, en numerosas redes basadas en Ethernet, las
conexiones punto a punto son la norma, y el uso de hubs y la operación half-
duplex asociadas se están volviendo menos frecuentes. Utilice el comando show
interfaces interface para diagnosticar este problema.
Paso 3. Verifique el direccionamiento en la red local. Al resolver problemas de

conectividad integral, es útil verificar las asignaciones entre las direcciones IP de
destino y las direcciones Ethernet de la capa 2 en los segmentos individuales. El
comando arp de Windows muestra y modifica las entradas en la caché ARP, que
se usan para almacenar las direcciones IPv4 y sus direcciones físicas de Ethernet
(MAC) resueltas. El comando netsh interface ipv6 show neighbor de Windows
enumera todos los dispositivos que están actualmente en el caché de la tabla de
detección de vecinos. El comando show ipv6 neighbors muestra un ejemplo de la
tabla de detección de vecinos en el router Cisco IOS. Use el comando show mac
address-table para visualizar la tabla de direcciones MAC en el switch.
Al resolver problemas de conectividad de extremo a extremo, otro problema que se

debe considerar es la asignación de VLAN. Utilice el comando arp de Windows
para ver la entrada de una puerta de enlace predeterminada. Utilice el
comando show mac address-table para comprobar la tabla MAC switch. Esto
puede mostrar que las asignaciones de VLAN no son correctas.
Paso 4. Verificar la puerta de enlace predeterminado. La salida del comando show

ip route Cisco IOS se utiliza para verificar la puerta de enlace predeterminada de
un router. En un host de Windows, el comando route print de Windows se utiliza
para verificar la presencia de la puerta de enlace predeterminada IPv4.
En IPv6, el gateway predeterminado puede configurarse manualmente con la

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

enrutamiento en función de la información de las tablas de enrutamiento. Utilice el
comando show ip route | begin Gateway para una tabla de enrutamiento IPv4.
Utilice el comando show ipv6 route para una tabla de enrutamiento IPv6.
Paso 6. Verificar la capa de transporte. Dos de los problemas más frecuentes que
afectan la conectividad de la capa de transporte incluyen las configuraciones de
ACL y de NAT. Una herramienta frecuente para probar la funcionalidad de la capa
de transporte es la utilidad Telnet.
Paso 7. Verificar las ACL Use el comando show ip access-lists para visualizar el
contenido de todas las ACL de IPv4 y el comando show ipv6 access-list para
visualizar el contenido de todas las ACL de IPv6 configuradas en un router.
Compruebe qué interfaz tiene aplicada la ACL mediante el comando show ip
interfaces .
Paso 8. Verifique el DNS. Para visualizar la información de configuración de DNS

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

Tema 12

Cargado por

Copyright:

Formatos disponibles

Tema 12

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 12

Cargado por

Copyright:

Formatos disponibles

TEMA 12.

- RESOLUCION DE PROBLEMAS DE RED

Bienvenido a la Resolución de problemas de red!

La verdad es que la única manera de convertirse en un buen solucionador de

¿Qué aprenderé en este módulo?

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

Título del tema Objetivo del tema

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

 Diagramas lógicos y físicos de topología de la red

Diagramas de topología de la red

Una topología física de la red muestra la distribución física de los dispositivos

 Nombre del dispositivo

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

Los diagramas de red de topología lógica muestran la conexión lógica de los

La información registrada en un diagrama de red lógico puede incluir lo siguiente:

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,

La figura muestra un ejemplo de topología lógica IPv6

Documentación de dispositivos de red

Documentación del router

La tabla muestra un ejemplo de la documentación de dos routers interconectados

Documentación del Switch LAN

Esta tabla muestra un ejemplo de la documentación de un Switch LAN.

Los archivos de configuración del sistema finales se centran en el hardware y el

En esta tabla se muestra un ejemplo de información que podría grabarse en un

Establecer una línea de base

Para establecer una línea de base de rendimiento de la red, es necesario reunir

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

 ¿Cómo funciona la red durante un día normal o promedio?

Medir el rendimiento y la disponibilidad inicial, de los dispositivos de red críticos,

Un análisis después de establecer una línea de base inicial también tiende a

Paso 1 - Determinar el tipo de

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

Al reducir la lista de puertos que se sondean, los resultados son concisos, y se

En la figura, se muestran ejemplos de varias capturas de pantalla de las

En este ejemplo, observe que las tendencias de la semana de trabajo son

Generalmente, las líneas de base no se deben extender durante más de seis

Las mediciones de una línea de base no se deben realizar durante momentos

Muestra la salida detallada de cada interfaz.

Muestra el de contenido de la tabla de enrutamiento de redes

La recolección manual de datos mediante los show comandos en dispositivos

Suele usarse software sofisticado de administración de redes para establecer

Establecer una línea de base inicial o realizar un análisis de monitoreo del

Procedimientos generales de resolución

Por lo tanto, el proceso de resolución de problemas debe guiarse por métodos

Existen varios procesos de resolución de problemas que se pueden usar para

Proceso de Siete Pasos para la

Mientras se recolectan los síntomas, es importante que el administrador de red

En una organización, los problemas suelen asignarse a los técnicos de red

Si el problema está fuera del límite de control de la organización (por ejemplo,

Las posibles causas deben ser identificadas. La información recopilada se

Eliminar posibles causas

Si se identifican múltiples causas, entonces la lista debe reducirse eliminando

Cuando se ha identificado la causa más probable, se debe formular una solución.

Antes de probar la solución, es importante evaluar el impacto y la urgencia del

Implementar la solución y verificar que haya resuelto el problema. A veces, una

Si la solución falla, se documenta la solución intentada y se eliminan los cambios.

Comunique a los usuarios y a todos los involucrados en el proceso de resolución

Hacer preguntas a usuarios finales.