amplif_1

7/16/2019 amplif_1

1/85

Universidad de Valencia Rogelio MontaanaAmpliacin Redes 1-1

Tema 1

Multicast(versin 2010-2011)

Rogelio MontaanaDepartamento de Informtica

Universidad de [email protected]

http://www.uv.es/~montanan/
mailto:[email protected]:[email protected]

7/16/2019 amplif_1

2/85


Sumario

Introduccin. Aspectos generales

IGMP

Routing Multicast

7/16/2019 amplif_1

3/85


Direcciones multicast en Ethernet:

I/G = 0 Direccin Individual (unicast)I/G = 1 Direccin de Grupo (multi./broad.)U/L = 0 Dir. nica (administrada globalmente IEEE)U/L = 1 Dir. Local (administrada localmente)

XX XX XX XX XX XX

OUI Direccin

U/L I/G

En Ethernet los bits dentro de cada byte se representan en orden

inverso. Por tanto el bit I/G es el ltimo del primer byte. Regla:En Ethernet una direccin es multicast si y solo si el segundo dgito

hexadecimal es impar.

Ej.: la direccin AB-00-03-00-00-00 es multicast.

7/16/2019 amplif_1

4/85


Multicast en LAN

El trfico multicast no es aislado normalmente porlos conmutadores

Muchos protocolos utilizan multicast en la LAN: Spanning tree (direccin 01-80-C2-00-00-00) Protocolos de routing: OSPF, IS-IS, RIP, etc.

Protocolos propietarios: Appletalk, IPX, CDP, etc.

El trfico multicast en una LAN puede serimportante aun cuando a nivel 3 (los routers) noest habilitado el multicast

7/16/2019 amplif_1

5/85


Multicast en una LAN broadcast compartida

RosaJuan Luis

0000.E85A.CA6D 0001.02CD.8397 0001.02CC.4DD5

M

Dir.Origen: 0000.102C.D832Dir.Destino: 0100.5E00.0001

0000.102C.D832

Grupo Multicast 0100.5E00.0001

0100.5E00.0001 0100.5E00.0001

Direccionescapturadas

por la tarjetade red

En la LAN todoslos equipos

reciben todo eltrfico multicast,

estn o nointeresados

Afortunadamentela tarjeta de red

descarta el que nonos interesa

MM

FFFF.FFFF.FFFF FFFF.FFFF.FFFF FFFF.FFFF.FFFF

Join0100.5E00.0001

Join0100.5E00.0001

M

7/16/2019 amplif_1

6/85


Multicast en una LAN broadcast conmutada

RosaJuan Luis

0000.E85A.CA6D 0001.02CD.8397 0001.02CC.4DD5

M

D.O.: 0000.102C.D832D.D.: 0100.5E00.0001

0000.102C.D832

Grupo Multicast 0100.5E00.0001

0100.5E00.0001 0100.5E00.0001

MM

M


por la tarjetade red

El uso de unconmutador no

mejora la situacinen lo que a trfico

multicast serefiere. El trficosigue llegando a

todos los hosts


Join0100.5E00.0001

Join0100.5E00.0001

Ana

7/16/2019 amplif_1

7/85Universidad de Valencia Rogelio MontaanaAmpliacin Redes 1-7

Emisin de un grupo multicast en una WAN

Rosa

Pedro

Luis

Juan

Los routers replican los paquetes justoall donde se produce la bifurcacin

Emisor

Receptor

Receptor

Receptor

Ana

7/16/2019 amplif_1


Emisin de dos grupos multicast

Rosa

Pedro

Luis

Juan

Pedro recibelos dos grupos

Paquetes de vdeo

Paquetes de audio

Lnea de bajavelocidadAna

ReceptorAudio/Video

ReceptorAudio

ReceptorVdeo

Normalmente cada grupo se identificapor una direccin multicast diferente

ReceptorVdeo

7/16/2019 amplif_1


Tipos de direcciones IPv4

Red Host

Unicast (A, B o C): 0.0.0.0223.255.255.255

Multicast (D): 224.0.0.0- 239.255.255.255

1110 Grupo Multicast (28 bits)

Reservado (E): 240.0.0.0255.255.255.254

1111 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1Broadcast (en la red actual): 255.255.255.255

Broadcast en una red (remota):

Red 1 1 1 1 1 1 . . . . 1 1 1 1 1 1

7/16/2019 amplif_1


Direcciones Multicast en IP

Las direcciones multicast tienen estructura plana (no jerrquica)

Las direcciones multicast solo pueden aparecer como direcciones dedestino, nunca de origen

No pueden aparecer en los campos opcionales source route o recordroute

ICMP y multicast: Los datagramas multicast no pueden dar lugar a mensajes ICMPDESTINATION UNREACHABLE

Tampoco pueden dar lugar a mensajes ICMP TIME EXCEEDED.Sin embargo el TTL se decrementa normalmente y cuando vale

cero el datagrama se destruye Los mensajes multicast ICMP ECHO REQUEST generan

respuestas unicast de todos los miembros del grupo. Lasrespuestas, unicast, llevan como direccin de origen la del emisor ydestino la del host que envi el ICMP multicast.

7/16/2019 amplif_1


Resolucin de direcciones multicast IP-Ethernet

Se realiza por mapeo de la direccin IP en la direccinMAC. No se utiliza ARP.

Para hacer un mapeo exacto de la IP en la MAC haranfalta 28 bits, es decir los 4 ltimos bits de la OUI y los 24siguientes. Esto requerira reservar 24 = 16 OUIscontiguos, que habran costado $16.000 dlares

El IETF decidi comprar solo un OUI (01-00-5E) y

dedicar solo la mitad inferior a multicast, reservando laotra para otros fines. Por tanto se dispone solo de 23 bits

Por tanto en el mapeo se ignoran los cinco primeros bits dela direccin IP

7/16/2019 amplif_1


Resolucin direcciones multicast IP-Ethernet

1110 xxxx xabcdefg hijklmno pqrstuvwDireccin IP multicast:

00000001 00000000 01011110 0abcdefg hijklmno pqrstuvw

01 00 5E

Direccin MAC:

Correspondencia no biunvoca:

Bitsignorados

Binario

Hexadecimal

Bits mapeados (23)

224.0.0.1

224.128.0.1225.0.0.1225.128.0.1..239.0.0.1239.128.0.1

0100.5E00.000132 direcciones IP 1 direccin MAC

OUI del IETF

Mitad inferior

7/16/2019 amplif_1


Resolucin direcciones multicast

Cuando en una LAN corresponde la misma MAC a dosdirecciones IP multicast la tarjeta LAN pasa los dos gruposal nivel de red

El nivel de red filtra los paquetes que no son suyos. Elprotocolo funciona pero el trabajo extra del nivel de redproduce un consumo adicional de CPU.

Algunas tarjetas de red aceptan un nmero muy limitadode grupos multicast; cuando se supera este lmite se ponenen modo aceptar todo el multicast. El nivel de red ha de

realizar el filtrado. Es como un modo promiscuo para eltrfico multicast

7/16/2019 amplif_1


Resolucin de direcciones multicast

RosaJuan Luis

0000.E85A.CA6D 0001.02CD.8397 0001.02CC.4DD5

0100.5E00.0001 0100.5E00.0001


por la tarjetade red 0100.5E00.0001

M M M M M M

M

D.D.: 0100.5E00.0001

Grupo Multicast 224.128.0.1 Grupo Multicast 225.0.0.1

M

Join

224.128.0.1

Join

224.128.0.1

Join

225.0.0.1


7/16/2019 amplif_1


Rangos de direcciones multicast IPv4reservadas o especiales

Rango Uso224.0.0.0/24 Direcciones locales asignadas por la IANA.

No propagadas por los routers.

224.0.1.0/24 Direcciones globales asignadas por la IANA.Propagadas por los routers

224.0.2.0/24224.0.255.0/24

Bloque para asignaciones ad-hoc.

Probablemente el ms utilizado

224.1.0.0/16 Grupos multicast para Stream Protocol

224.2.0.0/16 Bloque SAP/SDP (MBone)

232.0.0.0/8 Multicast especfico de la fuente (SSM)

233.0.0.0/8 Reservado para glop addressing239.0.0.0/8 Multicast con mbito limitado por la direccin

255.255.255.255/32 Broadcast confinado a la LAN

Los rangos no incluidos en esta tabla estn reservados por la IANA(Internet Assignment Numbers Authority) y no deberan utilizarse

7/16/2019 amplif_1


Algunas direcciones IPv4 multicast reservadas

Direccin Uso

224.0.0.0 Reservada224.0.0.1 Hosts con soporte multicast

224.0.0.2 Routers con soporte multicast

224.0.0.4 Routers DVMRP (routing multicast)

224.0.0.5 Routers OSPF

224.0.0.6 Routers OSPF designados224.0.0.9 Routers RIP v2

224.0.0.10 Routers IGRP

224.0.0.11 Agentes mviles

224.0.0.12 Agentes DHCP server/relay

224.0.0.13 Routers PIMv2 (routing multicast)

224.0.0.15 Routers CBT (routing multicast)

224.0.0.22 Routers IGMP v3 (Memb. Report)

255.255.255.255 Todos los hosts

Locales Globales

Direccin Uso

224.0.1.1 NTP Network TimeProtocol

224.0.1.7 Audio News

224.0.1.12 IETF-1-Video

224.0.1.16 Music-Service

224.0.1.39 RP Announce (PIM)

224.0.1.40 RP Discovery (PIM)

224.0.1.41 Gatekeepers (H.323)

224.0.1.52 Directorio VCR deMBone

224.0.1.68 Protocolo MADCAP

224.2.127.254 Anuncio de sesionesSAP (SDR)

Las direcciones multicast reservadas se resuelven al nombre correspondienteen el dominio mcast.net, p. ej. 224.0.1.7 es audionews.mcast.net

7/16/2019 amplif_1

17/85


Envos broadcast en Internet

En Internet no es posible hacer un envobroadcast. Si utilizamos la direccin255.255.255.255 el envo se difunde en la redlocal nicamente, no pasa ms all.

Dicho de otro modo, el paquete broadcast estratado como si tuviera TTL=1, cualquiera que seael valor de TTL que realmente tenga

Esto se hace para preservar la salud de la red. Delo contrario cualquier usuario desaprensivo odespistado podra saturar la red

7/16/2019 amplif_1

18/85


Diferencia entre envos a255.255.255.255 y a 224.0.0.1

RosaJuan Luis

W 3.11

IP

W 95

IP

Linux

IPX

255.255.255.255 224.0.0.1

Router IP(con soporte multicast)

255.255.255.255255.255.255.255

255.255.255.255

224.0.0.1

224.0.0.1

Ninguno de los dosdatagramas se

transmite al exterior(independientementede cual sea su TTL)

El kernel de Windows 3.11no tiene soporte multicast

7/16/2019 amplif_1

19/85


Broadcast dirigido

En Internet cuando se define una redautomticamente se define una direccin broadcasten dicha red. Dicha direccin es la ms altaexistente en esa red (parte host toda a unos).

Por ejemplo si definimos la red 130.206.4.0/23 sudireccin de broadcast es 130.206.5.255

En principio cualquier host puede hacer un envobroadcast a una red remota utilizando dichadireccin; esto se conoce como broadcastdirigido

7/16/2019 amplif_1

20/85


Ataques con broadcast dirigido

A finales de los 90 se produjeron diversos ataquesutilizando broadcast dirigido. La tcnica consista enenviar un paquete a la direccin broadcast de una redgrande poniendo una direccin de origen falsa (la del hosta atacar). Cuando ese host reciba las respuestas de los

pings su consumo de CPU creca enormemente Como consecuencia hoy en da es normal no permitir el

broadcast dirigido. Si se recibe un ping broadcast dirigidosolo lo responde el router que da acceso a esa red

En los routers cisco el broadcast dirigido se controla con elcomando ip directed-broadcast a nivel deinterfaz. Por defecto este comando est puesto a no entodas las interfaces (por tanto por defecto no se permite)

7/16/2019 amplif_1

21/85


Internet

Broadcast en IP

147.156.1.2/24

147.156.1.3/24

147.156.1.200/24

147.156.255.2/24

ping 147.156.1.255

A recibe 199ICMP echo reply

ping 147.156.1.255

B recibe un ICMPecho reply (de X)

147.156.1.1/24

Se supone que los routers X e Y tienen todas sus interfaces con laconfiguracin por defecto, es decir con no ip directed-broadcast

ping 147.156.255.255

A

B

D

D recibe un ICMPecho reply (de X)

X

Y

147.156.2.2/24

C

ping 147.156.1.255

C recibe un ICMP

echo reply (de X)

ping 147.156.2.255

D recibe un ICMPecho reply (de Y)

147.156.2.1/24

147.156.255.1/24

7/16/2019 amplif_1

22/85


mbito de una emisin multicast

En multicast es fundamental disponer demecanismos que permitan limitar el mbitode difusin de los grupos multicast. Estopuede conseguirse de tres formas:Ajustando el valor del TTL (obsoleto)Asignando rangos de direcciones a

determinados mbitosUtilizando el protocolo de anuncio de mbitos

MZAP (Multicast Zone AnnouncementProtocol, RFC 2776). Poco extendido.

7/16/2019 amplif_1

23/85


Delimitacin de mbito por direccin (RFC 2365)

Rango mbito

224.0.0.0/24

(224.0.0.0-224.0.0.255)

Nivel de enlace (LAN)

224.0.1.0-238.255.255.255 Global.

239.0.0.0 239.191.255.255 Reservado para usos futuros

239.192.0.0/14

(239.192.0.0-239.195.255.255)

Organizacin

239.196.0.0 239.254.255.255 Reservado para usos futuros

239.255.0.0/16

(239.255.0.0-239.255.255.255)

Nivel de enlace (LAN)

Se asigna un significado especial a determinados rangos dedirecciones multicast. El router, mediante ACLs, realiza un filtrado de los paquetes

multicast que no deben salir (este filtrado es independiente deldescarte por TTL=0

7/16/2019 amplif_1

24/85


Red de la Univ.de Valencia

RedIRIS

239.255.0.0/16

Delimitacin del mbito por direccin(RFC 2365, 7/1998)

239.192.0.0/14

224.0.1.0-238.255.255.255

Red de la Univ.de Murcia

Europa

Mundo

Filtra 239.192.0.0/14

Filtra 239.255.0.0/16

7/16/2019 amplif_1

25/85


Delimitacin de ambito multicast pordireccin en IPv6

Formato de las direcciones IPv6 multicast:

1111 1111 Flags Scope Grupo Multicast

Flags: 000T, donde:

8 4Bits 4 112

T = 0: direccin asignada de forma global y permanente (IANA)T = 1: direccin asignada de forma local y temporal

Scope (0-F): valor que indica el mbito o alcance de la emisin. Puedehaber 16 mbitos diferentes. El grupo multicast puede ser cualquiera.

7/16/2019 amplif_1

26/85


Equivalencia de mbitos IPv4-IPv6Scope IPv6 mbito Direcciones IPv4 (RFC 2365)

0 Reservado

1 Nodo

2 Nivel de enlace (LAN) 224.0.0.0/24239.255.0.0/16

3 (sin asignar)

4 (sin asignar)

5 Ubicacin (ej. Campus)6 (sin asignar)

7 (sin asignar)

8 Organizacin 239.192.0.0/14

9 (sin asignar)

A (sin asignar)

B (sin asignar)

C (sin asignar)

D (sin asignar)

E Global 224.0.1.0-238.255.255.255

F Reservado

7/16/2019 amplif_1

27/85


Asignacin de direcciones multicast Actualmente en Internet las direcciones multicast se

asignan normalmente mediante el protocolo SAP (SessionAnnouncement Protocol, RFC 2974, 10/2000). El rango dedirecciones que utiliza SAP es el 224.2.0.0/16.

El SAP presenta varios inconvenientes:

Tiene una estructura plana, no jerrquica. Por tanto noes escalable

Esta pensado especficamente para aplicacionesmultimedia

La asignacin se realiza dinmicamente. No es posibleefectuar asignaciones estticas (permanentes)

Se han propuesto otros protocolos ms avanzados perohasta la fecha no han tenido xito

7/16/2019 amplif_1

28/85


Glop addressing

Para asignar direcciones IP multicast estticas seutiliza actualmente el denominado Glopaddressing (RFC 3180, 9/2001), que funcionaas:

Se utiliza el rango 233.0.0.0/8 (233.0.0.0233.255.255.255) Se asigna a los dos bytes centrales el valor del AS

correspondiente. Ej.: a RedIRIS (AS 766) lecorresponde el rango 233.2.254/24 (2.254 equivale a

766 expresado en dos bytes) Dentro de cada AS el ISP asigna las direcciones comole parece.

7/16/2019 amplif_1

29/85


Sumario


IGMP

Routing Multicast

7/16/2019 amplif_1

30/85


IGMP = Internet Group

Management Protocol Objetivo: permite a los routers averiguar los grupos

multicast presentes en sus interfaces LAN Utiliza el valor 2 del campo protocolo en la cabecera IP Todos los mensajes IGMP se emiten con TTL=1, por lo

que solo son recibidos en la LAN correspondiente a lainterfaz por la que se emiten

Existen tres versiones de IGMP:

V1: RFC 1112 (8/1989): Ej. W95, NT 4.0 SP3 V2: RFC 2236 (11/1997): W98, NT 4.0 SP 4, W2000 V3: RFC 3376 (10/2002): XP Prof., W2003

7/16/2019 amplif_1

31/85


Tipos de mensajes en IGMPv1

Tipo Emitidopor

Funcin Direccinde destino

Consulta de miembros

(Membership Query)

Routers Preguntar a los hosts si estn

interesados en algn grupomulticast

224.0.0.1

Informe de Pertenencia(Membership Report)

Hosts Informar a los routers que elhost est interesado en undeterminado grupo multicast

La delgrupo encuestin

7/16/2019 amplif_1

32/85


Proceso presentarse de IGMPv1

CBA

A decide unirse a224.2.2.2

B decide unirse a224.1.1.1

Enva un IGMPMembership Report

a 224.1.1.1 2 3

Cuando un host quiere entrar a formar parte de un grupo multicast

enva un mensaje IGMP de saludo llamado Membership Report.

Estos mensajes se envan al mismo grupo multicast al que se quiereunir el host

1


a 224.2.2.2

C decide unirse a224.2.2.2


a 224.2.2.2

El mensaje nolo recibe nadie

El mensaje nolo recibe nadie

Este mensajelo recibe A

7/16/2019 amplif_1

33/85


Proceso pregunta-respuesta de IGMPv1

CBA

X

YRouter multicast

Es el Query Router

Miembro de 224.2.2.2 Miembro de 224.1.1.1 Miembro de 224.2.2.2

1: Cada 60 seg. Xenva un mensajequery a 224.0.0.1

1

2: B se reporta(mensaje a224.1.1.1)

2

3: C se reporta(mensaje a224.2.2.2)

3

4: A no sereporta (sabe queya lo ha hecho C)

4

5: X sabe que en la LAN haymiembros de 224.1.1.1 y de

224.2.2.2, pero no sabe cuantosni quienes

6: Y tiene la mismainformacin que X pues

recibe todos los mensajes

Los routers multicast son siempre miembrosde todos los grupos multicast de su LAN

Router multicast(no es Query Router)

Grupos de X Grupos de Y

224.1.1.1 224.1.1.1

224.2.2.2 224.2.2.2

7/16/2019 amplif_1

34/85


Proceso apuntarse (join) de IGMPv1

CBA

X Y

Router multicast

Miembro de224.2.2.2

Miembro de224.1.1.1

Miembro de224.2.2.2

3: Los routers toman nota de quehay presente un miembro de un

nuevo grupo multicast, el 224.3.3.3

Router multicast

D

1: D se apunta a224.3.3.3

2: D se reporta(mensaje a224.3.3.3)

2

Grupos de X

224.1.1.1

224.2.2.2

Grupos de Y

224.1.1.1

224.2.2.2

224.3.3.3 224.3.3.3

7/16/2019 amplif_1

35/85


Miembro de224.3.3.3

Proceso abandonar (leave) de IGMPv1

CBA

XY

Router multicastQuery router

Miembro de224.2.2.2

Miembro de224.1.1.1

Miembro de224.2.2.2

Router multicast

D

1: D decideabandonar 224.3.3.3

2: X enva el query una vez porminuto y no recibe respuesta de

224.3.3.3. Cuando esto ocurre tresveces seguidas decide borrar

224.3.3.3 de sus tablas

3: Al pasar 3 minutos sin orinformes de 224.3.3.3 Ytambin le borra de sus

tablas

Grupos de X224.1.1.1

224.2.2.2

Grupos de Y

224.1.1.1

224.2.2.2

224.3.3.3 224.3.3.3

222

7/16/2019 amplif_1

36/85


Problemas de IGMP v1

Cuando un host abandona un grupo el trficomulticast puede seguir inundando esa LANdurante un tiempo largo (tres minutos). Si elusuario hace zapping esto consume mucho ancho

de banda intilmente y puede suponer unproblema en la red. No se especifica por que mecanismo se elige al

Query router. Se supone que se utilizar el router

elegido como designado por el protocolo derouting. Los timeouts para la recepcin de informes no se

pueden configurar dinmicamente

7/16/2019 amplif_1

37/85


Mejoras introducidas por IGMPv2

Hay un mensaje Leave Group que permite a los hostsnotificar al router de forma explcita cuando abandonan ungrupo

Existen dos tipos de Query:

Query General Query especfico de grupo

La eleccin del Query router se realiza de formaindependiente al protocolo de routing. Se elige el de

direccin IP ms baja. Los timeouts para la recepcin de informes se pueden

modificar dinmicamente y anunciarse en los mensajesIGMP de Query

7/16/2019 amplif_1

38/85



Tipo Emitidopor

Funcin Direccinde destino

Consulta General(General Query)

Routers Preguntar a los hosts si estninteresados en algn grupo

multicast

224.0.0.1

Consulta especfica degrupo (Group-SpecificQuery)

Routers Preguntar a los hosts si estninteresados en un determinadogrupo multicast



Hosts Informar a los routers que elhost est interesado en un

determinado grupo multicast

La delgrupo en

cuestin

Abandono de Grupo(Leave Group)

Hosts Informar a los routers que elhost deja de estar interesado enun grupo multicast

224.0.0.2

Nuevo

Nuevo

7/16/2019 amplif_1

39/85


Proceso abandonar (leave) de IGMPv2 (I)

CBA

X Y


Miembro de224.2.2.2

Miembro de224.1.1.1

Miembro de224.2.2.2

Router multicast

1: La aplicacin de C decide

abandonar 224.2.2.2

3: X enva un Group-Specific Query a

224.2.2.2

3

4: A envaMembership

Report a

224.2.2.24

5: X decide mantener activoel grupo 224.2.2.2 ya que aun

tiene miembros

6: Y, que lo ha oido todo,decide tambin manteneractivo el grupo 224.2.2.2

Grupos de X

224.1.1.1

224.2.2.2

Grupos de Y

224.1.1.1

224.2.2.2

2: C enva LeaveGroup a224.0.0.2

2

7/16/2019 amplif_1

40/85


Proceso abandonar (leave) de IGMPv2 (II)

CBA

X Y


Miembro de224.2.2.2

Miembro de224.1.1.1

Router multicast

1: La aplicacin de A decide

abandonar 224.2.2.2

3: X enva un Group-Specific Query a

224.2.2.2

3 4: como no recibe respuestaX decide eliminar el grupo224.2.2.2 de esa interfaz

5: Y, que lo ha oido todo,decide tambin eliminar el

grupo 224.2.2.2

Grupos de X

224.1.1.1

224.2.2.2

Grupos de Y

224.1.1.1

224.2.2.2

2: A enva LeaveGroup a224.0.0.2

2

7/16/2019 amplif_1

41/85


En general cuando en una red hay algnrouter o algn host que utiliza IGMP v1

todo el conjunto funciona como IGMP v1 A menudo en estos casos los routers han de

configurarse manualmente para que

funcionen con IGMP v1 (para que sepanque no deben enviar los mensajes Group

Specific Query)

Compatibilidad IGMP v1-v2

7/16/2019 amplif_1

42/85


Mejoras introducidas por IGMP v3

La aportacin de IGMPv3 es que la eleccin delos flujos multicast ya no se limita solo a ladireccin de destino; tambin se puede especificarla direccin de origen

Esto permite aislar a saboteadores oindeseables. Evita que se puedan producirataques de denegacin de servicio en emisionesmulticast.

A la funcionalidad aportada por IGMPv3 se ladenomina SSM, Source Specific Multicast.

7/16/2019 amplif_1

43/85


Mensajes nuevos de IGMP v3

El Membership Report puede indicar una serie de fuentes aincluir, o a excluir, ej.: Unirse (Join):

Membership Report 224.1.1.1 EXCLUDE ()

Abandonar (Leave):Membership Report 224.1.1.1 INCLUDE ()

El comando Query tiene ahora tres modalidades: General Query (v1)

Group-Specific Query (v2) Group-and-Source-Specific Query (v3)

7/16/2019 amplif_1

44/85



Tipo Emitido

por

Funcin Direccin

de destino

Consulta General(General Query)

Routers Preguntar a los hosts si estninteresados en algn grupomulticast

224.0.0.1

Consulta especfica degrupo (Group-SpecificQuery)

Routers Preguntar a los hosts si estninteresados en un determinadogrupo multicast


Consulta especfica degrupo y fuente (Group-and-Source-SpecificQuery)

Routers Preguntar a los hosts si estninteresados en un determinadogrupo multicast de una serie defuentes determinada



Hosts Informar a los routers que elhost est interesado en undeterminado grupo multicast(indicando una serie de fuentesa incluir o a excluir)

224.0.0.22

Nuevo

Modificado

7/16/2019 amplif_1

45/85


Suscripcin selectiva de IGMP v3

Emisor de 224.1.1.1

Miembro de 224.1.1.1

Emisor de 224.1.1.1130.206.1.1 140.34.1.1

Membership Report:224.1.1.1EXCLUDE (140.34.1.1)

XGrupos de X

224.1.1.1 exclude ()

2Membership Report:224.1.1.1EXCLUDE ()

1

224.1.1.1 EXCLUDE (140.34.1.1)

A

BC

Y Z

3

Group-and-Source-Specific Query:224.1.1.1, 140.34.1.1

M l i LAN d

7/16/2019 amplif_1

46/85


Multicast en una LAN conmutada

Servidores de vdeo

MPEG-2 multicast

WAN

4 x 3 Mb/s

P1P2

P3P4

P1

P3

P1

P4

1 Gb/s

100 Mb/s

10 Mb/s

P1: 239.192.0.1P2: 239.192.0.2P3: 239.192.0.3P4: 239.192.0.4

12 Mb/s

M lti t t di

7/16/2019 amplif_1

47/85


Multicast con router en medio

Servidores de vdeoMPEG-2 multicast

WAN

3 Mb/s

P1

P2P3

P4

P1

P3

P1

P4

6 Mb/s9 Mb/s

El router tiene que procesartodo el trfico de vdeo

Multicast con VLANs

7/16/2019 amplif_1

48/85


Multicast con VLANsServidores de vdeoMPEG-2 multicast WAN

P1P2

P3 P4

P1

P3

P1

P4

VLANServidores

VLAN A VLAN B VLAN C

El router tiene que procesartodo el trfico de vdeo

Enlaces Trunk

7/16/2019 amplif_1

49/85


Multicast en LAN conmutada

Cuando un host desea recibir un grupomulticast tiene que emitir un IGMPMembership Report

Analizando los mensajes IGMP que pasanpor l un conmutador podra saber por quepuertos debe distribuir cada grupo

multicast, y filtrar el trfico innecesario Esto se conoce como IGMP snooping

(snooping = husmear)

7/16/2019 amplif_1

50/85


IGMP Snooping

Para realizar el IGMP snooping los conmutadores han de realizar elsiguiente proceso: Ver si se trata de una trama multicast Ver si se trata de un paquete IP (por ejemplo campo Ethertype =

x0800)

Ver si se trata de un mensaje IGMP (valor 2 en el campo protocolode la cabecera IP)

Una vez comprobado todo el conmutador ha de interpretar el mensajeIGMP y actuar en consecuencia

Este proceso puede hacerse de dos formas:

Por hardware: se incorporan ASICs adicionales al conmutador paraque no intervenga la CPU. Normalmente esto solo se hace enconmutadores de gama alta

Por software: la CPU realiza el IGMP snooping. Normalmente estolimita el rendimiento del equipo en trfico multicast

Multicast en LAN con IGMP snooping

7/16/2019 amplif_1

51/85


Multicast en LAN con IGMP snooping

Servidores de vdeo

MPEG-2 multicast

WAN

P1P2

P3P4

P1

P3

P1

P4

El router no reenva el trfico multicast,pero ha de procesar todos los paquetes

por si contuvieran mensajes IGMP

Conmutador con IGMPSnooping por hardware

Conmutadores conIGMP Snooping

por software

S i d i f

7/16/2019 amplif_1

52/85


Supresin de informes conIGMP Snooping

La supresin de informes permite que un host omita el envo delMembership Report si otro ya lo ha enviado. Esto da al traste con elIGMP Snooping, los conmutadores ya no saben exactamente en que

puertos estn los receptores multicast. Una solucin es que los conmutadores propaguen los Membership

Report solo por los puertos por donde recibieron los MembershipQuery (que es donde est el router que pregunt).

Pero los Membership Report tambin se han de enviar a los demsrouters, aunque no hayan lanzado la pregunta. Los conmutadores puedendescubrir a los routers por algunos mensajes caractersticos, o se puedeindicar en la configuracin del conmutador.

Todo esto complica el funcionamiento de IGMP Snooping. En IGMP v3 los Membership Report se envan a la direccin

224.0.0.22, que solo es recibida por los routers IGMP v.3 y no por loshosts. Por tanto en IGMPv3 no existe la supresin de informes, lo cualsimplifica el IGMP Snooping.

7/16/2019 amplif_1

53/85


Sumario


IGMP

Routing Multicast

7/16/2019 amplif_1

54/85


Funcionamiento del routing multicast

Una vez el router sabe (por IGMP) en que grupos multicastestn interesados los hosts de su LAN debe conspirar conlos dems routers para conseguir que dichos paquetes lelleguen desde donde se estn produciendo

El routing multicast funciona al revs que el unicast: seenruta en funcin de la direccin de origen, no de la dedestino.

El receptor busca la ruta ptima para llegar al emisor.Cuando la encuentra solicita a los routers del camino le

hagan llegar los paquetes Condicin: debe haber una ruta unicast viable emisor-

receptor y dicha ruta debe ser simtrica

7/16/2019 amplif_1

55/85


Modo denso y modo disperso

Modo denso: inicialmente los datagramas multicast sepropagan por toda la red y establecen un rbol ptimo sinbucles (spanning tree); si algn router no est interesado en

la emisin solicita cortar su rama del rbol enviando unmensaje prune (prune = podar).

Modo disperso: Se presupone que solo una minora de losrouters estn interesados en la emisin por lo que en

principio no se le enva a ninguno; si a alguno le interesa lodebe solicitar con un mensaje join (unirse, apuntarse).

7/16/2019 amplif_1

56/85


Modo denso Es el ms antiguo y el ms sencillo Se utiliza cuando hay un gran ancho de banda o cuando una

mayora de los routers quieren recibir el grupo multicast No es eficiente cuando el nmero de receptores es minoritario No es escalable. Protocolos que utilizan el modo denso:

DVMRP (Distance Vector Multicast Routing Protocol).RFC 1075 (11/1988)

PIM-DM (Protocol Independent MulticastDense

Mode). RFC 3973 (1/2005) MOSPF (Multicast OSPF) RFC 1584 (3/1994)

7/16/2019 amplif_1

57/85


Modo disperso

Es preferible al modo denso cuando el nmero dereceptores es minoritario

Es el ms utilizado actualmente en Internet, pues

es escalable Protocolos que utilizan el modo disperso:

PIM-SM v2 (Protocol Independent MulticastSparse Mode) RFC 2362 (6/1998)

CBT v2 (Core Based Trees) RFC 2189, 2201 (9/1997) BGMP (Border Gateway Multicast Protocol) RFC 3913

(9/2004)

7/16/2019 amplif_1

58/85


PIM-DM (Protocol IndependentMulticastDense Mode)

Para calcular las rutas ptimas utiliza la tabla de routing unicast,independientemente del protocolo utilizado para obtenerla (deah lo de protocol independent). Puede usar OSPF, IS-IS,EIGRP e incluso rutas estticas

El trfico se transmite inicialmente por inundacin. Los buclesse evitan por la tcnica denominada RPF Check

Los routers no interesados pueden enviar comandos prune(podar); si cambian de opinin pueden enviar comandos graft(injertar)

La inundacin (y el consiguiente podado) se repite cada 3

minutos Ha sido estandarizado por el IETF en el RFC 3973 Se utiliza en Internet junto con PIM-SM

RPF check (Re erse Path For arding

7/16/2019 amplif_1

59/85


Es una forma de evitar los bucles por inundacin que consiste enque antes de reenviar por inundacin un paquete el router realizala siguiente comprobacin: Analiza la interfaz de entrada del paquete y su direccin de

origen (unicast)

Consulta en la tabla de rutas la interfaz de la ruta ptimahacia la direccin de origen Si la interfaz de entrada coincide con la de la ruta ptima el

paquete es aceptado y redistribuido por inundacin. En casocontrario el paquete se descarta ya que probablemente se

trata de un duplicado El RPF check se usa en PIM-DM y PIM-SM El RPF check es incompatible con rutas asimtricas

RPF check (Reverse Path Forwardingcheck)

7/16/2019 amplif_1

60/85


A

E

B

F

G

C

D

M

M

M

M

M

Funcionamiento del RPF check

M M

M M

E sabe que su interfaz ptima haciaA es S1 y no S0; por tanto descartael paquete recibido por S0

S0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1S1S2

Emisor multicastRutas ptimas hacia A

En cada bucle se envan

dos paquetes de ms,pero como los routerslos descartan no hay

problema

Funcionamiento de PIM-DM

7/16/2019 amplif_1

61/85


Emisor multicast140.2.2.2

A

E

B

F

G

C

D

M

M

M

M

M

Funcionamiento de PIM DMInundacin inicial

S0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

1.1.1.0/24 S0S1

1.1.1.0/24 S1S2

1.1.1.0/24 S1S2

1.1.1.0/24 S1 1.1.1.0/24 S0

S2

1.1.1.0/24 S0

S2

1.1.1.0/24 S1

Red 140.2.2.0/24

MM

MM

Los paquetes recibidos en estas interfaces no son propagadospor inundacin porque no superan la prueba del RPF Check

Funcionamiento de PIM-DM (II)

7/16/2019 amplif_1

62/85


A

E

B

F

G

C

1.1.1.2

170.2.2.2

D


M

M

M

M

M

M

M

Emisor de 224.2.2.2 M

224.2.2.2

Grupos de E

P

P

P

1: Inundacin(flooding)

2: Podado(prune)

E0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

S11.1.1.2,224.2.2.2

Podado en A

S11.1.1.2,224.2.2.2

Podado en CS11.1.1.2,224.2.2.2

Podado en B

S2

2.2.2.2

( )Emisin broadcast y Podado (Pruning)

160.2.2.2

MM

MM

PP

PP

Funcionamiento de PIM-DM (III)

7/16/2019 amplif_1

63/85


A

E

B

F

G

C

1.1.1.2

170.2.2.2

D


M

M

M

M


224.2.2.2

Grupos de EE0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

S11.1.1.2,224.2.2.2

Podado en A

S11.1.1.2,224.2.2.2

Podado en CS11.1.1.2,224.2.2.2

Podado en B

S2

GM

( )Injerto (Grafting)

2.2.2.2

160.2.2.2Miembro de 224.2.2.2

G

M

224.2.2.2

Grupos de F

M

Funcionamiento de PIM-DM (IV)

7/16/2019 amplif_1

64/85


A

E

B

F

G

C

1.1.1.2160.2.2.2

170.2.2.2

D


M

M

M

M


224.2.2.2

Grupos de E

E0

E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

S11.1.1.2,224.2.2.2

Podado en A

S11.1.1.2,224.2.2.2

Podado en C

S2

M

( )Aparicin de un segundo emisor

M2M2

2.2.2.2

E0

160.2.2.2Miembro de 224.2.2.2

MEmisor de 224.2.2.2 M2

M2

M2 M2

M2

224.2.2.2

Grupos de F

rbol para

2.2.2.0/24

M

P P

P

S22.2.2.2,224.2.2.2

Podado en F

S12.2.2.2,224.2.2.2

Podado en B

S02.2.2.2,224.2.2.2

M2 M2

S02.2.2.2,224.2.2.2

Podado en D

7/16/2019 amplif_1

65/85


Problemas del modo denso

Cada router de la red ha de mantener: La topologa del SPT (la relacin de las ramas que

cuelgan de l en el rbol). Para cada red emisora y cadagrupo hay un rbol diferente

La relacin de las ramas que han sido podadas paracada emisor y cada grupo (cada par (S,G), Source,Group)

La gran cantidad de informacin de estado hace difcilestablecer un servicio multicast en una red grande para un

nmero elevado de emisores y grupos Para construir el SPT inicial se procede por inundacin.Para adaptarse a cambios en la red el proceso se repite cada2-3 minutos, lo cual genera mucho trfico.

7/16/2019 amplif_1

66/85


Funcionamiento de PIM-SM

Se basa para construir rboles en la tabla derouting unicast (como PIM-DM). Puede usarOSPF, IS-IS, EIGRP, etc., incluso rutas estticas

Al funcionar en modo disperso no se hace

inundacin de la informacin Problema: como localizamos a los emisores Solucin: establecemos un punto de encuentro

donde los emisores se registren y los receptores

vayan a preguntar. Ese punto de encuentro es unrouter que denominamos Rendezvous Point

Funcionamiento de PIM-SM (I)

7/16/2019 amplif_1

67/85


A

E

B

F

RP

C

1.1.1.2

3.3.3.3

D

2: Membership Report224.2.2.2 EXCLUDE ()

M

3: Fuente F1 deG (224.2.2.2) M

E0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

( )rbol compartido, receptores primero

2.2.2.3

RendezvousPoint ()

J

1: Membership Report

224.2.2.2 EXCLUDE ()

RP Ent Sal

(*, G) S1

R M R M

M

M

M

JJ

C Ent Sal

(F1,G) S0 S1B Ent Sal

(F1,G) S0 S1A Ent Sal

(F1,G) E0 S0

M M

E Ent Sal

(*,G) S2 E0

F Ent Sal

(*, G) S2 E0S0

M

MM

R M R M RSRS

Registro deemisores

(F1,G) S0

S0

G

Funcionamiento de PIM-SM (II)

7/16/2019 amplif_1

68/85


A

E

B

F

RP

C

1.1.1.2

3.3.3.3

D


224.2.2.2 EXCLUDE ()

M

E0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

( )rbol compartido, emisor primero

2.2.2.3

RendezvousPoint ()

J


224.2.2.2 EXCLUDE ()

RP Ent Sal

(F1, G) S0 S1

R M R MJJ

C Ent Sal



(F1,G) E0

M M

E Ent Sal

(*, G) S2 E0

F Ent Sal

(*,G) S2 E0S0

M

MM

RSRS

Registro de

emisores

(F1,G) S0

1: Fuente F1 deG (224.2.2.2) M

S0

Funcionamiento de PIM-SM (III)D f b l id

7/16/2019 amplif_1

69/85


A

E

B

F

RP

C

1.1.1.2

3.3.3.3

D

Miembro de (*,G)

M

Fuente F1 deG (224.2.2.2) M

E0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

( )Dos fuentes, rbol compartido

2.2.2.3

RendezvousPoint ()

Miembro de (*,G)

RP Ent Sal

(F1, G) S0 S1

M

M

M

C Ent Sal



(F1,G) E0 S0

M M

M2 M2E Ent Sal

(*, G) S2 E0

F Ent Sal

(*, G) S2 E0,S0

(F2,G) E0 S0

2.2.2.2

Fuente F2 de G

Registro deemisores

(F1,G) S0

(F2,G) S1

M2

Funcionamiento de PIM-SM (IV) b l SPT (Sh t t P th T )

7/16/2019 amplif_1

70/85


A

E

B

F

RP

C

1.1.1.2

3.3.3.3

D

Miembro de (*,G)

M

E0E0

S0

E0

S0

S0

S0

S0

S0

S1

S1S1S1

S2

S1

S0

S2S2

S1

S1S2

( )rbol SPT (Shortest Path Tree)

2.2.2.3

RendezvousPoint ()

Miembro de (*,G)

RP Ent Sal

(F1,G) S0 S1

C Ent Sal

(F1,G) S0 S1

B Ent Sal

(F1,G) S0 S1

A Ent Sal

(F1,G) E0 S0

M M

E Ent Sal

(*, G) S2 E0

F Ent Sal

(*,G) S2 E0S0

M

MM

1: E crea SPTpara (F1,G)

J

M

P

M

2: F crea SPTpara (F1,G)

J

M

M

Registro deemisores

(F1,G) S0

Fuente F1 de G (224.2.2.2) M

S2

S2

S1

S1

7/16/2019 amplif_1

71/85


Leyenda de smbolos empleados en lasdiapositivas

M Datagrama multicast. Direccin de origen: 1.1.1.2.Direccin de destino 224.2.2.2

M2 Datagrama multicast. Direccin de origen: 2.2.2.2.Direccin de destino 224.2.2.2

P Mensaje Prune (DVMRP, PIM-DM, PIM-SM y CBT)

G Mensaje Graft (DVMRP y PIM-DM)

J Mensaje Join (PIM-SM y CBT)

R M Mensaje Register con datagrama multicast encapsulado (PIM-SM)

RS Mensaje Register Stop (PIM-SM)

M Datagrama multicast desencapsulado por un RP (PIM-SM)

7/16/2019 amplif_1

72/85


Mensajes PIM SM Los mensajes Join o Prune de PIM-SM se envan por la

interfaz por la que apunta la ruta unicast hacia el RP (ohacia la fuente, en caso de que se est estableciendo elrbol SPT)

La direccin de destino de esos mensajes no es el RP o lafuente, sino la direccin multicast 224.0.0.13; por tanto

solo se mandan al siguiente router. El siguiente router, en funcin del mensaje recibido y su

informacin de estado multicast, decide si debe, o no,propagar el Join o Prune al siguiente router hacia el RP (ohacia la fuente, en caso de que se est estableciendo el

rbol SPT) Los mensajes Register y Register Stop son mensajesunicast; se envan siempre a la direccin unicast del RP ydel emisor. Los routers intermedios no tienen ninguna

posibilidad de interceptarlos o modificar su contenido

7/16/2019 amplif_1

73/85


Es el ms complejo de los protocolos de routing multicasten uso actualmente

Los rboles compartidos minimizan la cantidad deinformacin de estado en los routers. Los rboles SPT

optimizan el trfico Se suele fijar un umbral de trfico a partir del cual losrouters conmutan de rbol compartido a SPT. Si umbral=0se conmuta con el primer paquete, si umbral= siempre seusa el rbol compartido.

Debido a su flexibilidad y escalabilidad PIM-SM es elprotocolo que tiene ms futuro en Internet. MBone estevolucionando hacia PIM-SM

PIM-SM

7/16/2019 amplif_1

74/85


Eleccin del RP

El RP se puede asignar por configuracin en cadarouter Es posible asignar un RP diferente para diferentes

rangos de direcciones multicast

Se puede designar un RP backup por si falla el RPprincipal Dado que generalmente los rboles SPT desde la

fuente se establecen con el primer paquete enviado, la

ubicacin del RP no es crtica en lo que a rendimientose refiere. Sin embargo si el RP falla el multicast en lared deja de funcionar.

7/16/2019 amplif_1

75/85


Descubrimiento del RP

Para evitar la configuracin manual la mayora de lasimplementaciones utilizan un protocolo de descubrimiento delRP que hace uso de dos grupos multicast para distribuir susmensajes: RP Announce: 224.0.1.39

RP Discovery: 224.0.1.40 Para que el protocolo de descubrimiento del RP funcione los

grupos 224.0.1.39 y 224.0.1.40 han de distribuirse en mododenso (PIM-DM)

Esto da origen a lo que se conoce como el PIM-sparse-dense,

que utiliza modo sparse excepto para los dos grupos anteriores,para los que usa modo dense

7/16/2019 amplif_1

76/85


Multicast entre sistemas autnomos

En PIM-SM el RP es imprescindible para el funcionamiento delprotocolo Si el RP est en otro ISP (otro AS) y queda fuera de servicio los

usuarios locales no pueden utilizar multicast Para resolver este problema el IETF ha creado un protocolo

llamado MSDP (Multicast Source Discovery Protocol) (RFC3618, 10/2003) que consiste en que: Cada AS tiene su propio RP Los RPs de distintos AS se descubren mutuamente y una

vez se conocen acuerdan intercambiar informacin Para el trfico multicast entre ASs se utiliza el protocolo BGMP

(Border Gateway Multicast Protocol) (RFC 3913, 9/2004)

7/16/2019 amplif_1

77/85


Problemas del routing multicast en

las redes actuales Los principales problemas que tiene el multicast son los siguientes: Cortafuegos: no permiten el paso de paquetes multicast Rutas asimtricas: falla el RPF check y el multicast no funciona Soporte: algunos routers no soportan o no tienen configurado el routing

multicast. Fiabilidad: aunque el fabricante lo soporte en general el software multicast

est mucho menos extendido, menos probado y por tanto es menos fiableque el unicast

Rendimiento: determinados tipos de trfico multicast pueden cargarmucho los routers.

Seguridad: es muy fcil realizar ataques de denegacin de servicio en una

red con mutlicast habilitado. Escalabilidad: algunos protocolos de multicast no han sido probados agran escala, especialmente entre diferentes sistemas autnomos.

7/16/2019 amplif_1

78/85


Aplicaciones Multicast Todas las aplicaciones multicast utilizan UDP como protocolo

de transporteNo hay control de congestinNo hay control de datagramas errneos, duplicados,

descartados, etc.

Todas estas tareas quedan a cargo de la aplicacin, que recibeinformacin de la situacin a travs de los protocolos RTP yRTCP.

La inmensa mayora de las aplicaciones disponibles paramulticast son herramientas de comunicacin multimedia

(vdeoconferencia, distribucin de vdeo, etc.).

RFCs sobre multicast

7/16/2019 amplif_1

79/85


RFCs sobre multicastProtocolo RFC Fecha Pg. Estado Grado

Implement.

mbito Direcc. 2365 07/1998 8 Best current practice Alto

MZAP 2776 02/2000 27 Estndar Muy bajo

SAP 2974 10/2000 18 Experimental Alto

MADCAP 2730 12/1999 53 Estndar Muy bajo

MASC 2909 09/2000 56 Experimental Muy bajo

Glop addressing 3180 09/2001 5 Best current practice Alto

IGMP v1 1112 08/1989 5 (17) Estndar Muy bajo

IGMP v2 2236 11/1997 24 Estndar Medio

IGMP v3 3376 10/2002 53 Estndar Alto

DVMRP (v1) 1075 11/1988 24 Experimental Muy bajo

DVMRP v3 Draft 05/2004 49 Muy bajo

PIM-DM 3973 01/2005 61 Experimental Alto

MOSPF 1584 03/1994 102 Estndar Muy bajo

PIM-SM v1 2362 06/1998 66 Experimental Medio

PIM-SM v2 Draft 03/2006 148 Alto

CBT v2 2189 09/1997 23 Experimental Muy bajo

BGMP 3913 09/2004 41 Informativo Alto

MSDP 3618 10/2003 19 Experimental Muy bajo

Problema examen Febrero 2002

7/16/2019 amplif_1

80/85


D

C E

A

Emisor

Receptor

ReceptorReceptor

B F

G

Dada la red multicast PIM-SM de la figura dibuje cual sera el rbol de distribucinmulticast en caso de que el RP se site en cada uno de los siete routers de la red.

Diga cual o cuales ubicaciones hacen un uso ms eficiente de la red, usando comocriterio de optimizacin minimizar el trfico total en el conjunto de enlaces WAN.

Se supone que la mtrica utilizada es nicamente el nmero de saltos.

E E E

Solucin:

7/16/2019 amplif_1

81/85


A

R

DE

C B

G F

RR

A

E

R

DE

C B

G F

RR

A

R

DE

C B

G F

RR

A

E

R

DE

C B

G F

RR

A

E

R

DE

C B

G F

RR

A

R

DE

C B

G F

RR

A

E

R

DE

C B

G F

RR

RP en A: 6 enlaces RP en C: 5 enlaces

RP en D: 4 enlaces RP en F: 4 enlaces RP en G: 6 enlacesRP en E: 5 enlaces

RP en B: 4 enlaces

Junio 2004. Problema 2.2

7/16/2019 amplif_1

82/85

Universidad de Valencia Rogelio Montaana

Servidores devdeo multicast

P1P2

P3P4

P1

P3P4

Router multicast

1

2

3A

B

CD

1

2

1

2 3 4

Cada flujo multicast (P1, P2, P3 y P4) genera 2 Mb/s.Rellene la tabla indicando el flujo (entrante y saliente) en los puertos indicados.A implementa IGMP Snooping, B, C y D no.

Conmutador Puerto Flujo entrante (Mb/s) Flujo saliente (Mb/s)

B 123

C 12

D 1234

A enva por cada puerto solo las

emisiones multicast que tienenalgn suscriptor:Hacia B P1Hacia D P3 y P4Hacia C todos (router en modopromiscuo)

2 00 2

0 2

8 0

0 8

4 0

0 4

0 4

0 4

Ampliacin Redes 1-82

Febrero 2005. Problema 3.1 Routers:Eth0 recibe los cuatro grupos

7/16/2019 amplif_1

83/85


Servidores multicast

P1P2

P3P4

P1

P3

P1P4

Conmutadores conIGMP Snooping

H1 H2

H3 H4

H5 H6 H7 H8H9 H10 H11 H12

Eth0

Eth1

Eth2 Eth3

Indique que flujos pasan por cada una de las interfaces del router y que flujos llegan a cada host.Los conmutadores de primer nivel implementanIGMP Snooping, los de segundo nivel no

Eth0 recibe los cuatro grupos(modo promiscuo)Eth1 enva P1 y P3Eth2 enva P1

Eth3 enva P4

Hosts:H1 y H2 reciben P1H3 y H4 reciben P3H5 y H6 no reciben nadaH7 y H8 reciben P1H9 y H10 no reciben nadaH11 y H12 reciben P4


Junio 2007. Problema 2.1

7/16/2019 amplif_1

84/85


A

B C

2048 Kb/s 2048 Kb/s

64 Kb/s

E0

S0 S1

Emisor P1

Emisor P2 Emisor P3

Receptor P3 Receptor P3

Receptor P3

Receptor P1

Routing unicast: OSPF (mtrica basada en ancho de banda)Routing multicast: PIM-SM con RP en A. Se revierte al SPT de forma inmediataLos conmutadores tienen IGMP SnoopingCada emisor genera 500 Kb/s de trficoCalcule el flujo entrante y saliente en cada interfaz del router A

P1 genera 500 Kb/s detrfico entrante en E0 de A

P2 no genera ningn trficoen A

P3 genera 500 Kb/s de

trfico que entra por S1 ysale por E0 . Adems salen500 Kb/s por S0 hacia B

Interfaz Entrante SalienteE0 500 Kb/s (P1) 500 Kb/s (P3)S0 0 Kb/s 500 Kb/s (P3)

S1 500 Kb/s (P3) 0 Kb/s


Febrero 2007. Problema 2.1

7/16/2019 amplif_1

85/85

Servidor 192.168.1.1/24Emisin de vdeo (10 Mb/s)239.0.0.1

H1

Servidor 192.168.1.2/24Emisin de audio (50 Kb/s)239.128.0.1

H2 H3 H4

192.168.1.3/24 192.168.1.4/24 192.168.1.5/24 192.168.1.6/24

H1 y H2 reciben audio, ningn host recibe vdeo (no tienen aplicacin adecuada)Si la emisin de vdeo cambia a la direccin 239.0.0.2, Cmo cambia el trfico?Los conmutadores no implementan IGMP Snooping

R: Al no tener IGMP Snooping en los conmutadores el trfico multicast es inundado en toda la red,

todos los hosts reciben el audio y el vdeo, antes y despus del cambio de direccin en el flujo devdeoEn H3 y H4, que no se han asociado a ninguna emisin, la tarjeta de red filtra todo el trficomulticast por lo que este no consume ciclos de CPU ni antes ni despus del cambio.En H1 y H2 con la direccin 239.0.0.1 el vdeo utiliza la misma direccin MAC que el audio, porlo que no es posible filtrar el trfico de vdeo que consumir ciclos de CPU Con la nueva

amplif_1

Documents

ffff ffff

d832grupo multicast

eltrfico multicast

direcciones multicast

0001m7162019 amplif

0001ana7162019 amplif

lan todoslos

direccin ab