Semestre 2 CCNA, Módulo 8

Módulo 8: Mensajes de control y de error de los protocolos TCP/IP

Descripción general

El protocolo IP es limitado porque es un sistema de entrega de mejor esfuerzo. No dispone de un mecanismo para garantizar la entrega de los paquetes de datos, a pesar de los problemas con los que se puedan encontrar en la red. Los paquetes pueden no llegar a su destino por diversas razones, tales como fallas de hardware, configuración inadecuada o información de enrutamiento incorrecta. Para ayudar a identificar estas fallas, el IP usa el Protocolo de mensajes de control en Internets (ICMP), para notificar al emisor de los paquetes que se produjo un error durante el proceso de envío. Este módulo describe los diversos tipos de mensajes de error del ICMP y algunas de las formas en las que se utilizan.

Dado que el protocolo IP no cuenta con un mecanismo incorporado para enviar mensajes de error y control, usa ICMP para enviar y recibir mensajes de error y control a los hosts de la red. Este módulo se refiere principalmente a los mensajes de control, que son los mensajes que suministran información o parámetros de configuración a los hosts. El conocimiento de los mensajes de control del ICMP es una parte esencial del diagnóstico de fallas de la red y es un elemento clave para lograr una comprensión absoluta de las redes IP.

Los estudiantes que completen este módulo deberán ser capaces de:

* Describir el protocolo ICMP
* Describir el formato de mensajes del ICMP
* Identificar los tipos de mensajes de error del ICMP
* Identificar las causas potenciales de mensajes de error específicos
* Describir los mensajes de control del ICMP
* Identificar diversos mensajes de control del ICMP que se usan actualmente en las redes
* Determinar las causas de los mensajes de control del ICMP

8.1 Descripción general de los mensajes de error del TCP/IP

8.1.1 Protocolo de mensajes de control de Internets (ICMP)

El IP es un método poco confiable para la entrega de paquetes de red. Se le conoce como un mecanismo de entrega de mejor esfuerzo. No cuenta con ningún proceso incorporado para garantizar la entrega de paquetes en caso de que se produzca un problema de comunicación en la red. Si un dispositivo que actúa como intermediario falla como por ejemplo un router, o si un dispositivo de destino sale fuera de la red, los paquetes no se pueden entregar. Además, nada en su diseño básico hace que el IP notifique al emisor de que la transmisión ha fallado. El Protocolo de control de mensajes de Internet (ICMP) es el componente del conjunto de protocolos TCP/IP que corrige esta limitación básica del IP. El ICMP no resuelve los problemas de falta de confiabilidad en el protocolo IP. En caso de ser necesario, la confiabilidad debe ser prevista por los protocolos de capa superior.

8.1.2 Informes de error y corrección de errores

El ICMP es un protocolo de notificación de errores para el protocolo IP. Cuando se produce un error en la entrega de datagramas, se usa el ICMP para notificar de dichos errores a la fuente de los datagramas. Por ejemplo, si la estación de trabajo 1 de la Figura envía un datagrama a la estación de trabajo 6, pero la interfaz Fa0/0 del router C deja de funcionar, el router C utiliza ICMP para enviar un mensaje de vuelta a la estación de trabajo 1, el cual notifica que el datagrama no se pudo entregar. El ICMP no corrige el problema en la red; sólo informa del problema.

Cuando el router C recibe el datagrama de la estación de trabajo 1, sólo conoce las direcciones de IP de origen y destino del datagrama. No sabe cuál es la ruta exacta que tomó el datagrama en su camino hacia él. Por lo tanto, el router C sólo puede notificar a la estación de trabajo 1 acerca de la falla, y no se envía ningún mensaje de error ICMP al router A y al router B. El ICMP sólo informa al dispositivo de origen acerca del estado del paquete. No envía ninguna información sobre cambios en la red a los routers.

8.1.3 Entrega de mensajes ICMP

Los mensajes del ICMP se encapsulan en datagramas, del mismo modo en que se entrega cualquier otro dato mediante el protocolo IP. La Figura muestra el encapsulamiento de datos ICMP dentro de un datagrama IP.

Dado que los mensajes del ICMP se transmiten del mismo modo que cualquier otro paquete, están sujetos a las mismas fallas en la entrega. Esto crea una situación en la que los informes de error pueden generar más informes de error, lo que provoca una congestión creciente en una red que ya tiene fallas. Por esta razón, las fallas relativas a los mensajes del ICMP no generan sus propios mensajes de ICMP. De este modo, es posible que haya un error de entrega cuyo informe no llegue nunca de vuelta al emisor de los datos.

8.1.4 Redes fuera de alcance

Las comunicaciones en una red dependen de que se cumpla determinadas condiciones básicas. En primer lugar, los dispositivos emisor y receptor deben disponer de la pila del protocolo TCP/IP debidamente configurada. Esto incluye la instalación del protocolo TCP/IP y de la configuración adecuada de la dirección de IP y la máscara de subred. También se debe configurar una puerta de enlace predeterminada (también conocido como gateway por defecto), si va a haber envío de datagramas fuera de la red local. En segundo lugar, se debe proveer de dispositivos que actúen como intermediarios, para el enrutamiento de los datagramas desde el dispositivo y la red de origen hacia la red de destino. Los routers cumplen esta función. El router también debe disponer del protocolo TCP/IP debidamente configurado en sus interfaces y debe usar un protocolo de enrutamiento adecuado.

Si no se cumplen estas condiciones, no se puede realizar la comunicación entre redes. Por ejemplo, el dispositivo emisor puede dirigir el datagrama a una dirección de IP inexistente o a un dispositivo de destino que está fuera de la red. Los routers también pueden ser puntos de falla si la interfaz de conexión está desactivada o si el router no cuenta con la información necesaria para detectar la red de destino. Si la red de destino no está accesible, se dice que es una red que está fuera de alcance.

Las Figuras y muestran un router que recibe un paquete, el cual no puede enviar a su destino final. No se puede entregar el paquete porque no existe ninguna ruta conocida hacia el destino. Por ello, el router envía al origen un mensaje ICMP llamado de host fuera de alcance.

8.1.5 Uso de ping para verificar el estado del destino

El protocolo ICMP se puede usar para verificar el estado de un destino en particular. La Figura muestra el uso del ICMP para emitir un mensaje de solicitud de eco a un dispositivo de destino. Si el dispositivo de destino recibe la petición de eco, crea un mensaje de respuesta el cual es enviado de vuelta al origen de la petición. Si el emisor recibe la respuesta, confirma que el dispositivo destino se puede alcanzar mediante el uso del protocolo IP.

Generalmente, el mensaje de petición de eco se inicia al ejecutar el comando ping, como se muestra en la Figura . En este ejemplo, el comando se usa con la dirección de IP del dispositivo de destino. El comando se puede usar también como se muestra en la Figura usando la dirección IP del dispositivo destino. En estos ejemplos, el comando ping emite cuatro peticiones de eco y recibe cuatro respuestas, lo que confirma la conectividad IP entre los dos dispositivos.

Como se muestra en la figura , la respuesta de eco incluye un valor TTL (tiempo de vida) el cual es un campo del ancabezado de un paquete IP que limita el número de reenvíos de un paquete. al procesar un paquete, cada router decrementa el valor de TTL en uno. Cuando un router recibe un paquete con un valor de 1, éste no puede ser reenviado. Un mensaje ICMP se genera y se manda al origen, y el paquete original se elimina.

8.1.6 Detección de rutas excesivamente largas

Se puede producir situaciones en las comunicaciones de red en las que un datagrama viaje en círculos, sin llegar nunca a su destino. Esto puede ocurrir si dos routers enrutan continuamente un datagrama de ida y vuelta entre ellos, pensando que el otro debe ser el siguiente salto hacia el destino. Éste es un ejemplo de información de enrutamiento defectuosa.

Las limitantes del protocolo de enrutamiento pueden dar como resultado destinos inalcanzables. El número máximo de saltos en RIP es de 15, lo cual significa que las redes mayores a los 15 saltos no se pueden manejar con RIP.

En cualquiera de los casos, existe una ruta excesivamente larga. Ya sea que la ruta actual incluya un círculo, o bien que el paquete exceda el número máximo de saltos.

8.1.7 Mensajes de eco

Al igual que cualquier tipo de paquete, los mensajes ICMP tienen formatos especiales. Cada tipo de mensaje ICMP que se muestra en la Figura tiene sus propias características, pero todos los formatos de mensaje ICMP comienzan con estos mismos tres campos:

* Tipo
* Código
* Suma de comprobación (checksum)

El campo de tipo indica el tipo de mensaje ICMP que se envía. El campo de código incluye información adicional relativa al tipo de mensaje en particular. El campo checksum (suma de comprobación), al igual que en los otros tipos de paquetes, se usa para verificar la integridad de los datos.

La Figura muestra el formato de los mensajes ICMP "echo request" (petición de eco) y "echo reply" (respuesta de eco). Se muestra el tipo y los números de código pertinentes para cada tipo de mensaje. El campo identificador y el de número de secuencia son exclusivos de los mensajes de petición de eco y respuesta de eco. Estos campos se usan para comparar las respuestas de eco con la petición de eco correspondiente. El campo de datos contiene información adicional que puede formar parte de un mensaje de petición de eco o de respuesta de eco).

8.1.8 Mensaje "destination unreachable" (destino fuera de alcance)

No siempre es posible enviar los datagramas a sus destinos. Las fallas de hardware, configuraciones inadecuadas del protocolo, interfaces inactivas y errores en la información de enrutamiento son algunas de las razones que pueden impedir que la entrega se complete con éxito. En estos casos, el ICMP envía de vuelta al emisor un mensaje llamado "destination unreachable" (destino fuera de alcance), el cual le indica al emisor que el datagrama no se pudo entregar adecuadamente.

La Figura muestra el encabezado de un mensaje de destino fuera de alcance del ICMP. El valor 3 en el campo de tipo señala que es un mensaje de destino fuera de alcance. El valor del código indica el motivo por el cual el paquete no se pudo entregar. La Figura muestra un valor de código de 0, lo que indica que la red está fuera de alcance. La Figura muestra el significado de cada uno de los valores de código posibles en un mensaje de destino fuera de alcance.

También se puede enviar un mensaje de destino fuera de alcance cuando se requiere la fragmentación de los paquetes para hacer posible su envío. La fragmentación generalmente es necesaria cuando se envía un datagrama desde una red Token-Ring a una red Ethernet. Si el datagrama no permite la fragmentación, el paquete no puede enviarse, por lo que se envía un mensaje de destino fuera de alcance. Los mensajes de destino fuera de alcance también se pueden generar si los servicios IP relacionados, como por ejemplo el FTP o los servicios WWW, no están disponibles. Para diagnosticar las fallas de una red IP de forma eficaz, es necesario comprender las diversas causas de los mensajes ICMP de destino fuera de alcance.

8.1.9 Otros informes de error

Es posible que los dispositivos que procesan datagramas no puedan enviar un datagrama debido a un error en el encabezado. Este error no se relaciona con el estado del host de destino o de su red, pero impide que el datagrama se procese y se envíe, y debido a esto, el datgrama se descarta. En este caso, se envía un mensaje ICMP "parameter problem" (problema de parámetros) de tipo 12 a la fuente del datagrama. La Figura muestra el encabezado del mensaje de problema de parámetros.

El mensaje de problema de parámetros incluye el campo del marcador o apuntador del encabezado. Si el valor del código es 0, el campo de marcador indica el octeto del datagram que generó el error.

8.2 Mensajes de control del conjunto de protocolos TCP/IP

8.2.1 Introducción a los mensajes de control

El Protocolo de mensajes de control en Internet (ICMP) es una parte integral del conjunto de protocolos TCP/IP. De hecho, todas las implementaciones del IP deben incluir soporte al ICMP. La razón es muy sencilla. En primer lugar, dado que el IP no garantiza la entrega, no cuenta con ningún método incorporado para informar a los hosts que se ha producido un error. Además, el IP no cuenta con ningún método incorporado para suministrar mensajes de información o control a los hosts. El ICMP ejecuta estas funciones para el IP.

A diferencia de los mensajes de error, los mensajes de control no se presentan como el resultado deperdida de paquetes o condiciones de error que puedan ocurrir durante la transmisión de los paquetes, sino que se utilizan para mantener a los hosts informadosde eventos como congestionamiento o la existencia de un mejor gatewaya una red remota. ICMP usa el header IP básico para viajar a través de varias redes.

El ICMP usa múltiples tipos de mensajes de control. Algunos de los más comunes se muestran en la Figura . Muchos de ellos se tratan en esta sección.

8.2.2 Peticiones ICMP de redireccionamiento/cambio

Un mensaje común de control del protocolo ICMP es la petición de redireccionamiento/cambio. Este tipo de mensaje sólo puede originarse de un gateway, que es un término que se usa comúnmente para describir un router. Todos los hosts que se comunican con múltiples redes IP deben tener configurado un gateway por defecto. Este gateway por defecto es la dirección del puerto del router conectado a la misma red que el host. La Figura muestra un host conectado a un router que tiene acceso a la Internet. Una vez configurado con la dirección IP de la interfaz Fa 0/0 como su gateway por defecto, el host B usa esa dirección de IP para llegar a cualquier red a la cual no esté conectado directamente. Normalmente, el host B está conectado sólo a un gateway. Sin embargo, en algunos casos, el host está conectado a un segmento de red el cual tiene dos o más routers conectados directamente. En este caso, es posible que el gateway por defecto del host deba utilizar una petición de redireccionamiento/cambio para informar al host cuál es la mejor ruta hacia una red determinada.

La Figura muestra una red donde podría ocurrir el redireccionamiento ICMP. El host B envía un paquete al host C en la red 10.0.0.0/8. Dado que el host B no está directamente conectado a la misma red, envía el paquete a su gateway por defecto, el router A. El router A encuentra la ruta correcta hacia la red 10.0.0.0/8 en su tabla de enrutamiento, y determina que la ruta hacia la red es a través de la misma interfaz de la que provino la petición para enviar el paquete. Envía el paquete y hace una petición ICMP de redireccionamiento/cambio al host B, en la cual le indica que debe usar el router B como gateway para enviar todas las peticiones futuras para la red 10.0.0.0/8.

Los gateway por defecto envían mensajes ICMP de peticiones de redireccionamiento/cambio sólo si se cumplen las siguientes condiciones:

* La interfaz a través de la cual el paquete ingresa al router es la misma a través de la cual sale el paquete enrutado.
* La subred/red de la dirección de IP de origen es la misma red/subred de la dirección de IP del salto siguiente del paquete enrutado.
* El datagrama no está enrutado desde el origen.
* La ruta para el redireccionamiento no es otro redireccionamiento ICMP ni otra ruta por defecto.
* El router está configurado para enviar redireccionamientos. (Por defecto, los routers Cisco envían redireccionamientos ICMP. El subcomando de interfaces no ip redirects inhabilita todos los redireccionamientos ICMP).

La petición ICMP de redireccionamiento/cambio utiliza el formato que se muestra en la Figura . Tiene un código ICMP de tipo 5. Además, puede tener valores de código de 0, 1, 2 ó 3.

El campo Router Internet Address (Dirección Internet del router) del redireccionamiento ICMP es la dirección de IP a ser usada como gateway por defecto para una red en particular. En el ejemplo que aparece en la Figura , el redireccionamiento ICMP que se envía desde el router A al host B tiene un valor de campo del Router Internet Address de 172.16.1.200, el cual es la dirección IP de la interfaz E0 en el router B.

8.2.3 Sincronización de relojes y estimación del tiempo de tránsito

El conjunto de protocolos TCP/IP permite que los sistemas se conecten entre sí a través de amplias distancias por múltiples redes. Cada una de estas redes individuales hace su sincronización de reloj de una manera particular. Como resultado de ello, puede haber problemas en el caso de hosts en redes distintas que tratan de comunicarse mediante software que requiere de sincronización de reloj. El mensaje ICMP de tipo "timestamp" (de marca horaria) está diseñado para ayudar a resolver este problema.

El mensaje ICMP de petición de marca horaria permite que un host solicite la hora actual que observa el host remoto. El host remoto usa un mensaje ICMP de respuesta de marca horaria para responder a la petición.

El campo de tipo de un mensaje ICMP de marca horaria puede ser 13 (timestamp request/petición de marca horaria) o 14 (timestamp reply/respuesta de marca horaria). El valor del campo de código se fija siempre en 0 dado que no hay ningún parámetro adicional disponible. La petición de marca horaria ICMP contiene una marca horaria de origen, que es la hora en el host solicitante al momento de enviar la petición de marca horaria. La marca horaria de recepción es la hora en que el host destino recibe la petición de marca horaria. La marca horaria de transmisión se completa justo antes de que se devuelva la respuesta de marca horaria. Las marcas horarias de origen, recepción y transmisión se calculan según la cantidad de milisegundos que transcurrieron desde la medianoche de la Hora Universal (UT).

Todos los mensajes ICMP de respuesta de marca horaria contienen las marcas horarias de origen, recepción y transmisión. Usando estos tres marca de tiempo, el cliente puede determinar el tiempo de tránsito a través de la red mediante la resta del tiempo de llegada y el tiempo de salida. O también en la dirección contraria restando el tiempo de transmisión del tiempo actual. El host que originó la petición de marca horaria también puede estimar la hora local en la computadora remota.

Aunque los mensajes ICMP de marca horaria suministran una forma sencilla para estimar la hora en un host remoto y el tiempo de tránsito total de una red, no es la mejor manera de obtener esta información. En lugar de ello, existen protocolos más sólidos como por ejemplo el Protocolo de hora de red (NTP), perteneciente a las capas superiores de la pila del protocolo TCP/IP, el cual realiza la sincronización de relojes de un modo más confiable.

8.2.4 Formatos de los mensajes de petición de información y de respuesta

Los mensajes ICMP de petición de información y de respuesta fueron concebidos originalmente para permitir que el host determine su número de red. La Figura muestra el formato de un mensaje ICMP de petición de información y de respuesta.

Hay dos códigos de tipo disponibles para estos mensajes. El tipo 15 indica un mensaje de petición de información y el tipo 16 señala un mensaje de respuesta de información. Este tipo de mensaje ICMP en particular se considera obsoleto. En la actualidad se usan otros protocolos como, por ejemplo el BOOTP, Reverse Address Resolution Protocol (RARP), y el Protocolo de configuración dinámica del host (DHCP), para que los hosts obtengan sus números de red.

8.2.5 Solicitud de la máscara de dirección

Cuando un administrador de red emplea el proceso de división en subredes para dividir un grupo amplio de direcciones IP en múltiples subredes, se crea una nueva máscara de subred. Esta nueva máscara de subred es vital para identificar los bits correspondientes a la red, la subred y el host de una dirección de IP. Si un host no conoce su máscara de subred, puede enviar una petición de máscara al router local. Si se conoce la dirección del router, esta petición se puede enviar directamente al router. De otro modo, la petición será hecha como broadcast. Cuando el router recibe la petición, envía de vuelta una respuesta de máscara de dirección o "address mask reply". Esta respuesta de máscara de dirección indica la máscara de subred correcta. Por ejemplo, consideremos que el host se encuentra en una red Clase B y tiene una dirección de IP de 172.16.5.2. Este host desconoce su máscara de subred, por lo tanto hace una petición de la máscara de dirección como broadcast.

Dirección de origen: 172.16.5.2

Dirección de destino: 255.255.255.255

Protocolo: ICMP = 1

Tipo: Petición de máscara de dirección = AM1

Código: 0

Máscara: 255.255.255.0

Este broadcast se recibe en 172.16.5.1, el router local. El router responde enviando una respuesta de máscara de dirección o "address mask reply":

Dirección de origen: 172.16.5.1

Dirección de destino: 172.16.5.2

Protocolo: ICMP = 1

Tipo: Respuesta de máscara de dirección = AM2

Código: 0

Máscara: 255.255.255.0

Los formatos de la petición y respuesta de máscara de dirección se indican en la Figura . La Figura muestra las descripciones de cada uno de los campos del mensaje de petición de máscara de dirección. Observe que se usa el mismo formato tanto para la petición como para la respuesta de máscara de dirección. Sin embargo, el número de tipo 17 se asigna a la petición y, el 18, a la respuesta.

8.2.6 Mensaje de descubrimiento de routers

Cuando arranca un host de la red, y su gateway por defecto no se ha configurado manualmente, puede aprender cuáles son los routers disponibles a través del proceso de descubrimiento de routers. Este proceso comienza cuando el host envía un mensaje de solicitud de routers a todos los routers. Para ello utiliza la dirección multicast 224.0.0.2 como la dirección destino. La Figura muestra el mensaje ICMP de descubrimiento de routers o "router discovery". El mensaje de descubrimiento de router se puede enviar también como broadcast, para que incluya los routers que no se pueden configurar para multicast. Si se envía un mensaje de descubrimiento de router a un router que no maneja el proceso de descubrimiento, no se recibirá ninguna respuesta a dicho mensaje.

Si un router que permite el proceso de descubrimiento recibe un mensaje de descubrimiento de router, envía de vuelta una publicación o anuncio de router. El formato de la publicación de router se muestra en la Figura y la Figura da una explicación de cada uno de los campos.

8.2.7 Mensaje de solicitud de router

Un host genera un mensaje ICMP de solicitud de router en respuesta a la ausencia de un gateway por defecto. Este mensaje se envía mediante multicast y es el primer paso del proceso de descubrimiento de routers. El router local responde con una publicación de router, en la que se identifica el gateway por defecto para el host local. La Figura identifica el formato de la publicación de router y la Figura da una explicación de cada uno de los campos.

8.2.8 Mensajes de congestión y control de flujo

Si varias computadoras tratan de tener acceso al mismo destino a la vez, la computadora de destino puede ser incapaz de manejar el alto tráfico. También se puede producir congestión cuando el tráfico de una LAN de alta velocidad llega a una conexión WAN más lenta. Cuando hay demasiada congestión en una red, los paquetes se pierden. Los mensajes ICMP source-quench (supresión en el origen) se usan para reducir la cantidad de datos perdidos. Los mensajes de supresión en el origen solicitan a los emisores reducir la velocidad a la que transmiten los paquetes. En la mayoría de los casos, la congestión se reduce luego de un corto período de tiempo, y el origen lentamente aumenta la velocidad de transmisión siempre y cuando no se reciba ningún otro mensaje de supresión en el origen. La mayoría de los routers Cisco por defecto no envían mensajes de supresión en el origen, dado que dichos mensajes pueden contribuir a la congestión de la red.

El caso de las oficinas pequeñas o oficinas en el hogar (SOHO) es uno en el que los mensajes ICMP de supresión en el origen se pueden usar de forma efectiva. Una red SOHO puede estar compuesta por cuatro computadoras conectadas en red mediante cable CAT-5 y que tienen una conexión Internet compartida a través de un módem de 56K. Es muy fácil determinar que el ancho de banda de 10 ó 100 Mbps de la red local puede copar rápidamente el ancho de banda de 56Kbps del enlace WAN, lo que da como resultado la pérdida de datos y las retransmisiones. El host que actúa como gateway puede usar un mensaje ICMP "source quench" para solicitar que los otros hosts reduzcan sus velocidades de transmisión para prevenir la pérdida continua de datos. En la Figura se muestra una red en la que la congestión del enlace WAN puede provocar problemas en la comunicación.

by sdominguez.com