En ésta entrada voy a escribir una introducción a ICMP, que es el principal protocolo para diagnóstico de fallas en una red de datos. También voy a mencionar algunos importantes cambios que existen en el protocolo cuando se usa en IPv6 respecto a la versión anterior. Éste contenido está alineado con el contenido del módulo 13 de CCNAv7 ITN. Disfrútenlo.
Introducción: qué es ICMP?
El protocolo que vamos a describir se llama de esa manera por las siglas en inglés de Internet Control Messaging Protocol, es un protocolo adjunto a IP, es decir, cualquier nodo que soporte IP debe soportar ICMP y en el encabezado IP se identifica como el protocol type nro 1. Éste protocolo tiene dos propósitos: 1) Comunicar condiciones de error en la transmisión de paquetes, 2) Informar situaciones sobre la red que pueden cambiar el comportamiento del tráfico. Lo que más experimentamos cuando usamos este protocolo es el caso nro 1, es decir, condiciones de error como inalcanzabilidad de un nodo o red, de otro lado, menos conocidos, son los mensajes informativos, por ejemplo, rutas alternativas o congestión. Las «aplicaciones» más comunes que usamos con base en ICMP son ping y traceroute, ambas usan mensajes ICMP para diagnosticar la comunicación en una red IP.
ICMP versus ICMPv6
Hay muchas diferencias entre la versión 6 y 4 del protocolo, empezando con que la versión 6 se encapsula en paquetes IPv6. Adicionalmente a ésta obviedad, la nueva versión reemplaza lo que en v4 hacía ARP y lo mencionamos en una publicación anterior. En ICMPv6 existe una especie de subprotocolo llamado ND o Neighbor Discovery que sustituye y extiende las capacidades de ARP. Éste subprotocolo se divide a su vez en descubrimiento de routers y descubrimiento de vecinos, con una estrategia igual: primero se hace una solicitation y luego se hace un advertisement, en el caso de los routers los mensajes se llaman RS y RA respectivamente y en el caso de hosts (neighbors) se llaman NS/NA. Aunque suena simple, el diseño ha hecho que éstos mensajes sean muy importantes, por ejemplo, un RA (router adverstisement) es un mensaje ICMP que puede indicarle al host a qué segmento de red pertenece (prefix) y que se puede autoconfigurar, algo muy similar a DHCP pero sin llevar el control del estado de los préstamos de IPs. A éste procedimiento se le conoce como SLAAC por sus siglas en inglés: Stateless Address Auto Configuration que en español traduciría algo como autoconfiguración de dirección sin estado. Sin embargo, aunque este procedimiento permite que un host obtenga una IPv6 válida, el router le puede indicar que de todos modos busque más parámetros en un DHCPv6. Como ven, las diferencias entre ICMPv4 y v6 son grandes. Una nota interesante, es que en IPv6 la dirección de enlace local es muy importante, por ejemplo, cuando un nodo se autoconfigura, usará la dirección de enlace local (LLA) del router que respondió con un RA. Si no recuerda o quiere repasar qué son las direcciones de enlace local (LLA) lea mi publicación anterior: introducción a IPv6.
Según lo anterior, un host que recién se conecta a la red enviará una solicitud de router (RS) con una dirección destino especial (todos los routers del segmento), si existe un router configurado para responder a éstas solicitudes, éste responderá con una publicación de router (RA) y en ésta indicará el prefijo de la red y si es necesario usar el DHCPv6 de todas formas.
De otro lado, los hosts obtenían la MAC de los vecinos usando ARP, en IPv6 se utiliza la parte de ND dedicada a los vecinos para hacer lo mismo. Si un host necesita la MAC de otro en IPv6, éste envía un NS (neighbor solicitation) y si el host en cuestión recibe el paquete, éste responde con un NA (neighbor advertisement). Éste procedimiento también es más complejo que eso, por ejemplo, el host que responde puede indicarle a los hosts que escuchan por cuánto tiempo se debería guardar la información, entre otros parámetros.
En IPv4 hay un procedimiento poco conocido llamado Gratuitous ARP que consiste en enviar un ARP solicitando la IP que el host tiene asignada. Este es un truco ingenioso para descubrir si la dirección ya está asignada en la red. Éste procedimiento en IPv6 se hace mediante ICMPv6 y se llama DAD por sus siglas en inglés: Duplicate Address Detection. La idea es la misma: se hace un NS preguntando la MAC de un host con la IPv6 que se ha asignado y si alguno responde es porque la IPv6 está duplicada. Lindo, no?
Aplicaciones de ICMP: ping y traceroute
Cualquiera de las variantes del protocolo, usa los campos tipo y código para definir qué se está comunicando y éstos a su vez determinan qué información se transporta en el mensaje. Por ejemplo, cuando hacemos un ping, el mensaje inicial es un ICMP tipo echo y la respuesta es un ICMP tipo echo reply. Otro ejemplo más claro es el conjunto de mensajes de destination unreachable, que contienen en el campo tipo el nro 3 (para IPv4), pero como existen diferentes posibles causas se usa el campo code para distinguirlas: 0 = Network unreachable, 1 = Host unreachable, 2 = Protocol unreachable, 3 = port unreachable, etc. (saber más). Para ICMPv6 es similar, excepto porque los números que se usan son diferentes: tipo 1 y códigos similares (saber más).
Ping es una utilidad básica de diagnóstico que prueba si desde la IP origen hasta la IP destino hay conectividad de red, es decir, si hay conexión física y enrutamiento. Ping no es una utilidad muy confiable pero es la más fácil y rápida de usar. Además de estas características, ping se puede usar confiablemente dentro de nuestro dominio de administración, es decir, dentro de la porción del camino al destino que sí conocemos y administramos. Por qué no es tan confiable el ping? lo primero que hay que tener en cuenta es que existen muchas razones por las que un ping puede fallar que no tienen que ver con la conectividad IP, por ejemplo, un firewall en el camino o en el destino mismo puede rechazar, por seguridad, la respuesta a un ping. Éste es un caso típico en estaciones Windows que usualmente no responden por el firewall local.
Otra razón por la cual un ping puede fallar es porque la dirección origen no es conocida desde el destino. Es muy importante que observen que un mensaje de ping se hace desde una IP a otra, por ejemplo, cuando se hace desde un router, que tiene varias IPs (una por interfaz), se tiene que tener en cuenta cuál de ellas se está usando como dirección origen.
Cómo funciona traceroute?
Nota: la utilidad se llama traceroute, pero en Windows el comando es tracert. Uno de los mensajes ICMP se llama time to live exceeded o tiempo de vida excedido (icmp type 11 code 0), ya lo hemos mencionado antes: cada vez que un dispositivo de capa tres, como un router, pasa un paquete IP de una interfaz a otra, decrementa un contador del encabezado IP llamado TTL, cuando un router (u otro dispositivo capa 3), al decrementar el paquete obtiene 0, no envía el paquete y devuelve al origen un paquete ICMP time to live exceeded. Aunque eso no parece tener nada que ver, a alguien se le ocurrió la ingeniosa idea de determinar por qué equipos de capa 3 o saltos pasa un paquete para llegar a su destino usando el ttl. El principio es muy simple, cuando se inicia un traceroute a cierta IP destino, la compu toma la IP origen por donde salen los paquetes hacia el destino y envía tres paquetes icmp con el campo ttl en 1 consultando cierto puerto particular, cuando el primer router pasa el paquete a la interfaz de salida, establece el ttl en 0 y responde con ttl exceeded (y así tres veces), de ésta forma la app (traceroute) registra la IP origen de los paquetes como el primer salto y toma estadísticas de tiempo; luego repite el proceso pero ésta vez con ttl=2, el primer router pasa el paquete pero el segundo no y la app guarda el dato, luego repite con ttl=3 y así sucesivamente. Cuando los paquetes llegan al destino, la respuesta es diferente, en éste caso se responde con puerto inalcanzable y se termina el proceso. Es una idea muy ingeniosa y bastante práctica.
Éstas dos utilidades de cualquier sistema que soporte IP son fundamentales y son el principio de cualquier diagnóstico de fallos, sin embargo, se debe ser cuidadoso al momento de usarlas. La recomendación inicial es verificar conectividad desde lo más cercano a lo más lejano, por ejemplo, el primer ping debe ser a la puerta de enlace (se puede obtener con un cmd –> ipconfig y asegurarse de que se observan los datos de la interfaz que conecta con el destino). Una vez que se verifica la conectividad a la puerta por defecto, se puede hacer ping a los dns (también aparecen en el ipconfig pero si se usa /all), finalmente, se puede hacer ping a un host por nombre de dominio, es decir, google.com, cisco.com o facebook.com, en caso de que el último falle, las causas pueden ser diversas y se puede requerir información adicional. Por ejemplo, puede que falle el ping a facebook.com pero no a google.com, entonces el problema no es local, puede ser en el dns o en facebook mismo.
Una vez que se ha determinado si el problema es local o remoto, se puede hacer un traceroute con el fin de determinar hasta dónde en el camino al destino llegan los paquetes. Traceroute nos dará un conjunto de IPs, generalmente las direcciones de las interfaces de los routers por los cuales pasa el paquete rumbo al destino, el siguiente a la última IP que aparezca es donde el paquete no obtuvo respuesta y probablemente sea el lugar de la falla, que puede ser desde un problema de enrutamiento hasta un problema físico.
Ejemplo de uso de ping y traceroute
Ahora vamos a ver cómo se usan las aplicaciones mencionadas. Observemos la siguiente red, en ella tenemos tres redes LAN, tres enlaces punto a punto, un switch y tres routers:
En ésta caso, todo está configurado para funcionar bien y como se esperaría: si PC0 quiere alcanzar a PC1 el tráfico se va por el enlace entre LanRouter y LanRouter(1), si el mismo PC quiere alcanzar al Servidor0 el tráfico se va por el enlace entre LanRouter y DataCenterRT1. Esa podría no ser la situación, cuando vean enrutamiento podrán jugar con eso, por ejemplo, yo podría decir que el enlace entre LanRouter y DataCenterRT1 siempre debe ser mejor y el tráfico hacia la otra Lan debiera pasar por ahí, es una decisión que no es técnica, puede ser por costos de uso de los otros enlaces entre otras posibles razones, así que el tráfico no necesariamente se comportará como es lógico. Entonces debemos diagnosticar por dónde viajan los paquetes.
Packet Tracer simula estaciones windows, por lo que las imágenes que les voy a mostrar son muy fieles a como sería en una estación Windows. Primero abrimos el PC con un clic normal, luego buscamos el escritorio y ahí damos clic sobre Command prompt como se ve en la siguiente imagen:
El equivalente de ésto en una estación Windows real sería oprimir la tecla ventana simultáneamente con la letra R, escribir CMD, dar enter, alternativamente, se puede abrir el inicio y escribir CMD, luego dar clic sobre el ícono de terminal que diga CMD. Lo anterior nos da como resultado una pantalla negra para escribir comandos llamada shell. Teniendo una ventana de terminal escribimos los comandos ping y tracert como en la siguiente imagen y damos enter. Si queremos hacer los mismo en una red real cambiamos las IPs por las reales.
Observen cuál IP es la que registra el comando tracert: es la IP que tiene el router en la interfaz que da hacia el origen. Noten también algo: cuando describí el funcionamiento de traceroute dije que se envían tres paquetes y como pueden ver en el resultado, para cada salto hay tres tiempos diferentes, éstos corresponden a cada paquete enviado con el mismo ttl. Y también recuerden que un ping bien hecho consiste en ir de lo más cercano a lo más lejano e involucrar en algún momento el dns, es decir, hacer ping al default gateway, luego a los dns y finalmente a un nombre de host conocido como google.com, cisco.com o facebook.com. No se debe empezar con la última prueba porque en ésta puede estar fallando la conectividad IP, el DNS o ambas y no hay cómo hacer un diagnóstico exacto.
Conclusiones y siguientes publicaciones
Como ven, ICMP es un protocolo muy importante y cambia un poco en la nueva versión para IPv6. Lo que vemos y debemos aprender en éste momento es sólo cómo usar ping y traceroute, más adelante lo usaremos más intensivamente y será fundamental interpretar los resultados.
Siguiendo el contenido de ITN y preparación para el examen 200-301 CCNA, la siguiente publicación será sobre cómo funciona la capa de transporte de TCP/IP, es un tema fascinante y un poco complejo que probablemente requiera un par de publicaciones. Estén atentos, y si les gustó el contenido, comenten y compartan.