Le multicast est le moyen d'envoyer une seule copie de messages à un groupes de receveurs.
Les caractéristiques du multicast :

•  Le multicast est la transmission d'une trame IP à un groupe qui est définit par une seule adresse.
•  IP réduit la quantité de trafic en envoyant simultanément un stream aux multiples récipients.
•  Facilite la transmission d'un datagramme IP à un groupe de hosts qui comprend 0 hosts ou plus identifiés par une seule et même adresse.
•  Délivre un datagramme multicast à tous les membres du groupe de destination avec le même "best-effort" tout comme des datagrammes IP.
•  Supporte l'appartenance dynamique à un groupe.
•  Supporte tous les groupes sans restriction géographique ni de nombre de hosts.
•  Supporte le fait qu'un hosts puisse appartenir à un ou plusieurs groupes
•  Supporte un groupe d'adresses pour de multiples applications sur un host

Il existe une grande variété de délais dans le multicast dépendant du path au serveur multicast, ainsi qu'aux différences de bout en bout.
Une particularité du multicast est que le serveur ne connaît pas les adresses unicast des récipients. de ce fait les hosts peuvent appartenir à un groupe multicast de façon anonyme.
Le trafic multicast utilise UDP. De ce fait on ne dispose des mécanismes de contrôle de TCP, mais par contre en gagne en simplicité dans l'en-tête.

1.1.            La structure d'adressage multicast

Le multicast utilise des adresse de classe D.

Classe D :           224.0.0.0 - 239.255.255.255
                        239.0.0.0 /8 réservée
Les adresse multicast peuvent être assignées statiquement ou dynamiquement.
Les adresse multicast dynamiques sont utilisées au travers d'application à la demande.
Les adresse statiques sont assignées par l'IANA et sont permanentes.
Ces adresses sont appelées "permanent host groups" et doivent être considérés comme des ports sous TCP/UDP.
Quelques adresse réservées :

DVMRP = Distance Vector Multicast Routing Protocol
OSPF = Open Shortest Path First
RIP2 = Routing Information Protocol
PIM = Protocol Independent Multicast
! ping 224.0.0.1 pour connaître tous les hosts multicast

1.2.            Le mapping IP multicast et Ethernet

Ethernet dispose d'une adresse Mac de 48 bits.
IP dispose d'une adresse de 32 bits.
Pour ne pas avoir à invoquer arp (mode broadcast) pour réaliser la concordance d'adresses entre IP et Mac, IANA a désigné une tranche d'adresse Ethernet réservées aux seules fins du mapping multicast.
Les 23 bits les moins significatifs (lower, ou ceux de droite)

2.      IGMP

IGMP (Internet Group Management Protocol) permet de contrôler automatiquement le flux multicast.
IGMP V1 = RFC 1112
IGMP V2 = RFC 2236
IGMP traite le flux multicast au travers du réseau à l'aide de requêteurs (querier) et de hosts.
Le requêteur est un périphérique réseau capable d'émettre des requêtes, comme un routeur.
Un ensemble de requêteurs et de hosts qui reçoivent un flot multicast depuis la même source, forment un groupe.
Les requêteurs et les hosts utilisent des messages IGMP pour joindre et quitter un groupe.
IGMP supporte 2 structures de messages :
Les "query messages" qui sont utilisés pour connaître parmi les devices réseau, lesquels sont membres d'un groupe multicast donné.
Les "report message" sont envoyés par les hosts en réponse aux query messages pour informer les requêteurs de quel groupe les hosts appartiennent ainsi que pour l'initial join group message.
Dans le modèle multicast il n'y a pas de notion de membre entre une source et les receveurs. Une source ne doit pas appartenir à un groupe pour envoyer le trafic à ce groupe.
Par contre les receveurs informent les routeurs des groupes auxquels ils veulent appartenir.

2.1.            IGMP V1

L'en-tête est formé à partir d'une en-tête IP de 20 bytes ainsi que d'une en-tête IGMP de 8 bytes : 

ver :                 1
type :               1 pour host membership query
                        2 pour hosts membership report
group address :  multicast group adress
Le spécificités de IGMP V1 précise qu'un routeur multicast par lan doit périodiquement envoyer des messages "host membership query" pour déterminer quel groupe de hosts ont des membres pour les queriers directement rattachés.
Les messages IGMP query sont adressés au groupe de tous les hosts –224.0.0.1- et ont un TTL à 1.
Le TTL de 1 assure que le routeur ne peut transmettre ce message au-delà du réseau-local.
Le champ protocol de IP est égal à 2 lorsqu'il s'agit d'un message IGMP 

2.2.            Joindre un groupe

Les hosts qui veulent joindre un groupe n'ont pas besoin d'attendre un query pour le faire.
Quand un host veut joindre un groupe multicast, le host envoie un "host membership report" à l'adresse du groupe multicast qu'il veut joindre.

2.3.            General queries

les routeurs multicast envoie des messages "host membership query" pour découvrir quels sont les groupes de hosts qui ont des membres attachés sur le réseau. Les messages "general queries" sont destinés à tous les hosts (224.0.0.1) avec TTL=1.
Un membre pour chaque groupe du segment va répondre avec un report.
Les "general queries" sont envoyés périodiquement sur base de la valeur de ip igmp query-interval.
Il n'existe pas d'élection de routeur sous IGMPV1.
Cependant le processus d'élection est confié aux protocoles de routage multicast et différents protocoles utilisent différents mécanismes. Le résultat est de retrouver de multiples query sur un segment supportant de multiples routeurs multicast.

2.4.            Maintenir un groupe

Le routeur envoie des queries périodiques.
Un seul membre par groupe et par subnet répond. Ce process se nomme response suppression permet de préserver de la bande-passante sur le réseau. En fait le membre qui prend la responsabilité de répondre, envoi des messages reports au travers d'un timer initialisé avec le routeur pour monter que le groupe est encore actif.
Les autres membres suppriment les reports.

2.5.            Quitter un groupe

Les routeurs envoient des queries périodiques.
Le host quitte le groupe silencieusement.
Le routeur continue d'envoyer des queries périodiques.
Si le routeur ne reçoit aucun reports, le group tombe en time out

3.      IGMP V2

Les principales différences entre v1 et v2 portent sur le process qui sert à joindre et quitter le groupe.

IGMP V2 supporte

•  De multiples types de messages
•  Un maximum response time (10 sec. par défaut)
•  Un groupe d'adresses multicast (0.0.0.0 pour les queries généraux)

IGMP V2 apporte des améliorations par rapport à IGMP V1, la définition d'un groupe query spécifique.
Ce type de messages permet au routeur de transmettre un query spécifique à un groupe spécifique.
IGMP V2 un message pour quitter le groupe, le leave group message.
Il existe désormais 4 types de messages qui concernent la relation host/router :

•  Membership query
•  Version membership report
•  Leave report
•  Version 1 membership report

La prise en compte des reports V1 permet d'assurer une compatibilité montante.
Tous les routeurs écoutent les queries multicast. Si le query provient d'un routeur dont l'adresse IP est plus petite, il cesse d'émettre de queries. Si le routeur qui écoute les queries, entend un query d'une adresse IP plus grande, il devient le Designated Querier.

3.1.            Joindre un groupe

Le process est identique à V1.
Les hosts désireux de joindre un groupe n'ont pas besoin d'attendre un query pour le faire, il envoie simplement un "hosts membership report" au groupe d'adresse qu'il veut joindre.
Si le host et le serveur résident dans des subnets différents, le "join message" doit passer par le routeur.
Quand le routeur intercepte ce type de message, il regarde sa table IGMP. Si le network number n'est pas dans la table, le routeur ajoute l'information contenant l'IGMP message.
Un routeur multicast construit sa propre table à partir de reports et de queries. Cette table détaille les interfaces qui possèdent un ou plusieurs hosts dans des groupes multicast.
Quand un routeur reçoit un datagramme à destination d'un groupe multicast, il ne l'envoie que sur les interfaces intéressées, c'est à dire celles qui possède une liste de hosts appartenant au groupe.

Dans cet exemple le groupe 224.1.1.1 est actif depuis 6 jours et 17 heures sur l'interface Ethernet 0.
Les entrées vont expirer et seront effacées de la table dans 2 minutes. et 31 secondes si aucun hosts memebership n'envoie de report dans ce laps de temps.
Le dernier host à envoyer des reports est 172.16.41.2

3.2.            Querier election

IGMP V2 définit une procédure pour l'élection d'un multicast querier.
Il existe un multicast querier pour chaque segment.
Le routeur du segment possédant la plus petite adresse IP est élu multicast querier.
Initialement chaque routeur du segment pense qu'il est le querier et transmet donc des queries. Si un routeur détecte un message query d'un routeur possédant une adresse IP inférieure, le routeur cesse de se considérer comme un querier.
Le "query-interval response time" est le temps de réponse d'un membre.
Un "group specific query" a été rajouté pour qu'un routeur puisse envoyer des queries  à un seul groupe et non à tous (general query : 224.0.0.1).
Pour localiser le querier :
router> show igmp interface e0
Ethernet is up, line protocol is up
            Internet address is 172.16.41.141, subnet mask is 255.255.255.0
            IGMP is enabled on interface
            Current IGMP version 2
            CGMP is disabled on interface
            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 designated router (DR) is 172.16.41.141 (this system)
            IGMP querying router is 172.16.41.141 (this system)
            Multicast groups joined : 224.0.1.40 224.2.127.254

3.3.            Maintenir un groupe

A la façon d'un IGMP V1, les routeurs multicastent des membership queries à tous les hosts (224.0.0.1).
Seul un membre par segment répond avec un report. Tous les autres membres du groupe suppriment leurs membership reports.
Quand le host reçoit un general query, il démarre un compteur pour chaque groupe, en excluant le groupe "tout le monde"

3.4.            Quitter le groupe

Dans IGMP V2 il existe un message spécifique pour les hosts qui veulent quitter le groupe. Ce message est envoyé à tous les routeurs du groupe 224.0.0.2 avec dans le group field l'indiction du groupe que le hosts veut quitter.
Quand un host fait parvenir au routeur un message indiquant qu'il souhaite quitter le groupe, ce dernier un specific query depuis son interface qui vient de recevoir le message afin de découvrir si il reste des membres du groupe sur ce segment.
Si aucun report n'est reçu en réponse, le routeur décrète que le groupe a pris fin.

4.      CGMP

Dans le cas d'un trafic multicast, le switch forward le trafic sur l'ensemble de ses ports.
IGMP snooping : le switch écoute les reports et les queries et se constitue une table pour le multicast.
CGMP pour Cisco Group Management Protocol est plus simple a mettre en œuvre que IGMP snooping.
Le contrôle du multicast dans l'environnement L2 peut s'effectuer de 2 manières :

•  Par les vlans qui peuvent être définis pour correspondre au adresse multicast (des groupes). L'inconvénient de cette méthode est quelle ne supporte pas une assignation dynamique des adresses.
•  Le layer 2 switching peut utiliser les queries et reports snoop IGMP pour connaître les ports mappés sur des groupes multicast. Cependant le snooping de l'ensemble des données multicast représente une charge énorme pour le switch.

Le rôle traditionnel d'un routeur en tant que point de contrôle dans le réseau peut être conservé en définissant un routeur multicast to switch protocol. CGMP permet au routeur de configurer la table multicast du switch pour correspondre avec l'appartenance à un groupe.
Quand le routeur et le switch sont configurés pour fonctionner sous CGMP, le routeur informe le switch du
USA Mac-address du host +GDA

 

CGMP fonctionne sur un mode client-serveur où le serveur est le routeur et le client est le switch.
Le routeur voit tous les paquets IGMP puis informe le switch lorsqu'un host spécifique désire joindre ou quitter un groupe.
Quand le routeur voit un IGMP control packet, il créé un paquet CGMP. Le paquet CGMP contient le type de requête, le groupe multicast et la Mac-address du client. Le paquet est envoyé sur la well-known address des switches. De ce fait le switch connaît la mac-address associé au port. Ainsi seul le port concerné transférera le streaming multicast.

4.1.            Le routage du trafic multicast

Pour une transmission optimisée, les routeurs construisent un arbre qui connecte tous les membres d'un groupe multicast, le "distribution tree". Le distribution tree spécifie un chemin unique entre le subnet de la source et chaque subnet contenant un membre du groupe.

2 techniques sont utilisées pour construire l'arbre de distribution :

•  source : un arbre de distribution par source et par groupe.
•  shared : un arbre commun par groupe et pour plusieurs sources. Elle utilise le sparse mode et économise la BW.

Dans les 2 cas les routeurs utilisent leur table de routage unicast.

4.1.1.        Source distribution Tree

Source distribution Tree cherche à construir un arbre multicast à partir de chaque source.
Il s'agit de trouver le chemin le plus court entre la source et la réception. La méthode consiste à utiliser un "Called Reverse Path Forwarding" (RPF). Si un paquet provient d'un lien dont le routeur pense qu'il s'agit du chemin le plus court vers la source, le routeur forwarde le paquet sur toutes ses interfaces à l'exception de celle d'où il provient.
L'interface sur laquelle le routeur s'attend à recevoir des paquets multicast d'une source particulière est le lien parent, tandis que les liens utilisés pour la distribution des paquets vers la destination sont les fils.
L'algorithme RPF réduit la duplication inutile de paquets.
Le downstream neighbour est un routeur voisin qui considère que le routeur voisin est plus proche de la source que lui.
RPF cherche donc à déterminer si le routeur voisin est du type downstream sinon il ne lui envoie pas les paquets.

4.1.2.        Shared distribution Tree

Le shared Tree utilise la notion de centre de distribution et construit un arbre multicast en privilégiant un overhead minimum, mais en sacrifiant le délai de bout en bout.
Shared distribution tree construit un arbre unique partagé par toutes les ressources.
L'approche du shared distribution tree est identique à STP à l'exception que shared tree permet la mise en place d'arbres distincts par groupes.
Les devices qui veulent recevoir du trafic multicast doivent explicitement se joindre au shared tree. Le trafic multicast pour le groupe sera envoyé au travers du même arbre.
L'approche shared tree est très efficace du point de vue du routeur, puisque cette technique ne demande au routeur de ne retenir que les infos pour un groupe, et pas de l'ensemble des paires source-destination.
Les protocoles de routage multicast construisent des arbres de distribution en examinant des tables de routage  par le biais de protocoles unicast (PIM) ou en construisant leur propre table (DVMRP)

4.1.3.        La gestion du scope multicast

La gestion du scope se fait sur base du TTL.
Chaque routeur multicast dispose d'un seuil pour chaque interface. Les paquets avec un TTL supérieur au seuil de l'interface sont forwardés, les autres sont détruits.
les valeurs de threshold :

5.      Les protocoles de routage Multicast

Le protocole de routage multicast est responsable de la confection de l'arbre de distribution multicast.

5.1.1.        Dense-mode routing protocol

La 1° approche est basée sur le fait que les membres d'un groupe multicast sont distribués de manière dense sur tout le réseau, disposant d'une bande-passante dense,.
Les protocoles dense-mode sont :

•  DVMRP
•  MOSPF (Multicast Open Shortest Path First)
•  PIM DM

Dans le mode de fonctionnement DM (Dense-Mode), tous les rouyeurs di réseau ont a distribuer le trafic pour chacun des groupes multicast.
DM est approprié pour une infrastructure dont le réseau est capable d'absorber du flux multicast et dont les serveurs sont positionnées en fonction.

5.1.2.        DVMRP

Distance Vector Multicast Routing Protocol est utilsé au travers du MBONE, le Multicast backBONE.
DVMRP utilise le reverse path flooding.
Quand un routeur reçoit un paquet, il le renvoie sur toutes ses interfaces hormis celle sur laquelle le paquet a été reçu. Cette technique permet à un stream d’atteindre tous les LAN. Si le routeur est attaché à un LAN qui ne désire pas recevoir un groupe multicast, le routeur peut renvoyer un "prune message" à l'arbre de distribution afin que stoppe l'envoi de paquets.
DVMRP floode périodiquement des paquets afin de joindre d'éventuels nouveaux hosts qui souhaiteraient devenir membre d'un groupe. Il existe une relation directe entre le temps que met un nouveau receiver à recevoir un stream et la fréquence du flooding.
DVMRP implémente son propre protocole de routage unicast pour savoir quelles sont les interfaces en relation avec la source d'émission. Ce protocole est très proche de RIP et se base sur les "hop count", la limitation est de 32 hops. Le chemin trouvé pour le flux multicast peut être différent du chemin unicast.
Note : les routeurs Cisco utilisent PIM, ils connaissent DVMRP pour envoyer et recevoir du trafic issu de DVMRP.
Les routeurs Cisco peuvent propager DVMRP au travers d'un nuage PIM.

5.1.3.        MOSPF

MOSPF utilise des link-state advertisements pour construire l'arbre de distribution.
Les arbres sont recalculés quand arrive un "link-state change".
MOSPF est dépendant de OSPF comme support de protocole unicast. Dans un réseau OSPF/MOSPF, chaque routeur maintient une image à jour de la topologie de l'ensemble du réseau.
MOSPF inclue des informations multicast dans les link-state advertisements. Un routeur MOSPF apprend quels sont les groupes actifs sur le réseau.
Les link-state information servent à construire l'arbre de distribution pour chaque paire (source/group) et calcule
MOSPF convient aux environnements qui ont peu de paires (souce/group) actives en même temps.

5.1.4.        PIM DM

Protocol Independant Multicast Dense Mode.
PIM ressemble a DVMRP. Ce protocole fonctionne bien quand il y a un grand nombre de membres qui appartiennent à chaques groupes multimedia.
PIM envoie (floode) les paquets multimedia sur chaque routeur du réseau puis supprime les routeurs qui ne sont pas membres d'un groupe.
PIM Dense mode est utile quand :

•  Emetteur et receveurs sont proches les uns des autres.
•  On trouve peu d'émetteurs et beaucoup de receveurs.
•  Le volume du trafic multicast est élevé.
•  Le flux multicast est constant.
•  PIM peut être utilisé conjointement avec tous les protocoles de routage unicast.

5.1.5.        Sparse-mode

La seconde approche est de dire que les membres des groupes multicast sont disséminés sur le réseau et que la bande-passante est limitée.
Le sparse-mode ne sous-entend pas qu'il y a moins de receveurs.
Du fait de l'éloignement des membres, la technique de construction et de maintient de l'arbre de distribution est plus difficile.
Les protocoles de routage sparse-mode incluent :

•  Les Core-based Trees (CBT)
•  Protocol Independant Multicast Sparse Mode (PIM SM)

Le Sparse Mode part du principe qu'on dispose de peu de routeurs dans le réseau.
Dans le sparse-mode, une interface ne forwarde pas explicitement du trafic, elle n'est pas placée d'emblée dans la table de routage (mroute), jusqu'à ce que cette interface ne fsse partie de l'arbre après avoir reçu un message explicite "join massage" depuis un host ou un routeur PIM. Les exceptions sont :

•  la détection d'un routeur DVMRP
•  Sur un segment occupé par plusieurs routeurs, le designated router possède toutes ses interfaces actives

5.1.6.        Core-Based Tree

CBT construit un arbre simple partagé par l'ensemble des membres du groupe.
CBT utilise un core router pour construire l'arbre de distribution partagé.
Les routeurs qui veulent se joindre a l'arbre envoie des messages au core router. Quand le core router reçoit une "join request" il retourne un acqusé de réception sur le chemin inverse, formant par là même une branche de l'arbre.

5.1.7.        PIM SM

PIM SM est optimisé pour des environnements dans lesquels on trouve de nombreux flux multipoints :
Peu d receveurs dans un groupe
Le trafic est intermitent
En SM chaque data stream et destiné à un faible nombre de segments.
Pour déterminer quels sont les demandeurs d'un groupe, on met en place un "rendezvous point".
Le "rendez-vous Point" est la racine d'un arbre de distribution shared.
Quand un émetteur veut envoyer du trafic, il commence par prendre contact avec le "rendezvous point".
Quand un receveur veut recevoir du trafic, il s'annonce auprès du "rendezvous point".
Quand le flot de data arrive de l'émetteur au rendezvous point, il est renvoyé vers le receveur. Les routeurs optimisent le chemin en retirant tous les hops inutiles.
PIM est capable de supporter dens mode pour certains groupes multicast et sparse mode pour d'autres.

6.      La configuration du multicast

6.1.            La planification du multicast

Quelques figures imposées :
Serveurs et clients doivent posséder un stack multicast, windows sockets V1.1 et V2.0 supportent le multicast.
Serveur et client doivent disposer d'applications multimédia
Les cartes réseau sont configurées pour comprendre les paquets multicast et peuvent disposer de fonctons avancées telle que le filtrage de groupes non utilisés pour restreindre les interruptions CPU.
Un backbone très performant switché de type L2 et L3
Les switches L2 doivent disposer de fonctions inhérentes au multicasting afin de transmettre le flux uniquement où cela est nécessaire.

Les opérations à réaliser pour une configuration du multicast

•  Autoriser l'IP multicast routing
•  Démarrer PIM sur une interface
•  Configurer un rendezvous point
•  Configurer le TTL threshold
•  Joindre un groupe multicast
•  Changer la version d'IGMP
•  Autoriser IGMP

 Router(config)# ip multicast routing

6.2.            Dense Mode

Une interface peut être configurée pur tourner en :

•  dense mode
•  sparse mode
•  sparse-dense mode

Le mode détermine comment le routeur peuple sa table multicast et comment le routeur transmet ses paquets multicast directement sur les réseaux connectés.
En dense mode on part du principe que tous les routeurs veulent envoyer du trafic multicast à un groupe.
Si un routeur reçoit du multicast et qu'il ne possède pas de membres directement connectés ni la présence de voisins PIM, un message prune est renvoyé à la source. Les paquets suivants concernant ce flot ne sont plus envoyés.
Les interfaces en dense mode sont toujours rajoutées à la table de routage.
Tous les routeurs multicast maintiennent une liste de sortie (outgoing interface list ou oilist)
Une interface est placée dans cette liste si l'une des conditions suivantes est respectées :

•  Un voisin PIM a été entendu sur cette interface.
•  Un host servi par cette interface s'est join à un groupe.
•  L'interface a étébmanuellement configurée pour être membre d'un groupe.

 En Sparse mode on part du principe que les routeurs ne veulent pas envoyer du trafic pour un groupe multicast jusqu'à ce qu'une requête explicite soit émise.
Des RP (Rendezvous Point) sont utilisés par les envoyeurs pour s'annoncer et par les récepteurs pour connaître les nouveaux envoyeurs.

6.3.            La configuration d'une interface PIM

router(config-if)# ip pim {dens-mode|sparse-mode|sparse-dense-mode}
PIM se configure par interface et peu jouer en sparse et/ou en dense mode.

•  dense-mode quand tous les routeurs ont besoin de disstribuer du trafic multicast pour chaque groupe multicast
•  sparse-mode quand peu de routeurs vont avoir besoin d distribuer du trafic multicast
•  sparse-dense-mode quand l'interface utilise le mode dans lequel opère le groupe. Quand aucun rendezvous point n'est détecté l'interface passe en dense mode.

router(config-if)# no ip pim
router(config-if)# show ip pim
La sélection d'un"Designated Router"
Les queries PIM sont du type multicast à l'ensemble des routeurs (224.0.0.2).
2 routeurs PIM sont voisins si il existe une connexion directe entre eux.
Chaque routeur est configuré pour connaître ses interfaces qui utilisent PIM. Ces interfaces connectent soit des routeurs PIM voisins, soit des hosts.
Le DR est le routeur qui possède l'adresse IP la plus haute. Si le DR n'opère plus, une nouvelle election a lieu.
Seul le DR est abilité à transmettre du flux multicast.
Un DR PIM agît comme un DR IGMPV1.
Le DR a la responsabilité d'envoyer des IGMP host queries messages à l'ensemble des hosts du LAN.
On peut trouver plusieurs DR, 1 pour chaque subnet leaf de l'arbre de distribution.
router> show ip pim neighbor

6.3.1.        La configuration du Rendezvous Point (RP)

router(config-if)# ip pim rp-address 172.16.31.116
L'adresse des RP doit être configurée sur des "leaf routers", près des serveurs , près des clients.
Les "leaf-routers" sont les routeurs directement connectés aux groupes multicast ou à une source de messages multicast.
Un groupe peut posséder plus d'un RP. Un routeur peut être RP pour plus d'un groupe.

6.3.2.        Auto-RP

Il ne s'agit pas d'une nouvelle marque de voitures américaines fortement gualbées aux courbes généreuses et au confort sans communes mesures avec leur nourirture.
Auto-RP est un protocole Cisco pour automatiser la distribution de groupes de RP dans un réseau qui tourne en mode sparse PIM.
Un "RP mapping agent" est assigné aux routeurs qui sont suceptibles de devenir des RP (sélection manuelle au préalable des routeurs potentiels RP).
Le rôle du mapping agent est d'envoyer à tous les DR l'adresse du Rendezvous Point.
Les candidats RP envoient des messages d'annoncement sur une adresse multicast réservée à Cisco 224.0.1.39 (cisco-rp-announce).
Les agents mapping renvoient sur 224.0.1.40 (cisco-rp-discovery) des discovery messages. Les routeurs DR PIM écoutent ces messages pour déterminer quel RP utiliser.
router(config)# ip pim send-rp-announce type number scope ttl group-list access-list-number
Par défaut un routeur n'est pas configuré en tant bque PIM RP mapping agent.
router(config)# ip pim send-rp-discovery scope ttl
Le TTL threshold sert à contrôler si les paquets multicast peuvent passer l'interface.
On fixe un seuil sur l'interface, si le TTL du paquet qui arrive est égal ou inférieur, le paquet est détruit.
Si le paquet est envoyé, celui-ci est diminué de 1 évidemment.
Le but est de fixer le contrôle de la valeur TTL sur les routeurs de périphérie.
router(config-if)# ip multicast ttl-threshold ttl
router>show ip pim neighbor
router>show ip mroute

6.4.            Amélioration du RP

Router(config-if)# ip igmp join-group group_address
Quand on fait adhérer volontairement un routeur à un groupe multicast, le routeur répond aux commandes ICMP et peut participer au trace route.
! Dans un environnement mixte IGMP V1 et V2, les routeurs ne détectent pas automatiquemnt les versions de IGMP. On peut changer de version dans le cas d hosts qui ne suportent que IGMP V1 et n’assurent pas de leave messages pour quitter le groupe.
Router(config-if)#ip igmp version 1
! IGMP V2 par défaut sur les routeurs.
L’activation de CGMP sur le routeur et le switch :
Router(config-if)#ip cgmp
Switch(enable) set cgmp enable
Switch(enable) set cgmp leave enable à pour comprendre les fonctions IGMP V2 permettant de quitter un groupe et d’élaguer le port.
Switch(enable) show cgmp statistics 41