redes i - protocolos de capa de red

Universidad Politecnica Salesiana

Protocolos de capa de red

Daniel Cerna G.

Redes I

1

Daniel Cerna G REDES I UPS

Investigación REDES I

1 LA PROPUESTA DE INVESTIGACION:

Describa y dé ejemplos prácticos (en qué escenarios se utilizan) sobre los siguientes protocolos de capa de red:

• IPsec

• OSPF

• BGP

• RIP

• ICMP

• IGMP

2 RESUMEN DE LA INVESTIGACION:

Estos protocolos nos ayudan a la seguridad de nuestras conexiones y datos a través de algoritmos que nos permiten interconectarnos entre varias redes sin la necesidad de estar preocupados por nuestra privacidad, adicionalmente ciertos protocolos nos ayudan al correcto direccionamiento de nuestros paquetes. Existen protocolos de dependen el uno del otro como por ejemplo el IGMP depende de ICMP.



Daniel Cerna G.

Redes I

2


3 DESARROLLO:

• IPsec

Descripcion:

IPSec no es un solo protocolo, IPSec es un conjunto de algoritmos de seguridad más un entorno de trabajo que permite que dos entidades se comuniquen en forma segura de una manera adecuada.

Aplicaciones de IPSec:

Conexión de dos oficinas por medio del InterNet, Acceso Remoto seguro sobre el InterNet, Establecer conexiones IntraNet+ExtraNet con socios comerciales, Mejorando la seguridad del comercio electrónico.

Ejemplo:



Daniel Cerna G.

Redes I

3


Ventajas de IPSec:

• Transparente a aplicaciones (por debajo de la capa de Transporte )

• Provee seguridad para usuarios individuales.

IPSec nos puede asegurar que:

• Un mensaje proviene de una fuente (ruteador) autorizado.

• Un mensaje redirigido viene del ruteador para el cual fue originalmente enviado

• Las actualizaciones a las tablas de ruteo no hayan sido falsificadas� Ventajas de IPSec

• Transparente a aplicaciones (por debajo de la capa deTransporte )

• Provee seguridad para usuarios individuales.

• Un mensaje proviene de una fuente (ruteador) autorizado.

• Un mensaje redirigido viene del ruteador para el cual fue originalmente enviado

• Las actualizaciones a las tablas de ruteo no hayan sido falsificadas.



Daniel Cerna G.

Redes I

4


• OSPF

Descripcion:

Open Short Path First versión 2, es un protocolo de routing interno basado en el estado del enlace o algoritmo Short Path First, estándar de Internet, que ha sido desarrollado por un grupo de trabajo del Internet Engineering task Force, cuya especificación viene recogida en el RFC 2328.

OSPF, ha sido pensado para el entorno de Internet y su pila de protocolos TCP/IP, como un protocolo de routing interno, es decir, que distribuye información entre routers que pertenecen al mismo Sistema Autónomo.

OSPF es la respuesta de IAB a través del IETF, ante la necesidad de crear un protocolo de routing interno que cubriera las necesidades en Internet de routing interno que el protocolo RIP versión 1 ponía de manifiesto:

Lenta respuesta a los cambios que se producían en la topología de la red.

Poco bagaje en las métricas utilizadas para medir la distancia entre nodos.

Imposibilidad de repartir el trafico entre dos nodos por varios caminos si estos existían por la creación de bucles que saturaban la red.

Imposibilidad de discernir diferentes tipos de servicios.

Imposibilidad de discernir entre host, routers , diferentes tipos de redes dentro de un mismo Sistema Autónomo.

Algunos de estos puntos han sido resueltos por RIP versión 2 que cuenta con un mayor número de métricas así como soporta CIRD, routing por subnet y transmisión multicast.



Daniel Cerna G.

Redes I

5


Características de OSPF

Respuesta rápida y sin bucles ante cambios.

La algoritmia SPF sobre la que se basa OSPF permite con la tecnología actual que existe en los nodos un tiempo de respuesta en cuanto tiempo de computación para el calculo del mapa local de la red mucho más rápido que dicho calculo en el protocolo RIP. Además como todos los nodos de la red calculan el mapa de manera idéntica y poseen el mismo mapa se genera sin bucles ni nodos que se encuentren contando en infinito; principal problema sufrido por los protocolos basados en la algoritmia de vector distancia como RIP.

Seguridad ante los cambios.

Para que el algoritmo de routing funcione adecuadamente debe existir una copia idéntica de la topología de la red en cada nodo de esta.

Existen diversos fallos que pueden ocurrir en la red como fallos de los protocolos de sincronización o inundación, errores de memoria, introducción de información errónea.

El protocolo OSPF especifica que todos los intercambios entre routers deben ser autentificados. El OSPF permite una variedad de esquemas de autentificación y también permite seleccionar un esquema para un área diferente al esquena de otra área. La idea detrás de la autentificación es garantizar que sólo los routers confiables difundan información de routing.

Soporte de múltiples métricas.

La tecnología actual hace que sea posible soportar varias métricas en paralelo.

Evaluando el camino entre dos nodos en base a diferentes métricas es tener distintos mejores caminos según la métrica utilizada en cada caso, pero surge la duda de cual es el mejor. Esta elección se realizara en base a los requisitos que existan en la comunicación.



Daniel Cerna G.

Redes I

6


Diferentes métricas utilizadas pueden ser:

Mayor rendimiento

Menor retardo

Menor coste

Mayor fiabilidad

La posibilidad de utilizar varias métricas para el calculo de una ruta, implica que OSPF provea de un mecanismo para que una vez elegida una métrica en un paquete para realizar su routing esta sea la misma siempre para ese paquete, esta característica dota a OSPF de un routing de servicio de tipo en base a la métrica.

Balanceado de carga en múltiples caminos.

OSPF permite el balanceado de carga entre los nodos que exista más de un camino. Para realizar este balanceo aplica:

Una versión de SPF con una modificación que impide la creación de bucles parciales.

Un algoritmo que permite calcular la cantidad de trafico que debe ser enviado por cada camino.

Escalabilidad en el crecimiento de rutas externas.

El continuo crecimiento de Internet es debido a que cada vez son más los sistemas autónomos que se conectan entre si a través de routers externos. Además de tener en cuenta la posibilidad de acceder al exterior del sistema autónomo a través de un determinado router externo u otro se debe tener en cuenta que se tiene varios proveedores de servicios y es más versátil elegir en cada momento el router exterior y servicio requerido que establecer una ruta y servicio por defecto cuando se trata de routing externo como se tenia hasta ahora.

OSPF soluciona este problema permitiendo tener en la base de datos del mapa local los denominados “gateway link state records”.Estos registros nos permiten almacenar el valor



Daniel Cerna G.

Redes I

7


de las métricas calculadas y hacen más fácil el calculo de la ruta óptima para el exterior. Por cada entrada externa existirá una nueva entrada de tipo “gateway link state records” en la base de datos, es decir, la base de datos crecerá linealmente con el número de entradas externas tal como ocurre con los protocolos de vector distancia, pero el coste del calculo de las rutas crecerá en función de N*log*N para OSPF y no en función de N^2 como ocurre en los protocolos de vector distancia.

Ejemplo

Supongamos que en la red anterior el enlace que va del nodo A a B, queda fuera de servicio tal que la distancia pasa a ser infinito.

El mensaje que A enviara a D será:

Desde A hacia B, enlace 1, distancia infinito, numero 2.

El mensaje que B enviara a C será:

Desde B hacia A, enlace 1, distancia infinito, numero 2.

La

Hay que



Daniel Cerna G.

Redes I

8


Tener que un cambio en un enlace de la red puede dejar aislados a unos nodos de la red, es decir, puede partir la red. Este cambio tal como está planteado el mapa local no es problema ya que aunque todos los nodos de la red inicial no tendrán el mismo mapa local este si que será idéntico para cada uno de los nodos en cada una de sus particiones.

Del mismo modo debemos considerar el caso contrario que ocurre cuando un cambio en la topología de la red provoca una unión de redes de nodos, ya que pueden surgir problemas como la existencia de enlaces modificados en una mapa local de un nodo de una subred que no esta modificado en el mapa local de la otra subred.

• BGP

Descripcion:

BGP es el protocolo de encaminamiento EGP más utilizado en Internet. La versión 1 de este protocolo ( RFC 1105) apareció en 1989 para sustituir a EGP. Posteriormente, salieron nuevas versiones como la versión 2 en 1990 (RFC 1163) y la versión 3 en 1991 (RFC 1267). Finalmente apareció la versión 4 (RFC 1771 y RFC 4271) que proporciona soporte para CIDR (Classless Interdomain Routing).

BGP es un protocolo que funciona sobre TCP por el puerto 179. BGP permite el encaminamiento de los paquetes IP que se intercambian entre los distintos AS. Para ello, es necesario el intercambio de prefijos de rutas entre los diferentes AS de forma dinámica, lo cual se lleva a cabo mediante el establecimiento de sesiones BGP inter-AS sobre conexiones TCP. Este tipo de operación proporciona comunicación fiable y esconde todos los detalles de la red por la que se pasa.

Debido a que en cada AS se utiliza un protocolo IGP con una definición distinta para el coste de los enlaces, es imposible encontrar el camino más corto hacia cada destino. Por ello, una vez se han aplicado las restricciones sobre

las rutas, BGP utiliza un algoritmo similar al tipo vector de distancia, llamado path-vector, para seleccionar

aquellas rutas que impliquen el mínimo número de AS a atravesar.

Las tablas de encaminamiento de BGP almacenan rutas para alcanzar redes (indicadas mediante prefijos). Las rutas están formadas por una secuencia de números de sistemas



Daniel Cerna G.

Redes I

9


autónomos que se deben seguir

para alcanzar el prefijo indicado. El último número de AS de la ruta se corresponde con la organización que tiene registrado el prefijo, es decir, el AS donde se encuentra el destino. El principal motivo para almacenar la ruta completa es la detección y eliminación de bucles (loops) para evitar que los paquetes se envíen de forma infinita pasando varias veces por un mismo AS.

Caracteristicas:

• Protocolo de Vector de Trayectoria

• Actualizaciones Incrementales

• Muchas opciones para forzar medidas administrativas (de rutas)

• Soporta Enrutamiento Inter-Dominio SinClases

• Muy utilizado en la “espina dorsal” de Internet

• Sistemas Autónomos

• Funciona sobre TCP – puerto 179

• Protocolo de Vector de Trayectoria

• Actualización incremental

• BGP “Interno” y “Externo”

Funcionamiento del proceso BGP:

Cuando un router anuncia un prefijo a uno de sus vecinos BGP, esa información es considerada válida hasta que el primer router explícitamente anuncia que la información ya no es válida o hasta que la sesión BGP se pierde. Esto significa que BGP no requiere que la información de routing se refresque periódicamente. De este modo, en un principio existirá un alto flujo de mensajes cuando se establece la sesión BGP, pero transcurrido un tiempo de estabilización los routers sólo necesitarán informar de los cambios que han ocurrido. Por ejemplo, en un AS tipo backbone el intercambio es del orden de 50.000



Daniel Cerna G.

Redes I

10


prefijos inicialmente.

Para almacenar información de encaminamiento, el protocolo BGP necesita un conjunto de tablas de datos denominadas RIBs (Routing Information Bases). Éstas son las siguientes:

• Adj-RIB-in: En esta tabla se almacenan prefijos aprendidos de un vecino particular. Hay tantas tablas de este tipo como pares BGP.

• Loc-RIB: Almacena las mejores rutas seleccionadas (prefijos + longitud máscara) que conoce el proceso BGP bien porque las ha obtenido de la tabla de encaminamiento (comandos network, agrégate-address y redistribute), o bien porque se han aprendido por BGP (I-BGP o E-BGP), tras pasar los filtros de entrada. Estas rutas pueden ser anunciadas si la política de encaminamiento a la salida lo permite. Hay sólo uno por cada sistema autónomo.

• Adj-RIB-out: Almacena prefijos para ser anunciados a otros vecinos. Esta tabla se construye a partir de las informaciones de la tabla Loc-RIB que han sido

filtrados y cuyos atributos han sido modificados según configuración. Se tiene una tabla de este tipo por cada par BGP.



Daniel Cerna G.

Redes I

11


El proceso BGP consiste en un autómata de 6 estados con 13 eventos posibles. La interacción con otros procesos BGP se lleva a cabo intercambiando mensajes. Los mensajes intercambiados en una sesión BGP sirven para informar sobre el conocimiento de nuevas rutas activas, para suprimir rutas que ya no están activas, para indicar la viabilidad actual de la conexión o para informar sobre la existencia de condiciones inusuales en la conexión TCP. El siguiente esquema muestra los estados y los mensajes del proceso BGP:



Daniel Cerna G.

Redes I

12


Ejemplo:

La configuración para el ejemplo de la figura anterior sería la siguiente:

RTA# router bgp 100

neighbor 190.10.50.1 remote-as 100

neighbor 170.10.20.2 remote-as 300

network 150.10.0.0

redistribute static

ip route 190.10.0.0 255.255.0.0 null0



Daniel Cerna G.

Redes I

13


RTB# router bgp 100

neighbor 150.10.30.1

remote-as 100 network 190.10.50.0

RTE# router bgp 300

neighbor 170.10.20.1

remote-as 100

network 170.10.0.0

En este ejemplo se tienen una serie de rutas en las tablas de encaminamiento de los distintos routers con su valor correspondiente del atributo ORIGIN:

o RTA alcanzará la red 170.10.0.0 vía 300i (lo que indica que el próximo AS para llegar al destino es el 300 y que el origen de la ruta es IGP, lo cual quiere decir que el router BGP del AS 300 que envió la ruta a RTA la aprendió de otro router interno por IGP).

o RTA también alcanzará la ruta 190.10.50.0 vía i (lo cual quiere decir que dicha entrada pertenece al mismo AS que RTA y que ha sido aprendida por IGP).

o RTE alcanzará el destino 150.10.0.0 vía 100i (la próxima AS es 100 y su origen es IGP).

• RIP

Descripción:

RIP es un protocolo de encaminamiento interno, es decir para la parte interna de la red, la que no está conectada al backbone de Internet. Es muy usado en sistemas de conexión a internet como infovia, en el que muchos usuarios se conectan a una red y pueden acceder por lugares distintos.

Cuando un usuarios se conecta el servidor de terminales (equipo en el que finaliza la llamada) avisa con un mensaje RIP al router más cercano advirtiendo de la dirección IP que ahora le pertenece.



Daniel Cerna G.

Redes I

14


Así podemos ver que RIP es un protocolo usado por distintos routers para intercambiar información y así conocer por donde deberían enrutar un paquete para hacer que éste llegue a su destino.

Características:

RIPv1

Las principales características que definen esta primera versión del protocolo RIP son:

• No admite subredes.

• No admite direcciones con máscara de longitud variable (VLSM).

• No admite CIDR.

• Los intercambios de información no están autenticados.

RIPv2

A diferencia de la versión anterior, ésta presenta ciertas mejoras:

• Admite subredes.

• Admite direcciones con máscara de longitud variable (VLSM).

• Admite CIDR.

• Los intercambios están autenticados con contraseñas y se pueden llevar a cabo mediante multicast en lugar de broadcast (menos sobrecarga de la red).



Daniel Cerna G.

Redes I

15


Funcionamiento:

Proceso de solicitud/respuesta de RIP

RIP utiliza dos tipos de mensajes especificados en el campo Comando: Mensaje de solicitud y Mensaje de respuesta.

Cada interfaz configurada con RIP envía un mensaje de solicitud durante el inicio y solicita



Daniel Cerna G.

Redes I

16


que todos los RIP vecinos envíen sus tablas de enrutamiento completas.



Daniel Cerna G.

Redes I

17


Se envía de regreso un mensaje de respuesta por parte de los vecinos habilitados con RIP. Cuando el router que realiza la solicitud recibe las respuestas, evalúa cada entrada de ruta. Si una entrada de ruta es nueva, el router receptor instala la ruta en la tabla de enrutamiento.

Si la ruta ya se encuentra en la tabla, la entrada existente se reemplaza si la nueva entrada tiene un mejor conteo de saltos.

El router de inicio luego envía un update disparado a todas las interfaces habilitadas con RIP que incluyen su propia tabla de enrutamiento para que los RIP vecinos puedan recibir la información acerca de todas las nuevas rutas.

Ejemplo:

Pasamos a detallar equipo por equipo cuáles son los pasos que hay que seguir para configurar cada uno de ellos. En el caso de los router CIT basta con acceder al menú de configuración, a través del puerto serie, y ejecutar todas las acciones que aparecen detalladas más abajo. Y en el caso del terminal, la configuración se hará a través de la consola de GNU/Linux.

Router CIT2

1. Asignamos las direcciones correspondientes a las interfaces de red.

2. Habilitamos las direcciones de broadcast para ambas interfaces.

3. Listamos las interfaces para comprobarlo.

4. Habilitamos el protocolo RIP.

5. Habilitamos la propagación de subredes desconectadas a través de eth1.

6. Permitimos la recepción de rutas por defecto de otros router.



Daniel Cerna G.

Redes I

18


7. Permitimos la recepción de rutas de red.

8. Permitimos el envío de rutas por defecto a otros routers.

9. Permitimos el envío de rutas de red conectadas directamente al router.

10. Permitimos el envío de rutas de red.

11. Permitimos el envío de rutas estáticas configuradas en el router.

12. Establecemos que vamos a trabajar con RIPv1.

13. Creamos las rutas estáticas correspondientes y las listamos.

14. Guardamos toda la configuración y reiniciamos.

Config> protocol ip -- Internet protocol user configuration -- IP config> address ethernet0/0 192.168.1.2 255.255.255.0 IP config> address ethernet0/1 192.168.2.1 255.255.255.0 IP config> broadcast-address network 192.168.1.2 1 IP config> broadcast-address network 192.168.2.1 1 IP config> list addresses IP addresses for each interface: ethernet0/0 192.168.1.2 255.255.255.0 NETWORK broadcast, fill 1 ethernet0/1 192.168.2.1 255.255.255.0 NETWORK broadcast, fill 1 x25-node IP disabled on this ifc IP config> exit Config> protocol rip -- RIP protocol user configuration -- RIP config> enable RIP config> allow-disconnected-subnetted-networks 192.168.2.1 RIP config> receiving 192.168.2.1 default-routes RIP config> receiving 192.168.2.1 network-routes RIP config> sending 192.168.2.1 default-routes RIP config> sending 192.168.2.1 direct-routes RIP config> sending 192.168.2.1 network-routes RIP config> sending 192.168.2.1 static-routes RIP config> compatibility 192.168.2.1 receive rip1 RIP config> compatibility 192.168.2.1 send rip1 RIP config> exit



Daniel Cerna G.

Redes I

19


Config> protocol ip -- Internet protocol user configuration -- IP config> route 192.168.1.0 255.255.255.0 ethernet0/0 IP config> route 192.168.2.0 255.255.255.0 ethernet0/1 IP config> list routes route to 192.168.2.0,255.255.255.0 via ethernet0/1, cost 1 route to 192.168.1.0,255.255.255.0 via ethernet0/0, cost 1 IP config> exit Config> save Save configuration (Yes/No)? Y Building configuration as text... OK Writing configuration... OK on Flash Config> *restart Are you sure to restart the system(Yes/No)? Y

Router CIT

1. Asignamos las direcciones correspondientes a las interfaces de red.

2. Habilitamos las direcciones de broadcast para ambas interfaces.

3. Listamos las interfaces para comprobarlo.

4. Habilitamos el protocolo RIP.

5. Habilitamos la propagación de subredes desconectadas a través de eth0.

6. Permitimos la recepción de rutas por defecto de otros router.

7. Permitimos la recepción de rutas de red.

8. Permitimos el envío de rutas por defecto a otros routers.

9. Permitimos el envío de rutas de red conectadas directamente al router.

10. Permitimos el envío de rutas de red.

11. Permitimos el envío de rutas estáticas configuradas en el router.

12. Establecemos que vamos a trabajar con RIPv1.



Daniel Cerna G.

Redes I

20


13. Creamos las rutas estáticas correspondientes y las listamos.

14. Guardamos toda la configuración y reiniciamos.

p 4

Config> protocol ip -- Internet protocol user configuration -- IP config> address ethernet0/0 192.168.2.2 255.255.255.0 IP config> address ethernet0/1 192.168.3.1 255.255.255.0 IP config> broadcast-address network 192.168.2.2 1 IP config> broadcast-address network 192.168.3.1 1 IP config> list addresses IP addresses for each interface: ethernet0/0 192.168.2.2 255.255.255.0 NETWORK broadcast, fill 1 ethernet0/1 192.168.3.1 255.255.255.0 NETWORK broadcast, fill 1 x25-node IP disabled on this ifc IP config> exit Config> protocol rip -- RIP protocol user configuration -- RIP config> enable RIP config> allow-disconnected-subnetted-networks 192.168.2.2 RIP config> receiving 192.168.2.2 default-routes RIP config> receiving 192.168.2.2 network-routes RIP config> sending 192.168.2.2 default-routes RIP config> sending 192.168.2.2 direct-routes RIP config> sending 192.168.2.2 network-routes RIP config> sending 192.168.2.2 static-routes RIP config> compatibility 192.168.2.2 receive rip1 RIP config> compatibility 192.168.2.2 send rip1 RIP config> exit Config> protocol ip -- Internet protocol user configuration -- IP config> route 192.168.2.0 255.255.255.0 ethernet0/0 IP config> route 192.168.3.0 255.255.255.0 ethernet0/1 IP config> list routes route to 192.168.3.0,255.255.255.0 via ethernet0/1, cost 1 route to 192.168.2.0,255.255.255.0 via ethernet0/0, cost 1 IP config> exit Config> save Save configuration (Yes/No)? Y Building configuration as text... OK Writing configuration... OK on Flash



Daniel Cerna G.

Redes I

21


Config> *restart Are you sure to restart the system(Yes/No)? Y

• ICMP

Descripcion:

El Protocolo Internet (IP) [1] se utiliza para el servicio de datagramas de "host" a "host" en un sistema de redes interconectadas denominado Catenet [2]. Los dispositivos de conexión de redes se denominan Pasarelas (Gateways). Estas pasarelas se comunican entre ellas con propósito de control mediante el Protocolo Pasarela a Pasarela (Gateway to Gateway Protocol (GGP)) [3,4]. Ocasionalmente, una pasarela o un "host" de destino se comunicará con un "host" de origen para, por ejemplo, informar de un error en el procesamiento de datagramas. El Protocolo de Mensajes de Control Internet (ICMP) se usa para este propósito. ICMP utiliza el soporte básico de IP como si se tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integrante de IP, y debe ser implementado por todo módulo IP.

Los mensajes ICMP son enviados en varias situaciones: por ejemplo, cuando un datagrama no puede alcanzar su destino, cuando una pasarela no dispone de capacidad de almacenamiento temporal para reenviar el datagrama, y cuando la pasarela puede dirigir al "host" para enviar el tráfico por una ruta más corta.

El Protocolo Internet no está diseñado para ser absolutamente fiable. El propósito de estos mensajes de control no es hacer a IP fiable, sino suministrar información sobre los problemas en el entorno de comunicación. Sigue sin garantizarse que un datagrama sea entregado o que se devuelva un mensaje de control . Existe la posibilidad de que algunos datagramas no sean entregados, sin ningún informe sobre su pérdida. Los protocolos de nivel superior que usen IP deben implementar sus propios procedimientos de fiabilidad en caso de que requieran comunicación fiable.



Daniel Cerna G.

Redes I

22


Típicamente, los mensajes ICMP informan de errores en el procesamiento de datagramas. Para evitar la generación sin fin de mensajes acerca de mensajes, etc... , no se envían mensajes ICMP acerca de mensajes ICMP. Además sólo se envían mensajes ICMP acerca de errores en el procesamiento del fragmento cero de un datagrama fragmentado. (el fragmento cero es el que tiene el campo posición ("offset") de fragmento igual a cero).

Formatos de Mensaje

Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la parte de datos del datagrama es el campo de tipo ICMP; el valor de este campo determina el formato del resto de los datos. Los campos etiquetados como "no usado" están reservados para posteriores extensiones y deben ser cero al ser enviados, y los receptores no deberán usar estos campos (excepto para incluirlos en la suma de control). Exceptuando las descripciones de formato individuales en las que se indique lo contrario, los valores de los campos de la cabecera internet son como sigue:

Version

4

IHL ("Internet Header Length")

Longitud de la cabecera internet en palabras de 32 bits.

Tipo de Servicio

0

Longitud Total

Longitud de la cabecera y los datos en octetos.

Identificación, Indicadores ("flags") y Posición De Fragmento

Usados en fragmentación, ver [1].

Tiempo de Vida (TTL, "Time To Live")



Daniel Cerna G.

Redes I

23


Tiempo de vida en segundos; como este valor se decrementa en

cada

máquina en la cual el datagrama es procesado, debe ser al

menos

igual o mayor que el número de pasarelas que atravesará.

Protocolo

ICMP = 1

Suma de Control de Cabecera

El complemento a uno de 16 bits de la suma de los complementos a

uno de todas las palabras de 16 bits de la cabecera. A la hora de

calcular la suma de control, el valor inicial de este campo es

cero. Esta suma de control puede ser sustituida en el futuro.

Dirección de Origen

La dirección de la pasarela o "host" que crea el mensaje ICMP. Si

no se indica lo contrario, puede ser cualquiera de las direcciones

de una pasarela.

Dirección de Destino

La dirección de la pasarela o "host" al cual se debe enviar el

mensaje.



Daniel Cerna G.

Redes I

24


• IGMP

Descripcion:

IGMP es un protocolo estándar con número de STD 5 que también incluye IP e ICMP. Su status es recomendado y se describe en el RFC 1112.

Nota: Se requieren IP e ICMP.

IGMP es vagamente análogo a ICMP y ocupa el mismo lugar en la pila de protocolos IP.

Mensajes IGMP

Los mensajes ICMP se envían en datagramas IP. La cabecera IP tendrá siempre un número de protocolo de 2, indicando IGMP y un tipo de servicio de cero (rutina). El campo de datos IP contendrá mensaje IGMP de 8 bytes con el formato mostrado en la figura que se muestra a continuación.

donde:

Vers Versión IP de 4 bits. Siempre 1.

Tipo Especifica una recuperación o un informe. 1



Daniel Cerna G.

Redes I

25


Especifica una recuperación que envía un router multicast. 2 Especifica un informe que envía un host. Checksum

Una suma de comprobación de 16 bits calculada como para ICMP. Dirección de clase D

Esta es cero para una petición y es una dirección de grupo multicast válida para un informe.

1. Operación IGMP

Los sistemas que participan en IGMP son de dos tipos: hosts y routers multicast.

Como se describió en Multicasting, con objeto de recibir datagramas multicast, un host debe unirse a un grupo de host. Cuando un host es multi-homed, puede unirse a cualquier grupo en uno o más de sus interfaces (subredes conectadas). Los mensajes multicast que el host recibe del mismo grupo de dos subredes diferentes pueden ser diferentes. Por ejemplo 244.0.0.1 es el grupo para "todos los hosts de esta subred", así que los mensajes recibidos en una subred siempre serán distintos para este grupo de esos en otros. Pueden escucharse múltiples procesos en un único host para mensajes por un grupo multicast de una subred. Si se da el caso, el host une el grupo sólo una vez y mantiene una pista internamente de qué procesos están interesados en ese grupo.

Para unir un grupo, el host envía un informe por una interfaz. El informe se direcciona al grupo multicast de interés. Los routers multicast de la misma subred reciben el informe y ponen una bandera indicando que al menos un host de esa subred es un miembro de ese grupo. Ningún host tiene que unir a todo el grupo de hosts (224.0.0.1); la agrupación es automática. Los routers multicast tienen que escuchar todas las direcciones multicast (esto es, todos los grupos) para detectar tales informes. Las alternativas podrían ser que routers multicast usaran broadcast para los informes o para configurar hosts con direcciones unicast.

Los routers multicast regularmente, pero infrecuentemente (el RFC 1112 menciona intervalos de un minuto), mandan una pregunta a las direcciones multicast de todos los



Daniel Cerna G.

Redes I

26


hosts. Todos los host que todavía deseen ser miembro de uno o más grupos responderán una vez para cada grupo de interés (pero nunca a todo el grupo de hosts, dado que la agrupación es automática). Cada respuesta se envía después de un retardo aleatorio para asegurar que IGMP no causa despliegue violento de tráfico en la subred. Puesto que los routers no se preocupan de cómo muchos hosts son miembros de un grupo y dado que todos los hosts que son miembros de ese grupo pueden oir la respuesta de los otros, cualquier host que oiga otra demanda agrupación de un grupo cancelará cualquier respuesta que se debe enviar para evitar malgastar recursos. Si ningún host demanda agrupación de un grupo con un intervalo especifico, el router multicast decide que ningún host es un miembro del grupo. Cuando un host o un router multicast recibe un datagrama multicast, su acción depende del valor TTL y de la dirección IP de destino.

0 Un datagrama enviado con un TTL a cero es privado para el host origen.

1 Un datagrama con un TTL de uno alcanza a todos los hosts de la subred quesean miembros del grupo. pero distintos datagramas unicast, no informan esto con un mensaje ICMP de tiempo excedido. Expiration de un datagrama multicast es una ocurrencia normal.

2+ Todos los hosts que sean miembros del grupo y todos los routers multicast reciben el datagrama. La acción de los routers depende de la dirección de grupo multicast. 224.0.0.0 - 224.0.0.255 Este rango se propone sólo para aplicaciones multicasting de un salto. Los routers multicast no enviarán datagramas con dirección IP de destino en este rango.

Puede parecer en un principio como si un host no necesitara molestar informando a su agrupación de un grupo en este rango ya que los routers multicast no mandarán datagramas de otras subredes. Sin embargo, el informe también comunica a otros hosts de la subred que el reporting host es un miembro del grupo. Al único grupo que nunca se le informa es el 224.0.0.1 porque todos los hosts saben que el grupo consiste en todos los hosts de esa subred.

otro Los datagramas con otros valores para la dirección de destino los envía el router multicast como normales: decrementa el valor de TTL al menos un segundo como siempre.

Esto permite que un host localice el servidor más cercano que se escucha en una dirección multicast usando lo que se llama un buscador en anillo expandido. El host



Daniel Cerna G.

Redes I

27


manda un datagrama con valor de TTL 1 (misma subred) y espera por respuesta. Si no se recibe nada, intenta un valor de TTL de 2, luego de 3, y así sucesivamente. A la larga encontrará el servidor más cercano.

redes i - protocolos de capa de red

Documents