¿El enrutador 1 podrá hacer ping al bucle invertido del enrutador 3?
en el enrutador 3, un bucle invertido se configura como 3. 3. 3. 3 está disponible en
la tabla de enrutamiento del
enrutador local como una interfaz directamente conectada onloopback 0.
¿El router 1 podrá hacer ping a ese loopback?
y la respuesta es no porque el enrutador 1 no tiene
una ruta a esa interfaz loopback. podemos probar que al usar el comando sh ip
route nuevamente notamos que no hay una
ruta a 3. 3. 3. Paquete de 3
depuraciones de IP. Haga el ping de nuevo notificando que no se puede enrutar.
Entonces, el enrutador no sabe cómo llegar a ese bucle invertido, por
lo que tendríamos que configurar las rutas estáticas para ese bucle invertido.
Así que aquí está la pregunta, ¿cuántas rutas
estáticas necesitaríamos configurar en esta red para habilitar la conectividad total?
Para responder a la pregunta, observe qué redes no están conectadas directamente al enrutador 1.
El enrutador 1 tiene este loopback y esta red está directamente conectada a él, pero
la red 2. 2. 2. 2 esta red 10. 1. 2. 0 y
esta red 3. 3. 3. 3 no están conectados al enrutador
1, por lo que será necesario configurar 3 redes en el enrutador 1.
en el enrutador 2 esta red y esta red están conectadas directamente al enrutador,
podemos demostrar que al usar el comando
sh ip route notice 3 las redes están conectadas directamente al enrutador
2, pero esta red y esta no están conectadas directamente.
entonces teníamos 3 en el enrutador 1, tenemos que configurar 2 rutas
en el enrutador 2 en el enrutador 3, esta red y esta
red están conectadas directamente pero esta red esta red
y esta red no están conectadas directamente, por lo que el enrutador 3 necesita 3 rutas estáticas.
Entonces, en esta pequeña topología simplemente usando esta red
como se muestra en el diagrama, necesitaría agregar un total de 8 rutas estáticas.
3 + 2 + 3 sin embargo en el enrutador 1 agregué
algunas redes adicionales 10. 1. 1. 2 y 10. 1. 10. 0, eso significa
que necesitamos agregar 2 rutas adicionales al
enrutador 2, más 2 rutas adicionales al enrutador 3
suponiendo que es eso, que no resumimos.
Entonces es bastante trabajo.
Este es el problema con las rutas estáticas, puede haber
mucho trabajo, especialmente si tiene una topología grande.
Entonces corre | include route me mostrará mis
rutas estáticas en la configuración en ejecución del enrutador en el momento en que solo he
configurado 1, así que tendré que escribir la
ruta IP 2. 2. 2. 2 y
el próximo salto 10. 1. 1. 2 que agrega esa
ruta a la tabla de enrutamiento 1 del enrutador y
tengo que hacer algo similar para el bucle del enrutador 3 note que se usa la misma dirección
IP del siguiente salto desde el punto de vista del enrutador La dirección
IP del siguiente salto es esta dirección IP
al llegar a cualquiera de estas 3 redes.
Entonces, ¿el enrutador 1 puede hacer ping 3? 3. 3. 3? No, no puede, ¿por qué?
Así que apague la depuración, intentémoslo de nuevo.
¿Podemos hacer ping 3. 3. 3. 3?
No, veamos si hay un problema, entonces usemos
el comando traceroute 3. 3. 3. 3 Aviso para
llegar a 3. 3. 3. 3 el comando traceroute me muestra que el
enrutador 1 envía el tráfico a 10. 1. 1. 2 y
eso es porque esa ruta está en la tabla de enrutamiento local del enrutador
1, pero cuando llega al enrutador 2 falla.
Entonces el enrutador 1 envía el tráfico al enrutador
2 enrutador 2, sin embargo, cuando recibe el tráfico del enrutador 1 no sabe
dónde 3. 3. 3. 3 es.
Así que para demostrar que vamos a hacer un paquete de IP de depuración en el enrutador 2.
Voy a hacer ping al bucle de retorno del enrutador 3 desde el enrutador 1 para que el
tráfico pase del enrutador 1 al enrutador 2 y
luego veamos qué sucede con suerte,
también va al enrutador, 3 pero ¿lo hará?
Y podemos ver aquí que el enrutador 2 dice host inaccesible enviado
a 10. 1. 1. 1 para la red 3. 3. 3. 3 El
enrutador 2 no sabe cómo llegar a esta red de destino y, por lo tanto, le
dice a la red del enrutador 1 que no está disponible.
Este es un ejemplo del paradigma salto por salto utilizado en IPv4 e IPv6.
El paradigma de salto por salto significa que
cada enrutador toma su propia decisión de enrutamiento local independientemente de otros enrutadores.
Entonces, solo porque el enrutador 1 sabe cómo llegar al
enrutador 3 no significa que el enrutador 2 sepa cómo llegar al enrutador 3.
El enrutador 1 solo conoce el siguiente salto en
el camino para llegar a ese destino y no
conoce toda la ruta, por lo que sh ip route Notice router 1 sabe que para
llegar a esta red 3. 3. 3. 3 necesita enviar el
tráfico al enrutador 2, pero
depende del enrutador 2 para saber qué hacer con el tráfico.
Y en este caso, el enrutador 2 no sabe cómo llegar al enrutador 3, por
lo que el masaje inalcanzable se envía de vuelta al enrutador 1.
Entonces, una vez más, en el enrutador 2, no hay rutas estáticas.
Por lo tanto, debo configurar una ruta estática para el bucle invertido del enrutador 3 y, en este caso,
observar que el siguiente salto desde el punto de vista del
enrutador 2 es 10. 1. 2. 2 Ahora,
¿el ping tiene éxito? Y la respuesta es sí.
el ping tiene éxito porque cuando el enrutador 1 hace ping al loopback del enrutador 3 y
reenvía el tráfico al enrutador 2.
El enrutador 2 sabe dónde enviar el tráfico porque esa ruta
se encuentra en su tabla de enrutamiento local y, por lo tanto, puede reenviar el tráfico
al enrutador 3 y, en este caso, el enrutador 3 sabe
cómo volver a 10. 1. 1. 1 para que el ping tenga éxito.
podemos ver que en el enrutador 3, está enviando una respuesta a 10. 1. 1. 1 de 3. 3. 3. 3 Ahora aquí hay otra pregunta:
si miramos la tabla de enrutamiento del enrutador 2,
dice que el siguiente salto es 10. 1. 2. 2 pero no
nos muestra que el tráfico debe salir de F0 / 1
en lugar de F0 / 0 ¿cómo sabe el enrutador qué interfaz usar?
Bien, lo sabe porque esta dirección IP es parte de esta subred y esa subred está directamente conectada a
F0 / 1, por lo que el enrutador 2 sabe que
para llegar a 3. 3. 3. 3 necesita reenviar
el tráfico a esta dirección
IP y esta dirección IP es parte de esta red
que está disponible a través de esta
interfaz, por lo que sabe reenviar el
tráfico fuera de esta interfaz local, podemos
ver eso en la tabla CEF usando
el comando show ip cef show ip cef nos muestra
que esta red está disponible a través de este siguiente salto fuera de esta interfaz.
Entonces, con el reenvío rápido de
Cisco, el enrutador crea previamente esta información en la tabla CEF para
que no tenga que hacer una doble búsqueda en la tabla de enrutamiento.
en los viejos tiempos, cuando el tráfico llegaba a esta red, el enrutador debía hacer
una doble búsqueda, en otras palabras, sería
esta entrada en la tabla de enrutamiento y luego tener que mirar esta entrada en
la tabla de enrutamiento para determinar la interfaz de salida .
Ahora esa información está precompilada en la tabla
CEF para acelerar el reenvío del tráfico.