Saltar navegación

Video sobre ICMP- Redes

Ajuste de pantalla

El ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:

Subido el 13 de agosto de 2023 por Eva Concepciã³N L.

5 visualizaciones

Más información Transcripción

Descargar la transcripción

A continuación vamos a empezar a ver en este tema el protocolo ICMP, que significa Protocolo de Control de Mensajes en Internet. 00:00:02
El problema que tiene el protocolo IP, básicamente os acordáis que era un protocolo que cuando se producía un determinado error, como por ejemplo, os acordáis el TTL. 00:00:13
el TTL era el tiempo de vida de un paquete, es el tiempo máximo que puede circular por la red 00:00:28
por cada salto que iba dando a lo largo de la red, es decir, por cada router que iba atravesando 00:00:33
ese TTL disminuía en una unidad y cuando llegaba a un valor cero directamente 00:00:39
ese equipo donde hubiera llegado ese paquete lo descarta 00:00:44
es decir, que los paquetes IP en la red tienen un tiempo definido 00:00:51
es decir, no pueden estar infinitamente en la red 00:01:00
si no estuviera este mecanismo, podría ocurrir lo que acabo de decir 00:01:02
que hubiera un paquete que por lo que sea las rutas no están bien definidas 00:01:07
o la ruta no existe y entonces estaría siempre dando vueltas por la red 00:01:10
y esto saturaría totalmente la red si no pasara en uno, sino si pasara en muchos paquetes 00:01:14
Por ello se utiliza este mecanismo del TTL 00:01:18
¿Qué ocurre? Que cuando llega un router que no puede enviarlo porque su TTL ha llegado a un valor cero y no lo puede seguir enviando 00:01:22
Lo que ocurre es que el origen no se entera de lo que ha ocurrido 00:01:32
Entonces para poder enterarse de lo que ha ocurrido aparece por medio el protocolo ICMP 00:01:38
ya que de por sí el protocolo IP no tiene un mecanismo para ser capaz de detectar qué es lo que ha ocurrido a lo largo de la red. 00:01:46
No solo con el TTL, como dice ahí, como por ejemplo cuando la red está congestionada, cuando se ha tenido que fragmentar un paquete, 00:01:54
es decir, cuando ha ocurrido algo en la red, o sea, el protocolo IP por sí mismo no tiene ninguna forma de avisar al origen de lo que ha pasado. 00:02:01
También se utiliza el ICMP para proporcionar mecanismo para determinar si algún equipo determinado está activo 00:02:10
Es decir, si funciona 00:02:26
Se utiliza sobre todo el comando PIN que ya hemos visto muchas veces en clases 00:02:27
Si yo envío un PIN lo que estoy enviando es una serie de paquetes a un equipo para que ese equipo me responda 00:02:34
Si el equipo no me responde significa o bien que lo lógico es que esté caído o bien que tiene algún tipo de mecanismo de seguridad que está evitando que envíe ese tipo de mensajes. 00:02:39
Entonces todo esto se soluciona con el protocolo ICMP. 00:02:51
Entonces el protocolo ICMP es un protocolo que nos va sobre todo a informar, informar de determinados problemas que se han producido en la red. 00:03:04
no corrige, como dice ahí, no corrige ningún tipo de error, ningún tipo de problema 00:03:16
sino simplemente informa 00:03:21
y los mensajes ICMP, como se pueden ver aquí en esta transferencia 00:03:23
lo que van son encapsulados 00:03:29
van encapsulados dentro del campo datos del datagrama IP 00:03:31
es decir, que normalmente, dentro del campo datos de un datagrama IP 00:03:38
lo que va a encapsular es lo que está por encima, el nivel superior. El nivel superior suele ser el protocolo de nivel de transporte. 00:03:45
Puede ser, lo lógico en Internet, será el UDP o el TCP. Sin embargo, en este caso, lo que va encapsulado es el protocolo ICMP. 00:03:52
El protocolo ICMP tiene su cabecera y tiene también sus datos, como todos los protocolos que hemos visto. 00:04:03
Vale, entonces podríamos pensar, vale, si dentro del campo datos el protocolo IP va encasulado el ICMP es porque el ICMP es un protocolo de nivel de transporte 00:04:09
Sin embargo, no, vale, el protocolo ICMP no se considera un protocolo de nivel de transporte, sino un protocolo de nivel de red 00:04:21
Como veis aquí, tanto el protocolo ARP como el ICMP, vale, son protocolos de nivel de red 00:04:27
están a la misma altura, aunque es verdad que si veis está un poquito más arriba el ICMP 00:04:34
y un poquito más abajo el protocolo ARP. 00:04:41
Pero son todos protocolos de nivel de red y además todo sistema que implemente el protocolo IP 00:04:45
también está obligado a implementar el protocolo ICMP. 00:04:53
Es decir, por ejemplo, utilizo Windows 10, que implementa o da servicios para proporcionar el protocolo IP, también tiene que dar servicio para el protocolo ICMP. 00:04:57
Aquí podemos ver cuál es la cabecera de un datagrama IP. 00:05:10
Vemos que el datagrama IP tiene su cabecera. 00:05:18
Como ya vimos en el protocolo IP tendrá dirección IP origen, dirección IP destino, el tipo de protocolo, si es IPv4, IPv6, etc. Es decir, una serie de opciones. 00:05:20
Y luego dentro, dentro, ¿vale? En los datos iría el mensaje ICMP que también tiene, como veis aquí, su propia cabecera. 00:05:31
¿Qué cabecera tiene? Tiene el campo tipo que utiliza 8-bit, el campo código 8-bit y el campo checksum y luego ya el contenido, los datos. 00:05:39
El campo tipo lo que me indica es el tipo de mensaje que se está enviando 00:05:48
Veremos que hay 15 tipos diferentes 00:05:54
El código nos da más información sobre el tipo de mensaje 00:05:56
Y el checksum se utiliza para comprobar si se ha producido algún tipo de error en los datos que estamos enviando 00:06:00
Recordar que el checksum era una especie de algoritmo que se calcula en base a todos los datos 00:06:08
Y en base a ese algoritmo se genera un número 00:06:14
Ese número se mete ahí en ese campo checksum. Cuando se llega al destino o al siguiente salto, en función de dónde se vaya a tratar el error, se vuelve a calcular el checksum del mensaje recibido. 00:06:17
Si el checksum es igual del destino que el del origen, entonces se considera que no ha habido error, pero si es diferente significa que ha habido un error en el paquete de datos. 00:06:32
es decir, donde había un 0 es probable que haya llegado un 1 00:06:41
y por lo tanto los datos no hayan llegado correctos 00:06:43
para eso valía el check or sum 00:06:45
y luego ya tenemos el contenido 00:06:47
el contenido del mensaje ICMP 00:06:50
veis aquí el contenido 00:06:53
pues dependiendo del tipo de mensaje 00:06:57
lleva un valor o lleva otro valor 00:07:00
si es un mensaje de error 00:07:02
lo que está llevando el ICMP 00:07:04
entonces lo que lleva dentro 00:07:08
son todos los valores de la cabecera IP 00:07:10
más los 8 primeros bytes del campo de datos 00:07:13
¿por qué los primeros 8 bytes del campo de datos? 00:07:16
se añaden los 8 primeros bytes del campo de datos 00:07:21
porque lo que hay encapsulado dentro del protocolo IP 00:07:34
es decir, dentro del campo datos del protocolo IP 00:07:40
Normalmente siempre es un protocolo de nivel superior 00:07:44
Que puede ser TCP o UDP 00:07:47
Entonces, el protocolo TCP o UDP 00:07:50
Tiene como su cabecera 00:07:54
Los primeros campos de su cabecera 00:07:58
Es el puerto liger y el puerto destino 00:08:01
Por eso, esos campos se añaden también al hacer el checksum 00:08:03
¿Por qué se hacen al acelerar? 00:08:08
por qué se añaden al hacer 00:08:11
perdonad el checksune en este nivel 00:08:14
por si ha habido un error 00:08:16
en esos campos que son uno de los más importantes 00:08:17
detectarlo 00:08:20
y en consecuencia 00:08:20
pues desechar el paquete 00:08:24
y avisar al origen 00:08:26
para que los vuelva a reenviar 00:08:27
entonces esos serían los 00:08:29
campos que tienen 00:08:34
y luego bueno el contenido 00:08:36
que es lo que acabamos de decir 00:08:37
que en el caso de que sea una consulta, bueno, pues llevará un tipo de información adicional. 00:08:39
Imaginaos que es un ping, ¿vale? 00:08:46
¿Qué tipo de información? Pues llevará unos determinados datos en el campo contenido. 00:08:47
Hay muchos tipos de mensajes ya ICMP predefinidos. 00:08:55
Aquí tenemos algunos ejemplos, como el tiempo de vida seguido, que hemos visto antes. 00:08:59
El de echo request y echo replay, que son los del ping. 00:09:03
cuando el paquete llega a un router que no es capaz de encaminar, ¿vale? 00:09:08
Entonces no se puede alcanzar el destino, etcétera, es decir, hay varios tipos de mensajes. 00:09:15
Aquí en la siguiente tabla podéis ver, en función del tipo de mensaje, ¿vale? 00:09:20
Pues el valor que se pondría en el campo tipo y código de la cabecera del protocolo ICMP. 00:09:24
Por ejemplo, si en el tipo viene un 0 y el código un 0, significa que es un reply del ping. 00:09:34
Sin embargo, si en el tipo lleva un 8 y en el código un 0, lo que lleva es un request, o sea, una petición del comando ping. 00:09:42
Aquí tenemos un ejemplo en el caso de que lo que queramos enviar es un ping a un determinado equipo. 00:09:57
si enviamos un ping a un determinado equipo 00:10:05
lo que estamos enviando realmente 00:10:08
es un mensaje ICMP 00:10:10
un mensaje ICMP 00:10:12
encapsulado en un paquete IP 00:10:14
dentro de ese mensaje 00:10:16
ICMP, su cabecera 00:10:18
en el campo tipo 00:10:20
vendrá un 8 o un 0 00:10:21
dependiendo si es una petición o es la respuesta 00:10:24
del ping, en el campo 00:10:26
código vendrá un 0, luego el checksum 00:10:28
que tendrá su valor correspondiente 00:10:30
que se tendrá que calcular 00:10:32
y luego veis que también tiene una serie de campos adicionales 00:10:33
en el caso de que sea uno de estos dos tipos de mensajes 00:10:38
echo o request, que tiene un identificador, una secuencia 00:10:41
y una serie de datos adicionales 00:10:46
en el caso de que los mensajes sean mensajes 00:10:48
de errores, es decir, que se haya producido un error como por ejemplo 00:10:53
el TTL excedido o que por ejemplo 00:10:57
el paquete no pueda 00:11:01
alcanzar su destino, ¿vale? porque el router 00:11:04
no puede encaminarlo, pues entonces 00:11:06
lo que se hace es avisar 00:11:08
normalmente desechar 00:11:10
al mensaje, ¿vale? y avisar al destino 00:11:13
de que al origen 00:11:16
con un mensaje ICMP 00:11:18
en el caso de que se haya producido 00:11:20
¿vale? a uno 00:11:22
de esas posibles causas 00:11:23
sin embargo, imaginaros que lo que se ha producido es un error 00:11:25
del paquete 00:11:28
Es decir, el campo checksum se calcula, se comprueba que ese paquete que se está enviando tiene un error, ¿vale? 00:11:30
En ese caso, como dice ahí, no se corrige el error y ya será el nivel superior que decida qué hacer con esos paquetes. 00:11:37
Así que es importante que cuando se produce un error, no siempre se generan mensajes ICMP. 00:11:44
Por ejemplo, imaginaos en el caso de que el error se produzca en un propio mensaje ICMP, 00:11:50
de request o de reply 00:11:55
bueno, request o reply no porque no son 00:11:58
mensajes de error, son mensajes de 00:12:01
consulta, sino por ejemplo 00:12:03
un TTL excedido, se ha excedido el tiempo 00:12:05
se produce 00:12:07
un error, se envía un mensaje 00:12:09
ICMP avisando el origen 00:12:11
pero ese propio mensaje ICMP 00:12:13
sufre un error a lo largo del camino 00:12:15
bueno, pues en ese caso 00:12:17
no se vuelve a generar 00:12:19
un mensaje ICMP por cada uno de los 00:12:21
mensajes de error vale porque si no al final se generaría muchísimo tráfico 00:12:23
porque dice ahí para un datagrama fragmentado que no sea el primero 00:12:27
normalmente cuando se fragmenta un paquete también se avisa al origen con 00:12:31
un mensaje y cmd que se haya producido una fragmentación pero no se avisa por 00:12:34
cada uno de los fragmentos en los que se va dividiendo el paquete es decir 00:12:40
imaginaos pasa por un mensaje por un router y éste lo fragmenta a su vez 00:12:44
luego es cada uno de estos mensajes para esa por otro router que se fragmenta 00:12:49
otra vez y sucesivamente vale por cada mensaje fragmentado no se avisa sino únicamente se avisa 00:12:52
con el primero porque si no también se genera generaría muchísimo tráfico y tampoco se informa 00:12:59
no se envían mensajes y cmp muy de ahí de data gramos que utilizan direcciones múltiples o 00:13:06
direcciones especiales como por ejemplo la de las del local host que identifican a nuestra a 00:13:10
nuestra propia equipo, nuestra propia red. Aquí tenemos un ejemplo, por ejemplo, 00:13:18
cuando se genera el mensaje del destino inalcanzable. 00:13:23
Imaginad, llega un paquete, el router no es capaz de enviarlo, entonces avisa al 00:13:29
origen un mensaje ICMP de que no ha podido encaminar ese paquete. 00:13:33
Bueno, pues entonces también tiene una serie de campos, el ICMP en el campo tipo 00:13:38
con el valor 3, en el campo código con el valor 3 00:13:45
se calcula el checksum y luego bueno pues en este caso 00:13:48
lo que hace es enviar en los datos la cabecera IP 00:13:52
lo que hemos dicho antes, toda la cabecera IP más los primeros 8 bytes del datagrama IP 00:13:56
es decir los puertos, todos esos datos los envía en el mensaje 00:14:00
para que cuando lleguen al origen 00:14:03
el decida que hacer con esa información 00:14:07
También se utiliza mucho el protocolo ICMP conjuntamente con otro comando, aparte del PIN, que es el comando tracer o tracer router. 00:14:11
Dependiendo si lo utilizáis en Windows es el comando tracer, si lo utilizáis en Linux es el comando tracer router. 00:14:25
este comando básicamente lo que nos devuelve son aquellos nodos intermedios o equipos intermedios 00:14:32
por los que pasa un mensaje hasta llegar a su destino 00:14:41
por ejemplo si yo utilizo el comando y pongo tracer al www.google.es 00:14:45
lo que me va trazando es la ruta de todos los equipos o direcciones IP por las que va pasando mi equipo 00:14:50
o sea, ese paquete hasta llegar 00:14:57
a ese destino, en este caso el de Google 00:15:00
vamos a verlo con un ejemplo 00:15:02
vale, si en este caso 00:15:03
lo voy a hacer en Windows, se abre una consola 00:15:10
y pongo tracer 00:15:12
a www.google.es 00:15:13
lo he puesto mal 00:15:18
es tracer, que acaba en T 00:15:19
pues como veis ahí 00:15:24
primero traduce la dirección de Google 00:15:26
que es la 172.217.16.2.7 00:15:28
y luego me va indicando en orden 00:15:32
esos equipos intermedios que son routers 00:15:34
por los que va pasando 00:15:37
como veis ahí 00:15:39
primero dice que 00:15:44
el primer salto que ha dado 00:15:45
ese mensaje desde mi equipo 00:15:47
es a la IP 00:15:49
192.168.0.1 00:15:51
que será la dirección 00:15:54
la dirección de mi router 00:15:56
luego pasa a la siguiente 00:15:59
La 87, 235, 010 00:16:02
Luego la 10, 183, 51, 17 00:16:05
Luego veis que aparece 00:16:08
En el orden número 4 y 5 00:16:11
Aparecen asteriscos 00:16:14
Luego en la 6 00:16:15
Vuelven a aparecer otras IPs 00:16:17
Hasta la opción 9 00:16:19
Es decir, que para llegar 00:16:20
Mi mensaje desde mi máquina local 00:16:22
Hasta el www.google.es 00:16:25
Ha dado 9 saltos 00:16:29
Ha pasado por 9 enrutadores 00:16:30
hasta llegar al destino. 00:16:31
Cuando aparece un asterisco es porque normalmente esos routers 00:16:33
por los que ha llegado ese paquete 00:16:36
están por seguridad normalmente capados 00:16:40
para que no puedan enviar mensajes ICMP, 00:16:45
bien por seguridad o bien porque la red está congestionada en ese momento 00:16:48
y no se quiere generar más tráfico. 00:16:51
Y ahora vamos a verlo con un ejemplo. 00:17:04
Vamos a ver con un ejemplo cómo se van enviando esos mensajes ICMP 00:17:05
a través del comando trácer aquí tenemos un ejemplo una red de la que vemos un equipo a 00:17:09
un equipo p y desde a se hace un ping al 14 0 0 10 es decir perdona un pin un trácer un comando 00:17:16
trácer a b entonces qué es lo que se produce por debajo pues por debajo realmente lo que estamos 00:17:25
haciendo es lo siguiente es enviar un mensaje cuya ip origen es la de a cuya ip origen es la 00:17:32
de b cuyo valor ttl del protocolo ip se pone a uno y luego dentro lo que se envía es un 00:17:42
se encasula 00:17:54
el protocolo ICMP 00:17:56
vale, para avisar al origen 00:17:58
aquí tenemos 00:18:02
se puede ver un poco mejor 00:18:04
un segundito 00:18:05
bueno, vuelvo a repetir 00:18:08
vale, desde el equipo A 00:18:16
queremos enviar un mensaje al equipo B 00:18:18
un mensaje no, el comando traza 00:18:20
para ver la traza 00:18:22
para ir sabiendo, vale, por qué 00:18:23
por qué equipos intermedios vamos 00:18:25
se van a ir pasando hasta llegar a b 00:18:27
lo mismo que hemos hecho antes 00:18:30
con el ejemplo con google 00:18:32
entonces que es lo que hace a 00:18:33
lo que hace a es genera un mensaje 00:18:36
ip con la ip origen 00:18:38
la de a ip destino la de b 00:18:40
con el ttl lo que os he dicho antes 00:18:42
valor 1 00:18:44
y luego dentro 00:18:45
de los datos del protocolo 00:18:48
ip iría lo que está por encima 00:18:50
vale lo que está por encima 00:18:52
es el protocolo de nivel de transporte 00:18:54
que puede ser UDP o TCP 00:18:59
en este caso es UDP con un puerto origen 00:19:00
un puerto destino, etc. 00:19:03
eso nos interesa un poco menos 00:19:04
entonces ese mensaje se envía 00:19:05
para ello A mira su tabla de encaminamiento 00:19:08
y dice si yo quiero ir a B 00:19:12
mira su tabla y dice si lo tengo que enviar a R1 00:19:13
vale, entonces envía el mensaje a R1 00:19:16
cuando ese mensaje llega a R1 00:19:19
lo que hace R1 es disminuir el TTL de 1 a 0 00:19:22
por lo tanto al disminuir ese TTL de 1 a 0 00:19:27
lo que ocurre es que ese mensaje ya no lo puede seguir encaminando 00:19:32
y por lo tanto desecha ese mensaje, es decir, no va a llegar al destino 00:19:35
pero avisa al origen de que se ha producido un TTL excedido 00:19:39
¿Cómo lo avisa? Enviando un mensaje ICMP 00:19:45
que es el que está aquí en la parte de aquí abajo 00:19:49
envía un mensaje ICMP 00:19:51
que pone IP origen, en este caso 00:19:53
el de R1, que es quien va a avisar 00:19:55
IP destino, el de A 00:19:57
el TTL lo pone, bueno en este ejemplo 00:19:59
está puesto a 64, es decir 00:20:01
un valor alto para que llegue a su destino 00:20:03
y luego en tipo y código 00:20:06
pues pone los correspondientes 00:20:09
al TTL, al que correspondan 00:20:11
con el TTL excedido 00:20:13
para que cuando llegue al origen sepa de que tipo 00:20:15
es ese mensaje 00:20:17
Ese mensaje le llega a A 00:20:18
¿Vale? Y entonces ya puede apuntar 00:20:22
Puede apuntar cuál es el nodo por el que ha pasado 00:20:24
¿Cómo lo sabe? Mirando la IP origen de ese campo 00:20:28
O sea, la IP origen de ese mensaje que le acaba de llegar 00:20:33
Que es el 11.0.0.1 00:20:37
Que es el valor del R1 00:20:38
Y veis, lo apunta 00:20:41
Aquí en rojo, en un recuadro en rojo 00:20:42
Se va viendo lo que va generando el comando 00:20:44
Y pone 1, 11, 0, 0, 1 00:20:47
Es el primer salto 00:20:50
Vale, luego dice, vale, ya es el primer salto 00:20:51
Ahora debe ver el segundo salto 00:20:54
Y hace lo mismo que ha hecho antes 00:20:55
Pero generando un mensaje con el TTL igual a 2 00:20:56
Por tanto, ese mensaje igual a 00:21:00
Mira su tabla de encaminamiento 00:21:03
Dice, para ir a B lo tengo que enviar a R1 00:21:04
Ese campo llega a R1 00:21:07
R1 lo primero que hace es disminuir el TTL del 2 a 1 00:21:09
Y mira su tabla de encaminamiento 00:21:12
Y dice, vale, para ir a B 00:21:14
yo a quien tengo que enviárselo es a R3 00:21:16
y le llega a R3 00:21:18
R3 mira el paquete 00:21:21
el TTL lo disminuye una unidad 00:21:24
queda cero y dice ya no puedo seguir enviándolo 00:21:26
así que lo desecha y genera un mensaje ICMP 00:21:28
respuesta AAA 00:21:31
para eso igual genera como IP origen 00:21:34
pone la suya, la de R3 00:21:37
como IP destino la de A 00:21:38
un TTL en este caso 64 alto 00:21:40
para que le llegue a A 00:21:42
Y bueno, le pone los datos correspondientes a un mensaje ICMP de tipo TTL excedido 00:21:43
Que es el tipo 11, código 0 00:21:50
Y dice R3, vale, quiero enviárselo a, para enviárselo a 00:21:52
¿A quién se lo tengo que enviar? Mira su tabla de encaminamiento 00:21:56
Y dice, vale, se lo tengo que enviar a R1 00:21:59
Y se lo envía a R1 00:22:01
Y R1 cuando le llega, mira su tabla de encaminamiento 00:22:03
Y dice, vale, para llegar a A, ¿quién se lo tengo que enviar? 00:22:06
Vale, directamente a A y le llega el mensaje 00:22:08
Y ahí apunta, vale, que el siguiente salto es el 13003 que es el de R3 00:22:11
Y vuelve a hacer lo mismo, dice, vale, pues ahora vuelvo a generar otro mensaje pero con TTL igual a 3 00:22:18
Para enviarlo, mira su tabla de encaminamiento 00:22:24
A dice, para llevarle a B tengo que enviárselo a R1 00:22:28
R1 disminuye el TTL en una unidad y dice, vale, para enviárselo a B tengo que enviárselo a R3 00:22:31
R3 mira su tabla de encaminamiento 00:22:38
Disminuye una unidad 00:22:40
El TTL dice, vale, para enviarse la B 00:22:41
Se lo envío a R4 00:22:43
Cuando llega a R4 00:22:44
R4 disminuye en una unidad el TTL 00:22:47
Y lo pone a 0 00:22:49
Con lo cual ya no puede seguir enviándolo 00:22:50
Genera un mensaje ICMP igual que antes 00:22:52
De tipo TTL 00:22:55
Estebido 00:22:57
Y lo que pone es como su IP origen 00:22:59
La suya, R4 00:23:01
Y ese mensaje se lo envía a A 00:23:02
Ahora para enviárselo a A 00:23:04
Mira su tabla de encaminamiento 00:23:06
y dice, vale, para enviárselo a, resulta que tengo que enviársela por R2 00:23:07
bueno, pues no pasa nada, lo envía por otra ruta 00:23:10
pero le va a llegar igualmente a R4, lo envía a R2 00:23:13
R2, mira, su tabla de encaminamiento 00:23:16
dice, para llegar a A, se lo tengo que enviar a R1 00:23:19
y R1 hace lo mismo, dice, vale, para enviar a 00:23:24
A, se lo tengo que enviar directamente ya 00:23:26
o sea, ya está directamente conectado a mí, se lo envía 00:23:29
A con G, ese paquete, apunta 00:23:32
el IP origen y ya sabe que 00:23:35
el siguiente salto 00:23:37
era el de R4 00:23:39
y ahora 00:23:41
vuelve a hacer lo mismo, envía otro paquete 00:23:43
pero ahora con TTL igual a 4 00:23:45
hace exactamente lo mismo 00:23:47
de A lo envía R1 00:23:49
de R1 a R3, de R3 a R4 00:23:51
cuando el mensaje 00:23:53
le llega a R4, el TTL 00:23:55
lo puede disminuir a una unidad 00:23:57
si no llega a 0 no hay problema, así que se lo puede 00:23:59
enviar ya al destino que sabe 00:24:01
Ese mensaje le llega a P 00:24:03
Y lo que hace B, dice, vale, ahora 00:24:05
Lo que voy a hacer es contestar 00:24:07
Al mensaje que me ha enviado A 00:24:09
Vale, contesto 00:24:11
Y para contestarle 00:24:12
Mira su tabla de encaminamiento 00:24:16
Y dice, vale, para enviar algo a A 00:24:17
Se lo tengo que enviar a 00:24:19
En este caso, vale, a 00:24:21
Está en la red 11 00:24:23
Al 14.002 00:24:25
Es decir, por R2, vale, pues 00:24:27
B se lo envía 00:24:29
A R2 00:24:31
perdonad, a R4 se lo envía a R2 00:24:32
R2 envía a su tabla de encaminamiento 00:24:35
y dice para enviar a A se lo envía a R1 00:24:37
y R1 a A 00:24:39
y cuando le llega a A ya puede apuntar 00:24:41
que el siguiente salto es el que corresponda 00:24:43
y de esa manera funciona 00:24:46
el comando tracerrote 00:24:47
en este caso, en este ejemplo lo hemos visto 00:24:49
solamente enviando un datagrama 00:24:51
pero realmente lo que envía son 3 datagramas 00:24:53
es decir, primero envía 1, 2 y 3 seguidos 00:24:55
esos 3 datagramas, primero le envía 00:24:59
con ttl igual a 1, luego con ttl igual a 2, luego con ttl igual a 3, con ttl igual a 4 y así hasta que 00:25:01
llegue a su destino. En este caso hemos utilizado hasta un ttl igual a 4 pero en el ejemplo que 00:25:07
veíamos antes al hacer un tráfer a google había hasta nueve saltos así que internamente es como 00:25:13
si estuvieran enviando nueve veces el paquete, uno con ttl igual a 1, tres mensajes con ttl igual a 1, 00:25:19
tres mensajes con ttl igual a 2 00:25:28
tres con ttl igual a 3 00:25:30
y así hasta el último con ttl igual a 9 00:25:32
así es como 00:25:34
funciona este comando 00:25:36
como hemos visto antes 00:25:38
en el ejemplo de google 00:25:45
en algún momento puede ocurrir 00:25:47
que imprima un asterisco 00:25:49
y es por lo que os he dicho antes 00:25:50
puede imprimir un asterisco porque cuando llega 00:25:52
ese mensaje a ese nodo intermedio 00:25:54
puede ocurrir que ese nodo intermedio 00:25:56
esté configurado para que 00:25:59
no envíe mensajes ICMP 00:26:01
del tipo que sea, puede ser solo de 00:26:03
TTL o de todos los tipos 00:26:05
en cuyo caso, ¿vale? no se envía 00:26:06
un mensaje, el nodo espera un tiempo 00:26:09
no recibe el mensaje y por lo tanto 00:26:11
marca un asterisco 00:26:12
también puede ocurrir porque 00:26:14
cuando llegue ese paquete 00:26:16
a ese nuevo intermedio, ese nuevo intermedio 00:26:18
por lo que sea, no esté configurado para encaminar 00:26:20
el paquete al origen y por lo tanto tampoco 00:26:23
sepa llegar, o también puede ser 00:26:25
que esté configurado para que no genere más 00:26:27
tráfico de manera temporal porque 00:26:29
la red esté congestionada, entonces ese mensaje 00:26:30
tampoco llegará al origen 00:26:33
entonces en ese campo siempre se pone el asterisco 00:26:34
aquí tenéis una captura del ejemplo 00:26:37
que hemos visto antes 00:26:41
y luego tenemos el 00:26:43
protocolo ICMP versión 6 00:26:45
que sería 00:26:47
utilizado conjuntamente 00:26:48
con el protocolo IPv6 00:26:51
es muy parecido al 00:26:52
protocolo ICMP 00:26:54
la única diferencia 00:26:56
es que en el campo tipo 00:26:57
utiliza un valor menor que 128 00:27:00
y en el código 00:27:02
utiliza otro 00:27:03
otro valor 00:27:06
un valor mayor que 00:27:08
perdonad 00:27:09
la única diferencia es que 00:27:12
según los tipos de mensajes 00:27:14
recordad que podían ser mensajes de error 00:27:16
o mensajes de consulta 00:27:18
y son mensajes de error el campo tipo 00:27:19
tiene un valor menor que 128 00:27:22
y si es un mensaje de consulta 00:27:23
de información 00:27:25
como por ejemplo un request 00:27:26
es un replay del tiempo es lo que utilizan ese campo tipo es un valor mayor que 128 hay muchos 00:27:29
tipos de mensajes y cmp casi todos los mismos que en icmp versión 4 que además añaden algunos 00:27:35
especiales como son para el descubrimiento de vecinos para el descubrimiento multicast aquí 00:27:41
tenemos algunos algunos de ellos vale y podemos ver según el tipo vale pues a qué corresponde 00:27:51
cada uno de ellos 00:27:58
no hace falta aprendérselo de memoria 00:27:59
y lo único que 00:28:02
si cambia con respecto 00:28:06
al ICMP versión 4 00:28:08
es que al hacer el checksum 00:28:10
recordar que el checksum 00:28:14
es un cálculo 00:28:15
que se hacía 00:28:18
para verificar si había un error 00:28:20
en los datos 00:28:22
en el caso de ICMP versión 4 00:28:24
el check se hacían sobre todos los datos ICMP, es decir, sobre toda la cabecera y los datos 00:28:26
del protocolo ICMP. Sin embargo, en ICMPv6, aparte de esos datos, también se calcula 00:28:31
sobre una parte, como dice aquí, sobre una pseudo cabecera, es decir, sobre una parte 00:28:41
de la cabecera IP 00:28:48
IPv6 00:28:50
sobre qué parte, pues la que tiene 00:28:52
la IPv6 origen, la IPv6 destino 00:28:54
y el campo 00:28:56
siguiente 00:28:58
cabecera 00:28:59
del protocolo IPv6 00:29:01
¿por qué? 00:29:05
porque en el protocolo IPv6 00:29:06
desaparece el campo 00:29:08
checksum del protocolo IPv6 00:29:10
por lo tanto 00:29:12
al desaparecer 00:29:14
ese valor 00:29:16
lo que hace el ICMP es añadir el checksum también sobre estos datos 00:29:17
de esa manera si se ha producido un error en la dirección IP origen o la dirección IP destino 00:29:23
pues es capaz de detectarlo 00:29:28
si no, no sería capaz de detectarlo 00:29:30
y como conclusión podemos ver aquí lo que nos pone 00:29:33
nos dice que ICMP es un mecanismo para gestionar los errores 00:29:38
es decir, no corrige, sino simplemente informa de que se han producido errores 00:29:42
de la capa del nivel de red, es decir, sobre el protocolo IP. 00:29:47
Los mensajes ICMP se envían como datagramas encasulados en paquetes IP 00:29:52
y quien envía esos datagramas ICMP normalmente siempre suele ser los routers, 00:29:57
que es donde se generan los errores. 00:30:04
Y bueno, aparte de errores 00:30:06
También se utilizan para 00:30:09
Para hacer consultas 00:30:10
Como por ejemplo 00:30:13
La utilización del comando ping 00:30:14
Y el comando tracer 00:30:16
Como hemos visto antes 00:30:17
Y si es necesario 00:30:18
Como dice aquí 00:30:21
No solamente los routers 00:30:22
Pueden generar esos mensajes ICMP 00:30:23
Sino también 00:30:25
Aquí en el último punto 00:30:26
Dice que los hosts 00:30:27
También pueden usar 00:30:28
Los equipos finales 00:30:29
Pueden usar 00:30:30
Utilizar y enviar esos mensajes ICMP 00:30:31
¿En qué caso? 00:30:34
Pues por ejemplo 00:30:35
en el caso de fragmentación. Por ejemplo, en IPv6 recordar que no se pueden fragmentar 00:30:36
los paquetes, es decir, que los mensajes desde el origen tienen que ir ya fragmentados, mientras 00:30:46
que en IPv4 los mensajes a lo largo del camino pueden ir fragmentándose en trozos más pequeños. 00:30:54
Sin embargo en IPv6 no, por lo tanto IPv6 sí que puede utilizar este mecanismo para determinar cuál es el tamaño máximo de paquete que puede enviar a la red a través de mensajes ICMP, calcular cuál es ese tamaño máximo y en función de eso enviar los paquetes ya fragmentados al valor que correspondan. 00:31:00
En este caso, estos paquetes los enviaría el propio host para calcular cuál es el tamaño máximo de cada paquete que puede viajar por la red. 00:31:26
Con esto hemos terminado el protocolo ICMP. 00:31:36
Subido por:
Eva Concepciã³N L.
Licencia:
Reconocimiento
Visualizaciones:
5
Fecha:
13 de agosto de 2023 - 17:19
Visibilidad:
Clave
Centro:
IES TETUAN DE LAS VICTORIAS
Duración:
31′ 41″
Relación de aspecto:
1.88:1
Resolución:
1092x582 píxeles
Tamaño:
59.34 MBytes

Del mismo autor…

Ver más del mismo autor

EducaMadrid, Plataforma Educativa de la Comunidad de Madrid

Plataforma Educativa EducaMadrid