1 00:00:02,609 --> 00:00:12,109 A continuación vamos a empezar a ver en este tema el protocolo ICMP, que significa Protocolo de Control de Mensajes en Internet. 2 00:00:13,550 --> 00:00:28,829 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. 3 00:00:28,829 --> 00:00:33,229 el TTL era el tiempo de vida de un paquete, es el tiempo máximo que puede circular por la red 4 00:00:33,229 --> 00:00:39,109 por cada salto que iba dando a lo largo de la red, es decir, por cada router que iba atravesando 5 00:00:39,109 --> 00:00:44,850 ese TTL disminuía en una unidad y cuando llegaba a un valor cero directamente 6 00:00:44,850 --> 00:00:51,409 ese equipo donde hubiera llegado ese paquete lo descarta 7 00:00:51,409 --> 00:01:00,210 es decir, que los paquetes IP en la red tienen un tiempo definido 8 00:01:00,210 --> 00:01:02,490 es decir, no pueden estar infinitamente en la red 9 00:01:02,490 --> 00:01:07,170 si no estuviera este mecanismo, podría ocurrir lo que acabo de decir 10 00:01:07,170 --> 00:01:10,629 que hubiera un paquete que por lo que sea las rutas no están bien definidas 11 00:01:10,629 --> 00:01:14,430 o la ruta no existe y entonces estaría siempre dando vueltas por la red 12 00:01:14,430 --> 00:01:18,870 y esto saturaría totalmente la red si no pasara en uno, sino si pasara en muchos paquetes 13 00:01:18,870 --> 00:01:22,209 Por ello se utiliza este mecanismo del TTL 14 00:01:22,209 --> 00:01:32,950 ¿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 15 00:01:32,950 --> 00:01:38,650 Lo que ocurre es que el origen no se entera de lo que ha ocurrido 16 00:01:38,650 --> 00:01:46,209 Entonces para poder enterarse de lo que ha ocurrido aparece por medio el protocolo ICMP 17 00:01:46,209 --> 00:01:53,510 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. 18 00:01:54,450 --> 00:02:00,930 No solo con el TTL, como dice ahí, como por ejemplo cuando la red está congestionada, cuando se ha tenido que fragmentar un paquete, 19 00:02:01,489 --> 00:02:10,949 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. 20 00:02:10,949 --> 00:02:26,490 También se utiliza el ICMP para proporcionar mecanismo para determinar si algún equipo determinado está activo 21 00:02:26,490 --> 00:02:27,810 Es decir, si funciona 22 00:02:27,810 --> 00:02:34,509 Se utiliza sobre todo el comando PIN que ya hemos visto muchas veces en clases 23 00:02:34,509 --> 00:02:39,889 Si yo envío un PIN lo que estoy enviando es una serie de paquetes a un equipo para que ese equipo me responda 24 00:02:39,889 --> 00:02:50,770 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. 25 00:02:51,729 --> 00:02:54,550 Entonces todo esto se soluciona con el protocolo ICMP. 26 00:03:04,680 --> 00:03:16,860 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. 27 00:03:16,860 --> 00:03:21,139 no corrige, como dice ahí, no corrige ningún tipo de error, ningún tipo de problema 28 00:03:21,139 --> 00:03:23,020 sino simplemente informa 29 00:03:23,020 --> 00:03:29,400 y los mensajes ICMP, como se pueden ver aquí en esta transferencia 30 00:03:29,400 --> 00:03:31,979 lo que van son encapsulados 31 00:03:31,979 --> 00:03:38,520 van encapsulados dentro del campo datos del datagrama IP 32 00:03:38,520 --> 00:03:45,439 es decir, que normalmente, dentro del campo datos de un datagrama IP 33 00:03:45,439 --> 00:03:52,539 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. 34 00:03:52,800 --> 00:04:02,419 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. 35 00:04:03,080 --> 00:04:09,560 El protocolo ICMP tiene su cabecera y tiene también sus datos, como todos los protocolos que hemos visto. 36 00:04:09,560 --> 00:04:21,160 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 37 00:04:21,160 --> 00:04:27,560 Sin embargo, no, vale, el protocolo ICMP no se considera un protocolo de nivel de transporte, sino un protocolo de nivel de red 38 00:04:27,560 --> 00:04:34,980 Como veis aquí, tanto el protocolo ARP como el ICMP, vale, son protocolos de nivel de red 39 00:04:34,980 --> 00:04:41,240 están a la misma altura, aunque es verdad que si veis está un poquito más arriba el ICMP 40 00:04:41,240 --> 00:04:43,819 y un poquito más abajo el protocolo ARP. 41 00:04:45,819 --> 00:04:53,139 Pero son todos protocolos de nivel de red y además todo sistema que implemente el protocolo IP 42 00:04:53,139 --> 00:04:57,319 también está obligado a implementar el protocolo ICMP. 43 00:04:57,319 --> 00:05:07,899 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. 44 00:05:10,379 --> 00:05:17,600 Aquí podemos ver cuál es la cabecera de un datagrama IP. 45 00:05:18,160 --> 00:05:20,180 Vemos que el datagrama IP tiene su cabecera. 46 00:05:20,180 --> 00:05:31,079 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. 47 00:05:31,819 --> 00:05:38,720 Y luego dentro, dentro, ¿vale? En los datos iría el mensaje ICMP que también tiene, como veis aquí, su propia cabecera. 48 00:05:39,439 --> 00:05:48,240 ¿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. 49 00:05:48,240 --> 00:05:54,779 El campo tipo lo que me indica es el tipo de mensaje que se está enviando 50 00:05:54,779 --> 00:05:56,660 Veremos que hay 15 tipos diferentes 51 00:05:56,660 --> 00:06:00,639 El código nos da más información sobre el tipo de mensaje 52 00:06:00,639 --> 00:06:08,199 Y el checksum se utiliza para comprobar si se ha producido algún tipo de error en los datos que estamos enviando 53 00:06:08,199 --> 00:06:14,160 Recordar que el checksum era una especie de algoritmo que se calcula en base a todos los datos 54 00:06:14,160 --> 00:06:17,720 Y en base a ese algoritmo se genera un número 55 00:06:17,720 --> 00:06:31,660 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. 56 00:06:32,060 --> 00:06:41,100 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. 57 00:06:41,100 --> 00:06:43,439 es decir, donde había un 0 es probable que haya llegado un 1 58 00:06:43,439 --> 00:06:45,800 y por lo tanto los datos no hayan llegado correctos 59 00:06:45,800 --> 00:06:47,639 para eso valía el check or sum 60 00:06:47,639 --> 00:06:50,740 y luego ya tenemos el contenido 61 00:06:50,740 --> 00:06:53,459 el contenido del mensaje ICMP 62 00:06:53,459 --> 00:06:57,100 veis aquí el contenido 63 00:06:57,100 --> 00:07:00,019 pues dependiendo del tipo de mensaje 64 00:07:00,019 --> 00:07:02,399 lleva un valor o lleva otro valor 65 00:07:02,399 --> 00:07:04,800 si es un mensaje de error 66 00:07:04,800 --> 00:07:08,579 lo que está llevando el ICMP 67 00:07:08,579 --> 00:07:10,399 entonces lo que lleva dentro 68 00:07:10,399 --> 00:07:13,800 son todos los valores de la cabecera IP 69 00:07:13,800 --> 00:07:16,439 más los 8 primeros bytes del campo de datos 70 00:07:16,439 --> 00:07:20,540 ¿por qué los primeros 8 bytes del campo de datos? 71 00:07:21,819 --> 00:07:34,370 se añaden los 8 primeros bytes del campo de datos 72 00:07:34,370 --> 00:07:40,629 porque lo que hay encapsulado dentro del protocolo IP 73 00:07:40,629 --> 00:07:44,449 es decir, dentro del campo datos del protocolo IP 74 00:07:44,449 --> 00:07:47,449 Normalmente siempre es un protocolo de nivel superior 75 00:07:47,449 --> 00:07:50,670 Que puede ser TCP o UDP 76 00:07:50,670 --> 00:07:54,670 Entonces, el protocolo TCP o UDP 77 00:07:54,670 --> 00:07:58,629 Tiene como su cabecera 78 00:07:58,629 --> 00:08:01,430 Los primeros campos de su cabecera 79 00:08:01,430 --> 00:08:03,509 Es el puerto liger y el puerto destino 80 00:08:03,509 --> 00:08:08,110 Por eso, esos campos se añaden también al hacer el checksum 81 00:08:08,110 --> 00:08:11,449 ¿Por qué se hacen al acelerar? 82 00:08:11,449 --> 00:08:14,089 por qué se añaden al hacer 83 00:08:14,089 --> 00:08:16,329 perdonad el checksune en este nivel 84 00:08:16,329 --> 00:08:17,689 por si ha habido un error 85 00:08:17,689 --> 00:08:20,129 en esos campos que son uno de los más importantes 86 00:08:20,129 --> 00:08:20,870 detectarlo 87 00:08:20,870 --> 00:08:24,730 y en consecuencia 88 00:08:24,730 --> 00:08:26,649 pues desechar el paquete 89 00:08:26,649 --> 00:08:27,949 y avisar al origen 90 00:08:27,949 --> 00:08:29,389 para que los vuelva a reenviar 91 00:08:29,389 --> 00:08:34,250 entonces esos serían los 92 00:08:34,250 --> 00:08:36,230 campos que tienen 93 00:08:36,230 --> 00:08:37,570 y luego bueno el contenido 94 00:08:37,570 --> 00:08:39,649 que es lo que acabamos de decir 95 00:08:39,649 --> 00:08:45,870 que en el caso de que sea una consulta, bueno, pues llevará un tipo de información adicional. 96 00:08:46,070 --> 00:08:47,409 Imaginaos que es un ping, ¿vale? 97 00:08:47,509 --> 00:08:53,210 ¿Qué tipo de información? Pues llevará unos determinados datos en el campo contenido. 98 00:08:55,450 --> 00:08:58,909 Hay muchos tipos de mensajes ya ICMP predefinidos. 99 00:08:59,070 --> 00:09:03,070 Aquí tenemos algunos ejemplos, como el tiempo de vida seguido, que hemos visto antes. 100 00:09:03,990 --> 00:09:08,190 El de echo request y echo replay, que son los del ping. 101 00:09:08,190 --> 00:09:15,769 cuando el paquete llega a un router que no es capaz de encaminar, ¿vale? 102 00:09:15,789 --> 00:09:19,710 Entonces no se puede alcanzar el destino, etcétera, es decir, hay varios tipos de mensajes. 103 00:09:20,429 --> 00:09:24,490 Aquí en la siguiente tabla podéis ver, en función del tipo de mensaje, ¿vale? 104 00:09:24,669 --> 00:09:34,649 Pues el valor que se pondría en el campo tipo y código de la cabecera del protocolo ICMP. 105 00:09:34,649 --> 00:09:42,429 Por ejemplo, si en el tipo viene un 0 y el código un 0, significa que es un reply del ping. 106 00:09:42,929 --> 00:09:51,269 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. 107 00:09:57,120 --> 00:10:05,379 Aquí tenemos un ejemplo en el caso de que lo que queramos enviar es un ping a un determinado equipo. 108 00:10:05,379 --> 00:10:08,460 si enviamos un ping a un determinado equipo 109 00:10:08,460 --> 00:10:10,519 lo que estamos enviando realmente 110 00:10:10,519 --> 00:10:12,200 es un mensaje ICMP 111 00:10:12,200 --> 00:10:14,039 un mensaje ICMP 112 00:10:14,039 --> 00:10:16,120 encapsulado en un paquete IP 113 00:10:16,120 --> 00:10:18,360 dentro de ese mensaje 114 00:10:18,360 --> 00:10:20,419 ICMP, su cabecera 115 00:10:20,419 --> 00:10:21,659 en el campo tipo 116 00:10:21,659 --> 00:10:24,240 vendrá un 8 o un 0 117 00:10:24,240 --> 00:10:26,360 dependiendo si es una petición o es la respuesta 118 00:10:26,360 --> 00:10:28,460 del ping, en el campo 119 00:10:28,460 --> 00:10:30,860 código vendrá un 0, luego el checksum 120 00:10:30,860 --> 00:10:32,860 que tendrá su valor correspondiente 121 00:10:32,860 --> 00:10:33,980 que se tendrá que calcular 122 00:10:33,980 --> 00:10:38,279 y luego veis que también tiene una serie de campos adicionales 123 00:10:38,279 --> 00:10:41,639 en el caso de que sea uno de estos dos tipos de mensajes 124 00:10:41,639 --> 00:10:46,200 echo o request, que tiene un identificador, una secuencia 125 00:10:46,200 --> 00:10:48,279 y una serie de datos adicionales 126 00:10:48,279 --> 00:10:53,820 en el caso de que los mensajes sean mensajes 127 00:10:53,820 --> 00:10:57,320 de errores, es decir, que se haya producido un error como por ejemplo 128 00:10:57,320 --> 00:11:01,980 el TTL excedido o que por ejemplo 129 00:11:01,980 --> 00:11:04,379 el paquete no pueda 130 00:11:04,379 --> 00:11:06,299 alcanzar su destino, ¿vale? porque el router 131 00:11:06,299 --> 00:11:08,320 no puede encaminarlo, pues entonces 132 00:11:08,320 --> 00:11:10,539 lo que se hace es avisar 133 00:11:10,539 --> 00:11:10,919 a 134 00:11:10,919 --> 00:11:13,240 normalmente desechar 135 00:11:13,240 --> 00:11:16,559 al mensaje, ¿vale? y avisar al destino 136 00:11:16,559 --> 00:11:18,279 de que al origen 137 00:11:18,279 --> 00:11:20,059 con un mensaje ICMP 138 00:11:20,059 --> 00:11:22,419 en el caso de que se haya producido 139 00:11:22,419 --> 00:11:23,919 ¿vale? a uno 140 00:11:23,919 --> 00:11:25,600 de esas posibles causas 141 00:11:25,600 --> 00:11:28,620 sin embargo, imaginaros que lo que se ha producido es un error 142 00:11:28,620 --> 00:11:30,200 del paquete 143 00:11:30,200 --> 00:11:37,159 Es decir, el campo checksum se calcula, se comprueba que ese paquete que se está enviando tiene un error, ¿vale? 144 00:11:37,159 --> 00:11:43,740 En ese caso, como dice ahí, no se corrige el error y ya será el nivel superior que decida qué hacer con esos paquetes. 145 00:11:44,419 --> 00:11:49,940 Así que es importante que cuando se produce un error, no siempre se generan mensajes ICMP. 146 00:11:50,659 --> 00:11:55,159 Por ejemplo, imaginaos en el caso de que el error se produzca en un propio mensaje ICMP, 147 00:11:55,159 --> 00:11:57,539 de request o de reply 148 00:11:57,539 --> 00:11:58,279 o 149 00:11:58,279 --> 00:12:01,539 bueno, request o reply no porque no son 150 00:12:01,539 --> 00:12:03,100 mensajes de error, son mensajes de 151 00:12:03,100 --> 00:12:05,340 consulta, sino por ejemplo 152 00:12:05,340 --> 00:12:07,659 un TTL excedido, se ha excedido el tiempo 153 00:12:07,659 --> 00:12:09,399 se produce 154 00:12:09,399 --> 00:12:11,879 un error, se envía un mensaje 155 00:12:11,879 --> 00:12:13,460 ICMP avisando el origen 156 00:12:13,460 --> 00:12:15,399 pero ese propio mensaje ICMP 157 00:12:15,399 --> 00:12:17,340 sufre un error a lo largo del camino 158 00:12:17,340 --> 00:12:19,500 bueno, pues en ese caso 159 00:12:19,500 --> 00:12:21,100 no se vuelve a generar 160 00:12:21,100 --> 00:12:23,460 un mensaje ICMP por cada uno de los 161 00:12:23,460 --> 00:12:27,240 mensajes de error vale porque si no al final se generaría muchísimo tráfico 162 00:12:27,240 --> 00:12:31,320 porque dice ahí para un datagrama fragmentado que no sea el primero 163 00:12:31,320 --> 00:12:34,840 normalmente cuando se fragmenta un paquete también se avisa al origen con 164 00:12:34,840 --> 00:12:40,259 un mensaje y cmd que se haya producido una fragmentación pero no se avisa por 165 00:12:40,259 --> 00:12:44,960 cada uno de los fragmentos en los que se va dividiendo el paquete es decir 166 00:12:44,960 --> 00:12:49,340 imaginaos pasa por un mensaje por un router y éste lo fragmenta a su vez 167 00:12:49,340 --> 00:12:52,980 luego es cada uno de estos mensajes para esa por otro router que se fragmenta 168 00:12:52,980 --> 00:12:59,220 otra vez y sucesivamente vale por cada mensaje fragmentado no se avisa sino únicamente se avisa 169 00:12:59,220 --> 00:13:06,000 con el primero porque si no también se genera generaría muchísimo tráfico y tampoco se informa 170 00:13:06,000 --> 00:13:10,980 no se envían mensajes y cmp muy de ahí de data gramos que utilizan direcciones múltiples o 171 00:13:10,980 --> 00:13:18,059 direcciones especiales como por ejemplo la de las del local host que identifican a nuestra a 172 00:13:18,059 --> 00:13:23,559 nuestra propia equipo, nuestra propia red. Aquí tenemos un ejemplo, por ejemplo, 173 00:13:23,559 --> 00:13:29,259 cuando se genera el mensaje del destino inalcanzable. 174 00:13:29,259 --> 00:13:33,279 Imaginad, llega un paquete, el router no es capaz de enviarlo, entonces avisa al 175 00:13:33,279 --> 00:13:38,559 origen un mensaje ICMP de que no ha podido encaminar ese paquete. 176 00:13:38,559 --> 00:13:45,179 Bueno, pues entonces también tiene una serie de campos, el ICMP en el campo tipo 177 00:13:45,179 --> 00:13:48,559 con el valor 3, en el campo código con el valor 3 178 00:13:48,559 --> 00:13:52,639 se calcula el checksum y luego bueno pues en este caso 179 00:13:52,639 --> 00:13:56,399 lo que hace es enviar en los datos la cabecera IP 180 00:13:56,399 --> 00:14:00,940 lo que hemos dicho antes, toda la cabecera IP más los primeros 8 bytes del datagrama IP 181 00:14:00,940 --> 00:14:03,919 es decir los puertos, todos esos datos los envía en el mensaje 182 00:14:03,919 --> 00:14:07,639 para que cuando lleguen al origen 183 00:14:07,639 --> 00:14:11,980 el decida que hacer con esa información 184 00:14:11,980 --> 00:14:24,980 También se utiliza mucho el protocolo ICMP conjuntamente con otro comando, aparte del PIN, que es el comando tracer o tracer router. 185 00:14:25,539 --> 00:14:32,360 Dependiendo si lo utilizáis en Windows es el comando tracer, si lo utilizáis en Linux es el comando tracer router. 186 00:14:32,360 --> 00:14:41,360 este comando básicamente lo que nos devuelve son aquellos nodos intermedios o equipos intermedios 187 00:14:41,360 --> 00:14:45,039 por los que pasa un mensaje hasta llegar a su destino 188 00:14:45,039 --> 00:14:50,860 por ejemplo si yo utilizo el comando y pongo tracer al www.google.es 189 00:14:50,860 --> 00:14:57,960 lo que me va trazando es la ruta de todos los equipos o direcciones IP por las que va pasando mi equipo 190 00:14:57,960 --> 00:15:00,100 o sea, ese paquete hasta llegar 191 00:15:00,100 --> 00:15:02,360 a ese destino, en este caso el de Google 192 00:15:02,360 --> 00:15:03,740 vamos a verlo con un ejemplo 193 00:15:03,740 --> 00:15:10,190 vale, si en este caso 194 00:15:10,190 --> 00:15:12,190 lo voy a hacer en Windows, se abre una consola 195 00:15:12,190 --> 00:15:13,509 y pongo tracer 196 00:15:13,509 --> 00:15:18,090 a www.google.es 197 00:15:18,090 --> 00:15:19,250 lo he puesto mal 198 00:15:19,250 --> 00:15:24,279 es tracer, que acaba en T 199 00:15:24,279 --> 00:15:26,100 pues como veis ahí 200 00:15:26,100 --> 00:15:28,279 primero traduce la dirección de Google 201 00:15:28,279 --> 00:15:32,220 que es la 172.217.16.2.7 202 00:15:32,220 --> 00:15:34,620 y luego me va indicando en orden 203 00:15:34,620 --> 00:15:37,659 esos equipos intermedios que son routers 204 00:15:37,659 --> 00:15:39,519 por los que va pasando 205 00:15:39,519 --> 00:15:44,320 como veis ahí 206 00:15:44,320 --> 00:15:45,100 primero dice que 207 00:15:45,100 --> 00:15:47,360 el primer salto que ha dado 208 00:15:47,360 --> 00:15:49,899 ese mensaje desde mi equipo 209 00:15:49,899 --> 00:15:51,820 es a la IP 210 00:15:51,820 --> 00:15:54,600 192.168.0.1 211 00:15:54,600 --> 00:15:56,299 que será la dirección 212 00:15:56,299 --> 00:15:56,500 de 213 00:15:56,500 --> 00:15:59,639 la dirección de mi router 214 00:15:59,639 --> 00:16:02,600 luego pasa a la siguiente 215 00:16:02,600 --> 00:16:05,240 La 87, 235, 010 216 00:16:05,240 --> 00:16:08,919 Luego la 10, 183, 51, 17 217 00:16:08,919 --> 00:16:11,879 Luego veis que aparece 218 00:16:11,879 --> 00:16:14,240 En el orden número 4 y 5 219 00:16:14,240 --> 00:16:15,519 Aparecen asteriscos 220 00:16:15,519 --> 00:16:17,559 Luego en la 6 221 00:16:17,559 --> 00:16:19,080 Vuelven a aparecer otras IPs 222 00:16:19,080 --> 00:16:20,720 Hasta la opción 9 223 00:16:20,720 --> 00:16:22,840 Es decir, que para llegar 224 00:16:22,840 --> 00:16:25,639 Mi mensaje desde mi máquina local 225 00:16:25,639 --> 00:16:29,080 Hasta el www.google.es 226 00:16:29,080 --> 00:16:30,279 Ha dado 9 saltos 227 00:16:30,279 --> 00:16:31,919 Ha pasado por 9 enrutadores 228 00:16:31,919 --> 00:16:33,019 hasta llegar al destino. 229 00:16:33,620 --> 00:16:36,860 Cuando aparece un asterisco es porque normalmente esos routers 230 00:16:36,860 --> 00:16:40,080 por los que ha llegado ese paquete 231 00:16:40,080 --> 00:16:45,340 están por seguridad normalmente capados 232 00:16:45,340 --> 00:16:48,279 para que no puedan enviar mensajes ICMP, 233 00:16:48,440 --> 00:16:51,639 bien por seguridad o bien porque la red está congestionada en ese momento 234 00:16:51,639 --> 00:16:53,919 y no se quiere generar más tráfico. 235 00:17:04,079 --> 00:17:05,579 Y ahora vamos a verlo con un ejemplo. 236 00:17:05,960 --> 00:17:09,799 Vamos a ver con un ejemplo cómo se van enviando esos mensajes ICMP 237 00:17:09,799 --> 00:17:16,460 a través del comando trácer aquí tenemos un ejemplo una red de la que vemos un equipo a 238 00:17:16,460 --> 00:17:25,160 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 239 00:17:25,160 --> 00:17:32,599 trácer a b entonces qué es lo que se produce por debajo pues por debajo realmente lo que estamos 240 00:17:32,599 --> 00:17:42,740 haciendo es lo siguiente es enviar un mensaje cuya ip origen es la de a cuya ip origen es la 241 00:17:42,740 --> 00:17:54,359 de b cuyo valor ttl del protocolo ip se pone a uno y luego dentro lo que se envía es un 242 00:17:54,359 --> 00:17:56,119 se encasula 243 00:17:56,119 --> 00:17:58,480 el protocolo ICMP 244 00:17:58,480 --> 00:18:02,680 vale, para avisar al origen 245 00:18:02,680 --> 00:18:04,220 aquí tenemos 246 00:18:04,220 --> 00:18:05,880 se puede ver un poco mejor 247 00:18:05,880 --> 00:18:08,480 un segundito 248 00:18:08,480 --> 00:18:16,410 bueno, vuelvo a repetir 249 00:18:16,410 --> 00:18:18,569 vale, desde el equipo A 250 00:18:18,569 --> 00:18:20,230 queremos enviar un mensaje al equipo B 251 00:18:20,230 --> 00:18:22,089 un mensaje no, el comando traza 252 00:18:22,089 --> 00:18:23,750 para ver la traza 253 00:18:23,750 --> 00:18:25,730 para ir sabiendo, vale, por qué 254 00:18:25,730 --> 00:18:27,410 por qué equipos intermedios vamos 255 00:18:27,410 --> 00:18:30,190 se van a ir pasando hasta llegar a b 256 00:18:30,190 --> 00:18:32,009 lo mismo que hemos hecho antes 257 00:18:32,009 --> 00:18:33,950 con el ejemplo con google 258 00:18:33,950 --> 00:18:36,150 entonces que es lo que hace a 259 00:18:36,150 --> 00:18:38,630 lo que hace a es genera un mensaje 260 00:18:38,630 --> 00:18:40,730 ip con la ip origen 261 00:18:40,730 --> 00:18:42,650 la de a ip destino la de b 262 00:18:42,650 --> 00:18:44,589 con el ttl lo que os he dicho antes 263 00:18:44,589 --> 00:18:45,650 valor 1 264 00:18:45,650 --> 00:18:48,329 y luego dentro 265 00:18:48,329 --> 00:18:50,990 de los datos del protocolo 266 00:18:50,990 --> 00:18:52,849 ip iría lo que está por encima 267 00:18:52,849 --> 00:18:54,630 vale lo que está por encima 268 00:18:54,630 --> 00:18:59,630 es el protocolo de nivel de transporte 269 00:18:59,630 --> 00:19:00,890 que puede ser UDP o TCP 270 00:19:00,890 --> 00:19:03,289 en este caso es UDP con un puerto origen 271 00:19:03,289 --> 00:19:04,450 un puerto destino, etc. 272 00:19:04,630 --> 00:19:05,970 eso nos interesa un poco menos 273 00:19:05,970 --> 00:19:08,250 entonces ese mensaje se envía 274 00:19:08,250 --> 00:19:12,269 para ello A mira su tabla de encaminamiento 275 00:19:12,269 --> 00:19:13,890 y dice si yo quiero ir a B 276 00:19:13,890 --> 00:19:16,650 mira su tabla y dice si lo tengo que enviar a R1 277 00:19:16,650 --> 00:19:19,670 vale, entonces envía el mensaje a R1 278 00:19:19,670 --> 00:19:22,329 cuando ese mensaje llega a R1 279 00:19:22,329 --> 00:19:27,170 lo que hace R1 es disminuir el TTL de 1 a 0 280 00:19:27,170 --> 00:19:32,589 por lo tanto al disminuir ese TTL de 1 a 0 281 00:19:32,589 --> 00:19:35,930 lo que ocurre es que ese mensaje ya no lo puede seguir encaminando 282 00:19:35,930 --> 00:19:39,190 y por lo tanto desecha ese mensaje, es decir, no va a llegar al destino 283 00:19:39,190 --> 00:19:45,849 pero avisa al origen de que se ha producido un TTL excedido 284 00:19:45,849 --> 00:19:49,049 ¿Cómo lo avisa? Enviando un mensaje ICMP 285 00:19:49,049 --> 00:19:51,509 que es el que está aquí en la parte de aquí abajo 286 00:19:51,509 --> 00:19:53,650 envía un mensaje ICMP 287 00:19:53,650 --> 00:19:55,750 que pone IP origen, en este caso 288 00:19:55,750 --> 00:19:57,430 el de R1, que es quien va a avisar 289 00:19:57,430 --> 00:19:59,309 IP destino, el de A 290 00:19:59,309 --> 00:20:01,849 el TTL lo pone, bueno en este ejemplo 291 00:20:01,849 --> 00:20:03,529 está puesto a 64, es decir 292 00:20:03,529 --> 00:20:06,109 un valor alto para que llegue a su destino 293 00:20:06,109 --> 00:20:09,650 y luego en tipo y código 294 00:20:09,650 --> 00:20:11,329 pues pone los correspondientes 295 00:20:11,329 --> 00:20:13,890 al TTL, al que correspondan 296 00:20:13,890 --> 00:20:15,210 con el TTL excedido 297 00:20:15,210 --> 00:20:17,809 para que cuando llegue al origen sepa de que tipo 298 00:20:17,809 --> 00:20:18,670 es ese mensaje 299 00:20:18,670 --> 00:20:22,410 Ese mensaje le llega a A 300 00:20:22,410 --> 00:20:24,730 ¿Vale? Y entonces ya puede apuntar 301 00:20:24,730 --> 00:20:28,509 Puede apuntar cuál es el nodo por el que ha pasado 302 00:20:28,509 --> 00:20:33,049 ¿Cómo lo sabe? Mirando la IP origen de ese campo 303 00:20:33,049 --> 00:20:37,029 O sea, la IP origen de ese mensaje que le acaba de llegar 304 00:20:37,029 --> 00:20:38,829 Que es el 11.0.0.1 305 00:20:38,829 --> 00:20:41,289 Que es el valor del R1 306 00:20:41,289 --> 00:20:42,269 Y veis, lo apunta 307 00:20:42,269 --> 00:20:44,529 Aquí en rojo, en un recuadro en rojo 308 00:20:44,529 --> 00:20:47,750 Se va viendo lo que va generando el comando 309 00:20:47,750 --> 00:20:50,349 Y pone 1, 11, 0, 0, 1 310 00:20:50,349 --> 00:20:51,710 Es el primer salto 311 00:20:51,710 --> 00:20:54,009 Vale, luego dice, vale, ya es el primer salto 312 00:20:54,009 --> 00:20:55,309 Ahora debe ver el segundo salto 313 00:20:55,309 --> 00:20:56,690 Y hace lo mismo que ha hecho antes 314 00:20:56,690 --> 00:21:00,910 Pero generando un mensaje con el TTL igual a 2 315 00:21:00,910 --> 00:21:03,089 Por tanto, ese mensaje igual a 316 00:21:03,089 --> 00:21:04,609 Mira su tabla de encaminamiento 317 00:21:04,609 --> 00:21:07,650 Dice, para ir a B lo tengo que enviar a R1 318 00:21:07,650 --> 00:21:09,529 Ese campo llega a R1 319 00:21:09,529 --> 00:21:12,730 R1 lo primero que hace es disminuir el TTL del 2 a 1 320 00:21:12,730 --> 00:21:14,710 Y mira su tabla de encaminamiento 321 00:21:14,710 --> 00:21:16,210 Y dice, vale, para ir a B 322 00:21:16,210 --> 00:21:18,670 yo a quien tengo que enviárselo es a R3 323 00:21:18,670 --> 00:21:21,809 y le llega a R3 324 00:21:21,809 --> 00:21:24,509 R3 mira el paquete 325 00:21:24,509 --> 00:21:26,430 el TTL lo disminuye una unidad 326 00:21:26,430 --> 00:21:28,970 queda cero y dice ya no puedo seguir enviándolo 327 00:21:28,970 --> 00:21:31,990 así que lo desecha y genera un mensaje ICMP 328 00:21:31,990 --> 00:21:34,009 respuesta AAA 329 00:21:34,009 --> 00:21:37,170 para eso igual genera como IP origen 330 00:21:37,170 --> 00:21:38,609 pone la suya, la de R3 331 00:21:38,609 --> 00:21:40,210 como IP destino la de A 332 00:21:40,210 --> 00:21:42,569 un TTL en este caso 64 alto 333 00:21:42,569 --> 00:21:43,849 para que le llegue a A 334 00:21:43,849 --> 00:21:50,150 Y bueno, le pone los datos correspondientes a un mensaje ICMP de tipo TTL excedido 335 00:21:50,150 --> 00:21:52,589 Que es el tipo 11, código 0 336 00:21:52,589 --> 00:21:56,630 Y dice R3, vale, quiero enviárselo a, para enviárselo a 337 00:21:56,630 --> 00:21:59,549 ¿A quién se lo tengo que enviar? Mira su tabla de encaminamiento 338 00:21:59,549 --> 00:22:01,609 Y dice, vale, se lo tengo que enviar a R1 339 00:22:01,609 --> 00:22:03,470 Y se lo envía a R1 340 00:22:03,470 --> 00:22:06,589 Y R1 cuando le llega, mira su tabla de encaminamiento 341 00:22:06,589 --> 00:22:08,930 Y dice, vale, para llegar a A, ¿quién se lo tengo que enviar? 342 00:22:08,930 --> 00:22:11,390 Vale, directamente a A y le llega el mensaje 343 00:22:11,390 --> 00:22:18,349 Y ahí apunta, vale, que el siguiente salto es el 13003 que es el de R3 344 00:22:18,349 --> 00:22:24,890 Y vuelve a hacer lo mismo, dice, vale, pues ahora vuelvo a generar otro mensaje pero con TTL igual a 3 345 00:22:24,890 --> 00:22:28,529 Para enviarlo, mira su tabla de encaminamiento 346 00:22:28,529 --> 00:22:31,829 A dice, para llevarle a B tengo que enviárselo a R1 347 00:22:31,829 --> 00:22:38,109 R1 disminuye el TTL en una unidad y dice, vale, para enviárselo a B tengo que enviárselo a R3 348 00:22:38,109 --> 00:22:40,609 R3 mira su tabla de encaminamiento 349 00:22:40,609 --> 00:22:41,670 Disminuye una unidad 350 00:22:41,670 --> 00:22:43,750 El TTL dice, vale, para enviarse la B 351 00:22:43,750 --> 00:22:44,950 Se lo envío a R4 352 00:22:44,950 --> 00:22:47,049 Cuando llega a R4 353 00:22:47,049 --> 00:22:49,869 R4 disminuye en una unidad el TTL 354 00:22:49,869 --> 00:22:50,690 Y lo pone a 0 355 00:22:50,690 --> 00:22:52,769 Con lo cual ya no puede seguir enviándolo 356 00:22:52,769 --> 00:22:55,210 Genera un mensaje ICMP igual que antes 357 00:22:55,210 --> 00:22:57,930 De tipo TTL 358 00:22:57,930 --> 00:22:59,210 Estebido 359 00:22:59,210 --> 00:23:01,650 Y lo que pone es como su IP origen 360 00:23:01,650 --> 00:23:02,789 La suya, R4 361 00:23:02,789 --> 00:23:04,529 Y ese mensaje se lo envía a A 362 00:23:04,529 --> 00:23:06,130 Ahora para enviárselo a A 363 00:23:06,130 --> 00:23:07,430 Mira su tabla de encaminamiento 364 00:23:07,430 --> 00:23:10,950 y dice, vale, para enviárselo a, resulta que tengo que enviársela por R2 365 00:23:10,950 --> 00:23:13,289 bueno, pues no pasa nada, lo envía por otra ruta 366 00:23:13,289 --> 00:23:16,970 pero le va a llegar igualmente a R4, lo envía a R2 367 00:23:16,970 --> 00:23:19,309 R2, mira, su tabla de encaminamiento 368 00:23:19,309 --> 00:23:24,029 dice, para llegar a A, se lo tengo que enviar a R1 369 00:23:24,029 --> 00:23:26,910 y R1 hace lo mismo, dice, vale, para enviar a 370 00:23:26,910 --> 00:23:29,950 A, se lo tengo que enviar directamente ya 371 00:23:29,950 --> 00:23:32,210 o sea, ya está directamente conectado a mí, se lo envía 372 00:23:32,210 --> 00:23:35,049 A con G, ese paquete, apunta 373 00:23:35,049 --> 00:23:37,089 el IP origen y ya sabe que 374 00:23:37,089 --> 00:23:39,589 el siguiente salto 375 00:23:39,589 --> 00:23:41,970 era el de R4 376 00:23:41,970 --> 00:23:43,849 y ahora 377 00:23:43,849 --> 00:23:45,910 vuelve a hacer lo mismo, envía otro paquete 378 00:23:45,910 --> 00:23:47,690 pero ahora con TTL igual a 4 379 00:23:47,690 --> 00:23:49,289 hace exactamente lo mismo 380 00:23:49,289 --> 00:23:51,349 de A lo envía R1 381 00:23:51,349 --> 00:23:53,789 de R1 a R3, de R3 a R4 382 00:23:53,789 --> 00:23:55,390 cuando el mensaje 383 00:23:55,390 --> 00:23:57,869 le llega a R4, el TTL 384 00:23:57,869 --> 00:23:59,670 lo puede disminuir a una unidad 385 00:23:59,670 --> 00:24:01,809 si no llega a 0 no hay problema, así que se lo puede 386 00:24:01,809 --> 00:24:03,190 enviar ya al destino que sabe 387 00:24:03,190 --> 00:24:05,109 Ese mensaje le llega a P 388 00:24:05,109 --> 00:24:07,210 Y lo que hace B, dice, vale, ahora 389 00:24:07,210 --> 00:24:09,470 Lo que voy a hacer es contestar 390 00:24:09,470 --> 00:24:11,369 Al mensaje que me ha enviado A 391 00:24:11,369 --> 00:24:12,549 Vale, contesto 392 00:24:12,549 --> 00:24:15,470 Y para contestarle 393 00:24:16,009 --> 00:24:17,430 Mira su tabla de encaminamiento 394 00:24:17,430 --> 00:24:19,549 Y dice, vale, para enviar algo a A 395 00:24:19,549 --> 00:24:21,349 Se lo tengo que enviar a 396 00:24:21,349 --> 00:24:23,089 En este caso, vale, a 397 00:24:23,089 --> 00:24:25,390 Está en la red 11 398 00:24:25,390 --> 00:24:27,529 Al 14.002 399 00:24:27,529 --> 00:24:29,470 Es decir, por R2, vale, pues 400 00:24:29,470 --> 00:24:31,930 B se lo envía 401 00:24:31,930 --> 00:24:32,670 A R2 402 00:24:32,670 --> 00:24:35,849 perdonad, a R4 se lo envía a R2 403 00:24:35,849 --> 00:24:37,809 R2 envía a su tabla de encaminamiento 404 00:24:37,809 --> 00:24:39,789 y dice para enviar a A se lo envía a R1 405 00:24:39,789 --> 00:24:41,170 y R1 a A 406 00:24:41,170 --> 00:24:43,730 y cuando le llega a A ya puede apuntar 407 00:24:43,730 --> 00:24:46,470 que el siguiente salto es el que corresponda 408 00:24:46,470 --> 00:24:47,930 y de esa manera funciona 409 00:24:47,930 --> 00:24:49,230 el comando tracerrote 410 00:24:49,230 --> 00:24:51,609 en este caso, en este ejemplo lo hemos visto 411 00:24:51,609 --> 00:24:53,109 solamente enviando un datagrama 412 00:24:53,109 --> 00:24:55,809 pero realmente lo que envía son 3 datagramas 413 00:24:55,809 --> 00:24:59,430 es decir, primero envía 1, 2 y 3 seguidos 414 00:24:59,430 --> 00:25:01,549 esos 3 datagramas, primero le envía 415 00:25:01,549 --> 00:25:07,569 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 416 00:25:07,569 --> 00:25:13,529 llegue a su destino. En este caso hemos utilizado hasta un ttl igual a 4 pero en el ejemplo que 417 00:25:13,529 --> 00:25:19,789 veíamos antes al hacer un tráfer a google había hasta nueve saltos así que internamente es como 418 00:25:19,789 --> 00:25:28,690 si estuvieran enviando nueve veces el paquete, uno con ttl igual a 1, tres mensajes con ttl igual a 1, 419 00:25:28,690 --> 00:25:30,509 tres mensajes con ttl igual a 2 420 00:25:30,509 --> 00:25:32,190 tres con ttl igual a 3 421 00:25:32,190 --> 00:25:34,549 y así hasta el último con ttl igual a 9 422 00:25:34,549 --> 00:25:36,529 así es como 423 00:25:36,529 --> 00:25:38,390 funciona este comando 424 00:25:38,390 --> 00:25:45,299 como hemos visto antes 425 00:25:45,299 --> 00:25:47,039 en el ejemplo de google 426 00:25:47,039 --> 00:25:49,440 en algún momento puede ocurrir 427 00:25:49,440 --> 00:25:50,819 que imprima un asterisco 428 00:25:50,819 --> 00:25:52,720 y es por lo que os he dicho antes 429 00:25:52,720 --> 00:25:54,900 puede imprimir un asterisco porque cuando llega 430 00:25:54,900 --> 00:25:56,960 ese mensaje a ese nodo intermedio 431 00:25:56,960 --> 00:25:59,779 puede ocurrir que ese nodo intermedio 432 00:25:59,779 --> 00:26:01,240 esté configurado para que 433 00:26:01,240 --> 00:26:03,059 no envíe mensajes ICMP 434 00:26:03,059 --> 00:26:05,180 del tipo que sea, puede ser solo de 435 00:26:05,180 --> 00:26:06,640 TTL o de todos los tipos 436 00:26:06,640 --> 00:26:09,259 en cuyo caso, ¿vale? no se envía 437 00:26:09,259 --> 00:26:11,039 un mensaje, el nodo espera un tiempo 438 00:26:11,039 --> 00:26:12,640 no recibe el mensaje y por lo tanto 439 00:26:12,640 --> 00:26:14,980 marca un asterisco 440 00:26:14,980 --> 00:26:16,519 también puede ocurrir porque 441 00:26:16,519 --> 00:26:18,740 cuando llegue ese paquete 442 00:26:18,740 --> 00:26:20,839 a ese nuevo intermedio, ese nuevo intermedio 443 00:26:20,839 --> 00:26:23,160 por lo que sea, no esté configurado para encaminar 444 00:26:23,160 --> 00:26:25,099 el paquete al origen y por lo tanto tampoco 445 00:26:25,099 --> 00:26:27,220 sepa llegar, o también puede ser 446 00:26:27,220 --> 00:26:29,119 que esté configurado para que no genere más 447 00:26:29,119 --> 00:26:30,940 tráfico de manera temporal porque 448 00:26:30,940 --> 00:26:33,099 la red esté congestionada, entonces ese mensaje 449 00:26:33,099 --> 00:26:34,500 tampoco llegará al origen 450 00:26:34,500 --> 00:26:37,400 entonces en ese campo siempre se pone el asterisco 451 00:26:37,400 --> 00:26:41,019 aquí tenéis una captura del ejemplo 452 00:26:41,019 --> 00:26:43,180 que hemos visto antes 453 00:26:43,180 --> 00:26:45,059 y luego tenemos el 454 00:26:45,059 --> 00:26:47,059 protocolo ICMP versión 6 455 00:26:47,059 --> 00:26:48,680 que sería 456 00:26:48,680 --> 00:26:51,220 utilizado conjuntamente 457 00:26:51,220 --> 00:26:52,819 con el protocolo IPv6 458 00:26:52,819 --> 00:26:54,740 es muy parecido al 459 00:26:54,740 --> 00:26:56,259 protocolo ICMP 460 00:26:56,259 --> 00:26:57,599 la única diferencia 461 00:26:57,599 --> 00:27:00,460 es que en el campo tipo 462 00:27:00,460 --> 00:27:02,279 utiliza un valor menor que 128 463 00:27:02,279 --> 00:27:03,980 y en el código 464 00:27:03,980 --> 00:27:06,599 utiliza otro 465 00:27:06,599 --> 00:27:08,660 otro valor 466 00:27:08,660 --> 00:27:09,880 un valor mayor que 467 00:27:09,880 --> 00:27:12,099 perdonad 468 00:27:12,099 --> 00:27:14,660 la única diferencia es que 469 00:27:14,660 --> 00:27:16,460 según los tipos de mensajes 470 00:27:16,460 --> 00:27:18,380 recordad que podían ser mensajes de error 471 00:27:18,380 --> 00:27:19,920 o mensajes de consulta 472 00:27:19,920 --> 00:27:22,119 y son mensajes de error el campo tipo 473 00:27:22,119 --> 00:27:23,839 tiene un valor menor que 128 474 00:27:23,839 --> 00:27:25,980 y si es un mensaje de consulta 475 00:27:25,980 --> 00:27:26,859 de información 476 00:27:26,859 --> 00:27:29,839 como por ejemplo un request 477 00:27:29,839 --> 00:27:35,779 es un replay del tiempo es lo que utilizan ese campo tipo es un valor mayor que 128 hay muchos 478 00:27:35,779 --> 00:27:41,819 tipos de mensajes y cmp casi todos los mismos que en icmp versión 4 que además añaden algunos 479 00:27:41,819 --> 00:27:51,000 especiales como son para el descubrimiento de vecinos para el descubrimiento multicast aquí 480 00:27:51,000 --> 00:27:58,180 tenemos algunos algunos de ellos vale y podemos ver según el tipo vale pues a qué corresponde 481 00:27:58,180 --> 00:27:59,960 cada uno de ellos 482 00:27:59,960 --> 00:28:02,440 no hace falta aprendérselo de memoria 483 00:28:02,440 --> 00:28:06,140 y lo único que 484 00:28:06,140 --> 00:28:08,559 si cambia con respecto 485 00:28:08,559 --> 00:28:10,220 al ICMP versión 4 486 00:28:10,220 --> 00:28:14,220 es que al hacer el checksum 487 00:28:14,220 --> 00:28:15,900 recordar que el checksum 488 00:28:15,900 --> 00:28:18,240 es un cálculo 489 00:28:18,240 --> 00:28:20,480 que se hacía 490 00:28:20,480 --> 00:28:22,559 para verificar si había un error 491 00:28:22,559 --> 00:28:24,019 en los datos 492 00:28:24,019 --> 00:28:26,259 en el caso de ICMP versión 4 493 00:28:26,259 --> 00:28:31,559 el check se hacían sobre todos los datos ICMP, es decir, sobre toda la cabecera y los datos 494 00:28:31,559 --> 00:28:41,759 del protocolo ICMP. Sin embargo, en ICMPv6, aparte de esos datos, también se calcula 495 00:28:41,759 --> 00:28:48,700 sobre una parte, como dice aquí, sobre una pseudo cabecera, es decir, sobre una parte 496 00:28:48,700 --> 00:28:50,279 de la cabecera IP 497 00:28:50,279 --> 00:28:52,200 IPv6 498 00:28:52,200 --> 00:28:54,259 sobre qué parte, pues la que tiene 499 00:28:54,259 --> 00:28:56,960 la IPv6 origen, la IPv6 destino 500 00:28:56,960 --> 00:28:58,039 y el campo 501 00:28:58,039 --> 00:28:59,480 siguiente 502 00:28:59,480 --> 00:29:01,720 cabecera 503 00:29:01,720 --> 00:29:05,119 del protocolo IPv6 504 00:29:05,119 --> 00:29:05,619 ¿por qué? 505 00:29:06,180 --> 00:29:08,059 porque en el protocolo IPv6 506 00:29:08,059 --> 00:29:10,319 desaparece el campo 507 00:29:10,319 --> 00:29:12,880 checksum del protocolo IPv6 508 00:29:12,880 --> 00:29:14,000 por lo tanto 509 00:29:14,000 --> 00:29:16,960 al desaparecer 510 00:29:16,960 --> 00:29:17,500 ese valor 511 00:29:17,500 --> 00:29:23,200 lo que hace el ICMP es añadir el checksum también sobre estos datos 512 00:29:23,200 --> 00:29:28,140 de esa manera si se ha producido un error en la dirección IP origen o la dirección IP destino 513 00:29:28,140 --> 00:29:30,519 pues es capaz de detectarlo 514 00:29:30,519 --> 00:29:33,240 si no, no sería capaz de detectarlo 515 00:29:33,240 --> 00:29:38,740 y como conclusión podemos ver aquí lo que nos pone 516 00:29:38,740 --> 00:29:42,339 nos dice que ICMP es un mecanismo para gestionar los errores 517 00:29:42,339 --> 00:29:47,039 es decir, no corrige, sino simplemente informa de que se han producido errores 518 00:29:47,039 --> 00:29:50,799 de la capa del nivel de red, es decir, sobre el protocolo IP. 519 00:29:52,599 --> 00:29:57,539 Los mensajes ICMP se envían como datagramas encasulados en paquetes IP 520 00:29:57,539 --> 00:30:04,160 y quien envía esos datagramas ICMP normalmente siempre suele ser los routers, 521 00:30:04,160 --> 00:30:06,200 que es donde se generan los errores. 522 00:30:06,200 --> 00:30:09,759 Y bueno, aparte de errores 523 00:30:09,759 --> 00:30:10,859 También se utilizan para 524 00:30:10,859 --> 00:30:13,299 Para hacer consultas 525 00:30:13,299 --> 00:30:14,000 Como por ejemplo 526 00:30:14,000 --> 00:30:16,119 La utilización del comando ping 527 00:30:16,119 --> 00:30:17,000 Y el comando tracer 528 00:30:17,000 --> 00:30:18,420 Como hemos visto antes 529 00:30:18,420 --> 00:30:21,519 Y si es necesario 530 00:30:21,519 --> 00:30:22,259 Como dice aquí 531 00:30:22,259 --> 00:30:23,619 No solamente los routers 532 00:30:23,619 --> 00:30:25,339 Pueden generar esos mensajes ICMP 533 00:30:25,339 --> 00:30:26,059 Sino también 534 00:30:26,059 --> 00:30:27,579 Aquí en el último punto 535 00:30:27,579 --> 00:30:28,400 Dice que los hosts 536 00:30:28,400 --> 00:30:29,259 También pueden usar 537 00:30:29,259 --> 00:30:30,900 Los equipos finales 538 00:30:30,900 --> 00:30:31,519 Pueden usar 539 00:30:31,519 --> 00:30:34,220 Utilizar y enviar esos mensajes ICMP 540 00:30:34,220 --> 00:30:35,480 ¿En qué caso? 541 00:30:35,559 --> 00:30:36,119 Pues por ejemplo 542 00:30:36,119 --> 00:30:46,579 en el caso de fragmentación. Por ejemplo, en IPv6 recordar que no se pueden fragmentar 543 00:30:46,579 --> 00:30:54,839 los paquetes, es decir, que los mensajes desde el origen tienen que ir ya fragmentados, mientras 544 00:30:54,839 --> 00:31:00,839 que en IPv4 los mensajes a lo largo del camino pueden ir fragmentándose en trozos más pequeños. 545 00:31:00,839 --> 00:31:26,880 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. 546 00:31:26,880 --> 00:31:35,160 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. 547 00:31:36,400 --> 00:31:38,599 Con esto hemos terminado el protocolo ICMP.