Matías Baeza Graf #29654

2021

Clase 3 – Redes II 2021

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
Matías Baeza Graf #29654
2021

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.
Matías Baeza Graf #29654
2021

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
Matías Baeza Graf #29654
2021

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
Matías Baeza Graf #29654
2021

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:
Matías Baeza Graf #29654
2021

- 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.
Matías Baeza Graf #29654
2021

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.