1 / 29

GGTT RedIRIS (IRIS-mmedia) RGMP (Router-port Group Management Protocol)

GGTT RedIRIS (IRIS-mmedia) RGMP (Router-port Group Management Protocol). Palma de Mallorca, 3 de Noviembre de 2003 Francisco Cruz: paco@di.uc3m.es Universidad Carlos III de Madrid. Situación actual. Redes en las universidades de gran ancho de banda Intranet/Internet (ATM, Giga)

duane
Download Presentation

GGTT RedIRIS (IRIS-mmedia) RGMP (Router-port Group Management Protocol)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GGTT RedIRIS(IRIS-mmedia)RGMP(Router-port Group Management Protocol) Palma de Mallorca, 3 de Noviembre de 2003 Francisco Cruz: paco@di.uc3m.es Universidad Carlos III de Madrid

  2. Situación actual • Redes en las universidades de gran ancho de banda Intranet/Internet (ATM, Giga) • Puesto de acceso de usuario de 10/100 conmutados • Aparición de nuevos servicios y aplicaciones • Necesidad de activación de tráfico multicast en nuestras redes para dar cabida a estas aplicaciones

  3. Situación actual II: topología típica Switch ATM/Gb ATM Router IP Definición de LECs Router IP VTP Server Gb Router IP trunk trunk trunk Cliente vtp Vlan1,2,3,..

  4. Multicast: nivel 2 • Los conmuntadores incorporan una tabla (Content-Addressable Memory: CAM) para ver la dirección MAC destino, para determinar porque puerto deben enviar el tráfico. • Los conmutadores deben saber qué direcciones destinos (MAC) están conectados a cada puerto. • Esto lo hacen “escuchando” las direcciones fuente provenientes de cada puerto.

  5. Multicast: Nivel 2 • Cuando un conmutador recibe una trama que no está identificada, lo reenvía por todos los puertos esperando que llegue a su destino, esto sucede: • La MAC destino todavía no es conocida por el conmutador (no problema, en cuanto emita el equipo quedará registrada). • La MAC destino es una dirección broadcast o multicast (en este caso el conmutador no sabe distinguir que equipos están asociados a un grupo determinado y realiza un “flooding de la trama”)

  6. Multicast: nivel 2 Problema: El nivel 2 suele hacer Flooding de las tramas multicast Generalmente los conmutadores tratan Las tramas multicast como tráfico desconocido o broadcast, realizando Flood por todos los puertos Se pueden configurar entradas estáticas especificando qué puertos del conmutador deberían recibir qué grupos multicast. Sería deseable que se pudiera realizar una configuración dinámica de esta información PIM Multicast

  7. Multicast: sin control

  8. Multicast: con control

  9. Nivel 2: Soluciones • Controlar el ancho de banda: tiene el problema de que se pueden descartar paquetes importantes en el funcionamiento y la integridad de la propia red: ej protocolos de señalización que utilizan multicast (MOSPF) • Extender la MAC para multicast: mantener una lista de los puertos y sus grupos asociados • IGMP Snooping (Internet Group Management Protocol) • CGMP (Control Group Management Protocol) • GMRP (GARP Multicast Registration Protocol) • RGMP (Router-port Management Protocol)

  10. Multicast: nivel 2 • Problemática de tratamiento del tráfico multicast por parte de los equipos de comunicaciones (conmutadores) • Posibles soluciones: • IGMP Snooping. • CGMP (Cisco Group Management Protocol). • GMRP (GARP (Generic Attribute Registration Protocol) Multicast Registration Protocol)

  11. Nivel 2: IGMP Snooping • Requiere que el conmutador escuche algunos paquetes de nivel 3 (los mensajes IGMP Join/leave) que se envían entre el ordenador y el router • Cuando el conmutador escucha un “igmp host report” añade a su tabla multicast asociada el puerto de ese ordenador. • Cuando el conmutador escucha un “igmp leave” borra esa entrada para ese host

  12. Nivel 2: IGMP Snooping Los conmutadores entiende IGMP. Los paquetes IGMP son interceptados por un HW específico. Los conmutadores deben de examinar el contenido de los mensajes IGMP para determinar qué puertos quieren qué tráfico IGMP Membership Reports IGMP Live PIM IGMP IGMP

  13. Nivel 2: CGMP • Protocolo de control de nivel de enlace desarrollado por CISCO para informar a los conmutadores de reenvío de paquetes. • CGMP se debe configurar en los routers (interfaces) y en los comnutadores. • El tráfico saldrá sólo en aquellos puertos del conmutador donde haya receptores para ese tráfico • Los puertos conectados al router recibirán todo el tráfico multicast. • el ordenador envía el “IGMP membership report”, este mensaje pasa el conmutador y llega al router (que tiene activado el cgmp en ese interface). • El router crea un “CGMP join” hacia el conmutador que añade una entrada en la CAM para ese puerto y ese grupo. • El conmutador sólo debe escuchar los mensajes (join y leave) CGMP del router.

  14. CGMP: funcionamiento IGMP Report DST MAC=01005e010203 SRC MAC=0080c7a21093 DST IP=224.1.2.3 SRC IP=192.168.1.1 Group address=224.1.2.3 CGMP join Unicast source address 0080c7a21093 Group destination address 01005e010203 Conexión física IGMP report CGMP join

  15. Multicast: nivel 2 Debe de ejecutarse en los routers y en los conmutadores Los routers envían paquetes CGMP a los conmutadores a la dirección 0100:0cdd:dddd El paquetes CGMP contiene: Tipo de campo: Join o Live Dirección MAC del cliente IGMP Dirección multicast del grupo Los conmutadores utilizan la información CGMP para añadir o eliminar una entrada para una dirección MAC multicast específica

  16. Nivel 2: GMRP • Protocolo de control de tráfico multicast a nivel 2 equivalente a IGMP Snooping y CGMP. • Definido por el IEEE 802.1 • Realiza el registro y el borrado de los grupos multicast en el nivel 2 • Configurado en el ordenador y en el conmutador • Se generan peticiones de nivel 2 equivalentes a las generadas a nivel 3 por IGMP • El conmutador recibe ambas y anota los puertos en cuestión

  17. Problema!!!! • Los backbone suelen consistir en routers y conmutadores sin NINGÚN ordenador • Los tres protocolos anteriores se basan en el protocolo IGMP para controlar el tráfico multicast a nivel 2 • Cómo los routers no generan “IGMP host reports” no se pueden utilizan los protocolos anteriores • Es necesario incluir un nuevo protocolo que controle en tráfico multicast en el backbone de la red

  18. RGMP(Router-Port Group Management Protocol) • Protocolo desarrollado por CISCO • Las especificaciones de este protocolo vienen definidas en el RFC 3488

  19. RGMP(Router-Port Group Management Protocol) • Al igual que CGMP, RGMP debe estar corriendo en los routers y en los conmutadores. • Un router indica que está interesado en recibir un determinado tráfico y envía un mensaje de “RGMP join” para ese grupo. • El conmutador añade ese puerto a su tabla de envío para el grupo especificado (de manera parecida a lo que ocurría con los mensajes “CGMP join”) • Cuando el router deja de estar interesado manda un menaje “RGMP leave” al conmutador

  20. RGMP • Funciona en equipos de CISCO • Catalys 5000/6000 • Routers IOS: 12.2, 12.1E, 12.1T, 12.0S, 12.0ST • Limitaciones del protocolo • Debe estar activado RGMP en los routers y los conmutadores • Tiene que estar activado IGMP sooping en los conmutadores • Sólo funciona para grupos con PIM-SP • Sólo un router RGMP por puerto en cada conmutador • Los paquetes RGMP son enviados a la dirección multicast 01-00-5e-00-00-19 (224.0.0.25 todos los switchs) con TTL=1 (al igual que IGMP) • Los mensajes se encapsulan en datagramas IP con número de protocolo 2 (igual que IGMP)

  21. RGMP • Dirección de grupos para “hello” y “Bye” es la 0.0.0.0 • Hello -> se envía mensajes periódicamente. Le indica al conmutador que no envíe tráfico multicast al router a menos que éste (el router) envíe un mensaje “RGMP join” (siempre precede a un mensaje de “PIM Hello” • Bye -> cuando está desactivado en el router, todo el tráfico será envíado al router por el conmutador • Dirección de grupos para “join” y “leave” (grupo específico) • Join -> se deberá enviar todo el tráfico multicast con destino el grupo “G” (se envía junto con PIM Join) • Leave -> no se deberá enviar el tráfico con destino el grupo “G” • Un conmutador nunca envía paquetes RGMP, y un router ignora los paquetes RGMP • Un router nunca envía “join” a 224.0.0.x ni a 224.0.1.39 (cisco-rp-announce), 224.0.1.40 (cisco-rp-discovery), así que los conmutadores siempre reenvían ese tráfico a los routers con soporte RGMP

  22. RGMP Type: 0xFF = Hello 0xFE = Bye 0xFD = Join 0xFC = Leave Reserved = todo a 0 Checksum = el mismo que para IGMP (RFC 3228) Group Address Hello/bye = 0.0.0.0 Join/Leave = grupo multicast Cabecera IP Se envían de los routers a los conmutadores Source = dirección IP del interface del router que origina el mensaje RGMP Destination = 224.0.0.25

  23. RGMP • Activación en un switch • set igmp enable * • set rgmp • Activación en un router • ip multicast-routing * • Ip pim sparse mode * • ip rgmp (interface)

  24. Sin RGMP

  25. Con RGMP

  26. RGMP (I)

  27. RGMP (II)

  28. RGMP (III)

  29. RGMP (IV)

More Related