El encaminador de New
York ha enviado mensajes de Destino inalcanzable, que se muestran en la
pantalla con las respuestas "!H". La propia función
traceroute utiliza los mensajes de Plazo superado de ICMP. El
procedimiento es:
* Se construye un mensaje de UDP. Se le da una cabecera de IP cuyo
tiempo de vida sea 1.
* Se transmite el datagrama tres veces.
* El primer encaminador, nomad-gateway en el ejemplo anterior,
decrementa el tiempo de vida al valor 0, descarta el datagrama y envía
de vuelta un mensaje de Plazo superado de ICMP al origen.
* La función traceroute identifica al encaminador que envió el mensaje
e imprime los tres tiempos de ida y vuelta.
* Se pone el tiempo de vida a 2 y se envían de nuevo los mensajes.
* El proceso se repite, aumentando el tiempo de vida en cada paso.
Si se pudiera llegar al destino, se mostrara toda la ruta perfectamente
:) Ahora ya podeis jugar con este comando para ver por donde pasa un
datagrama cuando lo envies a un destino.
CUÁNDO NO ENVIAR MENSAJES DE ICMP
Se puede esperar que los mensajes de ICMP se envíen cuando una red
tiene problemas. Es importante asegurar que el tráfico de ICMP no
inunda la red, empeorando la situación. Hay que imponer algunos límites
obvios al protocolo. ICMP debe informar de los problemas causados por:
* El encaminamiento o el envío de mensajes de ICMP.
* La difusión o multienvío de datagramas.
* Fragmentos de datagrama distintos del primero.
* Mensajes cuya dirección de origen no identifique a un host único,
como por ejemplo las direcciones de IP como 127.0.0.1 o 0.0.0.0.
FORMATO DE MENSAJES DE ICMP
Recuerde que los mensajes de ICMP se transmiten en la parte de datos de
un datagrama de IP. Cada mensaje de ICMP empieza con los mismos tres
campos: un campo de Tipo, un campo de Código que a veces ofrece
descripción concreta del error y un campo Suma de control. El formato
del resto del mensaje viene determinado por el tipo. Los mensajes de
error de ICMP incluyen la cabecera de ip y los 8 primeros octetos del
datagrama que ocasionó el error. Esta información se puede utilizar
para resolver el problema, ya que incluye datos como el destino previsto
y protocolo destino de la capa 4. Al mensaje de ICMP se le aplica la
suma de control de ICMP, empezando desde el campo Tipo.
MENSAJE DESTINO INALCANZABLE
La entrega de un datagrama puede fallar en muchos momentos. Debido a un
enlace roto, a un encaminador físicamente incapaz de llegar a una
subred de destino o para ejecutar el siguiente salto de encaminamiento.
El destino puede estar fuera de servicio por labores de mantenimiento.
Todos sabemos que en esta tiempo podemos encontrar dispositivos
inteligentes que corten el paso a host de la red por administración
segura de sus redes, pues entonces tambien estariamos con un mensaje de
control de este tipo. El tipo de ICMP es el 3 y en el campo codigo
pueden haber distintos valores que expondremos ahora mismo:
Tipo = 3 "Código" Suma de control
|
|
No
usado
|
| Cabecera de
Internet + 8 octetos de los datos del datagrama original |
| Código |
Significado |
| 0 |
No se puede llegar
a la red. |
| 1 |
No se puede llegar
al host. |
| 2 |
El destino no
dispone del protocolo solicitado. |
| 3 |
No se puede llegar
al puerto. Puede que la aplicación de destino no esté libre. |
| 4 |
Se necesita
realizar fragmentación, pero se ha establecido la bandera
"No fragmentar". |
| 5 |
La ruta de origen
no es correcta. |
| 6 |
No se conoce la
red de destino. |
| 7 |
No se conoce el
host de destino. |
| 8 |
El host origen está
aislado. |
| 9 |
La comunicación
con la red de destino está prohibida por razones administrativas. |
| 10 |
La comunicación
con el host de destino está prohibida por razones
administrativas. |
| 11 |
No se puede llegar
a la red debido al Tipo de servicio. |
| 12 |
No se puede llegar
al host debido al Tipo de servicio. |
MENSAJE DE
PLAZO SUPERADO
Un datagrama puede expirar porque su tiempo de vida ha llegado a cero
mientras se encontraba en tránsito. Otra razón es cuando el plazo de
reensamblado del host expira antes de que lleguen todos los fragmentos.
En cualquier caso, se envía un mensaje de ICMP de Plazo expirado al
origen del datagrama. El formato del mensaje es el siguiente:
Tipo = 11 "Código" Suma de control
|
|
No
usado
|
| Cabecera de
Internet + 8 octetos de los datos del datagrama original |
Los
valores de los códigos indican la naturaleza del plazo, y se pueden ver
en la siguiente tabla:
| Código |
Significado |
| 0 |
Se ha excedido
el tiempo de vida |
| 1 |
Ha expirado el
plazo de reensamblado |
MENSAJE
PROBLEMAS DE PARÁMETROS
El mensaje de ICMP Problemas de parámetros se usa para informar de
otros problemas que no se cubre con ningún otro mensaje de error. Por
ejemplo, puede existir información inconsistente en un campo de
opciones que que sea imposible procesar el datagrama correctamente, por
lo que hay que descartarlo. Lo más habitual en cuanto a problemas de
parámetros se debe a errores de implementación en el sistema que
escribió los parámetros en la cabecera de IP. En el formato del
mensaje que estamos explicando, aparece un nuevo campo,
"Apuntador", te dice en que octeto a detectado el fallo. El
formato del mensaje es:
Tipo = 12 "Código" Suma de control
|
|
|
| Cabecera de
Internet + 8 octetos de los datos del datagrama original |
| Código |
Significado |
| 0 |
El valor del
campo apuntador indica el octeto donde se detectó el error. |
| 1 |
Falta una opción
obligatoria, se indica en la comunidad militar para indicar que
falta una opción de seguridad. |
| 2 |
Tamaño
incorrecto |
ACALLAMIENTO DE
ORIGEN
Este mensaje no es muy efectivo, ya que ¿Cuándo, y quién, debería
enviar un mensaje de acallamiento de origen?. Cuando un encaminador se
ve colapsado puede que el datagrama que descarte no sea del origen que
lo esta colapsando, por eso se esta intentando encontrar algo más
efectivo que un Acallamiento de origen. El formato del mensaje es el
siguiente:
Tipo = 4 "Código" Suma de control
|
|
No
usado
|
| Cabecera de
Internet + 8 octetos de los datos del datagrama original |
MENSAJE
REDIRECCIÓN
Puede que haya mas de un encaminador conectado a la LAN. Si el host
local envía un datagrama al encaminador equivocado, el encaminador
reenviará el datagrama y un mensaje Redirección (Redirect) al host
origen, como se muestra en la Figura 7.8. El jost debería enviar el tráfico
siguiente al encaminador con la ruta más corta. Los mensajes Redirección
se pueden usar para reducir el trabajo manual de administración. Se
puede configurar un encaminador con un único encaminador por defecto y
que aprenda dinámicamente sobre las rutas que van por otros
encaminadores. Algunos protocolos de encaminamiento pueden elegir el
camino de entrea según el campo Tipo de servicio (TOS). Los codigos 2 y
son consejos que reflejan estas consideraciones. El formato de los
mensajes Redirección es:
Tipo = 5 "Código" Suma de control
|
|
Dirección
del encaminador a usar
|
| Cabecera de
Internet + 8 octetos de los datos del datagrama original |
Y la
tabla con los codigos y su significado es:
| Código |
Significado |
| 0 |
Redirigir los
datagramas debido a la red. |
| 1 |
Redirigir los
datagramas debido al host. |
| 2 |
Redirigir los
datagramas debido al Tipo de servicio (TOS) y a la red. |
| 3 |
Redirigir los
datagramas debido al Tipo de servicio (TOS) y al host. |
TRATAMIENTO DE
LOS MENSAJES DE ERROR DE ICMP ENTRANTES
¿Qué se hace cuando llega un mensaje de error de ICMP a un host de
origen? Cada fabricante implementa su software de red de forma variada a
los demas, pero como el protocolo TCP/IP es muy libre, puede existir
muchos modos de actuar con un mensaje de ICMP. Las guías que se dan
para los distintos tipos de mensajes son:
| Destino
inalcanzable |
Entregar el
mensaje de ICMP a la capa de transporte. La acción depende de si
la razón es permanente o transitoria |
| Redirect |
El host debe
actualizar la tabla de encaminamiento |
| Acallamiento de
origen |
Entregar el
mensaje a la capa de transporte o a un módulo de procesamiento de
ICMP |
| Plazo superado |
Entregar el
mensaje a la capa de transporte |
| Problema de parámetros |
Entregar el
mensaje a la capa de transporte; opcionalmente notificar al
usuario |
A
veces, se pueden tratar las condiciones de error mediante la cooperación
entre el sistema operativo, el software de comunicaciones y la aplicación
que realiza la comunicación.
OBTENCIÓN DE LA MTU DE UNA RUTA
Cuando se realiza una operación que transmite gran cantidad de
información entre dos host, como una transferencia de archivos, el tamaño
de datagrama puede tener un gran impacto en el rendimiento del sistema.
Las cabeceras IP y de TCP aportan una sobrecarga de al menos 40 bytes.
Tipo = 8 o 0 "Código" Suma de control
|
Identificador Número de secuencia
|
|
DATOS
|
El famoso comando ping,
que existe en casi todos los sistemas operativos con TCP/IP está
programado usando los mensajes de petición y respuesta de ECO. En el diálogo
que sigue, en primer lugar se comprueba si el host 127.0.0.1 está
activo (tuve que hacerlo con esta host, ya que no estaba conectado en
ese momento a inet). A continuación se envía una secuencia de 14
mensajes, cada uno con 64 bytes de datos. Fíjese que los mensajes 0, 1
y 2 han desaparecido. En la parte derecha se muestra el tiempo de ida y
vuelta.
C:\WINDOWS>ping -n 14 -l 64 127.0.0.1
Pinging 127.0.0.1 with 64 bytes of data:
Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
Donde pone time=?? aparece el tiempo de ida y vuelta que ha transcurrido
a enviar el paquete, tambien puede aparecer time<?? o time>??.
MASCARA DE DIRECCIÓN
Recuerde que una organización puede decidir dividir sus campos de
direcciones locales en parte de subred y parte de host. Cuando se
arranca un sistema puede que no esté configurado para conocer cuantos
bits se le han asignado al campo de dirección de subred. Para
obtenerlo, el sistema puede difundir una petición de Máscara de
Dirección. La respuesta debería enviarla un servidor autorizado de Máscaras
de Dirección. Normalmente, se supone que el servidor sea un
encaminador, pero a veces puede usarse un host. La respuesta pondrá a
uno los campos de red y subred del camo de Máscara de dirección en
cuanto esté activo de nuevo. Se hace así en beneficio de los sitemas
que hayan arrancado mientras no estaba disponible el servidor.
El tipo 17 es para la petición y el Tipo 18 para la respuesta.
Generalmente se pueden ignorar los campos de número de secuencia. En la
actualidad el metodo preferido para determinar la Máscara de Dirección
es utilizando un protocolo de arranque como el Protocolo Dinámico de
Configuración de host, o BOOTP. Estos procesos son más eficientes ya
que disponen de un amplio conjunto de parámetros de configuración.
También son, a menudo, más precisos. Por ejemplo, una estación Unix
puede estar desconfigurada y responder erróneamente a los mensajes de
petición de Mascara de Dirección. El resultado es que su sistema
recibirá varias respuestas y algunas de ellas serán erróneas.
Tipo = 17 o 18 "Código" Suma de control
|
Identificador Número de secuencia
|
|
Máscara
de Dirección
|
MARCA DE TIEMPO
Y SU RESPUESTA
Los mensajes de Marca de Tiempo indican la hora de un sistema y
su objetivo es ofrecer una apreciación de lo que tarda el sistema
remoto en el proceso del búfer y del procesamiento de un datagrama.
Tenga en cuenta estos campos:
| Marca
de Tiempo Original |
La marca de tiempo
en que el origen tocó por última vez el mensaje. |
| Marca de Tiempo
de recepción |
La marca de tiempo
en que el destino lo tocó por primera vez. |
| Marca de tiempo
de transmisión |
La marca de tiempo
en que el destino lo tocó por última vez. |
Si es
posible, el tiempo devuelto debería medirse en milisegundos después de
medianoche, en Tiempo Universal, anteriormente Tiempo medio de
Greenwich. La mayor parte de las implementaciones actuales devuelven la
misma marca de tiempo en los campos Marca de tiempo de recepción y
Marca de tiempo de transmisión. Este protocolo podría ser un método
sencillo para sincronizar los relojes con otros. Por supuesto que la
sincronización sería un poco absurda debido a los posibles retardos de
la red. Existe un protocolo mejor, el Protocolo de Tiempo de Red
definido para la sincronización de la hora en internet. Se usa el Tipo
13 para la petición de Marca de Tiempo y el tipo 14 para la respuesta
de Marca de Tiempo.
Tipo = 13 o 14 "Código" Suma de control
|
Identificador Número de secuencia
|
|
Marca
de tiempo de generación
|
|
Marca
de tiempo de recepción
|
|
Marca
de tiempo de transmisión
|
OBTENCIÓN DE
LAS ACTIVIDADES DE ICMP
A continuación se muestra la parte de ICMP de un informe de netstat
sobre estadísticas de red. Este informe muestra la actividad de ICMP
desde la última inicialización. Veremos la estadistica de un netstat
en windows y en Unix.
Windows:
