Multicast - Mise en oeuvre de...

2008

UFR Ingénieurs 2000 Vivien Boistuaud Julien Herr

Ce document a été réalisé par V. Boistuaud et J. Herr dans le cadre des travaux pratiques de Routage IP Multicast coordonnés par Yves Mourrier et Michel Martin, au sein de l’UFR Ingénieurs 2000 de l’Université de Marne-la-vallée.

MULTICAST IP – MISE EN ŒUVRE DE PIM POUR L’ENVOI DE PAQUETS MULTICAST SUR UN RESEAU ROUTE

Routage Multicast – Multicast IPv4 avec PIM

Vivien Boistuaud – Julien HerrIngénieurs 2000 – IR3 – 2007-2008

2

Table des matières

Introduction .......................................................................................................................................................................... 3

1. Présentation générale du TP ................................................................................................................................. 4

1. Matériel utilisé ....................................................................................................................................................... 4

2. Montage initialement utilisé ............................................................................................................................ 5

1. Remise à zéro du routeur .............................................................................................................................. 7

2. Configuration du nom d’hôte ..................................................................................................................... 7

3. Configuration des interfaces réseaux ....................................................................................................... 8

3. Mise en œuvre d’OSPF et simplification ....................................................................................................... 9

1. Configurer une adresse de loopback ..................................................................................................... 10

2. Activer OSPF ................................................................................................................................................... 10

3. Vérifier la configuration OSPF .................................................................................................................. 10

4. Valider le fonctionnement par ping ....................................................................................................... 12

4. L’application client/serveur Multicast ........................................................................................................ 13

1. Démarrage des applications ..................................................................................................................... 13

2. Test de Multicast sur un même réseau IP ............................................................................................. 13

2. IGMP - PIM en Dense Mode ................................................................................................................................ 15

1. Activation d’IGMP et de PIM .......................................................................................................................... 15

2. Clients Multicast sur le réseau ....................................................................................................................... 16

3. Vérification de la configuration IGMP ........................................................................................................ 16

4. Observations ....................................................................................................................................................... 17

3. IGMP - PIM en Sparse Mode avec RP ............................................................................................................... 20

1. Configuration du routeur ............................................................................................................................... 20

2. Observations ....................................................................................................................................................... 21

Conclusion .......................................................................................................................................................................... 23



3

Introduction

Dans le cadre de nos études d'ingénieurs en informatique et réseaux à l'université

de Marne-la-vallée, nous avons étudié les différents protocoles de communication

permettant de faire du Multicast IP sur un réseau étendu.

En effet, les normes IPv4 comme IPv6, prévoient deux principaux type de

communications entre hôtes : unicast (communication entre deux hôtes) et

multicast (communication avec un groupe d'hôtes).

Le multicast permet ainsi de n'envoyer un paquet sur le réseau qu'une fois pour que

plusieurs hôtes le reçoive. Cette technique, utilisable seulement en conjonction avec

le protocole de transport UDP, permet de réduire la consommation de bande

passante lors de transmission de données d'informations à un groupe de machines.

Typiquement, le multicast est utilisé pour la communication inter-routeur sur un

réseau, ou pour la transmission de voix et de vidéo, par exemple pour transmettre

un programme de télévision ou de radio sur un réseau.

Cependant, les routeurs ne sont pas prévus pour transmettre ce type de trafic sur

d'autres réseau que celui sur lequel ils le reçoivent afin d'éviter une inondation sur

les réseaux de grande taille.

Pour palier à ce problème, plusieurs protocoles de routage Multicast comme PIM

ont été inventés, permettant alors la transmission multicast contrôlée sur un réseau

IPV4.

Dans un premier temps, ce rapport présente le réseau mis en place et sa

configuration initiale (par OSPF) puis, il présente plusieurs cas de mise en œuvre de

PIM pour de petits réseaux (dense-mode) comme pour de grands (sparse-mode) en

trois parties majeures en fonction de la configuration adoptée.



4

1. Présentation générale du TP

Cette section présente la façon dont les travaux pratiques se sont déroulés : le

matériel utilisé et sa configuration, la topologie du réseau mis en place, ainsi que les

protocoles de routage Multicast (PIM) dont la description est mise en œuvre dans la

seconde partie de ce T.P.

1. Matériel utilisé

Pour mettre en œuvre ce TP, nous avons utilisé le matériel suivant :

• 6 ordinateurs équipés de Windows 2000 et du logiciel Hyper-terminal, avec au

moins un port série (RS332) et une carte Ethernet disponibles ;

• 6 routeurs Cisco 2500 series IPv4, équipés de 2 ports série, 2 ports Ethernet et un

port console chacun ;

• 2 commutateurs Hewlett Packard 10/100 Base-TX équipés de 16 ports,

• 4 câbles réseaux RJ-45 Ethernet Classe 3 droits,

• 2 câbles réseaux RJ-45 Ethernet Classe 3 croisés,

• 6 câbles inversés Cisco pour la configuration par port série Hôte/Routeur

• 6 câbles DCE et 6 câbles DTE pour les communications série Cisco-Cisco,

Notez qu’à priori, n’importe quel système d’exploitation peut convenir du moment

que le système supporte IPv4 et une communication par liaison série 9600bps sans

bit de parité. De plus, sur les commutateurs, seuls 4 ports sont utiles par

commutateur pour ce TP. De même, un seul port Ethernet par routeur a été utilisé.

Dans la section suivante, nous détaillons le montage et la façon dont l’ensemble de

ces matériels interagissent ensemble.



5

2. Montage initialement utilisé

Le montage initialement réalisé est le suivant :

Figure 1 - Configuration initiale du réseau

Chaque hôte (Hx) est configuré avec, comme route par défaut, le routeur qui lui

correspond (Rx). Les câbles DCE (Femelles, qui fixent l’horloge), sont connectés sur

les ports Serial0 de chaque routeur, tandis que les câbles DTE (Mâles) sont connectés

sur le Serial1. De plus, les machines connectées directement aux routeurs le sont

entre leur port eth0 et le port Ethernet0 du routeur.

Le plan d’adressage retenu est le suivant, il n’est pas indiqué sur le diagramme car il

est très expansif :

• H1 • eth0 :128.25.1.1/16

• R1 • Ethernet 0 : 128.1.1.2/16 • Serial 0 : 10.1.0.1/16 • Serial 1 : 10.3.0.1/16



6

• Loopback 0 : 192.1.1.1/32 • H2 :

• eth0 : 128.25.2.1/16 • R2 :

• Ethernet 0 : 128.25.2.2/16 • Serial 0 : 10.2.0.2/16 • Serial 1 : 10.1.0.2/16 • Loopback 0 : 192.2.2.2/24

• H3 • eth0 :128.34.3.1/16

• R3 • Ethernet 0 : 128.34.3.2/16 • Serial 0 : 10.3.0.3/16 • Serial 1 : 10.2.0.3/16 • Loopback 0 : 192.3.3.3/32

• H4 • eth0 :128.34.4.1/16


• H5 • eth0 :128.35.5.1/16


• H6 • eth0 :128.6.6.1/16


Dans un premier temps, nous avons mis en place les réseaux IP nécessaires entre

chacun des périphériques, comme indiqué sur le plan de configuration initiale du

réseau.



7

1. Remise à zéro du routeur

Pour cela, on commence tout d’abord par allumer le routeur, se connecter en tant

qu’administrateur (commande enable) et réinitialiser la configuration du routeur

comme suit :

Router>enable Router#erase startup-config [OK] Router#reload Proceed with reload? [confirm] %SYS-5-RELOAD: Reload requested System Bootstrap, Version 11.0(10c)XB2, PLATFORM SPECIFIC RELEASE SOFTWARE (fc1) Copyright (c) 1986-1998 by cisco Systems

2. Configuration du nom d’hôte

Pour pouvoir identifier notre routeur au cours du temps et des manipulations, nous

avons décidé de lui affecter le nom « R5 » qui est le même que celui utilisé sur les

schémas de ce document. Pour cela, nous avons utilisé la commande :

Router>enable Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R5

On active également quelques options utiles pour l’utilisation du routeur : la

synchronisation de l’affichage par liaison série, la désactivation du timeout

automatique, et la désactivation des recherches de domaine, comme suit :

R5(config)#line console 0 R5(config-line)#logging synchronous R5(config-line)#no exec-timeout R5(config-line)#exit R5(config)#no ip domain-lookup R5(config)#exit



8

3. Configuration des interfaces réseaux

On commence par configurer la liaison Serial0 qui relie notre routeur (R5) au routeur

R4. De plus, comme ce port est relié à un câble DCE (femelle) alors il faut également

indiquer la commande clock rate, ce qui donne :

R5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R5(config)#interface Serial 0 R5(config-if)#clock rate 19200 R5(config-if)#no shutdown R5(config-if)#ip address 10.5.0.5 255.255.0.0 R5(config-if)#exit

On configure ensuite la liaison Serial1 qui relie notre routeur (R5) au routeur R6 :

R5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R5(config)#interface Serial 1 R5(config-if)#no shutdown R5(config-if)#ip address 10.4.0.5 255.255.0.0 R5(config-if)#exit

Enfin, on configure la liaison Ethernet0 qui relie notre routeur (R5) au commutateur

Ethernet S1 :

R5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R5(config)#interface Ethernet 0 R5(config-if)#no shutdown R5(config-if)#ip address 128.25.5.2 255.255.0.0 R5(config-if)#exit

Cependant, si on souhaite configurer l’ensemble des réseaux de façon statique dans

chaque routeur, ceci prendrait un temps important, et ne permettrait pas de

prendre en compte la disparition d’un routeur sur le réseau. Afin de résoudre ce

problème, nous allons mettre en œuvre le protocole OSPF (Open Shortest Path First)

pour configurer automatiquement l’ensemble des routeurs.

Par mesure de sécurité, avant de continuer, on sauvegarde la configuration :

R5#copy running-config startup-config Building configuration... [OK]



9

3. Mise en œuvre d’OSPF et simplification

A l’heure actuelle, il «est possible de pinger les interfaces qui sont sur le même

réseau (par exemple communiquer entre H2 et H4, ou entre H5 et l’interface Serial1

du routeur R6).

C:\>ping 10.5.0.6 Envoi d'une requête 'ping' sur 10.5.0.6 avec 32 octets de données : Réponse de 10.5.0.6 : octets=32 temps<10 ms TTL=128 Réponse de 10.5.0.6 : octets=32 temps<10 ms TTL=128 Réponse de 10.5.0.6 : octets=32 temps<10 ms TTL=128 Réponse de 10.5.0.6 : octets=32 temps<10 ms TTL=128 Statistiques Ping pour 10.5.0.6: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : minimum = 0ms, maximum = 0ms, moyenne = 0ms

Cependant, il n’est pas possible de communiquer entre deux machines de réseaux

différents, car les tables de routage des routeurs ne contiennent pas d’information

concernant les autres réseaux.

Pour simplifier la configuration des tables de routage, nous avons activé le

protocole OSPF (Open Shortest Path First) sur les routeurs afin que chacun

construise lui-même la carte du réseau.

Pour cela, nous avons réalisé deux opérations : assigner une adresse de loopback

spécifique à chaque routeur, pour qu’il serve d’identifiant OSPF, et activer OSPF sur

les interfaces de communication inter-routeurs. En effet, il n’est pas nécessaire de

l’activer sur les interfaces de communication routeur-machine (Ethernet 0 des

routeurs R6 et R1).



10

1. Configurer une adresse de loopback

L’adresse de loopback doit être un grand nombre utilisé uniquement pour des

besoins internes. Elle servira comme identifiant de routeur permanent pour OSPF.

Pour la configurer, on fait comme pour toute interface réseau :

R5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R5(config)#interface Ethernet 0 R5(config-if)#ip address 192.5.5.5 255.255.255.255 R5(config-if)#exit

On notera que le no shutdown n’est pas nécessaire : les interfaces de loopback sont

automatiquement allumées la première fois qu’on les utilise, par exemple, en leur

affectant une adresse IP.

2. Activer OSPF

Pour activer OSPF sur les routeurs Cisco, la manipulation à réaliser est très simple :

on choisit un numéro de configuration OSPF à utiliser, puis on précise pour chaque

réseau géré par OSPF les wildcard bits du réseau, et le numéro de l’area OSPF à

laquelle il est relié.

Ici, il s’agit de la backbone area, qui vaut toujours 0.0.0.0 en OSPF. On configure alors

comme suit :

R5#configure terminal R5(config)#router ospf 1 R5(config-router)#network 10.0.0.0 0.255.255.255 area 0.0.0.0 R5(config-router)#network 128.25.5.2 0.0.0.0 area 0.0.0.0

Sur notre routeur, les messages de mise à jour OSPF doivent être envoyées sur

toutes les interfaces dans la mesure où il est connecté par tous ses ports à d’autres

routeurs soit directement (par le port Serial), soit par l’intermédiaire d’un

commutateur (par le port Ethernet).

3. Vérifier la configuration OSPF

Grâce à la commande show ip protocols, nous pouvons visualiser le nombre de

gateway qui ont été contactées (ici, 5), et leurs adresses, comme ci-dessous :



11

R5#show ip protocols Routing Protocol is "ospf 1" Sending updates every 0 seconds Invalid after 0 seconds, hold down 0, flushed after 0 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: ospf 1 Routing for Networks: 10.0.0.0 128.25.5.2/32 Routing Information Sources: Gateway Distance Last Update 128.1.1.2 110 00:22:16 128.34.3.2 110 00:22:16 128.34.4.2 110 00:22:17 192.2.2.2 110 00:22:17 192.6.6.6 110 00:22:17 Distance: (default is 110)

De plus, grâce à la commande show ip route, on peut visualiser les différentes

routes présentes dans la table de routage et on peut en déduire que 4 réseaux sont

connectés directement au routeur, dont celui utilisé pour l’adresse de loopback. Le

résultat est le suivant :

R5#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route Gateway of last resort is not set 10.0.0.0/16 is subnetted, 6 subnets O 10.2.0.0 [110/74] via 128.25.2.2, 00:22:39, Ethernet1 O 10.3.0.0 [110/138] via 128.25.2.2, 00:22:39, Ethernet1 [110/138] via 10.4.0.4, 00:22:39, Serial1 O 10.1.0.0 [110/74] via 128.25.2.2, 00:22:39, Ethernet1 O 10.6.0.0 [110/128] via 10.4.0.4, 00:22:39, Serial1 [110/128] via 10.5.0.6, 00:22:39, Serial0 C 10.4.0.0 is directly connected, Serial1 C 10.5.0.0 is directly connected, Serial0 O 128.1.0.0/16 [110/84] via 128.25.2.2, 00:22:39, Ethernet1 O 128.6.0.0/16 [110/74] via 10.5.0.6, 00:22:39, Serial0 C 128.25.0.0/16 is directly connected, Ethernet1 O 128.34.0.0/16 [110/74] via 10.4.0.4, 00:22:40, Serial1 192.5.5.0/32 is subnetted, 1 subnets C 192.5.5.5 is directly connected, Loopback0

Le sigle C en début de certaines lignes indique que les réseaux correspondants sont

directement connectés aux routeurs. Le sigle O indique que la route est configurée

automatiquement par OSPF. Si plusieurs Area OSPF étaient présentes dans notre

réseau, les routes marquées O IA seraient des routes configurées par OSPF et

transitant vers une autre Area OSPF.



12

Sur les routes configurées par OSPF, on remarque la présence d’une information de

métrique du type [X/Y]. La valeur X indique le poids administratif du protocole, ce

qui vaut toujours 110 pour OSPF. La valeur Y correspond au coût de la route, qui est

un mélange entre la distance, la vitesse des liens et de nombreux autres facteurs…

4. Valider le fonctionnement par ping

Pour vérifier que le routage fonctionne correctement sur l’ensemble du réseau,

OSPF ayant été activé sur tous les routeurs, on peut tenter de communiquer par

ICMP ECHO (commande ping) entre notre machine (H5) et la machine H4 comme

suit :

C:\>ping 128.34.3.1 Envoi d'une requête 'ping' sur 128.34.3.1 avec 32 octets de données : Réponse de 128.34.3.1 : octets=32 temps=62 ms TTL=126 Réponse de 128.34.3.1 : octets=32 temps=47 ms TTL=126 Réponse de 128.34.3.1 : octets=32 temps=47 ms TTL=126 Réponse de 128.34.3.1 : octets=32 temps=47 ms TTL=126 Statistiques Ping pour 128.34.3.1: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : minimum = 47ms, maximum = 62ms, moyenne = 50ms

Notre réseau semble donc fonctionner correctement. Par mesure de sécurité, nous

sauvegardons alors la configuration pour qu’elle soit appliquée automatiquement

au démarrage comme suit :

R5#copy running startup Building configuration... [OK]



13

4. L’application client/serveur Multicast

Maintenant que notre réseau est configuré et routable de bout en bout, l’intérêt de

ce TP est de mettre en avant les différents algorithmes de propagation Multicast

inter-réseau. Pour tester le Multicast IP, nous avons utilisé une application Java

écrite par Yves Mourrier, et qui permet de transmettre simplement de petits

messages à intervalles réguliers, en Multicast.

Pour simplifier nos tests, nous utiliseront toujours par la suite de ce document une

de ces trois adresses multicast pour échanger des données de groupe : 224.0.0.1

(alias groupe1), 224.0.0.2 (alias groupe2) et 224.0.0.3 (alias groupe 3). Dans tous les

cas, le port utilisé pour la transmission de données est le même, et fixé en dur dans

l’application.

1. Démarrage des applications

L’application s’utilise comme suit. Pour démarrer le serveur Multicast sur une

adresse IP Multicast donnée, on utilise la commande comme suit :

C:\>java -cp c:\multicast_appl multicast.MulticastServeur x.x.x.x

L’application s’utilise comme suit. Pour démarrer le serveur Multicast sur une

adresse IP Multicast donnée, on utilise la commande comme suit :

C:\>java -cp C:\multicast_appl multicast.MulticastClient x.x.x.x

2. Test de Multicast sur un même réseau IP

Pour vérifier que l’application Multicast fonctionne correctement, tant pour la partie

serveur que pour la partie cliente, les opérateurs de la machine H2 ont démarré

l’application cliente comme suit :



14

C:\>java -cp c:\multicast_appl multicast.MulticastServeur grp1 Envoi vers le groupe: grp1/230.100.100.1 Horodatage: Wed Dec 19 10:06:38 CET 2007 Envoi vers le groupe: grp1/230.100.100.1 Horodatage: Wed Dec 19 10:06:40 CET 2007 Envoi vers le groupe: grp1/230.100.100.1 Horodatage: Wed Dec 19 10:06:41 CET 2007 Envoi vers le groupe: grp1/230.100.100.1 Horodatage: Wed Dec 19 10:06:42 CET 2007 Envoi vers le groupe: grp1/230.100.100.1 Horodatage: Wed Dec 19 10:06:43 CET 2007

Puis, nous avons lancé l’application cliente sur notre machine (H5) qui est reliée

directement sur le même sous-réseau, via le commutateur S1. Le résultat est le

suivant :

C:\>java -cp C:\multicast_appl multicast.MulticastClient grp1 Signal recu de: /128.25.2.1 pour le groupe: grp1/230.100.100.1 Horodatage recu: Wed Dec 19 10:06:38 CET 2007 Signal recu de: /128.25.2.1 pour le groupe: grp1/230.100.100.1 Horodatage recu: Wed Dec 19 10:06:40 CET 2007 Signal recu de: /128.25.2.1 pour le groupe: grp1/230.100.100.1 Horodatage recu: Wed Dec 19 10:06:41 CET 2007 Signal recu de: /128.25.2.1 pour le groupe: grp1/230.100.100.1 Horodatage recu: Wed Dec 19 10:06:42 CET 2007 Signal recu de: /128.25.2.1 pour le groupe: grp1/230.100.100.1 Horodatage recu: Wed Dec 19 10:06:43 CET 2007

On reçoit bien les messages multicast adressés au groupe 1 et envoyés depuis la

machine H2 ayant pour adresse IP 128.25.2.1.



15

2. IGMP - PIM en Dense Mode

Protocol Independant Multicast est une technologie qui permet de faire transiter les

communications multicast au-delà d’un routeur, en fonction des hôtes ayant

demandé à recevoir un flux. On dit alors qu’elles ont demandé à s’abonner aux flux.

PIM présente l’avantage d’être indépendant du protocole (du moment qu’il s’agit

d’un protocole IP), et d’être transparent pour les hôtes : ce sont les routeurs qui

communiquent entre eux pour s’accorder sur le routage de flux Multicast.

Il existe deux modes de fonctionnement pour PIM, qui sont habituellement

incompatibles entre eux. Aussi, il faut choisir le mode à utiliser et en informer les

routeurs lors de la mise en place de PIM. Ces deux modes s’appellent « Sparse

Mode » et « Dense Mode ». Le Dense Mode est utilisable pour les réseaux de petite

taille, car il fonctionne par inondation. Le Sparse Mode fonctionne par abonnement

et référencement auprès d’un point de Rendez-vous comme nous le verrons dans la

section suivante.

1. Activation d’IGMP et de PIM

Pour activer IGMP sur le routeur Cisco, il suffit d’utiliser la commande suivante :

R5(config)#ip multicast-routing

Puis ensuite on précise les interfaces sur lesquelles on souhaite activer PIM en

dense-mode. Dans notre cas, nous ne l’activeront que sur les connexions inter-

routeurs car les clients n’ont pas besoin de recevoir ces informations, et il est inutile

d’inonder le réseau.

R5(config)#interface Serial 0 R5(config-if)#ip pim dense-mode R5(config-if)#exit R5(config)#interface Serial 1 R5(config-if)#ip pim dense-mode R5(config-if)#exit

De plus, pour les machines H3, H4, H2 et H5 (notre routeur), il faut également activer

PIM sur l’interface Ethernet0 dans la mesure où un routeur est également connecté

au commutateur Ethernet. On le fait comme suit :



16

R5(config)#interface Ethernet 0 R5(config-if)#ip pim dense-mode R5(config-if)#exit

2. Clients Multicast sur le réseau

Pour observer comment se construit la couverture du réseau, on lance un émetteur

multicast sur la machine H2, pour le groupe grp2, et on lance des clients multicast

abonnés à grp2 sur les machines H1, H4 et H6.

On peut alors observer, ci-après comment PIM et IGMP gèrent ces abonnements,

sachant que sur les clients nous recevons correctement les paquets.

3. Vérification de la configuration IGMP

On peut, dans un premier temps, utiliser la commande suivante pour détecter les

informations de configuration d’IGMP actives :

R5#show ip igmp interface ethernet 1 Ethernet1 is up, line protocol is up Internet address is 128.25.5.2, subnet mask is 255.255.0.0 IGMP is enabled on interface CGMP is disabled on interface Current IGMP version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Inbound IGMP access group is not set Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 128.25.5.2 (this system) IGMP querying router is 128.25.2.2 No multicast groups joined

On peut tirer de ce résultat deux informations utiles :

• Le Designated Router IGMP, qui est utilisé pour rediriger les trames Multicast

même s’il n’offre pas le meilleur chemin, est élu (dans la version 2 de la

norme) en fonction de l’adresse IP la plus élevée sur le sous-réseau sur

lequel sont émises les trames multicast. Ici, il s’agit de notre routeur R5 qui a

pour adresse 128.25.5.2.

• Le Querier est le routeur qui envoi périodiquement des demandes sur le

réseau pour détecter les nouveautés. Il est sélectionné, dans IGMPv2, par

l’adresse IP la plus petite. Sur notre sous-réseau, il s’agit du routeur R2 qui a

pour adresse 128.25.2.2.



17

Si on observe la table des groupes IGMP disponibles depuis le routeur R5, on obtient

le résultat suivant :

R5#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Serial0 00:25:01 never 0.0.0.0 230.100.100.2 Ethernet0 00:03:08 00:02:46 128.25.2.1

On observe que le routeur sait que, sur son interface Ethernet0, l’hôte ayant pour

adresse 128.25.2.1 (qui est H2) émet des trames multicast à destination de l’adresse

de groupe 230.100.100.2 (qui est notre adresse grp2).

La ligne indiquant un groupe Multicasts sur 224.0.1.40 est liée à une spécificité des

routeurs Cisco, qui utilisent cette adresse de Multicast pour l’Auto-RP (auto rendez-

vous point, utilisable en Dense Mode.

4. Observations

Lors du routage de la première trame entre une source et les abonnés à un groupe,

en PIM dense-mode, la trame est propagée à toute l’arborescence y compris ceux

qui ne sont pas intéressés. On parle alors d’inondation. Ceci explique pourquoi le

dense-mode ne doit être utilisé que sur de petits réseaux : à grande échelle, on

pourrait engorger le réseau.



18

Après analyse, on obtient les routes multicast suivantes :

On remarque un illogisme dans le résultat obtenu : les paquets multicast devraient

toujours être expédiés par l’IGMP Designated Router pour éviter qu’il n’y ait une

propagation en double sur le réseau, même si la route n’est pas optimale.

Dans le cadre de ce TP, et sans que ce ne soit explicable, il semblerait que les

routeurs aient utilisé un mode hybride entre le dense-mode et le sparse-mode,

provoquant l’utilisation d’un chemin plus court pour aller de H2 vers H1. Ceci est

propre au matériel Cisco, car ces deux modes ne sont pas habituellement

combinables car incompatibles.

Figure 2 - Pruned interfaces in PIM dense-mode



19

Les tableaux ci-dessous récapitulent les informations issues des six routeurs lors de

cette manipulation (obtenus via la commande show ip mroute).

Routeur Interface d’entrée Interface de sortie Flags

R1 S0 E0 Forward

R1 - S1 Pruned

R2 E0 S1 Forward

R2 - S0 Pruned

R3 - E0 Pruned

R3 - S0 Pruned

R3 - S1 Pruned

R4 S0 E0 Forward

R4 - S1 Pruned

R5 E0 S0 Forward

R5 E0 S1 Forward

R6 - S0 Pruned

R6 S1 E0 Forward

En théorie, nous aurions dû voir les lignes en rouge modifiées comme suit :

Routeur Interface d’entrée Interface de sortie Flags

R2 S1 Pruned

R3 E0 S0 Forward

Dans les autres séances de TP, cette manipulation n’avait toutefois pas posé de

problèmes. Il est fort probable que le problème soit venu d’une mauvaise

configuration du routeur R2 bien que ceci n’ai pas été démontré.



20

3. IGMP - PIM en Sparse Mode avec RP

Lorsqu’on souhaite faire du Multicast de niveau 3 (couche 3) avec IGMP sur un

réseau de grande taille, on ne peut utiliser le dense-mode car son fonctionnement

par inondation et la non-optimisation des chemins pose d’importants problèmes de

trafic. De plus, si le réseau n’est pas bouclé, le dense-mode ne fonctionne pas sur

l’ensemble du réseau.

1. Configuration du routeur

Afin de mettre en place une stratégie de PIM Sparse-Mode, il faut tout d’abord

désactiver PIM Sparse-Mode. Pour cela, sur chaque interface, on tape la commande :

R5(config-if)#no ip pim dense-mode

Ensuite, sur chacune des interfaces, on active PIM en Sparse Mode comme suit :

R5(config-if)#ip pim sparse-mode

Notez que, tout comme précédemment, les interfaces Ethernet0 des routeurs R1 et R6

n’ont pas besoin d’avoir le Sparse Mode activé dans la mesure où ils ne communiquent

qu’avec une machine via cette interface.

Une fois le Sparse-Mode activé, il est nécessaire de définir un RP (Rendez-vous Point)

qui servira à recevoir en unicast des commandes REGISTER permettant la création

dynamique de mroutes (routes multicast) qui seront ensuite utilisées selon le

principe de RPF (Reverse Path Forwarding). Lorsqu’une route entre la source d’une

émission Multicast et le RP est crée, on parle alors d’arbre partagé (Shared Tree).

Nous avons décidé d’utiliser le routeur R3 (ayant pour adresse IP publique

128.34.3.2) comme Rendez-vue Point. Pour activer cette fonctionnalité, il faut entrer

la commande suivante sur chaque routeur :

R5(config)#ip pim rp-address 128.34.3.2

Notez que, durant les phases d’enregistrement (avant le JOIN), la route qui permet

de recevoir les paquets multicast n’est pas nécessairement la plus optimale.

Toutefois, les messages JOIN sont rapides à se propager.



21

2. Observations

En conséquence, les observations que nous avons faites ne permettront pas de voir

ce qui se passe pendant le processus de REGISTER/JOIN, mais d’en observer le

résultat.

Nous avons décidé de démarrer, cette fois, le serveur Multicast vers le groupe grp1

sur l’hôte H6, et de démarrer un client de grp1 sur H1 et un second sur H2.

Nous obtenons le circuit suivant présentant la circulation des messages Multicast de

façon optimale sur le réseau :

On observe aisément que la répartition du trafic sur le réseau est optimale compte

tenue des distances et poids de chacun des liens.

Figure 3 - Propagation des trames multicast en Sparse-Mode



22

Le tableau suivant récapitule les informations issues des routeurs en

fonctionnement :

Routeur De Vers Entrée Sortie

R1 * grp1 S1 E0

R1 srv grp1 S1 E0

R2 * grp1 null null

R2 srv grp1 E0 null

R3 * grp1 null S0, E0

R3 srv grp1 E0 S0

R4 * grp1 E0 S0

R4 srv grp1 S1 E0

R5 * grp1 S1 E0

R5 srv grp1 S0 E0

R6 * grp1 null null

R6 srv grp1 E0 S0, S1

Le seul inconvénient du Sparse-Mode avec RP fixe est que si le RP disparait du

réseau, il faut reconfigurer tous les routeurs pour utiliser un nouveau RP, ce qui

suspend les possibilités de connexion Multicast durant ce temps.

Par conséquent, il existe une seconde méthode, qui est toujours du Sparse-Mode

mais cette fois utilisant un RP dynamique automatiquement sélectionné et

automatiquement remplacé en cas de disparition. Toutefois, nous n’avons pas eu le

temps de voir cette manipulation durant nos séances de travail.



23

Conclusion

Ce rapport nous a permis d’apprendre à configurer des routeurs équipés de l’IOS

Cisco pour qu’ils utilisent le protocole PIM en Sparse Mode et en Dense Mode. Les

routeurs Cisco étant les plus répandus dans l’industrie informatique, ceci nous

permettra dans la suite de notre carrière de pouvoir répondre à des besoins précis

en configuration de réseaux Multicast.

De plus, ce T.P. complémente de façon claire le cours de M. Yves Mourrier sur les

technologies Multicast IPv4, dans la mesure où ils permettent de vérifier en pratique

le fonctionnement étudié de façon théorique en cours.

Il est cependant dommage que nous ayons rencontré des problèmes au niveau de

la mise en œuvre du PIM Sparse Mode, liés au fait que Cisco ai implémenté un mode

de fonctionnement hybride Sparse Mode/Dense Mode qui ne fonctionne qu’entre

routeurs Cisco et qui tente, sous certaines réserves, de trouver un chemin optimal

alors que ce mode devrait choisir les routeurs par leur poids/importance sur le

réseau. Les normes IGMPv2 sont alors violées.

De plus, ce retard nous a empêchés de réaliser la dernière partie de ce TP, qui

consistait à mettre en œuvre le Sparse-Mode avec un RP dynamique. Cependant, à

partir des informations fournies par M. Mourrier au cours des enseignements

théoriques, nous sommes supposés connaître le fonctionnement normal de ce type

de technologie et savoir le configurer sur un routeur Cisco.

Multicast - Mise en oeuvre de...

Documents

Transcript of Multicast - Mise en oeuvre de...