MOD 12 - CCNA3 - Solución de Problemas de Red

Solución de problemas de red
¿Por qué debo tomar este módulo?

¡Bienvenido a la solució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 en la solución de problemas de red.
Probablemente son administradores experimentados, pero esa no es toda la historia. Los buenos
solucionadores de problemas de red generalmente hacen esto de una manera metódica y usan 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
resolver problemas. Se necesita tiempo para 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 para la solución de
problemas de red y todos los consejos y herramientas que necesita para comenzar. Este módulo también tiene
dos actividades de Packet Tracer realmente buenas para poner a prueba sus nuevas habilidades y
conocimientos. Tal vez su objetivo debería ser convertirse en el mejor administrador de red que alguien más ha
visto!
12.0.2
¿Qué aprenderé a hacer en este módulo?

Título del módulo:Solución de problemas de red
Objetivo del módulo: Solucionar problemas de redes empresariales.
Título del tema Objetivo del tema

Explique cómo se desarrolla y se utiliza la documentación de red para
Documentación de red
solucionar problemas de red.
Compare los métodos de solución de problemas que utilizan un enfoque
Proceso de solución de problemas
sistemático y por capas.
Herramientas de solución de problemas Describir diferentes herramientas de solución de problemas de red.
Determine los síntomas y las causas de los problemas de red mediante un
Síntomas y causas de problemas de red
modelo en capas.
Solución de problemas de conectividad
Solucione problemas de una red mediante el modelo en capas.
IP
Información general sobre la documentación

Al igual que con cualquier actividad compleja como la solución de problemas de red, deberá comenzar con una
buena documentación. Se requiere documentación de red precisa y completa para monitorear y solucionar
problemas de redes de manera efectiva.
La documentación de red común incluye lo siguiente:
 Diagramas de topología de red física y lógica

 Documentación del dispositivo de red que registra toda la información pertinente del dispositivo
 Documentación de línea base de rendimiento de red
Toda la documentación de red debe guardarse en una única ubicación, ya sea como copia impresa o en la red
en un servidor protegido. La documentación de copia de seguridad debe mantenerse y mantenerse en una
ubicación separada.
12.1.2
Diagramas de topología de red

Los diagramas de topología de red realizan un seguimiento 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 red: la topología física y la topología lógica.
Topología física
Una topología de red física muestra el diseño físico de los dispositivos conectados a la red. Necesita saber
cómo están conectados físicamente los dispositivos para solucionar problemas de capa física. 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)
 Interfaz y puertos utilizados
 Tipo de cable
La figura muestra un diagrama de topología de red física de ejemplo.
Topología lógica IPv4
Una topología de red lógica ilustra cómo los dispositivos están conectados lógicamente a la red. Esto se refiere
a cómo los dispositivos transfieren datos a través de la red al comunicarse con otros dispositivos. Los símbolos
se utilizan para representar componentes de red, como enrutadores, conmutadores, servidores y hosts.
Además, se pueden mostrar conexiones entre varios sitios, pero no representan ubicaciones físicas reales.
La información registrada en una topología de red lógica puede incluir lo siguiente:
 Identificadores de dispositivo
 Direcciones IP y longitudes de prefijo
 Identificadores de interfaz
 Protocolos de enrutamiento / rutas estáticas
 Información de capa 2 (es decir, VLAN, troncos, EtherChanneles)
La figura muestra una topología de red IPv4 lógica de ejemplo.
Topología lógica IPv6
Aunque las direcciones IPv6 también podrían mostrarse en la misma topología lógica IPv4, en aras de la
claridad, hemos creado una topología de red IPv6 lógica independiente.
La figura muestra una topología lógica IPv6 de ejemplo.

Documentación de dispositivos de red
La documentación del dispositivo de red debe contener registros precisos y actualizados del hardware y
software de la 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.
Router Device Documentation
The table displays sample network device documentation for two interconnecting routers.
Título de tabla
Dispositivo Modelo Descripción Ubicación IOS Licencia
Software del Cisco IOS XE, flash de la versión
ISR Enrutador de Edificio A ipbasek9
Central 16.09.04: isr4300-
4321 borde central Rm: 137 seguridadk9
universalk9_ias.16.09.04.SPA.bin
Interfaz Descripción Dirección IPv4 Dirección IPv6 Dirección MAC Enrutamiento
G0/0/0 Se conecta a SVR-1 10.0.0.1/30 2001:db8:acad:1::1/64 a03d.6fe1.e180 OSPF
Se conecta a
G0/0/1 10.1.1.1/30 2001:db8:acad:a001::1/64 a03d.6fe1.e181 OSPFv3
branch-1
G0/1/0 Se conecta al ISP 209.165.200.226/30 2001:db8:feed:1::2/64 a03d.6fc3.a132 Predeterminado
Se conecta a
S0/1/1 10.1.1.2/24 2001:db8:acad:2::1/64 n/d OSPFv3
Branch-2
Dispositivo Modelo Descripción Sitio IOS Licencia
Enrutador
ISR Edificio B Software del Cisco IOS XE, flash de la versión ipbasek9
Rama-1 perimetral de
4221 Rm: 107 16.09.04: isr4200-universalk9.16.09.04.SPA.bin seguridadk9
rama 2
Interfaz Descripción Dirección IPv4 Dirección IPv6 Dirección MAC Enrutamiento
Se conecta a
G0/0/0 Router-en-un-palo Router-en-un-palo a03d.6fe1.9d90 OSPF
S1
Se conecta a
G0/0/1 10.1.1.2/30 2001:db8:acad:a001::2/64 a03d.6fe1.9d91 OSPF
Central
Documentación del dispositivo del conmutador LAN
Esta tabla visualiza la documentación del dispositivo de muestra para un Switch LAN.
Título de tabla
Dirección IP de
Dispositivo Modelo Descripción IOS WT1
Mgt.
Cisco
Catalyst Conmutador
IOS: 15.0(2)SE7 Imagen: C2960- Dominio: Modo
S1 WS- LAN1 de rama 192.168.77.2/24
LANBASEK9-M CCNA: Servidor
C2960- 1
24TC-L
Puerto Descripción Acceso VLAN Baúl EtherChannel Nativo Habilitado
Trunk del canal de puerto 1
Fa0/1 - - Sí Canal de puerto 1 99 Sí
al S2 Fa0/1
Trunk del canal de puerto 1
Fa0/2 - - Sí Canal de puerto 1 99 Sí
al S2 Fa0/2
Fa0/3 No está en uso *** Sí 999 - - Cerrar
Fa0/5 Puerto de acceso al usuario Sí 10 - - Sí
... - - -
Fa0/24 Puerto de acceso al usuario Sí 20 - - Sí
G0/1 Enlace troncal a branch-1 - - Sí - 99 Sí
G0/2 No está en uso *** Sí 999 -
Archivos de documentación del sistema final
La documentación del sistema final se centra en el hardware y el software utilizados en servidores, consolas
de administración de red y estaciones de trabajo de usuario. Un sistema final configurado incorrectamente
puede tener un impacto negativo en el rendimiento general de una red. Por este motivo, tener acceso a la
documentación del dispositivo del sistema final puede ser muy útil al solucionar problemas.
Esta tabla muestra una muestra de información que se podría registrar en un documento de dispositivo del
sistema final.
Título de tabla
SISTEMA
Servicio Dirección Direcciones IPv4 / Puerta de enlace
Dispositivo OPERATIV DNS
s MAC IPv6 predeterminada
O
SMTP, 10.0.0.2/30 10.0.0.1 10.0.0.1
POP3,
MS Server Servicios 5475.d08e.9ad
SRV1 2001:db8:acad:1:: 2001:db8:acad:1::
2016 de 8 2001:db8:acad:1::2/64
archivos, 1 1
DHCP
Título de tabla
SISTEMA
Servicio Dirección Direcciones IPv4 / Puerta de enlace
Dispositivo OPERATIV DNS
s MAC IPv6 predeterminada
O
209.165.201.10 209.165.201.1 209.165.201.1
MS Server HTTP, 5475.d07a.531
SRV2 2001:db8:feed:1:: 2001:db8:feed:1::
2016 HTTPS 2 2001:db8:feed:1::10/64
1 1
192.168.10.10/24 192.168.10.1 192.168.10.1
MS Windows HTTP, 5475.d017.313
PC1 2001:db8:acad:1::251/6 2001:db8:acad:1:: 2001:db8:acad:1::
10 HTTPS 3
4 1 1
...
Establecer una línea de base de red

El propósito de la supervisión de red es observar el rendimiento de la red en comparación con una 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.
El establecimiento de una línea base de rendimiento de red requiere la recopilación de datos de rendimiento de
los puertos y dispositivos que son esenciales para el funcionamiento de la red.
Una línea base de red debe responder a las siguientes preguntas:
 ¿Cómo funciona la red durante un día normal o normal?

 ¿Dónde se producen más errores?
 ¿Qué parte de la red se utiliza más?
 ¿Qué parte de la red se utiliza menos?
 ¿Qué dispositivos deben supervisarse y qué umbrales de alerta deben establecerse?
 ¿Puede la red cumplir con las políticas identificadas?
La medición del rendimiento inicial y la disponibilidad de los dispositivos de red y vínculos críticos permite a un
administrador de red determinar la diferencia entre el comportamiento anormal y el rendimiento adecuado de la
red, a medida que la red crece o cambian los patrones de tráfico. La línea de base también proporciona
información sobre si el diseño de red actual puede satisfacer los requisitos empresariales. Sin una línea de
base, no existe ningún estándar para medir la naturaleza óptima del tráfico de red y los niveles de congestión.
El análisis después de una línea de base inicial también tiende a revelar problemas ocultos. Los datos
recopilados muestran la verdadera naturaleza de la congestión o la posible congestión en una red. También
puede revelar áreas en la red que están subutilizadas, y muy a menudo puede conducir a esfuerzos de rediseño
de la red, basados en observaciones de calidad y capacidad.
La línea base de rendimiento de red inicial establece el escenario para medir los efectos de los cambios de red
y los esfuerzos de solución de problemas posteriores. Por lo tanto, es importante planificarlo cuidadosamente.
Paso 1 - Determinar qué tipos de datos recopilar
Al realizar la línea base inicial, comience seleccionando algunas variables que representen las políticas
definidas. Si se seleccionan demasiados puntos de datos, la cantidad de datos puede ser abrumadora, lo que
dificulta el análisis de los datos recopilados. Comience de manera sencilla y afinar en el camino. Algunas
buenas variables de partida son la utilización de la interfaz y la utilización de la CPU.
Paso 2 - Identificar dispositivos y puertos de interés

Utilice la topología de red para identificar los dispositivos y puertos para los que se deben medir los datos de
rendimiento. Entre los dispositivos y puertos de interés se incluyen los siguientes:
 Puertos de dispositivo de red que se conectan a otros dispositivos de red

 Servidores
 Usuarios clave
 Cualquier otra cosa que se considere crítica para las operaciones
Una topología de red lógica puede ser útil para identificar los dispositivos y puertos clave que se deben
supervisar. En la figura, el administrador de red ha resaltado los dispositivos y puertos de interés para
monitorear durante la prueba de línea base.
Los dispositivos de interés incluyen PC1 (el terminal de administración) y los dos servidores (es decir, Srv1 y
Svr2). Los puertos del interés incluyen típicamente las interfaces del router y los puertos dominantes en el
Switches.
Al acortar la lista de puertos que se sondean, los resultados son concisos y se minimiza la carga de
administración de red. Recuerde que una interfaz en un router o un Switch puede ser una interfaz virtual, tal
como una interfaz virtual del Switch (SVI).
Paso 3 - Determinar la duración de la línea base

El período de tiempo y la información de línea de base que se recopila deben ser lo suficientemente largos
como para determinar una imagen "normal" de la red. Es importante que se supervisen las tendencias diarias
del tráfico de red. También es importante monitorear las tendencias que ocurren durante un período más largo,
como semanal o mensual. Por esta razón, al capturar datos para su análisis, el período especificado debe ser,
como mínimo, de siete días de duración.
La figura muestra ejemplos de varias capturas de pantalla de las tendencias de uso de cpu capturadas durante
un período diario, semanal, mensual y anual.
En este ejemplo, observe que las tendencias de la semana laboral son demasiado cortas para revelar el
aumento recurrente de la utilización cada fin de semana el sábado por la noche, cuando una operación de copia
de seguridad de la base de datos consume ancho de banda de red. Este patrón recurrente se revela en la
tendencia mensual. Una tendencia anual, como se muestra en el ejemplo, puede ser demasiado larga para
proporcionar detalles significativos de rendimiento de línea base. Sin embargo, puede ayudar a identificar
patrones a largo plazo que deben analizarse más a fondo.
Por lo general, una línea de base no debe durar más de seis semanas, a menos que sea necesario medir
tendencias específicas a largo plazo. En general, una línea de base de dos a cuatro semanas es adecuada.
Las mediciones de línea base no deben realizarse en momentos de patrones de tráfico únicos, porque los datos
proporcionarían una imagen inexacta de las operaciones normales de la red. Realizar un análisis anual de toda
la red, o línea de base diferentes secciones de la red sobre una base rotativa. El análisis debe realizarse
regularmente para comprender cómo la red se ve afectada por el crecimiento y otros cambios.
Medición de datos
Al documentar la red, a menudo es necesario recopilar información directamente de enrutadores y
conmutadores. Los comandos de documentación de red útiles obvios incluyen ping, traceroutey telnet, así
como comandos show.
La tabla enumera algunos de los comandos más comunes del Cisco IOS usados para la recopilación de datos.
Mandar Descripción
Muestra el tiempo de actividad, la información de versión para el software y el

show version hardware del dispositivo.
Muestra todas las opciones de configuración que se establecen en una

show ip interface interfaz.
[brief]
show ipv6 interface Utilice la palabra clave brief para visualizar solamente el estatus arriba/abajo
[brief] de las interfaces IP y la dirección IP de cada interfaz.
Muestra la salida detallada para cada interfaz.

Para visualizar la salida detallada para solamente una sola interfaz, incluya el
show interfaces
tipo y el número de la interfaz en el comando (e.g. Gigabit Ethernet 0/0/0).
Muestra la lista de contenido de la tabla de enrutamiento que enumera las

show ip route redes conectadas directamente y las redes remotas aprendidas.
show ipv6 route Añada los static, el eigrp,o el ospf para visualizar esas rutas solamente.
show cdp neighbors Visualiza la información detallada sobre los dispositivos vecinos de Cisco directamente
detail conectados.
show arp Muestra el contenido de la tabla ARP (IPv4) y la tabla de vecinos (IPv6).
show ipv6 neighbors
show running-config Muestra la configuración actual.
show vlan Visualiza el estatus de los VLA N en un Switch.
show port Muestra el estado de los puertos de un conmutador.
Este comando es útil para recopilar una gran cantidad de información sobre el
dispositivo con fines de solución de problemas.
show tech-support Ejecuta los comandos show múltiples que se pueden proporcionar a los
representantes de soporte técnico al señalar un problema
La recopilación manual de datos mediante comandos show en dispositivos de red individuales consume mucho
tiempo y no es una solución escalable. La recopilación manual de datos debe reservarse para redes más
pequeñas o limitarse a dispositivos de red de misión crítica. Para diseños de red más sencillos, las tareas de
línea base suelen utilizar una combinación de recopilación manual de datos e inspectores de protocolo de red
simples.
El software sofisticado de la administración de la red se utiliza típicamente para la línea de fondo las redes
grandes y complejas. Estos paquetes de software permiten a los administradores crear y revisar
automáticamente informes, comparar los niveles de performance actuales con las observaciones históricas,
identificar automáticamente los problemas de performance y crear 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 supervisión del rendimiento puede requerir muchas
horas o días para reflejar con precisión el rendimiento de la red. El software de administración de redes o los
inspectores y rastreadores de protocolos a menudo se ejecutan continuamente en el transcurso del proceso de
recopilación de datos.
Procedimientos generales de solución de problemas

La solució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 solución de problemas acortará el tiempo total de solución de problemas.
Por lo tanto, el proceso de solución de problemas debe guiarse por métodos estructurados. Esto requiere
procedimientos de solución de problemas bien definidos y documentados para minimizar el tiempo perdido
asociado con la solución de problemas errática de aciertos y errores. Sin embargo, estos métodos no son
estáticos. Los pasos de solución de problemas necesarios para resolver un problema no siempre son los
mismos o se ejecutan exactamente en el mismo orden.
Hay varios procesos de solución de problemas que se pueden utilizar para resolver un problema. La figura
muestra el diagrama de flujo lógico de un proceso simplificado de solució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 solución de problemas de siete pasos
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 ser capaces de saltar entre pasos en
función de su nivel de experiencia.
Definir el problema
El objetivo de esta etapa es verificar que hay un problema y, a continuación, 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 de red pueden aparecer en muchas formas diferentes, incluidas las alertas del
sistema de administración de red, los mensajes de la consola y las quejas de los usuarios.
Mientras se recopilan los síntomas, es importante hacer preguntas e investigar el problema con el fin de
localizar el problema a una gama más pequeña de posibilidades. Por ejemplo, ¿el problema está restringido a
un solo dispositivo, un grupo de dispositivos o una subred o red completa de dispositivos?
En una organización, los problemas se asignan normalmente a los técnicos de red como tickets de problemas.
Estos tickets se crean utilizando un software de tickets de problemas que rastrea el progreso de cada ticket. El
software 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 en la que se pueden realizar búsquedas,
capacidades de control remoto para resolver problemas del usuario final y más.
Recopilar información
En este paso, se deben identificar los objetivos (es decir, hosts, dispositivos) que se investigarán, se debe
obtener acceso a los dispositivos de destino y se debe recopilar información. Durante este paso, el técnico
puede recopilar y documentar más síntomas, dependiendo de las características que se identifiquen.
Si el problema está fuera del límite del control de la organización (por ejemplo, pérdida de conectividad a
Internet fuera del sistema autónomo), póngase en contacto con un administrador del sistema externo antes de
recopilar síntomas de red adicionales
Analizar información
Hay que identificar las posibles causas. La información recopilada se interpreta y analiza utilizando
documentación de red, líneas de base de red, búsqueda de bases de conocimiento organizacionales, búsqueda
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 posibles
causas para identificar eventualmente la causa más probable. La experiencia en la solución de problemas 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 al proponer un plan.
Hipótesis de prueba
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 debe sopesarse
contra el impacto de la solución. Por ejemplo, si un servidor o enrutador crítico debe estar sin conexión durante
una cantidad significativa de tiempo, puede ser mejor esperar hasta el final de la jornada laboral para
implementar la corrección. A veces, se puede crear una solución provisional hasta que se resuelva el problema
real.
Cree un plan de reversión que identifique cómo revertir rápidamente una solución. Esto puede resultar
necesario si la solución falla.
Implemente la solución y compruebe que ha 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 continuar con el siguiente
paso.
Si se produce un error en la solución, se documenta la solución intentada y se quitan los cambios. El técnico
ahora debe volver al paso recopilar información y aislar el problema.
Resolver el problema
Cuando se resuelva el problema, informe a los usuarios y a cualquier persona involucrada en el proceso de
solución de problemas que el problema se ha resuelto. Otros miembros del equipo de TI deben ser informados
de la solución. La documentación apropiada de la causa y de la corrección ayudará a otros técnicos de la ayuda
en la prevención y la solución de problemas similares en el futuro.
Preguntar a los usuarios finales

Muchos problemas de red son notificados inicialmente por un usuario final. Sin embargo, la información
proporcionada es a menudo vaga o engañosa. Por ejemplo, los usuarios a menudo informan de problemas
como "la red está caída", "No puedo acceder a mi correo electrónico" o "mi equipo es lento".
En la mayoría de los casos, se requiere información adicional para comprender completamente un problema.
Esto normalmente 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 nivel técnico que pueden 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 al
documentar un problema complejo.
 Siempre sea considerado y empatice con los usuarios mientras les hace saber que los ayudará a
resolver su problema. Los usuarios que informan de un problema pueden estar bajo estrés y ansiosos por
resolver el problema lo más rápido posible.
Al entrevistar al usuario, guíe la conversación y utilice técnicas de interrogatorio 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 pautas de preguntas y ejemplos de preguntas abiertas para el usuario final.
Cuando termine de entrevistar al usuario, repita su comprensión del problema al usuario para asegurarse de
que ambos están de acuerdo en el problema que se informa.
Directrices Ejemplo de preguntas abiertas para el usuario final
¿Qué no funciona?
Haga las preguntas pertinentes. ¿Cuál es exactamente el problema?
¿Qué estás tratando de lograr?
¿A quién afecta este problema? ¿Es solo usted u otros?

Determinar el alcance del
¿En qué dispositivo está sucediendo esto?
problema.
¿Cuándo se produce exactamente el problema?

Determinar cuándo se produjo / ¿Cuándo se notó el problema por primera vez?
se produce el problema. ¿Se ha mostrado algún mensaje de error?
¿Se puede reproducir el problema?

Determine si el problema es
¿Puedes enviarme una captura de pantalla o un video del problema?
constante o intermitente.
Determine si algo ha cambiado. ¿Qué ha cambiado desde la última vez que funcionó?
Utilice preguntas para eliminar o ¿Qué funciona?

descubrir posibles problemas. ¿Qué no funciona?
Recopilar información
Para recopilar los síntomas del dispositivo de red sospechoso, utilice los comandos cisco IOS y otras
herramientas tales como capturas de paquetes y registros del dispositivo.
La tabla describe los comandos comunes del Cisco IOS usados para recoger los síntomas de un problema de
red.
Mandar Descripción
Envía un paquete de solicitud de eco a una dirección y, a continuación,

espera una respuesta
ping {host | ip-address} La variable de dirección IP o host es el alias IP o la dirección IP del sistema
de destino
Identifica la ruta que toma un paquete a través de las redes

La variable de destino es el nombre de host o la dirección IP del sistema
traceroute destination
de destino
Se conecta a una dirección IP mediante la aplicación Telnet

telnet {host | ip-
address} Utilice SSH siempre que sea posible en lugar de Telnet
Se conecta a una dirección IP mediante SSH

ssh -l user-id ip-
address SSH es más seguro que Telnet
Muestra un estado de resumen de todas las interfaces de un dispositivo

show ip interface brief
Útil para identificar rápidamente el direccionamiento IP en todas las
show ipv6 interface
brief interfaces.
show ip route Muestra las tablas de enrutamiento IPv4 e IPv6 actuales, que contienen las rutas a
show ipv6 route todos los destinos de red conocidos
Visualiza los protocolos configurados y muestra el estatus global y interfaz-

show protocols específico de cualquier protocolo configurado de la capa 3
debug Muestra una lista de opciones para habilitar o deshabilitar eventos de depuración
Nota:Aunque el comando debug sea una herramienta importante para recoger los síntomas, genera una gran
cantidad de tráfico de mensajes de la consola y el funcionamiento de un dispositivo de red se puede afectar
perceptiblemente. Si el debug se debe realizar durante las horas de trabajo normales, advierta a los usuarios de
la red que un esfuerzo de Troubleshooting está en curso, y que el funcionamiento de la red puede ser afectado.
Recuerde deshabilitar la depuración cuando haya terminado.
Solución de problemas con modelos en capas

Los modelos OSI y TCP/IP se pueden aplicar para aislar problemas de red al solucionar problemas. Por
ejemplo, si los síntomas sugieren un problema de conexión física, el técnico de red puede centrarse en resolver
problemas el circuito que actúa en la capa física.
La figura muestra algunos dispositivos comunes y las capas OSI que se deben examinar durante el proceso de
troubleshooting para ese dispositivo.
Observe que los routers y los switches multicapa se muestran en la Capa 4, la capa de transporte. Aunque el
Routers y el Switches multicapa toman generalmente las decisiones de reenvío en la capa 3, los ACL en estos
dispositivos se pueden utilizar para tomar las decisiones de filtrado usando la información de la capa 4.
Métodos estructurados de solución de problemas

Hay varios enfoques de solución de problemas estructurados que se pueden utilizar. Cuál usar dependerá de la
situación. Cada enfoque tiene sus ventajas y desventajas. En este tema se describen métodos y se
proporcionan instrucciones para elegir el mejor método para una situación específica.
De abajo hacia arriba
En la solución de problemas ascendente, usted comienza con la capa física y los componentes físicos de la red
tal y como se muestra en de la figura, y se mueve hacia arriba a través de las capas del modelo OSI hasta que
se identifique la causa del problema.
La solución de problemas de abajo hacia arriba es un buen enfoque para usar cuando se sospecha que el
problema es físico. La mayoría de los problemas de red residen en los niveles inferiores, por lo que la
implementación del enfoque ascendente suele ser eficaz.
La desventaja con el acercamiento de Troubleshooting ascendente es que requiere que usted marque cada
dispositivo y interfaz en la red hasta que se encuentre la causa posible del problema. Recuerde que cada
conclusión y posibilidad debe estar documentada para que pueda haber una gran cantidad de papeles
asociados con este enfoque. Otro desafío es determinar qué dispositivos comenzar a examinar primero.
De arriba hacia abajo
Como se muestra en la figura, la solución de problemas de arriba hacia abajo comienza con las aplicaciones de
usuario final y se mueve hacia abajo a través de las capas del modelo OSI hasta que se ha identificado la causa
del problema.
Las aplicaciones de usuario final de un sistema final se prueban antes de abordar las piezas de red más
específicas. Utilice este enfoque para problemas más simples, o cuando usted piensa que el problema es con
una pieza de software.
La desventaja con el enfoque descendente es que requiere comprobar cada aplicación de red hasta que se
encuentre la posible causa del problema. Cada conclusión y posibilidad debe ser documentada. El reto consiste
en determinar qué solicitud se debe empezar a examinar primero.
Divide y vencerás
La figura muestra el enfoque de divide y vencerás para solucionar un problema de red.
El administrador de red selecciona una capa y prueba en ambas direcciones desde esa capa.
En la solución de problemas de divide y vencerás, comienza recopilando experiencias de usuario del problema,
documenta los síntomas y, a continuación, con esa información, realiza una conjetura informada sobre qué capa
OSI debe iniciar la investigación. Cuando se comprueba que una capa funciona correctamente, se puede
suponer que las capas inferiores están funcionando. El administrador puede trabajar hasta las capas OSI. Si
una capa OSI no funciona correctamente, el administrador puede trabajar hacia abajo en el modelo de capa
OSI.
Por ejemplo, si los usuarios no pueden acceder al servidor Web, pero pueden hacer ping al servidor, después el
problema está sobre la capa 3. Si hacer ping al servidor no tiene éxito, es probable que el problema se presente
en una capa OSI inferior.
Siga el camino
Esta es una de las técnicas de solución de problemas más básicas. El enfoque primero descubre la ruta de
tráfico desde el origen hasta el destino. El alcance del Troubleshooting se reduce a apenas los links y los
dispositivos que están en el trayecto de reenvío. El objetivo es eliminar los links y los dispositivos que son
inaplicables a la tarea de Troubleshooting en la mano. Este enfoque suele complementar uno de los otros
enfoques.
Sustitución
Este enfoque también se denomina swap-the-component porque se intercambia físicamente el dispositivo

problemático con uno conocido y de trabajo. Si se soluciona el problema, el problema es con el dispositivo
eliminado. Si el problema persiste, entonces la causa puede estar en otra parte.
En situaciones específicas, este puede ser un método ideal para la resolución rápida de problemas, como con
un único punto crítico de error. Por ejemplo, un router de borde deja de caer. Puede ser más beneficioso
simplemente reemplazar el dispositivo y restaurar el servicio, en lugar de solucionar el problema.
Si el problema se encuentra dentro de varios dispositivos, es posible que no sea posible aislar correctamente el
problema.
Comparación
Este enfoque también se denomina enfoque de detectar las diferencias e intenta resolver el problema
cambiando los elementos no operativos para que sean coherentes con los que funcionan. Puede comparar
configuraciones, versiones de software, hardware u otras propiedades, vínculos o procesos de dispositivos entre
situaciones de trabajo y no laborables y detectar diferencias significativas entre ellos.
La debilidad de este método es que podría conducir a una solución de trabajo, sin revelar claramente la causa
raíz del problema.
Conjetura
Este enfoque también se denomina enfoque de solución de problemas de disparos desde la cadera. Se trata de
un método de solución de problemas menos estructurado que utiliza una estimación informada 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 son más exitosos porque pueden confiar en su amplio conocimiento y
experiencia para aislar y resolver de manera decisiva los problemas de la red. Con un administrador de red con
menos experiencia, este método de solución de problemas puede ser demasiado aleatorio para ser eficaz.
Directrices para seleccionar un método de solución de

problemas
Para resolver rápidamente los problemas de red, tómese el tiempo para seleccionar el método de solución de
problemas de red más eficaz.
La figura ilustra qué método se podría utilizar cuando se descubre un determinado tipo de problema.
Por ejemplo, los problemas de software a menudo se resuelven utilizando un enfoque de arriba hacia abajo,
mientras que los problemas basados en hardware se resuelven utilizando el enfoque de abajo hacia arriba. Los
nuevos problemas pueden ser resueltos por un técnico experimentado utilizando el método divide y vencerás.
De lo contrario, se puede utilizar el enfoque ascendente.
La solución de problemas es una habilidad que se desarrolla al hacerlo. Cada problema de red que identifique y
resuelva se agrega a su conjunto de habilidades.
Herramientas de solución de problemas
Herramientas de solución de problemas de software
Como ustedes saben, las redes se componen de software y hardware. Por lo tanto, tanto el software como el
hardware tienen sus respectivas herramientas para solucionar problemas. En este tema se describen las
herramientas de solución de problemas disponibles para ambos.
Una amplia variedad de herramientas de software y hardware están disponibles para facilitar la solución de
problemas. Estas herramientas se pueden utilizar para recopilar y analizar los síntomas de los problemas de
red. A menudo proporcionan funciones de supervisión y generación de informes que se pueden utilizar para
establecer la línea de base de la red.
Herramientas del sistema de administración de redes
Las herramientas del sistema de administración de red (NMS) incluyen herramientas de supervisión,
configuración y administración de fallas a nivel de dispositivo. Estas herramientas se pueden utilizar para
investigar y corregir problemas de red. El software de monitoreo de red muestra gráficamente una vista física de
los dispositivos de red, lo que permite a los administradores de red monitorear dispositivos remotos de forma
continua y automática. El software de administración de dispositivos proporciona información dinámica sobre el
estado, las estadísticas y la configuración de los dispositivos de red. Busque en Internet "Herramientas NMS"
para obtener más información.
Bases de conocimiento
Las bases de conocimiento de los proveedores de dispositivos de red en línea se han convertido en fuentes
indispensables de información. Cuando las bases de conocimiento basadas en proveedores se combinan con
motores de búsqueda en Internet, un administrador de red tiene acceso a un vasto conjunto de información
basada en la experiencia.
Por ejemplo, las herramientas de Cisco & la página de los recursos se pueden encontrar
en http://www.cisco.com en el menú Soporte. Esta página proporciona las herramientas que se pueden utilizar
para el hardware y el software de Cisco.
Herramientas de línea base
Hay disponibles muchas herramientas para automatizar la documentación de la red y el proceso de línea de
base. Las herramientas de línea base ayudan con las tareas de documentación comunes. Por ejemplo, pueden
dibujar diagramas de red, ayudar a mantener actualizada la documentación de software y hardware de red y
ayudar a medir de forma rentable el uso del ancho de banda de red de línea base. Busque en Internet
"Herramientas de supervisión del rendimiento de la red" para obtener más información.
Analizadores de protocolo
Los analizadores de protocolos pueden investigar el contenido del paquete mientras fluyen a través de la red.
Un analizador de protocolos decodifica las distintas capas de protocolo en una trama grabada y presenta esta
información en un formato relativamente fácil de usar. La figura muestra una captura de pantalla del analizador
de protocolo Wireshark.
La información mostrada por un analizador de protocolos incluye los datos de bits de la capa física, la
información de la capa de vínculo de datos, los protocolos y las descripciones de cada trama. La mayoría de los
analizadores de protocolo pueden filtrar el tráfico que cumple ciertos criterios para que se pueda capturar todo el
tráfico hacia y desde un dispositivo. Los analizadores de protocolo como Wireshark pueden ayudar a solucionar
problemas de rendimiento de la red. Es importante tener una buena comprensión de TCP/IP y cómo utilizar un
analizador de protocolos para inspeccionar la información en cada capa TCP/IP.
Herramientas de solución de problemas de

hardware
Hay varios tipos de herramientas de solución de problemas de hardware.
Multímetros digitales
Los multímetros digitales (DMMs) son instrumentos de prueba que se utilizan para medir directamente los
valores eléctricos de voltaje, corriente y resistencia.
En la solución de problemas de red, la mayoría de las pruebas que necesitarían un multímetro implican la
comprobación de los niveles de voltaje de la fuente de alimentación y la verificación de que los dispositivos de
red están recibiendo energía.
Probadores de cables
Los probadores de cables son dispositivos portátiles especializados diseñados para probar los diversos tipos de
cableado de comunicación de datos. La figura muestra el Fluke LinkRunner AT Network Auto-Tester.
Los probadores de cables se pueden utilizar para detectar cables rotos, cableado cruzado, conexiones en
cortocircuito y conexiones emparejadas incorrectamente. Estos dispositivos pueden ser probadores de
continuidad de bajo costo, probadores de cableado de datos a precios moderados o reflectómetros de dominio
del tiempo (TDRs) costosos. Los TDR se utilizan para identificar la distancia a una rotura en un cable. Estos
dispositivos envían señales a lo largo del cable y esperan a que se reflejen. El tiempo entre el envío de la señal
y su recepción se convierte en una medición de distancia. La función TDR normalmente se empaqueta con
probadores de cableado de datos. Los TDR utilizados para probar los cables de fibra óptica se conocen como
reflectómetros ópticos de dominio del tiempo (OTDR).
Analizadores de cables
Los analizadores de cables son dispositivos portátiles multifuncionales que se utilizan para probar y certificar
cables de cobre y fibra para 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 la diafonía de extremo cercano (NEXT) o la pérdida de retorno
(RL), identifican acciones correctivas y muestran gráficamente el comportamiento de diafonía e impedancia. Los
analizadores de cables también suelen incluir software basado en PC. Una vez recopilados los datos de campo,
los datos del dispositivo de mano se pueden cargar para que el administrador de red pueda crear informes
actualizados.
Analizadores de red portátiles
Los dispositivos portátiles se utilizan para solucionar problemas de redes conmutadas y VLAN.
Al conectar el analizador de red en cualquier lugar de la red, un ingeniero de red puede ver el puerto del
conmutador al que está conectado el dispositivo y la utilización media y máxima. El analizador también se
puede utilizar para descubrir la configuración de VLAN, identificar a los principales interconectores de red (hosts
que generan la mayor parte del tráfico), analizar el tráfico de red y ver los detalles de la interfaz. Por lo general,
el dispositivo puede emitirse a un equipo que tiene instalado un software de supervisión de red para su posterior
análisis y solución de problemas.
Módulo de análisis de red de Cisco Prime
La cartera del Módulo de análisis de red de la prima de Cisco (NAM), mostrada en la figura, incluye el hardware
y el software para el análisis de rendimiento en los entornos del Switching y de ruteo. Incluye una interfaz
integrada basada en explorador que genera informes sobre el tráfico que consume recursos de red críticos.
Además, el NAM puede capturar y decodificar los paquetes y seguir los tiempos de respuesta para señalar un
problema de la aplicación a una red o a un servidor.
Servidor de Syslog como herramienta de

Troubleshooting
Syslog es un protocolo simple utilizado por un dispositivo IP conocido como cliente syslog, para enviar mensajes
de registro basados en texto a otro dispositivo IP, el servidor syslog. El Syslog se define actualmente en el RFC
5424.
La implementación de un recurso de registro es una parte importante de la seguridad de la red y para la

solución de problemas de red. Los dispositivos de Cisco pueden registrar la información con respecto a los
cambios de configuración, a las violaciones ACL, al estatus de la interfaz, y a muchos otros tipos de eventos.
Los dispositivos de Cisco pueden enviar los mensajes del registro a varias diversas instalaciones. Los mensajes
de eventos se pueden enviar a uno o varios de los siguientes elementos:
 Consola: el registro de la consola está activado de forma predeterminada. Los mensajes se registran en
la consola y se pueden ver al modificar o probar el enrutador o conmutador mediante el software de emulación
de terminal mientras está conectado al puerto de la consola del dispositivo de red.
 Líneas de terminal : las sesiones EXEC habilitadas se pueden configurar para recibir mensajes de
registro en cualquier línea de terminal. Al igual que el registro de consola, este tipo de registro no es
almacenado por el dispositivo de red y, por lo tanto, solo es valioso para el usuario en esa línea.
 Registro almacenado en búfer: el registro almacenado en 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 durante un tiempo. Sin
embargo, los mensajes de registro se borran cuando se reinicia el dispositivo.
 Snmp traps - Ciertos umbrales se pueden preconfigurar en el Routers y otros dispositivos. Los eventos
del enrutador, como superar un umbral, pueden ser procesados por el enrutador y reenviados como capturas
SNMP a una estación de administración de red SNMP externa. Las capturas SNMP son una instalación de
registro de seguridad viable, pero requieren la configuración y el mantenimiento de un sistema SNMP.
 Syslog - Los routeres y switches Cisco se pueden configurar para reenviar mensajes de registro a un
servicio 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. El Syslog es la facilidad de registro de mensajes
más popular, porque proporciona las capacidades de almacenamiento de registro a largo plazo y una ubicación
central para todos los mensajes del router.
Los mensajes del registro del Cisco IOS bajan en uno de ocho niveles, tal y como se muestra en de la tabla.
Nivel Palabra clave Descripción Definición
0 Emergencias El sistema es inutilizable LOG_EMERG
1 Alertas Es necesario adoptar medidas inmediatas LOG_ALERT
Nivel más alto 2 Crítico Existen condiciones críticas LOG_CRIT
3 Errores Existen condiciones de error LOG_ERR
4 Advertencias Existen condiciones de advertencia LOG_WARNING
5 Notificaciones Condición normal (pero significativa) LOG_NOTICE
Nivel más bajo 6 Informativo Sólo mensajes informativos LOG_NFO
7 Depuración Depuración de mensajes LOG_DEBUG

Cuanto menor sea el número de nivel, mayor será el nivel de gravedad. De forma predeterminada, todos los
mensajes del nivel 0 al 7 se registran en la consola. Mientras que la capacidad de ver los registros en un
servidor de Syslog central es provechosa en el troubleshooting, tamizar a través de una gran cantidad de datos
puede ser una tarea abrumadora. El comando logging trap level limita los mensajes registrados al servidor de
Syslog basado en la gravedad. El nivel es el nombre o el número del nivel de gravedad. Sólo se registran los
mensajes iguales o numéricamente inferiores al nivel especificado.
En la salida del comando, los mensajes del sistema del nivel 0 (emergencias) a 5 (notificaciones) se envían al
servidor de Syslog en 209.165.200.225.
R1(config)# logging host 209.165.200.225
R1(config)# logging trap notifications
R1(config)# logging on
R1(config)#
Solución de problemas de la capa física

Ahora que tiene su documentación, algunos conocimientos sobre los métodos de solución de problemas y las
herramientas de software y hardware que se deben usar 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 a menudo se presentan como problemas de rendimiento. Los problemas de
rendimiento significan que hay una diferencia entre el comportamiento esperado y el comportamiento
observado, y el sistema no funciona como se podría esperar razonablemente. Las fallas y las condiciones
subóptimas en la capa física no solo incomodan a los usuarios, sino que pueden afectar la productividad de toda
la empresa. Las redes que experimentan este tipo de condiciones generalmente se cierran. Dado que las capas
superiores del modelo OSI dependen de la capa física para funcionar, un administrador de red debe tener la
capacidad de aislar y corregir eficazmente los problemas en esta capa.
La figura resume los síntomas y las causas de los problemas de red de la capa física.
La tabla enumera los síntomas comunes de los problemas de red de la capa física.
Síntoma Descripción
Requiere líneas de base anteriores para la comparación.

Las razones más comunes para el rendimiento lento o pobre incluyen servidores
Rendimiento inferior a la
sobrecargados o con poca potencia, configuraciones inadecuadas de switch o enrutador,
línea de base
congestión de tráfico en un enlace de baja capacidad y pérdida crónica de trama.
La pérdida de conectividad podría deberse a un cable fallido o desconectado.

Se puede verificar utilizando una simple prueba de ping.
Pérdida de conectividad La pérdida de conectividad intermitente puede indicar una conexión suelta u
oxidada.
Si un router, una interfaz, o un cable falla, los Routing Protocol pueden reorientar el
Cuellos de botella o tráfico a otras rutas que no se diseñe para llevar la capacidad adicional.
congestión de la red Esto puede provocar congestión o cuellos de botella en partes de la red.
Las altas tasas de utilización de la CPU son un síntoma de que un dispositivo, como
un enrutador, conmutador o servidor, está funcionando con o superando sus límites de
Altas tasas de utilización diseño.
de la CPU Si no se soluciona rápidamente, la sobrecarga de la CPU puede hacer que un
dispositivo se apague o falle.
Los mensajes de error notificados en la consola del dispositivo podrían indicar un

Mensajes de error de la problema de capa física.
consola Los mensajes de la consola se deben registrar a un servidor de Syslog central.
En la tabla siguiente se enumeran los problemas que normalmente causan problemas de red en el nivel físico.
Causa del problema Descripción
Esta es la razón más fundamental para el error de red.

Compruebe el funcionamiento de los ventiladores y asegúrese de que la admisión del
Relacionados con la chasis y las salidas de escape estén despejadas.
energía Si otras unidades cercanas también se han apagado, sospeche que se ha producido un
fallo de alimentación en la fuente de alimentación principal.
Las tarjetas de interfaz de red (NIC) defectuosas pueden ser la causa de los errores de
transmisión de red debido a colisiones tardías, tramas cortas y jabber.
El Jabber se define a menudo como la condición en la cual un dispositivo de red
Errores de hardware transmite continuamente los datos al azar, sin sentido sobre la red.
Otras causas probables del jabber son archivos defectuosos o corruptos del driver NIC,
mal cableado, o problemas de puesta a tierra.
Fallos de cableado Muchos problemas se pueden corregir simplemente recomiendo cables que se han
desconectado parcialmente.
Al realizar una inspección física, busque cables dañados, tipos de cables inadecuados y
conectores RJ-45 mal engarzados.
Los cables sospechosos deben probarse o intercambiarse con un cable de
funcionamiento conocido.
La atenuación puede ser causada si la longitud de un cable excede el límite de diseño

para el medio, o cuando hay una conexión deficiente resultante 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 tren 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, radio
de la policía, seguridad del edificio y aviónica para el aterrizaje automatizado, diafonía (ruido
Ruido inducido por otros cables en la misma vía o cables adyacentes), cables eléctricos cercanos,
dispositivos con motores eléctricos grandes o cualquier cosa que incluya un transmisor más
potente que un teléfono celular.
Muchas cosas se pueden configurar mal en una interfaz para hacer que vaya abajo, tal
Errores de configuración como velocidad de reloj incorrecta, fuente de reloj incorrecta, e interfaz que no es girada.
de interfaz Esto provoca una pérdida de conectividad con segmentos de red conectados.
Un componente puede estar funcionando de manera subóptima en la capa física porque

se está utilizando más allá de las especificaciones o la capacidad configurada.
Superar los límites de Al resolver problemas este tipo de problema, llega a ser evidente que los recursos para
diseño el dispositivo están actuando en o cerca de la capacidad máxima y hay un aumento en el
número de errores de interfaz.
Los síntomas incluyen procesos con porcentajes elevados de utilización de la CPU,

caídas de la cola de entrada, rendimiento lento, tiempos de espera SNMP, ningún acceso
remoto, o servicios como DHCP, Telnet y ping son lentos o no responden.
En un Switch el siguiente podía ocurrir: spanning tree reconvergence, rebote de los
links EtherChannel, aleteo UDLD, fallas IP SLAs.
Sobrecarga de CPU Para el Routers, no podría haber actualizaciones de ruteo, aleteo de la ruta, o aleteo del
HSRP.
Una de las causas de la sobrecarga de la CPU en un router o switch es tráfico elevado.
Si una o más interfaces se sobrecargan regularmente con tráfico, considere la
posibilidad de rediseñar el flujo de tráfico en la red o actualizar el hardware.
Solución de problemas de capa de vínculo de datos

Resolver problemas los problemas de la capa 2 puede ser un proceso desafiando. La configuración y el
funcionamiento de estos protocolos son fundamentales para crear una red funcional y bien ajustada. Los
problemas de la capa 2 causan los síntomas específicos que, cuando están reconocidos, ayudarán a identificar
el problema rápidamente.
La figura resume los síntomas y las causas de los problemas de red de la capa de vínculo de datos.
La tabla enumera los síntomas comunes de los problemas de red de la capa de vínculo de datos.
Sin funcionalidad ni
Algunos problemas de la capa 2 pueden parar el intercambio de tramas a través de un link,
conectividad en la capa de
mientras que otros hacen solamente el funcionamiento de la red degradar.
red o superior
Hay dos tipos distintos de operación subóptima de la capa 2 que pueden ocurrir en una
red.
Primero, las tramas toman una trayectoria subóptima a su destino pero llegan haciendo
La red está operando por la red experimentar el uso inesperado del alto ancho de banda en los links.
debajo de los niveles de
En segundo lugar, algunas tramas se caen según lo identificado con las estadísticas del
rendimiento de referencia
contador de errores y los mensajes de error de la consola que aparecen en el Switch o el router.
Un ping extendido o continuo puede ayudar a revelar si se están descartando tramas.
Los sistemas operativos utilizan difusiones y multidifusiones ampliamente para

descubrir servicios de red y otros hosts.
Generalmente, las difusiones excesivas son el resultado de aplicaciones mal
Emisiones excesivas
programadas o configuradas, de un dominio de broadcast grande de la capa 2, o de un problema
de red subyacente (e.g., loopes STP o aleteo de la ruta).
Un router reconoce que ha ocurrido un problema de la capa 2 y envía los mensajes de

alerta a la consola.
Típicamente, un router hace esto cuando detecta un problema con la interpretación de
las tramas entrantes (encapsulación o problemas de trama) o cuando se espera el Keepalives pero
Mensajes de consola
no llega.
El mensaje más común de la consola que indica un problema de la capa 2 es un mensaje
de abajo del Line Protocol
La tabla enumera los problemas que normalmente causan problemas de red en la capa de vínculo de datos.
Un error de encapsulación ocurre porque los bits colocados en un campo por el

remitente no son lo que el receptor espera ver.
Errores de encapsulación Esta condición ocurre cuando la encapsulación en un extremo de un link PÁLIDO se
configura diferentemente de la encapsulación usada en el otro extremo.
En las topologías, tales como Ethernet de punto a multipunto o broadcast, es esencial

que una dirección de destino apropiada de la capa 2 esté dada a la trama. Esto asegura su llegada
al destino correcto.
Para alcanzar esto, el dispositivo de red debe hacer juego un direccionamiento de la capa
3 de destino con el direccionamiento correcto de la capa 2 usando las correspondencias estáticas
Errores de asignación de o dinámicas.
direcciones En un entorno dinámico, la asignación de la información de la capa 2 y de la capa 3
puede fallar porque los dispositivos se pueden haber configurado específicamente para no
responder a las peticiones ARP, la información de la capa 2 o de la capa 3 que se oculta pudo
haber cambiado físicamente, o las respuestas ARP inválidas se reciben debido a un
misconfiguration o a un ataque de seguridad.
Las tramas suelen funcionar en grupos de bytes de 8 bits.

Un error de trama se produce cuando una trama no termina en un límite de bytes de 8
bits.
Cuando esto sucede, el receptor puede tener problemas para determinar dónde termina
una trama y se inicia otra trama.
Errores de trama Demasiadas tramas no válidas pueden impedir que se intercambien keepalives válidos.
Los errores de trama se pueden causar por una línea serial ruidosa, un cable
incorrectamente diseñado (demasiado largo o no blindado correctamente), nic defectuoso,
discordancia dúplex, o un reloj de línea incorrectamente configurado de la Unidad de servicio de
canal (CSU).
El propósito del Spanning Tree Protocol (STP) es resolver una topología física
redundante en un árbol-como la topología bloqueando los puertos redundantes.
La mayoría de los problemas STP se relacionan con los loopes de reenvío que ocurren
cuando no se bloquea ningún puerto en una topología redundante y el tráfico se remite en
círculos indefinidamente. Esto causa la inundación excesiva debido a una alta tasa de cambios de
la topología STP.
Un cambio de topología debe ser un evento poco frecuente en una red bien configurada.
Cuando un link entre dos Switches sube o baja, hay eventual un cambio de la topología
Errores o bucles STP
cuando el estado STP del puerto está cambiando a o de la expedición.
Sin embargo, cuando un puerto está agitando (oscilando entre arriba y abajo de los
estados), esto causa los cambios repetitivos de la topología y la inundación, o la convergencia o
la re-convergencia STP lenta.
Esto se puede causar por una discordancía entre la topología real y documentada, un
error de configuración, tal como una configuración incoherente de los temporizadores STP, un
Switch sobrecargado CPU durante la convergencia, o un defecto de software.
Solución de problemas de capa de red

Los problemas de la capa de red incluyen cualquier problema que implique un protocolo de la capa 3, tal como
IPv4, IPv6, EIGRP, OSPF, etc. La figura resume los síntomas y las causas de los problemas de red de capa de
red.
En la tabla se enumeran los síntomas comunes de los problemas de red de la capa de red.
El error de red es cuando la red es casi o completamente no funcional, lo que afecta a

todos los usuarios y aplicaciones de la red.
Error de red Estos fallos suelen ser notado rápidamente por los usuarios y administradores de red y
son obviamente críticos para la productividad de una empresa.
Los problemas de optimización de red suelen implicar un subconjunto de usuarios,

aplicaciones, destinos o un tipo de tráfico.
Los problemas de optimización pueden ser difíciles de detectar y aún más difíciles de
Rendimiento subóptimo aislar y diagnosticar.
Esto se debe a que normalmente implican varias capas, o incluso un único equipo host.
Determinar que el problema es un problema de capa de red puede llevar tiempo.
En la mayoría de las redes, las Static rutas se utilizan conjuntamente con los Dynamic Routing Protocol. La
configuración incorrecta de las Static rutas puede llevar a la encaminamiento menos que óptima. En algunos
casos, las Static rutas mal configuradas pueden crear los Loopes de ruteo que hacen las partes de la red
inalcanzables.
La resolución de problemas de los Protocolos de enrutamiento dinámico requiere una comprensión completa de
cómo funciona el Protocolo de enrutamiento específico. Algunos problemas son comunes a todos los Routing
Protocol, mientras que otros problemas son particulares al Routing Protocol individual.
No hay una sola plantilla para resolver los problemas de la capa 3. Los problemas de enrutamiento se resuelven
con un proceso metódico, utilizando una serie de comandos para aislar y diagnosticar el problema.
La tabla enumera las áreas a explorar al diagnosticar un problema posible que implica los Routing Protocol.
A menudo, un cambio en la topología, como un vínculo descendente, puede tener efectos

en otras áreas de la red que podrían no ser obvios en ese momento.
Esto puede incluir la instalación de nuevas rutas, estáticas o dinámicas, o la eliminación
Problemas generales de red de otras rutas.
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, incluidos problemas de energía

como cortes y problemas ambientales (por ejemplo, sobrecalentamiento).
Problemas de conectividad También marque si hay problemas de la capa 1, tales como problemas de cableado,
puertos defectuosos, y problemas ISP.
Compruebe en la tabla de enrutamiento si hay algo inesperado, como rutas que faltan o
rutas inesperadas.
Tabla de ruteo Utilice los comandos debug de ver las actualizaciones de ruteo y el mantenimiento de la
tabla de ruteo.
Si el Routing Protocol establece una adyacencia con un vecino, marque para ver si hay algún
Problemas de vecinos
problema con el Routers que forma las adyacencias vecinas.
Si el protocolo de enrutamiento utiliza una tabla de topología o una base de datos, compruebe si
Base de datos de topología
hay algo inesperado en la tabla, como entradas que faltan o entradas inesperadas.
Solución de problemas de la capa de transporte: ACL

Los problemas de red pueden surgir de problemas de capa de transporte en el enrutador, especialmente en el
borde de la red donde se examina y modifica el tráfico. Por ejemplo, las listas de control de acceso (ACL) y 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.
Los problemas más comunes con los ACL son causados por la configuración incorrecta, tal y como se muestra
en de la figura.
Los problemas con las ACL pueden hacer que los sistemas que funcionan de otro modo fallaran. La tabla
enumera las áreas en las que normalmente se producen configuraciones incorrectas.
Título de tabla
Configuraciones
Descripción
incorrectas
El tráfico es definido por la interfaz del router a través de la cual el tráfico está
viajando y la dirección en la cual este tráfico está viajando.
Selección del flujo de
Un ACL se debe aplicar a la interfaz correcta, y la dirección de tráfico correcta se
tráfico
debe seleccionar para funcionar correctamente.
Las entradas en un ACL deben ser de específico a general.

Aunque un ACL pueda tener una entrada para permitir específicamente un tipo de
flujo de tráfico, los paquetes nunca hacen juego esa entrada si están siendo negados por otra
entrada anterior en la lista.
Si el router está ejecutando los ACL y el NAT, la orden en la cual cada una de estas
Orden de las entradas de
tecnologías se aplica a un flujo de tráfico es importante.
control de acceso
El tráfico entrante es procesado por la ACL entrante antes de ser procesado por nat
de fuera a dentro.
El tráfico saliente es procesado por el ACL saliente después de ser procesado por el
NAT de dentro a fuera.
Denegar implícitamente Cuando la alta Seguridad no se requiere en el ACL, este elemento implícito del control de
cualquier acceso puede ser la causa de un misconfiguration ACL.
Las máscaras comodín IPv4 complejas proporcionan mejoras significativas en la

eficiencia, pero están más sujetas a errores de configuración.
Direcciones y máscaras Un ejemplo de una máscara comodín compleja es utilizar la dirección IPv4 10.0.32.0
comodín IPv4 y la máscara comodín 0.0.32.15 para seleccionar las primeras 15 direcciones de host en la red
10.0.0.0 o la red 10.0.32.0.
Título de tabla
Configuraciones
Descripción
incorrectas
Al configurar las ACL, es importante que solo se especifiquen los protocolos de capa
de transporte correctos.
Muchos administradores de red, cuando no están seguros de si un tipo de flujo de
tráfico utiliza un puerto TCP o un puerto UDP, configuran ambos.
Selección del protocolo de
Especificar ambos abre un agujero a través del firewall, posiblemente dando a los
capa de transporte
intrusos una avenida en la red.
También introduce un elemento adicional en la ACL, por lo que la ACL tarda más en
procesarse, introduciendo más latencia en las comunicaciones de red.
El control adecuado del tráfico entre dos hosts requiere elementos de control de
acceso simétricos para las ACL entrantes y salientes.
Puertos de origen y La información de dirección y puerto para el tráfico generado por un host que
destino responde 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 proporcionada por una ACL.

Uso de la palabra clave Sin embargo, si la palabra clave se aplica incorrectamente, pueden producirse
establecida resultados inesperados.
Las ACL mal configuradas a menudo causan problemas para protocolos distintos de
TCP y UDP.
Protocolos poco comunes Los protocolos poco comunes que están ganando popularidad son vpn y protocolos
de cifrado.
La palabra clave log es un comando útil para ver la operación ACL en las entradas ACL. Esta palabra clave da
instrucciones al router para poner una entrada en el registro del sistema siempre que se haga juego esa
condición de la entrada. El evento registrado incluye detalles del paquete que coincide con el elemento ACL. La
palabra clave log es especialmente útil para solucionar problemas y proporciona información sobre los intentos
de intrusión bloqueados por la ACL.
Solución de problemas de la capa de transporte: NAT

para IPv4
Hay varios problemas con NAT, como no interactuar con servicios como DHCP y tunelización. Éstos pueden
incluir el NAT mal configurado adentro, el NAT fuera, o los ACL. Otros problemas incluyen la interoperabilidad
con otras tecnologías de red, especialmente aquellas que contienen o derivan información del direccionamiento
de red del host en el paquete.
La figura resume las áreas de interoperabilidad comunes con NAT.

La tabla enumera las áreas de interoperabilidad comunes con NAT.
Protocolo Descripción
Ambos protocolos administran la asignación automática de direcciones IPv4 a los

clientes.
Recuerde que el primer paquete que envía un nuevo cliente es un paquete IPv4 de
difusión de solicitud DHCP.
El paquete dhcp-request tiene un direccionamiento del IPv4 de la fuente de 0.0.0.0.
BOOTP y DHCP Debido a que NAT requiere una dirección IPv4 de destino y de origen válida, BOOTP
y DHCP pueden tener dificultades para funcionar a través de un enrutador que ejecuta NAT
estática o dinámica.
La configuración de la característica auxiliar de IPv4 puede ayudar a resolver este
problema.
Porque un router que ejecuta el NAT dinámico está cambiando la relación entre los
direccionamientos interiores y exteriores regularmente mientras que las entradas de la tabla
expiran y se vuelven a crear, un servidor DNS fuera del router NAT no tiene una representación
DNS exacta de la red dentro del router.
problema.
Al igual que los paquetes DNS, NAT no puede alterar la información de

direccionamiento almacenada en la carga útil de datos del paquete.
Debido a esto, una estación de administración SNMP en un lado de un router NAT
SNMP puede no poder ponerse en contacto con los agentes SNMP en el otro lado del router NAT.
problema.
Los protocolos de cifrado y tunelización a menudo requieren que el tráfico se origine

Protocolos de túnel y desde un puerto UDP o TCP específico, o que usen un protocolo en el nivel de transporte que
cifrado NAT no pueda procesar.
Protocolo Descripción
Por ejemplo, nat no puede procesar los protocolos de túnel IPsec y los protocolos de
encapsulación de enrutamiento genéricos utilizados por las implementaciones de VPN.
Solución de problemas de la capa de aplicación

La mayoría de los protocolos de capa de aplicación proporcionan servicios de usuario. Los protocolos de capa
de aplicación se utilizan normalmente para la administración de redes, la transferencia de archivos, los servicios
de archivos distribuidos, la emulación de terminales y el correo electrónico. A menudo se agregan nuevos
servicios de usuario, como VPN y VoIP.
La figura muestra los protocolos de capa de aplicación TCP/IP más conocidos e implementados.
La tabla proporciona una breve descripción de estos protocolos de capa de aplicación.
Aplicaciones Descripción
SSH/Telnet Permite a los usuarios establecer conexiones de sesión de terminal con hosts remotos.
Admite el intercambio de texto, imágenes gráficas, sonido, vídeo y otros archivos multimedia en
HTTP
la web.
FTP Realiza transferencias de archivos interactivas entre hosts.
Realiza transferencias de archivos interactivas básicas normalmente entre hosts y dispositivos de
TFTP
red.
SMTP Admite servicios básicos de entrega de mensajes.
POP Se conecta a servidores de correo y descarga correo electrónico.
SNMP Recopila información de administración de dispositivos de red.
Aplicaciones Descripción
DNS Asigna direcciones IP a los nombres asignados a los dispositivos de red.
Permite a los equipos montar unidades en hosts remotos y operarlas como si fueran unidades
Sistema de archivos de red locales. Originalmente desarrollado por Sun Microsystems, se combina con otros dos protocolos
(NFS) de capa de aplicación, representación de datos externos (XDR) y llamada a procedimiento
remoto (RPC), para permitir el acceso transparente a los recursos de red remotos.
Los tipos de síntomas y causas dependen de la propia aplicación real.
Los problemas de la capa de aplicación impiden que se proporcionen servicios a los programas de aplicación.
Un problema en el nivel de aplicación puede dar lugar a recursos inalcanzables o inutilizables cuando las capas
físicas, de vínculo de datos, de red y de transporte son funcionales. Es posible tener conectividad de red
completa, pero la aplicación simplemente no puede proporcionar datos.
Otro tipo de problema en la capa de aplicación se produce cuando las capas física, de vínculo de datos, de red
y de transporte son funcionales, pero la transferencia de datos y las solicitudes de servicios de red desde un
único servicio de red o aplicación no cumplen las expectativas normales de un usuario.
Un problema en la capa de aplicación puede hacer que los usuarios se quejen de que la red o una aplicación
con la que están trabajando es lenta o más lenta de lo habitual al transferir datos o solicitar servicios de red.
Solución de problemas de conectividad IP
Componentes de la solución de problemas de

conectividad de un extremo a otro
En este tema se presenta una topología única y las herramientas para diagnosticar y, en algunos casos,
resolver un problema de conectividad de un extremo a otro. Diagnosticar y resolver problemas es una habilidad
esencial para los administradores de red. No hay una receta única para la solución de problemas, y un problema
se puede diagnosticar de muchas maneras. Sin embargo, mediante el empleo de un enfoque estructurado para
el proceso de solución de problemas, un administrador puede reducir el tiempo que se tarda en diagnosticar y
resolver un problema.
En este tema, se usa el siguiente escenario. El host de cliente PC1 no puede tener acceso a las aplicaciones en
el servidor SRV1 o servidor SRV2. La figura muestra la topología de esta red. PC1 utiliza SLAAC con EUI-64
para crear su dirección de unidifusión global IPv6. EUI-64 crea el ID de interfaz utilizando la dirección MAC
ethernet, insertando FFFE en el centro y volteando el séptimo bit.
Cuando no hay conectividad de un extremo a otro y el administrador elige solucionar problemas con un enfoque
ascendente, los siguientes son pasos comunes que puede realizar el administrador:
Paso 1. Compruebe la conectividad física en el punto donde se detiene la comunicación de red. Esto incluye
cables y hardware. El problema pudo estar con un cable o una interfaz defectuosos, o implicar hardware mal
configurado o defectuoso.
Paso 2. Marque para ver si hay discordancias dúplex.
Paso 3. Compruebe el enlace de datos y el direccionamiento de la capa de red en la red local. Esto incluye
tablas ARP IPv4, tablas de vecinos IPv6, tablas de direcciones MAC y asignaciones de VLAN.
Paso 4. Compruebe que la puerta de enlace predeterminada es correcta.
Paso 5. Asegúrese de que los dispositivos están determinando la trayectoria correcta de la fuente al destino.
Manipule la información de enrutamiento si es necesario.
Paso 6. Compruebe que la capa de transporte funciona correctamente. Telnet también se puede utilizar para
probar las conexiones de capa de transporte desde la línea de comandos.
Paso 7. Verifique que no haya ACL que bloquean el tráfico.
Paso 8. Asegúrese de que la configuración de DNS es correcta. Debe haber un servidor DNS que sea
accesible.
El resultado de este proceso es la conectividad operativa de extremo a extremo. Si se han realizado todos los
pasos sin ninguna resolución, es posible que el administrador de red desee repetir los pasos anteriores o remitir
el problema a un administrador sénior.
El problema de conectividad de extremo a extremo

inicia la solución de problemas
Por lo general, lo que inicia un esfuerzo de solución de problemas es la detección de que hay un problema con
la conectividad de extremo a extremo. Dos de las utilidades más comunes usadas para verificar un problema
con la Conectividad de punta a punta son ping y traceroute,tal y como se muestra en de la figura.
Ping IPv4
El ping es probablemente la utilidad de prueba de conectividad más extensamente conocida en la red y ha sido
siempre parte del Cisco IOS Software. Envía solicitudes de respuestas desde una dirección de host
especificada. El comando ping utiliza un protocolo de capa 3 que forma parte del conjunto de aplicaciones
TCP/IP denominado ICMP. Ping utiliza 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. Ping se puede utilizar para verificar la conectividad de extremo a extremo para IPv4 e IPv6. La salida del
comando muestra un ping acertado del PC1 al SRV1, en la dirección 172.16.1.100.
C:\> ping 172.16.1.100

Pinging 172.16.1.100 with 32 bytes of data:
Reply from 172.16.1.100: bytes=32 time=199ms TTL=128
Ping statistics for 172.16.1.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 193ms, Maximum = 199ms, Average = 195ms
C:\>
Traceroute del IPv4
Como el comando ping, el comando traceroute del Cisco IOS se puede utilizar para el IPv4 y el IPv6. El
comando tracert se utiliza con los sistemas operativos Windows. La traza genera una lista de saltos,
direcciones IP del router y la dirección IP de destino que se alcanzan con éxito a lo largo de la trayectoria. Esta
lista proporciona información importante sobre la verificación y la solución de problemas. Si los datos alcanzan
el destino, la traza enumera la interfaz en cada router en la trayectoria. Si los datos fallan en un cierto salto a lo
largo de la manera, el direccionamiento del router más pasado que respondió a la traza se sabe. Esta dirección
es una indicación de dónde reside el problema o las restricciones de seguridad.
La salida del tracert ilustra la trayectoria que los paquetes del IPv4 toman para alcanzar su destino.
C:\> tracert 172.16.1.100
Tracing route to 172.16.1.100 over a maximum of 30 hops:

1 1 ms <1 ms <1 ms 10.1.10.1
2 2 ms 2 ms 1 ms 192.168.1.2
3 2 ms 2 ms 1 ms 192.168.1.6
4 2 ms 2 ms 1 ms 172.16.1.100
Trace complete.
C:\>
Ping y traceroute del IPv6
Al usar estas utilidades, la utilidad del Cisco IOS reconoce si el direccionamiento es un direccionamiento del
IPv4 o del IPv6 y utiliza el protocolo apropiado para probar la Conectividad. La salida del comando muestra los
comandos ping y traceroute en el r1 del router usado para probar la Conectividad del IPv6.
R1# ping 2001:db8:acad:4::100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:4::100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R1#
R1# traceroute 2001:db8:acad:4::100
Tracing the route to 2001:DB8:ACAD:4::100
1. 2001:DB8:ACAD:2::2 20 msec 20 msec 20 msec

2. 2001:DB8:ACAD:3::2 44 msec 40 msec 40 msec
R1#
Nota: El comando traceroute se realiza comúnmente cuando el comando ping falla. Si el ping tiene éxito, el
comando traceroute no es comúnmente necesario porque el técnico sabe que existe la Conectividad.
Paso 1 - Verificar la capa física

Todos los dispositivos de red son sistemas informáticos especializados. Como mínimo, estos dispositivos
constan de una CPU, RAM y espacio de almacenamiento, lo que permite al dispositivo arrancar y ejecutar el
sistema operativo y las interfaces. Esto permite la recepción y transmisión del tráfico de 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 comprobar el funcionamiento de estos componentes genéricos.
Los comandos cisco IOS más de uso general para este propósito son cpu de los procesos de la
demostración,memoria de la demostración,y interfaces de la demostración. En este tema se describe el
comando show interfaces.
Cuando los problemas relacionados con el rendimiento y el hardware se sospechan para estar culpables, el
comando show interfaces se puede utilizar para verificar las interfaces a través de las cuales el tráfico pasa.
Refiera a la salida del comando del comando show interfaces.
R1# show interfaces GigabitEthernet 0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is d48c.b5ce.a0c0(bia d48c.b5ce.a0c0)
Internet address is 10.1.10.1/24
(Output omitted)
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
85 packets input, 7711 bytes, 0 no buffer
Received 25 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 5 multicast, 0 pause input
10112 packets output, 922864 bytes, 0 underruns
0 output errors, 0 collisions, l interface resets
11 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R1#
Caídas de la cola de entrada
Los descensos de la cola de entrada (y los contadores ignorados y del acelerador relacionados) significan que
en algún momento, más tráfico fue entregado al router que podría procesar. Esto no indica necesariamente un
problema. Eso podría ser tráfico normal durante los períodos pico. Sin embargo, podría ser una indicación que
el CPU no puede procesar los paquetes a tiempo, así que si este número es constantemente alto, vale el valor
intentar detectar en qué momentos estos contadores están aumentando y cómo esto se relaciona con el uso de
la CPU.
Caídas de la cola de salida
Los descensos de la cola de salida indican que los paquetes fueron caídos debido a la congestión en la interfaz.
Ver las caídas de salida es normal para cualquier punto donde el tráfico de entrada agregado sea más alto que
el tráfico de salida. Durante los períodos de tráfico máximo, se caen los paquetes si el tráfico se entrega a la
interfaz más rápidamente que puede ser enviado. Sin embargo, incluso si esto se considera comportamiento
normal, lleva al descenso del paquete y a los retardos que hace cola, así que las aplicaciones que son sensibles
a ésos, tales como VoIP, pudieron sufrir de los problemas de rendimiento. Ver constantemente los descensos
de la cola de salida puede ser un indicador que usted necesita implementar un mecanismo de colocación en
cola avanzado para implementar o para modificar QoS.
Errores de entrada
Los errores de entrada indican los errores que se experimentan durante la recepción de la trama, tales como
errores CRC. Un gran número de errores CRC podría indicar problemas de cableado, problemas de hardware
de interfaz o, en una red basada en Ethernet, discordancias dúplex.
Errores de salida
Los errores de salida indican errores, como colisiones, durante la transmisión de una trama. En la mayoría de
las redes basadas en Ethernet hoy en día, la transmisión full-duplex es la norma, y la transmisión semidúplex es
la excepción. En la transmisión full-duplex, las colisiones de la operación no pueden ocurrir; por lo tanto, las
colisiones (especialmente las colisiones tardías) indican a menudo discordancias dúplex.
Paso 2 - Marque para las discordancias dúplex

Otra causa común para los errores de interfaz es un modo dúplex no coincidente entre dos extremos de un link
Ethernet. En muchas redes basadas en Ethernet, las conexiones punto a punto son ahora la norma, y el uso de
concentradores y la operación semidúplex asociada es cada vez menos común. Esto significa que la mayoría de
los links Ethernet actúan hoy en el modo full-duplex, y mientras que las colisiones eran normales para un link
Ethernet, las colisiones hoy indican a menudo que la negociación dúplex ha fallado, o el link no está actuando
en el modo dúplex correcto.
El estándar IEEE 802.3ab Gigabit Ethernet exige el uso de la negociación automática para la velocidad y el
dúplex. Además, aunque no es estrictamente obligatorio, prácticamente todas las NIC Fast Ethernet también
utilizan la negociación automática de forma predeterminada. El uso del autonegotiation para la velocidad y el
duplex es la práctica recomendada actual.
Sin embargo, si la negociación dúplex falla por alguna razón, puede ser que sea necesario fijar la velocidad y el
duplex manualmente en ambos extremos. Normalmente, esto significaría establecer el modo dúplex en dúplex
completo en ambos extremos de la conexión. Si esto no trabaja, el half-duplex corriente en ambos extremos se
prefiere sobre una discordancía dúplex.
Entre las directrices de configuración dúplex se incluyen las siguientes:
 Se recomienda la negociación automática de la velocidad y del duplex.

 Si el autonegotiation falla, fije manualmente la velocidad y el duplex en los extremos de la interconexión.
 Los links Ethernet punto a punto deben ejecutarse siempre en modo full-duplex.
 El semidúplex es poco común y se encuentra normalmente solo cuando se utilizan concentradores
heredados.
Ejemplo de solución de problemas
En el escenario anterior, el administrador de red necesitaba agregar usuarios adicionales a la red. Para
incorporar estos nuevos usuarios, el administrador de red instaló un segundo conmutador y lo conectó al
primero. Poco después de que S2 se agregara a la red, los usuarios de ambos conmutadores comenzaron a
experimentar problemas de rendimiento significativos para conectarse con dispositivos del otro conmutador,
como se muestra en la figura.
El administrador de red nota un mensaje de 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).
Usando el comando show interfaces fa 0/20, el administrador de la red examina la interfaz en el S1 que se

utiliza para conectar con el S2 y nota que se fija al full-duplex, tal y como se muestra la salida del comando.
S1# show interface fa 0/20
FastEthernet0/20 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0cd9.96e8.8a01 (bia 0cd9.96e8.8a01)
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, reliability 255/255, txload 1/255,
rxload 1/255
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
Full-duplex , Auto-speed, media type is 10/100BaseTX
(Output omitted)
S1#
El administrador de red ahora examina el otro lado de la conexión, el puerto en S2. El comando out muestra que
este lado de la conexión se ha configurado para semidúplex.
S2# show interface fa 0/20
FastEthernet0/20 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0cd9.96d2.4001 (bia 0cd9.96d2.4001)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255,
rxload 1/255
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
Half-duplex, Auto-speed, media type is 10/100BaseTX
(Output omitted)
S2(config)# interface fa 0/20
S2(config-if)# duplex auto
S2(config-if)#
El administrador de red corrige la configuración a auto dúplex para negociar automáticamente el dúplex.

Porque el puerto en el S1 se fija al full-duplex, el S2 también utiliza el full-duplex.
Los usuarios informan de que ya no hay ningún problema de rendimiento.
Paso 3 - Verificar el direccionamiento en la red local

Al resolver problemas la conectividad de extremo a extremo, es útil verificar las asignaciones entre los IP
Addresses de destino y los direccionamientos Ethernet de la capa 2 en segmentos individuales. En IPv4, arp
proporciona esta funcionalidad. En el IPv6, la funcionalidad ARP es substituida por el proceso de detección del
vecino y el ICMPv6. La tabla de vecinos almacena en caché las direcciones IPv6 y sus direcciones físicas
Ethernet (MAC) resueltas.
Tabla ARP IPv4 de Windows
El comando arp de Windows muestra y modifica las entradas en la caché ARP que se utilizan para almacenar
direcciones IPv4 y sus direcciones físicas Ethernet (MAC) resueltas. Tal y como se muestra en de la salida del
comando, el comando arp Windows enumera todos los dispositivos que están actualmente en el 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).
La caché se puede borrar mediante el comando arp -d de Windows si el administrador de red desea volver a
llenar la caché con información actualizada.
Nota: Los comandos arp en Linux y MAC OS X tienen una sintaxis similar.
C:\> arp -a
Interface: 10.1.10.100 --- 0xd
Internet Address Physical Address Type
10.1.10.1 d4-8c-b5-ce-a0-c0 dynamic
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static

239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
C:\>
Tabla de vecinos IPv6 de Windows
La salida del comando netsh interface ipv6 show neighbor Windows enumera todos los dispositivos que
están actualmente en la tabla de vecinos.
La información que se muestra para cada dispositivo incluye la dirección IPv6, la dirección física (MAC) y el tipo
de direccionamiento. Examinando la tabla de vecinos, el administrador de red puede verificar que las
direcciones IPv6 de destino se asignan a las direcciones Ethernet correctas. Los direccionamientos locales del
link del IPv6 en todas las interfaces del r1 se han configurado manualmente al FE80::1. Semejantemente, el r2
se ha configurado con la dirección local del link de FE80::2 en sus interfaces y el r3 se ha configurado con la
dirección local del link de FE80::3 en sus interfaces. Recuerde que las direcciones locales de vínculo deben ser
únicas en el vínculo o la red.
Nota: La tabla vecina para Linux y MAC OS X se puede visualizar usando el comando ip neigh show.
C:\> netsh interface ipv6 show neighbor
-------------------------------------------- ----------------- -----------
fe80::9657:a5ff:fe0c:5b02 94-57-a5-0c-5b-02 Stale
fe80::1 d4-8c-b5-ce-a0-c0 Reachable
(Router)
ff02::1 33-33-00-00-00-01 Permanent
ff02::2 33-33-00-00-00-02 Permanent
ff02::16 33-33-00-00-00-16 Permanent
ff02::1:2 33-33-00-01-00-02 Permanent
ff02::1:3 33-33-00-01-00-03 Permanent

ff02::1:ff0c:5b02 33-33-ff-0c-5b-02 Permanent
ff02::1:ff2d:a75e 33-33-ff-2d-a7-5e Permanent

Tabla de vecinos IPv6 del IOS
La salida del comando show ipv6 neighbors visualiza un ejemplo de la tabla del vecino en el router del Cisco
IOS.
Nota:Los estados vecinos para el IPv6 son más complejos que los estados de la tabla ARP en el IPv4.
Información adicional se encuentra en RFC 4861.
R1# show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::21E:7AFF:FE79:7A81 8 001e.7a79.7a81 STALE Gi0/0
2001:DB8:ACAD:1:5075:D0FF:FE8E:9AD8 0 5475.d08e.9ad8 REACH Gi0/0
Tabla de direcciones MAC del conmutador
Cuando una dirección MAC de destino se encuentra en la tabla de la dirección MAC del Switch, el Switch
adelante la trama solamente al puerto del dispositivo que tiene esa dirección MAC. Para ello, el switch consulta
su tabla de direcciones MAC. La tabla de direcciones MAC enumera la dirección MAC conectada a cada puerto.
Utilice el comando show mac address-table de visualizar la tabla de la dirección MAC en el Switch. Un ejemplo
de una tabla de la dirección MAC del Switch se muestra en la salida del comando.
Note cómo la dirección MAC para el PC1, un dispositivo en el VLA N 10, se ha descubierto junto con el puerto
del switch S1 al cual el PC1 asocia. Recuerde, la tabla de la dirección MAC del Switch contiene solamente la
información de la capa 2, incluyendo la dirección MAC de los Ethernetes y el número de puerto. No se incluye la
información de la dirección IP.
S1# show mac address-table
Mac Address Table
--------------------------------------------
Vlan Mac Address Type Ports
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU

10 d48c.b5ce.a0c0 DYNAMIC Fa0/4
10 000f.34f9.9201 DYNAMIC Fa0/5
10 5475.d08e.9ad8 DYNAMIC Fa0/13
Total Mac Addresses for this criterion: 5
Ejemplo de asignación de VLAN de Solución de

problemas
Otro problema a tener en cuenta al solucionar problemas de conectividad de extremo a extremo es la
asignación de VLAN. En la red conmutada, cada puerto de un conmutador pertenece a una VLAN. Cada VLAN
se considera una red lógica independiente y los paquetes destinados a estaciones que no pertenecen a la VLAN
deben reenviarse a través de un dispositivo que admita el enrutamiento. Si un host en un VLA N envía una
trama Ethernet del broadcast, tal como una petición ARP, todos los host en el mismo VLA N reciben la trama;
los host en otros VLA N no lo hacen. Incluso si dos hosts están en la misma red IP, no podrán comunicarse si
están conectados a puertos asignados a dos VLAN independientes. Además, si se elimina la VLAN a la que
pertenece el puerto, el puerto se vuelve inactivo. Todos los hosts conectados a puertos que pertenecen a la
VLAN que se eliminó no pueden comunicarse con el resto de la red. Los comandos tales como vlan de la
demostración se pueden utilizar para validar las asignaciones del VLA N en un Switch.
Supongamos, por ejemplo, que en un esfuerzo por mejorar la administración de cables en el armario de
cableado, su empresa ha reorganizado los cables que se conectan al conmutador S1. Casi inmediatamente
después, los usuarios comenzaron a llamar al servicio de soporte indicando que ya no podían llegar a los
dispositivos fuera de su propia red.
Marque la tabla ARP
Una examinación de la tabla ARP PC1 usando el comando arp Windows muestra que la tabla ARP contiene no
más una entrada para el default gateway 10.1.10.1, tal y como se muestra en de la salida del comando.
C:\> arp -a
Interface: 10.1.10.100 --- 0xd
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static

239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

Marque la tabla mac del switch
No había cambios de configuración en el router, así que el S1 es el foco del Troubleshooting.
La tabla de la dirección MAC para el S1, tal y como se muestra en de la salida del comando, muestra que la
dirección MAC para el r1 está en un diverso VLA N que el resto de los dispositivos 10.1.10.0/24, incluyendo el
PC1.
Mac Address Table
--------------------------------------------
10 000f.34f9.9201 DYNAMIC Fa0/5
S1#
Corrija la asignación de VLAN
Durante el re-cableado, el cable de conexión para el r1 fue movido de Fa 0/4 en el VLA N 10 al Fa 0/1 en el
VLAN1. Después de que el administrador de red configurara el puerto Fa 0/1 de S1 para estar en el VLA N 10,
tal y como se muestra en de la salida del comando, el problema fue resuelto. La tabla de la dirección MAC
ahora muestra el VLA N 10 para la dirección MAC del r1 en el puerto Fa 0/1.
S1(config)# interface fa0/1

S1(config-if)# switchport mode access
S1(config-if)# switchport access vlan 10
S1(config-if)# exit
S1#
Mac Address Table
--------------------------------------------
10 000f.34f9.9201 DYNAMIC Fa0/5
S1#
Paso 4 - Verificar la puerta de enlace predeterminada

Si no hay ninguna ruta detallada en el router, o si el host se configura con el default gateway incorrecto,
después la comunicación entre dos puntos finales en diversas redes no trabaja.
La figura ilustra cómo PC1 utiliza el r1 como su default gateway. Semejantemente, el r1 utiliza el r2 como su
gateway predeterminado o gateway del último recurso. Si un host necesita acceso a recursos más allá de la red
local, se debe configurar la puerta de enlace predeterminada. La puerta de enlace predeterminada es el primer
enrutador en la ruta de acceso a destinos más allá de la red local.
Ejemplo de solución de problemas de puerta de enlace predeterminada de IPv4
En este ejemplo, el r1 tiene el default gateway correcto, que es el direccionamiento del IPv4 del r2. Sin
embargo, PC1 tiene la puerta de enlace predeterminada incorrecta. Pc1 debe tener la puerta de enlace
predeterminada de R1 10.1.10.1. Esto se debe configurar manualmente si la información de direccionamiento
del IPv4 fue configurada manualmente en el PC1. Si la información de direccionamiento IPv4 se obtuvo
automáticamente de un servidor DHCPv4, se debe examinar la configuración del servidor DHCP. Un problema
de configuración en un servidor DHCP suele afectar a varios clientes.
R1 Routing Table
The command output of the show ip route Cisco IOS command is used to verify the default gateway of R1
R1# show ip route | include Gateway|0.0.0.0
Gateway of last resort is 192.168.1.2 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.2
R1#
Tabla de ruteo PC1
En un host de Windows, el comando route print windows se utiliza para verificar la presencia de la puerta de

enlace predeterminada de IPv4 como se muestra en la salida del comando.
C:\> route print
(Output omitted)
IPv4 Route Table

===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.1.10.1 10.1.10.10 11
Ejemplo de solución de problemas de puerta de enlace

predeterminada de IPv6Troubleshoot IPv6 Default
En IPv6, la puerta de enlace predeterminada se puede configurar manualmente, mediante la configuración
automática sin estado (SLAAC) o mediante DHCPv6. Con SLAAC, el enrutador anuncia la puerta de enlace
predeterminada a los hosts mediante mensajes de anuncio de enrutador (RA) ICMPv6. La puerta de enlace
predeterminada en el mensaje de RA es la dirección IPv6 local de vínculo de una interfaz de enrutador. Si la
puerta de enlace predeterminada se configura manualmente en el host, lo que es muy poco probable, la puerta
de enlace predeterminada se puede establecer en la dirección IPv6 global o en la dirección IPv6 local del
vínculo.
Tabla de ruteo del r1
Tal y como se muestra en de la salida del comando, utilizan al comando show ipv6 route Cisco IOS de marcar
para saber si hay la ruta predeterminada del IPv6 en el r1. El r1 tiene una ruta predeterminada vía el r2.
R1# show ipv6 route
(Output omitted)
S ::/0 [1/0]
via 2001:DB8:ACAD:2::2
R1#
Direccionamiento PC1
El comando ipconfig de Windows se utiliza para comprobar que un PC1 tiene una puerta de enlace
predeterminada IPv6. En la salida del comando, pc1 falta una dirección de unidifusión global IPv6 y una puerta
de enlace predeterminada IPv6. PC1 está habilitado para IPv6 porque tiene una dirección local de vínculo IPv6.
El dispositivo crea automáticamente la dirección local del vínculo. Al comprobar la documentación de red, el
administrador de red confirma que los hosts de esta LAN deben recibir su información de dirección IPv6 del
enrutador mediante SLAAC.
Nota:En este ejemplo, otros dispositivos en el mismo LAN usando el SLAAC también experimentarían el mismo
problema que recibía la información de dirección del IPv6.
C:\> ipconfig Configuración IP de Windows Sufijo DNS específico de la conexión.
: Dirección IPv6 local de vínculo . . . . : fe80::5075:d0ff:fe8e:9ad8%13 Dirección
IPv4 . . . . . : 10.1.10.1 C:\>

Configuraciones de la interfaz del r1 del control
La salida del comando show ipv6 interface GigabitEthernet 0/0/0 en el r1 revela que aunque la interfaz tenga
un direccionamiento del IPv6, no es un miembro del grupo de multidifusión FF02::2 del All-IPv6-Routers. Esto
significa que el router no está habilitado como router IPv6. Por lo tanto, no está enviando los RU ICMPv6 en
esta interfaz.
R1# show ipv6 interface GigabitEthernet 0/0/0
IPv6 is enabled, link-local address is FE80::1
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
Joined group address(es):
FF02:: 1
FF02::1:FF00:1
(Output omitted)
R1#
Enrutamiento IPv6 R1 correcto

El r1 se habilita como router del IPv6 usando el comando unicast-routing del ipv6. El comando show ipv6
interface GigabitEthernet 0/0/0 verifica que el r1 sea un miembro de ff02::2, el grupo de multidifusión all-
IPv6-Routers.
R1(config)# ipv6 unicast-routing
R1(config)# exit
R1# show ipv6 interface GigabitEthernet 0/0/0
IPv6 is enabled, link-local address is FE80::1
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
Joined group address(es):
FF02:: 1
FF02:: 2
FF02::1:FF00:1
(Output omitted)
R1#
Verifique que pc1 tiene un default gateway del IPv6
Para comprobar que PC1 tiene establecida la puerta de enlace predeterminada, utilice el comando ipconfig en
el PC con Microsoft Windows o el comando netstat -r o ip route en Linux y Mac OS X. En el, PC1 tiene una
dirección de unidifusión global IPv6 y una puerta de enlace predeterminada IPv6. El default gateway se fija a la
dirección local del link del r1 del router, fe80::1.
C:\> ipconfig
Windows IP Configuration
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . : 2001:db8:acad:1:5075:d0ff:fe8e:9ad8
Link-local IPv6 Address . . . . : fe80::5075:d0ff:fe8e:9ad8%13
IPv4 Address . . . . . . . . . . : 10.1.10.10
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway. . . . . . . . . : fe80::1
10.1.10.1
C:\>
Paso 5 - Verificar la ruta correcta

Al resolver problemas, es a menudo necesario verificar la trayectoria a la red de destino. La figura muestra la
topología de referencia que indica la trayectoria prevista para los paquetes del PC1 al SRV1.
Tabla de ruteo del IPv4 del r1
R1# show ip route | begin Gateway

Gateway of last resort is 192.168.1.2 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:13, Serial0/1/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.10.0/24 is directly connected, GigabitEthernet0/0/0
L 10.1.10.1/32 is directly connected, GigabitEthernet0/0/0
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.1.0 [110/100] via 192.168.1.2, 00:01:59, Serial0/1/0
192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.1.0/30 is directly connected, Serial0/1/0
L 192.168.1.1/32 is directly connected, Serial0/1/0
O 192.168.1.4/30 [110/99] via 192.168.1.2, 00:06:25, Serial0/1/0
R1#
Tabla de ruteo del IPv6 del r1
R1# show ipv6 route
IPv6 Routing Table - default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination

NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
a - Application
OE2 ::/0 [110/1], tag 1
via FE80::2, Serial0/1/0
C 2001:DB8:ACAD:1::/64 [0/0]
via GigabitEthernet0/0/0, directly connected
L 2001:DB8:ACAD:1::1/128 [0/0]
via GigabitEthernet0/0/0, receive
C 2001:DB8:ACAD:2::/64 [0/0]
via Serial0/1/0, directly connected
L 2001:DB8:ACAD:2::1/128 [0/0]
via Serial0/1/0, receive
O 2001:DB8:ACAD:3::/64 [110/99]
O 2001:DB8:ACAD:4::/64 [110/100]
L FF00::/8 [0/0]
via Null0, receive

R1#
Las tablas de enrutamiento IPv4 e IPv6 se pueden rellenar con los métodos siguientes:
 Redes conectadas directamente

 Host local o rutas locales
 Rutas estáticas
 Rutas dinámicas
 Rutas predeterminadas
El proceso de reenvío de paquetes IPv4 e IPv6 se basa en la coincidencia de bits más larga o la coincidencia de
prefijo más larga. El proceso de la tabla de ruteo intentará remitir el paquete usando una entrada en la tabla de
ruteo con el mayor número de bits coincidentes más a la izquierda. El número de bits coincidentes se indica
mediante la longitud del prefijo de la ruta.
La figura describe el proceso para las tablas de ruteo IPv4 e IPv6.
Los dispositivos no pueden conectarse al servidor SRV1 en 172.16.1.100. Usando el comando show ip

route, el administrador debe marcar para ver si existe una entrada de ruteo a la red 172.16.1.0/24. Si la tabla de
ruteo no tiene una ruta específica a la red SRV1, el administrador de red debe entonces marcar para saber si
existe una entrada de ruta predeterminada o de resumen en la dirección de la red 172.16.1.0/24. Si no existe
ninguno, el problema puede estar con el ruteo y el administrador debe verificar que la red está incluida dentro de
la configuración del Protocolo de ruteo dinámico o agregar una Static ruta.
Paso 6 - Verificar la capa de transporte

Si la capa de red parece estar funcionando como se esperaba, pero los usuarios siguen sin poder acceder a los
recursos, el administrador de red debe comenzar a solucionar problemas de las capas superiores. Dos de los
problemas más comunes que afectan a la conectividad de la capa de transporte incluyen configuraciones ACL y
nat configuraciones. Una herramienta común para probar la funcionalidad de la capa de transporte es la utilidad
Telnet.
Precaución:Mientras que Telnet se puede utilizar para probar la capa de transporte, por razones de seguridad,
SSH se debe utilizar para manejar y para configurar remotamente los dispositivos.
Un administrador de red está solucionando un problema en el que no puede conectarse a un enrutador

mediante HTTP. El administrador hace ping al r2 tal y como se muestra en de la salida del comando.
R1# ping 2001:db8:acad:2::2
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:2::2, timeout is 2 seconds:
!!!!!
R1#
R2 responde y confirma que la capa de red y todas las capas por debajo de la capa de red están operativas. El
administrador sabe que el problema es con la capa 4 o para arriba y debe comenzar a resolver problemas esas
capas.
Después, el administrador verifica que puedan Telnet al r2 tal y como se muestra en de la salida del comando.
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 están ejecutando en el r2. Aunque la aplicación de
servidor Telnet se ejecuta en su propio número de puerto conocido 23 y los clientes Telnet se conectan a este
puerto de forma predeterminada, se puede especificar un número de puerto diferente en el cliente para
conectarse a cualquier puerto TCP que deba probarse. El uso de un puerto diferente que no sea el puerto TCP
23 indica si la conexión se acepta (como se indica con la palabra "Abrir" en la salida), se rechaza o se agote el
tiempo de espera. A partir de cualquiera de esas respuestas, se pueden sacar conclusiones adicionales sobre la
conectividad. Algunas aplicaciones, si utilizan un protocolo de sesión basado en ASCII, incluso pueden mostrar
un banner de aplicación, puede ser posible desencadenar algunas respuestas del servidor escribiendo ciertas
palabras clave, como con SMTP, FTP y HTTP.
Por ejemplo, el administrador intenta Telnet al 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#
La salida verifica una conexión de capa de transporte correcta, pero R2 rechaza la conexión mediante el puerto
80.
Paso 7 - Verifique los ACL

En el Routers, puede haber los ACL que prohíben que los protocolos pasen a través de la interfaz en la
dirección entrante o saliente.
Utilice el comando show ip access-lists de visualizar el contenido de todos los IPv4 ACL y el comando show
ipv6 access-list de visualizar el contenido de todos los IPv6 ACL configurados en un router. El ACL específico
se puede visualizar ingresando el nombre o el número ACL como opción para este comando. Los
comandos show ip interfaces y show ipv6 interfaces visualizan la información de la interfaz del IPv4 y del
IPv6 que indica si cualquier IP ACL está fijada en la interfaz.
Para evitar ataques de suplantación de identidad, el administrador de red decidió implementar una ACL que
impide que los dispositivos con una dirección de red de origen de 172.16.1.0/24 entren en la interfaz S0/0/1
entrante en R3, como se muestra en la figura. Se debe permitir el resto del tráfico IP.
Sin embargo, poco después de implementar el ACL, los usuarios en la red 10.1.10.0/24 no podían conectar con
los dispositivos en la red 172.16.1.0/24, incluyendo SRV1.
muestre las listas de acceso del IP
El comando show ip access-lists visualiza que el ACL está configurado correctamente, tal y como se muestra
en de la salida del comando.
R3# show ip access-lists
Extended IP access list 100
10 deny ip 172.16.1.0 0.0.0.255 any (108 matches)
20 permit ip any any (28 matches)
R3#
muestre las interfaces ip
Podemos verificar qué interfaz tiene el ACL aplicado usando el comando show ip interfaces serial 0/1/1 y el
comando show ip interfaces gig 0/0/0. La salida revela que el ACL nunca fue aplicado a la interfaz entrante en
el serial 0/0/1 pero fue aplicado accidentalmente a la interfaz G0/0/0, bloqueando todo el tráfico saliente de la
red 172.16.1.0/24.
R3# show ip interface serial 0/1/1 | include access list
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is not set
R3#
R3# show ip interface gig 0/0/0 | include access list
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is 100
R3#
Corregir el problema
Después de colocar correctamente el IPv4 ACL en la interfaz de entrada serial 0/0/1, tal y como se muestra en
de la salida del comando, los dispositivos pueden conectar con éxito con el servidor.
R3(config)# interface GigabitEthernet 0/0/0
R3(config-if)# no ip access-group 100 in
R3(config-if)# exit
R3(config)#
R3(config)# interface serial 0/1/1
R3(config-if)# ip access-group 100 in
R3(config-if)# end
R3#
Paso 8 - Verificar DNS

El protocolo DNS controla el DNS, una base de datos distribuida con la que puede asignar nombres de host a
direcciones IP. Cuando usted configura el DNS en el dispositivo, usted puede substituir el nombre de host para
la dirección IP con todos los comandos IP, tales como ping o telnet.
Para visualizar la información de configuración DNS en el Switch o el router, utilice el comando show running-
config. Cuando no hay servidor DNS instalado, es posible ingresar los nombres a las asignaciones IP
directamente en la configuración del Switch o del router. Utilice el comando ip host de ingresar un nombre que
se utilizará en vez del direccionamiento del IPv4 del Switch o del router, tal y como se muestra en de la salida
del comando.
R1(config)# ip host ipv4-server 172.16.1.100
R1(config)# exit
R1#
Ahora el nombre asignado se puede utilizar en vez de utilizar la dirección IP, tal y como se muestra en de la
salida del comando.
R1# ping ipv4-server
Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2 seconds:
!!!!!
R1#
Para mostrar la información de asignación de nombre a dirección IP en un equipo basado en Windows, utilice el
comando nslookup.
Qué aprendí en este módulo?

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 línea de base de rendimiento
de red. La información que se encuentra en una topología física normalmente incluye 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 enrutador 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, el acceso, la VLAN, el tronco, el EtherChannel, el
nativo y el habilitado. La documentación de dispositivos de red para sistemas finales puede incluir el nombre del
dispositivo, el sistema operativo, los servicios, la dirección MAC, las direcciones IPv4 e IPv6, la puerta de enlace
predeterminada y el DNS. Una línea base de red debe responder a las siguientes preguntas:
 ¿Cómo funciona la red durante un día normal o normal?

 ¿Dónde se producen más errores?
 ¿Qué parte de la red se utiliza más?
 ¿Qué parte de la red se utiliza menos?
 ¿Qué dispositivos deben supervisarse y qué umbrales de alerta deben establecerse?
 ¿Puede la red cumplir con las políticas identificadas?
Al realizar la línea de base inicial, comience seleccionando algunas variables que representan las directivas
definidas, como la utilización de la interfaz y la utilización de la CPU. Un diagrama de topología de red lógica
puede ser útil para identificar los dispositivos y puertos clave que se deben supervisar. El período de tiempo y la
información de línea de base que se recopila deben ser lo suficientemente largos como para determinar una
imagen "normal" de la red. Al documentar la red, recopile la información directamente del Routers y del
Switches usando los comandos show, ping, traceroute,y telnet.
El proceso de solución de problemas debe guiarse por métodos estructurados. Un método es el proceso de
solución de problemas de siete pasos: 1. Definir el problema, 2. Recopilar información, 3. Analizar información,
4. Eliminar posibles causas, 5. Proponer hipótesis, 6. Probar hipótesis y 7. Resolver el problema. Cuando hable
con los usuarios finales sobre sus problemas de red, haga preguntas abiertas y cerradas. Utilice los
comandos show, ping, traceroutey telnet de recopilar información de los dispositivos. Utilice los modelos en
capas para realizar la solución de problemas de abajo hacia arriba, de arriba hacia abajo o de divide y vencerás.
Otros modelos incluyen seguir el camino, la sustitución, la comparación y la conjetura educada. Los problemas
de software a menudo se resuelven utilizando un enfoque de arriba hacia abajo, mientras que los problemas
basados en hardware se resuelven utilizando el enfoque de abajo hacia arriba. Los nuevos problemas pueden
ser resueltos por un técnico experimentado utilizando el método divide y vencerás.
Herramientas de solución de problemas

Las herramientas comunes de Troubleshooting del software incluyen las herramientas NMS, las bases de
conocimiento, y las herramientas de baselining. Un analizador de protocolos, como Wireshark, decodifica las
distintas capas de protocolo en una trama grabada y presenta esta información en un formato fácil de usar. Las
herramientas de Troubleshooting del hardware incluyen multímetros digitales, probadores de cable,
analizadores de cable, analizadores de red portátiles, y Cisco Prime NAM. El servidor de Syslog se puede
también utilizar como herramienta de Troubleshooting. Implementación de un recurso de registro para la
solución de problemas de red. Los dispositivos de Cisco pueden registrar la información con respecto a los
cambios de configuración, a las violaciones ACL, al estatus de la interfaz, y a muchos otros tipos de eventos.
Los mensajes de eventos se pueden enviar a uno o más de los siguientes elementos: consola, líneas de
terminal, registro almacenado en búfer, capturas SNMP y syslog. Cuanto menor sea el número de nivel, mayor
será el nivel de gravedad. El comando logging trap level limita los mensajes registrados al servidor de Syslog
basado en la gravedad. El nivel es el nombre o el número del nivel de gravedad. Sólo se registran los mensajes
iguales o numéricamente inferiores al nivel especificado.
Los errores y las condiciones subóptimas en la capa física suelen hacer que las redes se apaguen. 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 de la línea de base, pérdida de conectividad, congestión, uso
elevado de la CPU y mensajes de error de la consola. Las causas suelen estar relacionadas con la
alimentación, fallos de hardware, fallos de cableado, atenuación, ruido, errores de configuración de la interfaz,
superación de los límites de diseño de componentes y sobrecarga de la CPU.
Los problemas de la capa de vínculo de datos causan síntomas específicos que, cuando se reconocen,
ayudarán a identificar el problema rápidamente. Los síntomas no incluyen ninguna funcionalidad/conectividad
en la capa 2 o arriba, red que funciona debajo de los niveles de la línea de fondo, broadcasts excesivos, y
mensajes de la consola. Las causas son generalmente errores de encapsulación, errores de asignación de
direcciones, errores de trama, y errores o loopes STP.
Los problemas de la capa de red incluyen cualquier problema que implique un protocolo de la capa 3, ambos
protocolos ruteados (tales como IPv4 o IPv6) y Routing Protocol (tales como EIGRP, OSPF, etc.). Los síntomas
incluyen un error de red y un rendimiento subóptimo. Las causas suelen ser problemas generales de red,
problemas de conectividad, problemas de tabla de enrutamiento, problemas de vecino y la base de datos de
topología.
Los problemas de la capa de transporte pueden surgir de problemas de la capa de transporte en el router,
particularmente 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. Los
misconfigurations ACL ocurren comúnmente en la selección del flujo de tráfico, de la orden de las entradas del
control de acceso, implícito niega ningunos, de los direccionamientos y de las máscaras comodín del IPv4, de la
selección del protocolo de la capa de transporte, de los puertos de origen y de destino, del uso de la palabra
clave establecida, y de los protocolos infrecuentes. 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 cifrado.
Los problemas de la capa de aplicación pueden dar lugar a recursos inalcanzables o inutilizables cuando las
capas físicas, de vínculo de datos, de red y de transporte son funcionales. Es posible tener conectividad de red
completa, pero la aplicación simplemente no puede proporcionar datos. Otro tipo de problema en la capa de
aplicación se produce cuando las capas física, de vínculo de datos, de red y de transporte son funcionales, pero
la transferencia de datos y las solicitudes de servicios de red desde un único servicio de red o aplicación no
cumplen las expectativas normales de un usuario.
Solución de problemas de conectividad IP

Diagnosticar y resolver problemas es una habilidad esencial para los administradores de red. No hay una receta
única para la solución de problemas, y un problema se puede diagnosticar de muchas maneras. Sin embargo,
mediante el empleo de un enfoque estructurado para el proceso de solución de problemas, un administrador
puede reducir el tiempo que se tarda en diagnosticar y resolver un problema.
Los problemas de conectividad de extremo a extremo suelen ser lo que inicia un esfuerzo de solución de
problemas. Dos de las utilidades más comunes usadas para verificar un problema con la Conectividad de punta
a punta son ping y traceroute. El comando ping utiliza un protocolo de capa 3 que forma parte del conjunto de
aplicaciones TCP/IP denominado ICMP. El comando traceroute se realiza comúnmente cuando el
comando ping falla.
Paso 1. Compruebe la capa física. Los comandos cisco IOS más de uso general para este propósito son cpu
de los procesos de la demostración,memoria de la demostración,y interfaces de la demostración.
Paso 2. Marque para ver si hay discordancias dúplex. Otra causa común para los errores de interfaz es un
modo dúplex no coincidente entre dos extremos de un link Ethernet. En muchas redes basadas en Ethernet, las
conexiones punto a punto son ahora la norma, y el uso de concentradores y la operación semidúplex asociada
es cada vez menos común. Utilice el comando show interfaces interface de diagnosticar este problema.
Paso 3. Compruebe el direccionamiento en la red local. Al resolver problemas la conectividad de extremo a

extremo, es útil verificar las asignaciones entre los IP Addresses de destino y los direccionamientos Ethernet de
la capa 2 en segmentos individuales. El comando arp de Windows muestra y modifica las entradas en la caché
ARP que se utilizan para almacenar direcciones IPv4 y sus direcciones físicas Ethernet (MAC) resueltas. La
salida del comando netsh interface ipv6 show neighbor Windows enumera todos los dispositivos que están
actualmente en la tabla de vecinos. La salida del comando show ipv6 neighbors visualiza un ejemplo de la
tabla del vecino en el router del Cisco IOS. Utilice el comando show mac address-table de visualizar la tabla
de la dirección MAC en el Switch.
VLAN assignment is another issue to consider when troubleshooting end-to-end connectivity. Use
the arp Windows command to see the entry for a default gateway. Use the show mac address-table command
to check the switch MAC table. This may show that not a VLAN assignments are correct.
Step 4. Verify the default gateway. The command output of the show ip route Cisco IOS command is used to
verify the default gateway of a router. On a Windows host, the route print Windows command is used to verify
the presence of the IPv4 default gateway.
En IPv6, la puerta de enlace predeterminada se puede configurar manualmente, mediante la configuración

automática sin estado (SLAAC) o mediante DHCPv6. Utilizan al comando show ipv6 route Cisco IOS de
marcar para saber si hay la ruta predeterminada del IPv6 en un router. El comando ipconfig de Windows se
utiliza para verificar si un PC1 tiene una puerta de enlace predeterminada IPv6. La salida del comando de
la interfaz del ipv6 de la demostración le dirá si un router está o no se habilita como router del IPv6. Habilite a
un router como router del IPv6 usando el comando unicast-routing del ipv6. Para verificar que un host tiene
establecida la puerta de enlace predeterminada, utilice el comando ipconfig en el PC con Microsoft Windows o
el comando ifconfig en Linux y Mac OS X.
Paso 5. Compruebe la ruta correcta. Los routers de la ruta de acceso toman la decisión de enrutamiento en
función de la información de las tablas de enrutamiento. Utilice la ruta del IP de la demostración | comando
begin Gateway para una tabla de ruteo IPv4. Utilice el comando show ipv6 route para una tabla de ruteo del
IPv6.
Paso 6. Compruebe la capa de transporte. Dos de los problemas más comunes que afectan a la conectividad
de la capa de transporte incluyen configuraciones ACL y nat configuraciones. Una herramienta común para
probar la funcionalidad de la capa de transporte es la utilidad Telnet.
Paso 7. Verifique las ACL. Utilice el comando show ip access-lists de visualizar el contenido de todos los IPv4
ACL y el comando show ipv6 access-list de mostrar el contenido de todos los IPv6 ACL configurados en un
router. Verifique qué interfaz tiene el ACL aplicado usando el comando show ip interfaces.
Paso 8. Compruebe DNS. Para visualizar la información de configuración DNS en el Switch o el router, utilice el
comando show running-config. Utilice el comando ip host de ingresar el nombre a la asignación del IPv4 al
Switch o al router tal y como se muestra en de la salida del comando.

MOD 12 - CCNA3 - Solución de Problemas de Red

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

MOD 12 - CCNA3 - Solución de Problemas de Red

Cargado por

Copyright:

Formatos disponibles

Solución de problemas de red

¿Por qué debo tomar este módulo?

¿Qué aprenderé a hacer en este módulo?

Objetivo del módulo: Solucionar problemas de redes empresariales.

Título del tema Objetivo del tema

Información general sobre la documentación

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

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

Diagramas de topología de red

 Nombre del dispositivo

La figura muestra un diagrama de topología de red física de ejemplo.

Topología lógica IPv4

La información registrada en una topología de red lógica puede incluir lo siguiente:

La figura muestra una topología de red IPv4 lógica de ejemplo.

Topología lógica IPv6

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

Router Device Documentation

Documentación del dispositivo del conmutador LAN

Archivos de documentación del sistema final

Establecer una línea de base de red

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

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

Paso 2 - Identificar dispositivos y puertos de interés

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

Paso 3 - Determinar la duración de la línea base

Muestra el tiempo de actividad, la información de versión para el software y el

Muestra todas las opciones de configuración que se establecen en una

Muestra la salida detallada para cada interfaz.

Muestra la lista de contenido de la tabla de enrutamiento que enumera las

show running-config Muestra la configuración actual.

show vlan Visualiza el estatus de los VLA N en un Switch.

show port Muestra el estado de los puertos de un conmutador.

Proceso de solución de problemas

Procedimientos generales de solución de problemas

Eliminar posibles causas

Preguntar a los usuarios finales

Las siguientes recomendaciones deben emplearse al comunicarse con el usuario:

Directrices Ejemplo de preguntas abiertas para el usuario final

¿A quién afecta este problema? ¿Es solo usted u otros?

¿Cuándo se produce exactamente el problema?

¿Se puede reproducir el problema?

Utilice preguntas para eliminar o ¿Qué funciona?

Envía un paquete de solicitud de eco a una dirección y, a continuación,

Identifica la ruta que toma un paquete a través de las redes

Se conecta a una dirección IP mediante la aplicación Telnet

Se conecta a una dirección IP mediante SSH

Muestra un estado de resumen de todas las interfaces de un dispositivo

Visualiza los protocolos configurados y muestra el estatus global y interfaz-

Solución de problemas con modelos en capas

Métodos estructurados de solución de problemas

De abajo hacia arriba

La figura muestra el enfoque de divide y vencerás para solucionar un problema de red.

Este enfoque también se denomina swap-the-component porque se intercambia físicamente el dispositivo

Directrices para seleccionar un método de solución de

Herramientas del sistema de administración de redes

Herramientas de línea base

Herramientas de solución de problemas de

Analizadores de red portátiles

Módulo de análisis de red de Cisco Prime

Servidor de Syslog como herramienta de

La implementación de un recurso de registro es una parte importante de la seguridad de la red y para la

Nivel Palabra clave Descripción Definición

0 Emergencias El sistema es inutilizable LOG_EMERG