Ahora ping es genial para probar como un ejemplo si
hago ping 10. 1. 1. 2 el ping tiene
éxito porque el primer ping falló debido a ARP, el
enrutador necesita ARP para la dirección MAC del enrutador 2, pero fíjese si
hago ping a 10. 1. 2. 2, que es la dirección
IP del enrutador 3, los pings fallan porque esa ruta no está en la tabla de enrutamiento.
10. 1. 2. 0 no está en la tabla de enrutamiento del enrutador local.
10. 1. 1. 0 está en la tabla de enrutamiento local.
entonces el enrutador puede enrutar apropiadamente
ahora los errores son muy útiles para probar y solucionar problemas y
en este ejemplo, voy a usar un comando para depurar ip icmp
tanto en el enrutador 2 como en el enrutador 3 solo para demostrar que el tráfico está llegando
como se esperaba en los enrutadores correctos .
así que haga ping a 10. 1. 1. 2 este aviso de dirección IP vemos
que las respuestas de eco ICMP se envían nuevamente a 10. 1. 1. 1 hagámoslo
así que 10. 1. 2. 2 el tráfico no llega a este enrutador, no
vemos salidas en la pantalla del enrutador 3, donde solo hay que
volver a hacerlo a 10. 1. 1. 2 vemos los
errores porque el tráfico se está enviando desde el enrutador 1 al enrutador 2 y lo está recibiendo
el enrutador 2, que a su vez está respondiendo.
Por lo tanto, en el enrutador 1, podemos usar el comando depurar paquete de
ip tenga cuidado con este comando en un entorno en vivo.
En un entorno en vivo, si desea utilizar una lista
de control de acceso para limitar el tráfico que está depurando en un entorno de
producción o en vivo, puede matar su enrutador si ejecuta este comando.
Pero en este entorno en vivo, está bien hacerlo.
por lo tanto, desde un punto de vista de prueba y solución de problemas, trabaje a través
de la lógica en el enrutador 1, tratamos
de hacer ping a 10. 1. 2. 2 no recibimos
una respuesta. Ejecutamos un ICMP de IP de depuración en el enrutador 3
para ver si el tráfico está realmente llegando al enrutador
3 y no, eso es útil porque los pings envían tráfico y luego esperan responder y
esto permite verificar si el
problema está en la ruta R1 a R3 o si el problema está en el retorno
R3 a R1, por lo que este es un gran
comando para probar, por lo
que se hace ping a 10. 1. 2. 2 aviso en la salida que estamos obteniendo sin enrutar, el enrutador local
nos dice que la dirección IP de origen 10. 1. 1. 1 ir al
destino 10. 1. 2. 2 no se puede
enrutar, por lo que no sabe a dónde reenviar el tráfico.
Otra gran cosa en el resultado aquí es
que sabemos qué interfaz está usando el enrutador para enviar
paquetes; por lo general, un enrutador utiliza la
interfaz saliente como fuente en paquetes y puede verlo aquí.
entonces la fuente del ping es 10. 1. 1. 1 porque
esa es la interfaz de salida para llegar a un destino
como 10. 1. 2. 2 como
ejemplo, si hacemos ping a 10. 1. 1. 2 el ping tiene éxito,
obtenemos un gran volumen de salida, así
que retrocedemos, tenemos el ping, son los mensajes de éxito, podemos ver que la dirección IP de
origen es 10. 1. 1. 1 destino
es 10. 1. 1. 2 esta dirección
IP y esto fue enrutado a través de la Base de información de reenvío o FIB de F0 / 0 por lo que el
paquete fue enviado y luego recibimos una
respuesta de 10. 1. 1. 2 yendo a 10. 1. 1. 1 así que
aquí podemos ver que el paquete fue enviado
fuera del enrutador o enviado por el enrutador y aquí podemos ver una respuesta del enrutador 2.
por lo que es un comando muy útil, pero una vez más, tenga cuidado de usarlo en producción sh ip route me
muestra que no tengo una ruta en
la tabla de enrutamiento para 10. 1. 2. 0 y tampoco tengo una
puerta de enlace de último recurso; en otras palabras,
no tengo una puerta de enlace predeterminada ni una
ruta predeterminada configuradas en este enrutador.
Entonces, el enrutador no sabe qué hacer con
el tráfico y, por lo tanto, cuando hacemos ping, el enrutador nos dice que el tráfico no se puede enrutar.
El enrutador no sabe a dónde
reenviar el tráfico, por lo que debemos configurar las rutas estáticas.