Verificación de la conectividad
El
comando ping es una manera efectiva de probar la conectividad. La prueba
se denomina prueba de stack de protocolos, porque el comando ping se mueve
desde la Capa 3 del Modelo OSI hasta la Capa 2 y luego hacia a la Capa.
El ping
utiliza el protocolo ICMP (Protocolo de mensajes de control de Internet)
para comprobar la conectividad.
Un
ping de IOS cederá a una de varias indicaciones para cada eco ICMP enviado. Los
indicadores más comunes son:
• ! - indica la recepción de una respuesta de eco ICMP
• . - indica un límite de tiempo cuando se espera una respuesta
• U - se recibió un mensaje ICMP inalcanzable
El
"!" (signo de exclamación) indica que el ping se completó
correctamente y verifica la conectividad de la Capa 3.
El
"." (punto) puede indicar problemas en la comunicación. Puede
señalar que ocurrió un problema de conectividad en algún sector de la ruta.
También puede indicar que un router a lo largo de la ruta no tenía una ruta
hacia el destino y no envió un mensaje ICMP de destino inalcanzable. También
puede señalar que el ping fue bloqueado por la seguridad del dispositivo.
La
"U" indica que un router del camino no tenía una ruta a la
dirección de destino y respondió con un mensaje ICMP inalcanzable.
A
modo de primer paso en la secuencia de prueba, se utiliza el comando ping para
verificar la configuración IP interna en el host local. Recuerde que esta
prueba se cumple con el comando ping en una dirección reservada denominada
loopback (127.0.0.1). Esto verifica la correcta operación del stack de
protocolos desde la capa de Red a la capa Física, y viceversa, sin colocar
realmente una señal en el medio.
Del
mismo modo que se usan comandos y utilidades para verificar la configuración de
un host, se deben aprender los comandos para verificar las interfaces de
dispositivos intermediarios. El IOS provee comandos para verificar la operación
de interfaces de router y switch.
Uno
de los comandos más utilizados es el comando show ip interface brief.
Este proporciona un resultado más abreviado que el comando show ip interface.
Ofrece además un resumen de la información clave de todas las interfaces.
Si se
observa la línea de la interfaz FastEthernet 0/0, se ve que la dirección IP es
192.168.254.254. Si se observan las dos últimas columnas, se advierte el estado
de la interfaz de Capa 1 y Capa 2. up en la columna de estado muestra
que esta interfaz está en funcionamiento en la Capa 1. up en la columna
de protocolo señala que el protocolo de Capa 2 está funcionando.
Prueba de la
conectividad del router
Como
con un dispositivo final, es posible verificar la conectividad de Capa 3 con
los comandos ping y traceroute.
Verificación de las
interfaces del switch
Comando
show ip interface para verificar la condición de las interfaces del
switch. Como se aprendió anteriormente, la dirección IP para el switch se
aplica a una interfaz VLAN (Red de área local virtual). En este caso, se asigna
una dirección IP 192.168.254.250 a la interfaz Vlan1. También se puede observar
que esta interfaz está activada y en funcionamiento.
Al
examinar la interfaz FastEthernet0/1, se puede detectar que esta interfaz está
desactivada. Esto quiere decir que no hay un dispositivo conectado a la
interfaz o que la interfaz de red de los
dispositivos conectada no está funcionando.
Por
otro lado, los resultados de las interfaces FastEthernet0/2 y FastEthernet0/3
muestran que están en funcionamiento.
Esto
se indica en el Estado y en el Protocolo, cuando ambos se muestran activos.
Prueba de la
conectividad del switch
Del
mismo modo que otros hosts, el switch puede probar la conectividad de su Capa 3
con los comandos ping y traceroute.
No
deben olvidarse dos cosas importantes: que no se requiere de una dirección IP
para que un switch cumpla su tarea de reenvío de trama y que el switch requiere
una gateway para comunicarse con el exterior de su red local.
La
siguiente prueba de la secuencia corresponde a los hosts en la LAN local.
Al
hacer ping a los hosts remotos satisfactoriamente se verifica que tanto el host
local (en este caso, el router) como el host remoto estén configurados
correctamente. Esta prueba se realiza al hacer ping a cada host en forma
individual en la LAN.
Si un
host responde con el mensaje "Destination Unreachable" (destino
inalcanzable), observe qué dirección no fue satisfactoria y continúe haciendo
ping a los otros hosts de la LAN.
Otro
mensaje de falla es "Request Timed Out" (la petición ha expirado).
Indica que no hubo respuesta al intento del ping en el período de tiempo
predeterminado, lo cual indica que el problema puede estar en la latencia de
red.
Ping
extendido
Para
examinarlo, el IOS ofrece un modo "extendido" del comando ping. Este
modo se ingresa escribiendo ping en modo EXEC privilegiado, en la
petición de entrada de la CLI sin una dirección IP de destino. Luego se
presenta una serie de peticiones de entrada como se muestra en este ejemplo. Al
presionar Intro se aceptan los valores predeterminados indicados.
Router#ping
Protocol [ip]:
Target IP address:10.0.0.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:5
Extended
commands [n]: n
Al
ingresar un período de tiempo de espera más prolongado que el predeterminado,
se podrán detectar posibles problemas de latencia. Si la prueba de ping es
exitosa con un valor superior, existe una conexión entre los hosts, pero es posible
que haya un problema de latencia en la red.
Observe
que al ingresar "y" en la petición de entrada "Extended
commands" se proporcionan más opciones provechosas para la resolución de
problemas. Estas opciones se analizarán en la práctica de laboratorio y en las
actividades del Packet Tracer.
El
siguiente paso de la secuencia de prueba es utilizar el comando ping para
verificar que un host local puede conectarse con una dirección de gateway. Esto
es sumamente importante porque el gateway es la entrada y salida del host hacia
la red más amplia. Si el comando ping devuelve una respuesta
satisfactoria, se verifica la conectividad a la gateway.
Al
comenzar, elija una estación como dispositivo de origen. En este caso, se optó
por 10.0.0.1, Utilice el comando ping para llegar a la dirección de
gateway, en este caso, 10.0.0.254.
c:\>ping
10.0.0.254
La
dirección IPv4 de gateway debe encontrarse disponible en la documentación de la
red, pero si no se encontrara disponible, utilice el comando ipconfig para
detectar la dirección IP de gateway.
Una
vez que se ha completado la verificación de la LAN local y el gateway, la
prueba puede continuar con los dispositivos remotos, lo cual es el siguiente
paso en la secuencia de prueba.
Hay 3
hosts dentro de una LAN, un router (que actúa como gateway) que está conectado
a otro router (que actúa como gateway para una LAN remota) y 3 hosts remotos.
Las pruebas de verificación deben comenzar dentro de la red local y progresar
externamente hacia los dispositivos remotos.
Comience
con la prueba de la interfaz externa de un router que está directamente
conectada a una red remota. En este caso, el comando ping prueba la
conexión a 192.168.0.253, la interfaz externa del router de gateway de la red
local.
Si el
comando ping resulta satisfactorio, se verifica la conectividad a la
interfaz externa. A continuación, haga ping a la dirección IP externa del
router remoto, en este caso, 192.168.0.254. Si es satisfactorio, se verifica la
conectividad del router remoto. Si se produce una falla, intente aislar el
problema. Vuelva a realizar la prueba hasta que exista una conexión válida a un
dispositivo y verifique dos veces cada una de las direcciones.
El
comando ping no siempre será de ayuda para identificar el motivo
subyacente de un problema, pero puede aislar los problemas y orientar el
proceso de resolución de problemas. Documente cada prueba, los dispositivos
involucrados y los resultados.
Un
router establece una conexión entre ciertas redes gracias al reenvío de
paquetes entre ellas. Para reenviar paquetes entre dos redes dadas, el router
debe poder comunicarse tanto con la red de origen como con la red de destino.
El router necesitará rutas hacia ambas redes en su tabla de enrutamiento.
Para
probar la comunicación hacia la red remota, se puede hacer ping a un host
conocido en esta red remota. Si no puede hacer ping correctamente en el host de
la red remota desde un router, primero debe verificar la tabla de enrutamiento
en busca de un ruta adecuada hacia cada red remota. Es posible que el router
use la ruta predeterminada para llegar a un destino. Si no hay una ruta para
llegar a esta red, será necesario determinar por qué no existe la ruta.
Como siempre, también
se debe descartar que el ping no esté prohibido administrativamente.
El
siguiente paso en la secuencia de prueba es realizar un rastreo.
Un
rastreo proporciona una lista de saltos cuando un paquete se enruta a través de
una red. La forma del comando depende de dónde se emita el comando. Cuando
lleve a cabo el rastreo desde un equipo con Windows, utilice tracert.
Cuando
lleve a cabo el rastreo desde la CLI de un router, utilice traceroute.
Ping y Trace
Ping
y trace pueden utilizarse en forma conjunta para diagnosticar un problema.
Supongamos
que se he establecido una conexión satisfactoria entre el Host 1 y el Router A,
Luego,
supongamos que el Host 1 hace ping al Host 2 mediante este comando.
C:\>ping
10.1.0.2
El
comando ping devuelve este resultado:
Ping
10.1.0.2 con 32 bytes de datos:
Tiempo
límite de la solicitud.
Tiempo
límite de la solicitud.
Tiempo
límite de la solicitud.
Tiempo
límite de la solicitud.
Estadísticas de ping para 10.1.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
The ping
test failed.
Ésta
es una prueba de comunicación fuera de la red local a un dispositivo remoto.
Dado que el gateway local respondió pero el host más distante no lo hizo, el
problema parece estar en algún punto fuera de la red local. Un próximo paso es
aislar el problema de una red en particular fuera de la red local. Los comandos
trace pueden mostrar la ruta de la última comunicación satisfactoria.
Trace a un host remoto
Del
mismo modo que los comandos ping, los comandos trace se ingresan
en la línea de comandos y toman una dirección IP como argumento.
Suponiendo
que se emitirá el comando desde un equipo con Windows, se utilizará el formato tracert
:
C:\>tracert
10.1.0.2
Rastreo
de la ruta a 10.1.0.2 en un máximo de 30 saltos
1 2
ms 2 ms 2 ms 10.0.0.254
2 * *
* Tiempo límite de la solicitud.
3 * *
* Request timed out.
4 ^C
La
única respuesta satisfactoria provino del gateway en el Router A. Las
peticiones de rastreo al siguiente salto expiraron, lo cual significa que el
siguiente salto no respondió. Los resultados del comando trace indican que la
falla entonces se encuentra en la internetwork más allá de la LAN.
Comentarios
Publicar un comentario