TTL

Partiendo de esta configuración:

Sabemos que con una mala configuración de tablas se puede generar un bucle y los datagramas pueden
nunca llegar a su destino. Por ejemplo, a R1 le configuro como default router a R3, y a R3 le configuro el
default router como R1, es decir:

R1:

DESTINO/MASK NEXT HOP INTERFAZ

0.0.0.0/0 192.168.1.3 (R3) INT5

R3:

DESTINO/MASK NEXT HOP INTERFAZ

0.0.0.0/0 192.168.1.1 (R1) INT5

Entonces si R1 debe encaminar un datagrama a 10.1.1.1:

1) R1 utiliza su ruta por omisión y lo envía a 192.168.1.3(R3)

2) R3 utiliza su ruta por omisión y lo envía a 192.168.1.1(R1)
3) R1 utiliza su ruta por omisión y lo envía a 192.168.1.3(R3)
4) R3 utiliza su ruta por omisión y lo envía a 192.168.1.1(R1)
5) Y así sucesivamente…

En el datagrama hay un campo llamado Time To Leave (TTL). Este evita que viaje alrededor de un bucle
para siempre. Cada router a lo largo de la ruta desde el origen decrementa el TTL en 1. Si al
decrementarlo el TTL llega a 0 y el router debe reenviarlo, descarta el datagrama, si es que este no está
dirigido al router.

Entonces el el ejemplo anterior el TTL va disminuyendo cada vez que “rebota” en R1 y R3, hasta que el
datagrama llega a R3 con TTL = 1, entonces lo decrementa a 0 y descarta el datagrama.

Por ejemplo, si R1 debe encaminar un datagrama a 10.1.1.1 y TTL = 6:

 1) R1 decrementa en 1 el TTL. Utiliza su ruta por omisión y lo envía a 192.168.1.3 (R3) con TTL = 5.
2) R3 decrementa en 1 el TTL. Utiliza su ruta por omisión y lo envía a 192.168.1.1 (R1) con TTL = 4.
3) R1 decrementa en 1 el TTL. Utiliza su ruta por omisión y lo envía a 192.168.1.3 (R3) con TTL = 3.
4) R3 decrementa en 1 el TTL. Utiliza su ruta por omisión y lo envía a 192.168.1.1 (R1) con TTL = 2.
5) R1 decrementa en 1 el TTL. Utiliza su ruta por omisión y lo envía a 192.168.1.3 (R3) con TTL = 1.
6) R3 decrementa en 1 el TTL. El TTL llega a 0. R3 descarta el datagrama.

Ahora vamos a volver a la misma configuración, pero vamos a asumir que todos los dispositivos tienen
sus tablas correctamente configuradas:

¿Cuál es el TTL mínimo para que un datagrama llegue de PCA a PCC? Si el TTL llegara a 0 cuando R3 lo
decrementa, este router va a descartar el datagrama. Para que R3 no descarte el datagrama, X (TTL
inicial) debe ser mayor o igual a 3. Es decir que PCA debe generar el datagrama destinado a PCC con X >=
3.

ICMP

¿Qué pasa cuando se descarta un datagrama? Acá entra el Internet Control Message Protocol (ICMP).
Este permite a los dispositivos enviar mensajes de control o mensajes de error de regreso al origen de
un datagrama que causo un problema. Los mensajes ICMP no se entregan normalmente a las
aplicaciones (excepto a las de diagnóstico). Pensamos en ICMP como un mecanismo que proporciona un
medio de comunicación entre un módulo ICMP sobre un dispositivo y un módulo ICMP sobre otro.

Los routers y hosts pueden enviar y recibir mensajes ICMP. Por lo tanto, también puede estar dirigido a
cualquiera de estos. Algunos tipos de mensajes (códigos) ICMP pueden ser generados exclusivamente
por routers, por ejemplo, cuando el datagrama no se puede reenviar porque el TTL llegó a 0.

En el caso de que se termine el TTL de un datagrama en un router, se envía un mensaje ICMP al origen
de ese datagrama, es decir al host que lo envió. Cabe destacar que el destinatario de un mensaje ICMP
puede estar en otra red, por lo que hay que reenviarlo.
Si por ejemplo, PCA genera un datagrama con X = 2, cuando este llegue a R3, va a ser descartado.
Entonces R3 va a enviar un mensaje ICMP a PCA. Este mensaje ICMP se encapsula en un datagrama. Este
datagrama va a tener como destino, el origen del datagrama original, que fue descartado por R3. Es
decir, la IP de PCA. Y como origen, la interfaz de R3, el router que lo descartó, que esté más cerca de
PCA.

Pero el hecho de que el TTL llegue a 0, es solo uno de muchos eventos que provocan un mensaje ICMP.
Por ejemplo, si el datagrama llega al host PCC, y está dirigido a un puerto que no está activo, también se
genera un mensaje ICMP. Lo va a generar el host. El error se da cuando el datagrama tiene que pasar a
las capas superiores. Ya está en el destinatario final, por lo que este genera el mensaje ICMP.

Anteriormente mencionamos que el

destinatario de un mensaje ICMP puede
estar en otra red, como en todos los
ejemplos que estuvimos viendo. Esto nos
dice que entonces, para llegar al origen,
este mensaje ICMP debe ser reenviado.
Esta es la razón por la que este se
encapsula en un datagrama, porque el
que sabe hacer forwarding es IP.

Entonces podemos decir correctamente

que ICMP usa los servicios de IP, pero no
es un protocolo de transporte. ¿Qué pasa entonces si un datagrama que lleva un mensaje de error se
descarta? Porque este tiene la misma probabilidad de ser descartado que un datagrama común y
corriente.

La respuesta es que cuando un datagrama con un mensaje ICMP de error se descarta, no se genera un
nuevo mensaje de error ICMP. Pero si el mensaje ICMP es de control, si se genera un mensaje de error
ICMP. Cada mensaje ICMP tiene su propio formato. Sin embargo, todos los mensajes ICMP comienzan
con los mismos tres campos

Cada mensaje ICMP tiene su propio

formato. Sin embargo, todos los mensajes
ICMP compienzan con los mismos tres
campos. La combinación de los primeros
dos campos (TIPO + CODIGO) identifica la
situación que provocó el error o el tipo de
mensaje de control del que estamos
hablando. EL checksum es para control de errores. Y por ultimo el cuerpo depende de si es un mensaje
de control o error ICMP. Lo que cambia entre error y control es lo que pongo en el cuerpo del mensaje.
Si es de error, en el cuerpo viaja el encabezado y los primeros bytes de datos del datagrama que
provoco el error. En mensajes de control el uso de este campo queda sujeto al tipo de mensaje de
control.

Entonces siguiendo la línea del ejemplo anterior, cuando el TTL del datagrama que viene de PCA a PCC
se agota en R3, este genera un ICMP destinado a PCA con un tipo y código que indica que el problema es
 que el TTL llegó a 0. A su vez
este ICMP debe decirle a PCA
cual fue el datagrama que
falló. Entonces para eso en el cuerpo
del mensaje ICMP se copia el encabezado del
datagrama descartado por provocar un
error. Si el mensaje es de control, cada
tipo de mensaje de control hace un uso
específico del cuerpo del mensaje para poner datos
que necesita esa funcion de control.

Cuando un router tiene que generar un mensaje ICMP

porque el TTL expiró, se crea un nuevo datagrama en el cual el origen es el router que lo generó y el
destino es el origen del datagrama que falló. Cabe destacar, que el router que genera el mensaje ICMP
debe tener en sus tablas la información necesaria para enviar datagramas al origen, es decir a PCA,
porque es posible que con tablas incompletas, un router solo pueda transmitir datagramas en un
sentido.

El programa ping es una herramienta de diagnostico fundamental para configurar, para saber y
comprobar si hay conectividad con ciertos routers o hosts etc. Este trabaja con dos tipos de mensajes
ICMP. Uno es Echo Request. Cualquier dispositico que recibe un Echo Request ICMP crea un Echo Reply

ICMP y devuelve la respuesta a la computadora original. Se puede usar para verificar si un destino es
alcanzable y responde, o si hay conectividad entre origen y destino.

Por ejemplo, en A escribo ping 10.3.3.1. Se genera un mensaje ICMP de Echo Request que tiene tipo 8 y
código 0, y tiene un identificador y un numero de secuencia, además de poder llevar datos opcionales
puesto que ping tiene muchos modificadores. Claro que en el encabezado IP de este mensaje están el
origen, el cual es 10.1.1.1 y destino, 10.3.3.1. Entonces el datagrama llega a C. Ahí se desarma y el
protocolo IP le pasa el contenido del datagrama al protocolo ICMP, el cual analiza el tipo y codigo y
genera la respuesta. Esta es un Echo Reply de tipo 0 y código 0. En esta se copia el identificador y la
secuencia que recibió de forma que cuando la PCA reciba la respuesta pueda vincularla con el Request
correspondiente y si el Request llevaba datos se copian en el Reply.
Sin embargo, cada vez que un error le impide a un ruteador reevniar o entregar un datagrama, el
ruteador genera y envía un mensaje de Destination Unreachable(type 3)

Ejemplos donde se generan mensajes ICMP tipo 3:

- El destino es inalcanzable porque la red subyacente está temporalmente fuera de servicio

- Porque el emisor especificó una dirección destino inexistente
- Porque el ruteador no tiene una ruta hacia la red destino
- Si en el host de destino el módulo IP no puede enviar el datagrama debido a que el módulo IP no
está disponible

Vamos a tomar un caso en el que la topografía es como la que mostramos recién y las tablas son las
siguientes (solo con entregas indirectas):

R1

DESTINO/MASK NEXT HOP INTERFAZ

0.0.0.0/0 192.168.1.3 INT5

R3

DESTINO/MASK NEXT HOP INTERFAZ

10.1.1.0/24 192.168.1.1 INT5

PCA

DESTINO/MASK NEXT HOP INTERFAZ

0.0.0.0/0 10.1.1.254 INT0

PCC

DESTINO/MASK NEXT HOP INTERFAZ

0.0.0.0/0 10.3.3.126 INT0

Supongamos que:

- En A escribimos ping 10.4.4.4.

Viendo la topología, nuestro sentido común nos dice que no existe el destino, pero recordemos que
los dispositivos no tiene esta vista. Entonces cada dispositivo va a hacer lo que pueda. Entonces:

- A va a armar un mensaje ICMP de control de Echo Request (T = 8, C = 0) con identificador y

secuencia.
- Lo mete en un datagrama con origen 10.1.1.1 y destino 10.4.4.4.
- A mira su tabla y envía este datagrama por su default router, que es R1.
 - Ahora le toca a R1 reenviarlo. Con lo que tiene en su tabla, decide enviarlo por el default router
nuevamente, hacia R3.
- Ahora con la información disponible en su tabla, R3 na sabe que hacer, entonces lo descarta y
genera un mensaje ICMP de error de tipo Network Unreachable (T = 3, C = 0).
- Lo mete en un datagrama con origen 192.168.1.3, una de las IPs de R3, y con destino 10.1.1.1.
- Con la información en la tabla de R3, el datagrama sale hacia R1.
- Una vez en R1, nos damos cuenta que este puede hacer entrega directa al destinatario final
(10.1.1.1).
- El mensaje de Network Unreachable llega a PCA.

Ahora vamos a hacer un cambio en las tablas, más específicamente donde la tabla de R3 queda sin
configurar, para modelar otro caso probable:

R3

DESTINO/MASK NEXT HOP INTERFAZ

10.1.1.0/24 192.168.1.1 INT5

Supongamos que:

- En A escribimos ping 10.3.3.1, un destino que sabemos que existe

- Se genera un mensaje ICMP de tipo Echo Request (T = 8, C = 0) con identificador y secuencia
- Lo mete en un datagrama con origen 10.1.1.1 y destino 10.3.3.1.
- A mira su tabla y envía este datagrama por su default router, que es R1.
- Ahora le toca a R1 reenviarlo. Con lo que tiene en su tabla, decide enviarlo por el default router
nuevamente, hacia R3.
- Por mas que no tenga configurada ninguna fila de entrega indirecta, R3 puede entregar el
datagrama al destino final mediante entrega directa.

Cabe destacar que la única manera de que R3 no pueda hacer entrega directa es no tener
configurada la interfaz o estar desconectado de la red.

- El datagrama con el Echo Request llega satisfactoria a PCC.

- PCC toma el Echo Request, se lo entrega al ICMP el cual genera un Echo Reply.
- Lo mete en un datagrama con origen 10.3.3.1 y destino 10.1.1.1.
- PCC mira su tabla, y decide enviar el datagrama a R3, su ruta por omisión.
- Sin embargo R3 no tiene información suficiente para adelantar el datagrama con destino
10.1.1.1, entonces lo descarta y genera un mensaje de error ICMP de tipo Network Unreachable
(T = 3, C = 0).
- Lo mete en un datagrama con origen 10.3.3.126 y destino 10.3.3.1, PCC.
- Lo envía por entrega directa a PCC sin problema.

Podemos ver que PCA no recibió nada. Sin embargo PCA tiene un temporizador, el cual se agota y le
muestra al usuario un mensaje de “Tiempo de espera agotado para esta solicitud”. Podemos ver que con
esta configuración de tablas, si el Echo Request proviene de PCC, el error se va a generar en R3, y el
mensaje de error va a volver al origen de donde partio este Echo Request, la misma PCC, pero que si el
Echo Request parte de PCA, nunca va a llegar un mensaje ICMP de error a PCA.
Hay dos lecciones importantes para sacar de este ejemplo:

1) Una vez que el router está directamente conectado al destino final la entrega se hace, puesto
que la entrega directa siempre es posible y tiene prioridad por sobre la entrega indirecta.
2) Si el error lo provoca el Echo Request, voy a recibir un mensaje ICMP de error (Nerwork
Unreachable). Pero si el mensaje de error lo genera el Echo Reply, no voy a recibir un mensaje
de error ICMP, en cambio un mensaje de tiempo de espera agotado. Si estamos trabajando en
un laboratorio, podemos en este caso, pararnos en el destino del Echo Request y hacer un ping
en el sentido contrario. Porque como dijimos en el ultimo ejemplo, ahora si vamos a recibir el
mensaje de error ICMP, y podemos deducir que el problema esta en uno de los saltos del
camino.

SOLICITUDES DE CAMBIO DE RUTA DESDE LOS ROUTERS

Hay un mensaje especial que es raro pero puede aparecer. Se asume que los routers conocen rutas. Los
hosts comienzan con la info miunima de ruteo y aprenden nuevas rutas de los ruteadores.