1.25. ICMPv4 e ICMPv6


Nota: Lastimosamente el contenido completo solo está disponible para miembros… por favor suscríbete
CCNA 200-301 Módulo 1 — Fundamentos de red ICMPv4 e ICMPv6: Mensajes de control y ping

ICMPv4 e ICMPv6: Mensajes de control, ping y diagnóstico de redes

⏱️ 25 min lectura 📊 Nivel: Intermedio

¿Qué es ICMP y por qué existe?

El Protocolo de Mensajes de Control de Internet (ICMP, Internet Control Message Protocol) es uno de los protocolos más importantes con los que interactuarán en su vida como ingenieros de redes. Fue definido originalmente en el RFC 792 para IPv4, y su versión para IPv6 denominada ICMPv6 está definida en el RFC 4443.

Para entender por qué existe ICMP, hay que partir de una característica fundamental de IP: IP no fue diseñado para ser un protocolo confiable. La capa de red no dispone de ningún mecanismo para recuperar errores en la transmisión de paquetes. Esa responsabilidad se delega a la capa de transporte, donde protocolos como TCP implementan sus propios mecanismos de confiabilidad (ACKs, retransmisiones, control de flujo).

Por lo tanto, ICMP fue creado para que los dispositivos de red puedan enviar mensajes a los dispositivos que iniciaron la comunicación, para reportar errores, y circunstancias inesperadas que ocurren en la red. Gracias a estos mensajes pueden comunicarle al origen que algo salió mal en la transmisión de sus paquetes. Para eso existe ICMP. No vuelve a IP en un protocolo confiable ni garantiza la entrega de paquetes; su único propósito es proporcionar retroalimentación sobre problemas en el procesamiento de paquetes IP.

Nota: ICMP no tiene número de puerto, a diferencia de TCP y UDP. Los mensajes ICMP no pertenecen a la capa de transporte: son una parte integral de IP y todo dispositivo que implemente IP está obligado a implementar ICMP. Por eso se clasifica como protocolo de capa 3.

¿Cuándo se generan mensajes ICMP?

Los mensajes ICMP se generan en diversas situaciones de error o diagnóstico dentro de la red. Las más comunes son:

  • Sin ruta al destino: un router recibe un paquete pero no tiene ninguna ruta en su tabla de enrutamiento que le indique por dónde reenviarlo. En lugar de descartar el paquete en silencio, envía un mensaje ICMP al origen indicando que el destino no es alcanzable.

    Si trabajamos con la anterior topología, en este caso un paquete le llega al router RT_1, sin embargo ese router no dispone de rutas en su tabla de enrutamiento para enviar el paquete a un siguiente salto. En este caso el router enviara el mensaje ICMP hacia el origen (PC_1) notificando del problema.
  • Host de destino inactivo: el paquete llega al router directamente conectado a la red de destino, pero el host final no responde porque está apagado o desconectado de la red.
  • Loop de enrutamiento: tablas de enrutamiento incorrectas provocan que el paquete viaje indefinidamente entre dos o más routers. El campo TTL (en IPv4) o Hop Limit (en IPv6) actúa como mecanismo de protección: cuando llega a cero, el paquete se descarta y se notifica al origen.
  • Router sobrecargado: un dispositivo no puede procesar el paquete a tiempo y lo descarta, notificando al origen.
  • Diagnóstico: herramientas como ping y traceroute generan mensajes ICMP intencionalmente para verificar el estado y la conectividad de la red.

Un punto crítico que deben recordar es el siguiente: los mensajes ICMP se envían al dispositivo que originó la comunicación. En la topología anterior, si un paquete atraviesa los tres routers y falla en el tercero (RT_3), es precisamente ese router el que notifica directamente al host de origen, omitiendo todos los routers intermedios. Esto lo mostramos gráficamente en la siguiente topología, asumamos que la PC_1 generó un mensaje que llegó hasta el router RT_3. Si, por algún motivo, es este router el que genera un mensaje ICMP (por ejemplo, un Destination Unreachable o un Time Exceeded), lo enviará directamente al origen del mensaje, es decir, a PC_1. No lo enviará al router RT_2 (el salto anterior), ni tampoco a PC_2, que era el destino final.



Encapsulación y campo Protocol / Next Header

Los mensajes ICMP se transportan encapsulados dentro de un paquete IP, exactamente igual que si fueran datos de cualquier otro protocolo de capa superior. La estructura completa la pueden ver en la imagen siguiente: trama de capa 2 → header IP → mensaje ICMP.

Para que el dispositivo receptor sepa que el contenido del paquete es un mensaje ICMP y no TCP o UDP, los headers IP incluyen un campo identificador:

  • En IPv4: el campo Protocol lleva el valor 1 para indicar ICMPv4.
  • En IPv6: el campo Next Header lleva el valor 58 para indicar ICMPv6.

Aunque ICMP está encapsulado dentro de IP, esto no lo convierte en un protocolo de capa 4. ICMP es parte integral del protocolo IP y ninguna implementación de IP puede omitirlo. Por esa razón se considera un protocolo de capa 3.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

❓ Preguntas Frecuentes

¿ICMP es un protocolo de capa 3 o de capa 4?

ICMP es un protocolo de capa 3. Aunque sus mensajes se encapsulan dentro de paquetes IP (igual que haría TCP o UDP), forma parte integral del protocolo IP. El RFC 792 establece que todo dispositivo que implemente IP debe implementar ICMP. No tiene número de puerto y no pertenece a la capa de transporte.

¿Por qué un ping sin respuesta no siempre significa que el host está caído?

Porque muchos firewalls y dispositivos de seguridad están configurados para bloquear el tráfico ICMP. Un host puede estar activo y respondiendo a tráfico TCP o UDP mientras ignora los Echo Request de ICMP. En entornos corporativos esto es frecuente. Por eso el ping es una primera herramienta de diagnóstico, pero nunca la única.

¿ICMP puede hacer que IP sea confiable?

No. ICMP no convierte a IP en un protocolo confiable. Solo proporciona retroalimentación sobre errores: informa al origen que algo falló, pero no retransmite paquetes ni garantiza que los propios mensajes ICMP lleguen a destino. La confiabilidad sigue siendo responsabilidad de la capa de transporte, específicamente de protocolos como TCP.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

PREGUNTAS!

Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.

Paso 1 de 2

  • Este campo está oculto cuando se visualiza el formulario

¡PARTICIPEMOS!

Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor suscríbete

NUESTROS CURSOS Foros ICMPv4 e ICMPv6

Etiquetado: 

Viendo 13 entradas - de la 1 a la 13 (de un total de 13)
  • Autor
    Entradas
  • #11106
    AdminNG
    Superadministrador
    #17213

    Buenas noches Alvaro,

    Tengo una pregunta para hacer pruebas sobre una red, medir el ancho de banda asignado por ISP. Si bien el protocolo ICMP me ayuda hacer pruebas sobre la capa de red, quería saber si los medidores de velocidad usan el mismo protocolo y en realidad no nos muestran la carga ni descarga contratada.

    #17218
    AlvaroM
    Superadministrador

    Hola Jose.

    Vayamos por partes, en primer lugar ancho de banda de la red no es lo mismo a velocidad de la red… ancho de banda en palabras simples es el «grosor» de tu canal para transportar datos, en este contexto es la cantidad de datos que SE PUEDEN transportar en un determinado momento… y la velocidad de la red, en palabras simples es la cantidad de información que se está enviado entre 2 puntos en un determinado momento. Seguramente tú quieres analizar la velocidad de la red no es cierto? para comprobar si el proveedor está cumpliendo con lo ofrecido. Ahora, a qué te refieres cuando hablas de «medidores de velocidad»… tal vez hablas de las herramientas online existentes?… si es así, la velocidad va depender de tu contrato con el proveedor de servicios y de la tecnología que contrataste…. con algunas de las tecnologías no siempre alcanzas a las máximas velocidades ofrecidas por el proveedor, el proveedor te indica la velocidad que podrías alcanzar en condiciones normales, por ejemplo cuando tu contratas Internet a través de Cable, muchas veces la velocidad en «condiciones normales» podría llegar hasta un valor mínimo del 70% de la velocidad total contratada.

    Ahora, para medir la velocidad de descarga… estas herramientas online utilizan al protocolo HTTP conjuntamente con el protocolo TCP, a través de este protocolo se envían muchos pedazos de información y de acuerdo a esto se mide la velocidad que tu dispones… tú mismo puedes hacer esta prueba… vete a una de esas páginas que miden la velocidad… abre Wireshark… comienza a capturar paquetes… inicia el programa de velocidad y ahí veras lo que se está transfiriendo entre el servidor que mide la velocidad y tu navegador.

    La verdad es que pueden existir muchísimos problemas que afecten a la velocidad que tienes para salir a Internet…no sé qué tecnología tienes o bajo que topología trabajas… pero generalmente una prueba que se puede hacer, es conectar la computadora de tu red directamente al cable que viene del proveedor de servicios, colocarte un IP del rango del proveedor de servicios y comenzar a hacer pruebas de carga y descarga desde tu computadora y medir este rendimiento con algún programa, en este punto tendrás la prueba más apegada a la realidad de lo que te entrega el ISP. Verificar la velocidad desde una computadora que se encuentre en tu red no es lo adecuado… en tu red pueden existir muchísimos otros problemas que afecten a la velocidad contratada del ISP.

    Espero haberte ayudado con mi respuesta.

    Saludos cordiales!

    #17324

    Gracias alvaro por las aclaraciones dado estas como ingeniero de redes si me solicitan certificación de un canal de internet debo contar con herramientas para hacer estas pruebas con el proveedorISP por ejemplo un servidor ftp.

    En segundo lugar como usuario debo considerar la velocidad de los switch en mi red LAN y de la tarjera de red de la pc con la que se realizaran pruebas sus interfaces pueden ser fasEthernet o Gigaethernet.

    #17326

    Pero aun tengo la duda de la medición de velocidad por ejemplo mi PC tiene una tarjeta Ethernet 10/100Mbps en prueba realizo la descarga de un archivo de 2.3GB la descarga mostrada es de 248KB/s -548MB de 2.3GB.

    En resumen 248KB/s lo multiplico por 8 para obtener los Megabit de mi red para un total de 2Megabit de descarga que me esta ofreciendo mi ISP si es así ??.

    #17347
    AlvaroM
    Superadministrador

    Buenas noches Jose!

    En realidad cuando quieres verificar el ancho de banda que te ha dado el ISP para INTERNET, simplemente conéctate directo al router del ISP y haz una prueba de speed test en páginas como https://www.speedtest.net/es … estas páginas muestran las velocidades de una manera bastante certera.

    Otra prueba que puedes hacer, es bajar al mismo tiempo múltiples archivos de Internet que tengan un tamaño considerable, y medir cuantos bits/s estas recibiendo en tu interface, para esto puedes instalarte por ejemplo herramientas como Bit Meter OS o Networx, son herramientas gratuitas que te muestran de manera gráfica cuantos bits por segundo están atravesando tu interface.

    Por otro lado si lo quieres es medir tu enlace WAN, ahí podrías utilizar un servidor FTP en tu red central y que en la red remota descarguen un archivo de tamaño considerable de ese servidor, de la misma forma podrías instalarte Networx en la PC de la oficina remota y medir cuantos bits/s está recibiendo a través del enlace WAN. Para medir el rendimiento de un enlace WAN existen herramientas más especializadas como WAN Killer Network Traffic Generator de Solarwinds, sin embargo para estas pruebas básicas vas bien con las herramientas anteriormente mencionadas.

    Respecto a tu segundo comentario, tu indicas que tu descarga es a 248 KB/s… para llevarlo a Kilo bit tienes que multiplicar x8… esto sería 1984 Kbit/s… que prácticamente esto es equivalente 2 Mbps que es lo que «en teoría» te ofrece el ISP. Sin embargo tienes que tener en cuenta de donde estás realizando tu descarga, generalmente muchos servidores de archivos en Internet, ponen un límite de velocidad a la cual se pueden descargar datos… no hagas solo 1 descarga… haz múltiples descargas de múltiples lugares, tienes que saturar tu conexión y medir efectivamente cuantos bits/s recibes en tu interface. Instálate una de esas herramientas y lo podrás ver de una manera más adecuada.

    Atento a tus comentarios =D

    Saludos cordiales!

    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    #17349

    Excelente Alvaro ya queda mas claro el tema.

    #19443
    Ricardo Casillas
    Participante

    Hola Alvaro
    Tengo una duda respecto a la siguiente pregunta.
    5. ¿Qué significaría que un ping fue exitoso a la dirección IPv6 ::1?
    La respuesta «Que la capa de Enlace de datos funciona correctamente» también podría ser correcta? Comprendo que como el mensaje llego exitosamente es gracias en parte a la capa de enlace de datos.

    Gracias de antemano.
    Saludos.

    #19448
    AlvaroM
    Superadministrador

    Hola Ricardo!

    No podría ser correcto ya que estas haciendo un ping a una dirección Loopback, recuerda esta clase https://netwgeeks.com/topic/1-11-direcciones-privadas-publicas-y-especiales-2/, cuando tú haces un ping a una dirección Loopback, solamente estas verificando el correcto funcionamiento hasta la capa de Red/Internet. Cuando haces un ping a una dirección loopback, el paquete NUNCA sale de la interface de red, por lo tanto el paquete nunca llega a la capa de Enlace de datos y por consiguiente tampoco llega a la capa Física! =)

    Espero que ahora quede claro!

    Atento a tus comentarios!

    Saludos cordiales

    #33557

    Buenas noches, una consulta, al hacer ping a una dirección IP, cuales son los valores óptimos que debe tener el campo de «Bytes», «tiempo» y «TTL» ?

    #33562
    AlvaroM
    Superadministrador

    Hola Gianfranco, no existen valores óptimos, todo depende de lo que quieres hacer, del sistema operativo que utilizas para generar el ping, con qué dispositivo te comunicas (distancia, medios de transmisión involucrados, dispositivos existentes, etc.)

    Respecto al campo bytes, todo depende del tipo de implementación que se haga en tu SO, algunos sistemas operativos generan pings de 64 bytes, otros de 56, otros de 32, si gustas puedes incrementar el valor, ya depende de ti y lo que quieras hacer. Respecto al campo tiempo, esto dependerá de muchísimos factores, por ejemplo no es lo mismo hacer un ping a un dispositivo directamente conectado, que un ping a un host al otro lado del mundo a través de una conexión satelital… no es lo mismo un ping utilizando fibra óptica que cobre, no es lo mismo hacer ping a través de un dispositivo nuevo que a través de dispositivos de los años 70, no es lo mismo hacer ping a un servidor sin carga que a un servidor/dispositivo con problemas de procesamiento, no es lo mismo hacer ping a una red congestiona que a una red libre… hay tantos factores a considerar; diferentes situaciones tendrán diferentes respuestas. Respecto al campo TTL, de nuevo el valor «recomendado» no existe, ya que el valor de TTL solo te indica los saltos que das para llegar al destino, de nada sirve que solo tengas 1 salto al destino si el medio de transmisión/ancho de banda es pobre, por otro lado no importa que estés a 20 saltos del destino si la conexión es estable y tienes buen ancho de banda de inicio a fin.
    Al final todo se resume a DEPENDE de cada situación, no hay reglas absolutas, hay tantas situaciones a considerar.

    saludos! =)

    #46283
    richchri
    Participante

    No me queda claro el tema de los códigos. Los Códigos varian de acuerdo al campo Type del encabezado ICMP o la tabla de valores de los códigos es la misma independientente al valor en el campo type?. Es que todos los códigos citan que es el host, la red inalcanzable, entonces para un Type=8 indica que es ICMP ECHO Request pero si tiene el código 0 indicaría Network unrechable, pero cual sería el código si la red es alcanzable. No se si logra entender el sentido de mi pregunta. Gracias y saludos.

    #46289
    AlvaroM
    Superadministrador

    Hola Richri!

    Los significados de los códigos varían de acuerdo al campo Type, los valores de código pueden ser los mismos en diferentes situaciones, pero el significado es el que cambia. Por ejemplo, el valor de Type 3 es «Destination Unreachable», y para ese Type 3 el Code 0 significa «Network Unreachable»; sin embargo, el valor de Type 5 significa «Redirect», y un valor de Code 0 para ese Type significa «Redirect Datagram for the network».

    En ICMP Echo request tenemos un Type 8 y un Code 0; el que tengas un Code 0 no significa nada por sí solo, ya que necesitas saber cuál es el «Type» para entender qué es lo que significa en realidad. Ambos números son relevantes.

    Respecto a «red alcanzable», esto se indica gracias al mensaje ICMP Echo Reply (Type 0 Code 0), eso confirma que el dispositivo de destino es alcanzado, y por ende su red lógica también lo es.

    No sé si ahora queda claro…. estoy atento!

    Saludos cordiales. =)

Viendo 13 entradas - de la 1 a la 13 (de un total de 13)
  • Debes estar registrado para responder a este debate.