infra / reseaux-tcp-ip
Multicast
Explication
Ce que vous allez apprendre
- Distinguer unicast, broadcast et multicast et savoir quand chacun est pertinent
- Reconnaître les plages d'adresses multicast réservées, en IPv4 comme en IPv6
- Comprendre le rôle d'IGMP (abonnement) et de PIM (routage entre réseaux) dans le multicast
- Comprendre le rôle du TTL multicast pour contrôler la portée de diffusion d'un flux
- Reconnaître mDNS comme l'usage multicast le plus courant au quotidien (découverte de service)
Dans quel contexte ?
Un technicien réseau d'entreprise doit diffuser un flux vidéo de formation en direct vers 200 postes simultanément, sans saturer le réseau. Envoyer 200 flux individuels par unicast consommerait une bande passante considérable. En configurant le flux en multicast, un seul flux est émis, et ce sont les routeurs intermédiaires (via PIM) qui le dupliquent uniquement là où des postes se sont abonnés — une économie de bande passante déterminante à cette échelle.
Trois façons d'envoyer un message sur un réseau
Envoyer des données à un seul destinataire précis (unicast) est le cas le plus courant. Envoyer à absolument tout le monde sur le segment local (broadcast) est brutal et ne passe pas les frontières de réseau. Le multicast propose une troisième voie, plus fine : envoyer une seule fois vers un "groupe" d'abonnés volontaires, quelle que soit leur position sur le réseau — sans dupliquer les données pour chaque destinataire, et sans déranger ceux qui ne sont pas intéressés.
| Mode d'envoi | Destinataires | Passe les routeurs ? |
|---|---|---|
| Unicast | Un seul récepteur | Oui |
| Broadcast | Tous les hôtes du segment local | Non (bloqué par les routeurs) |
| Multicast | Un groupe d'abonnés volontaires | Oui, via PIM |
Prérequis
Il est utile d'avoir déjà vu les notions d'adressage IP (leçon 2) et de routage (leçon 7) : le multicast réutilise ces mêmes bases, appliquées à des plages d'adresses réservées (224.0.0.0/4 en IPv4).
Pourquoi c'est plus efficace qu'envoyer individuellement à chacun
Si mille personnes regardent le même flux vidéo en direct, envoyer mille copies identiques (une par unicast) gaspille énormément de bande passante. Avec le multicast, l'émetteur envoie une seule fois, et ce sont les routeurs intermédiaires qui dupliquent le flux uniquement là où existent des abonnés — jamais plus loin que nécessaire.
Comment un hôte "s'abonne" à un groupe
IGMP (Internet Group Management Protocol) est le mécanisme par lequel une machine annonce localement "je veux recevoir le trafic destiné à ce groupe". Pour que ce flux traverse plusieurs réseaux, un protocole de routage dédié (PIM) prend le relais entre routeurs, en s'assurant de ne transmettre le flux que sur les chemins qui mènent réellement à des abonnés actifs — évitant d'inonder inutilement tout le réseau.
Un usage multicast que vous avez probablement déjà croisé
mDNS (multicast DNS, utilisé par Bonjour/Avahi) est l'exemple le plus fréquent au quotidien : c'est ce qui permet à un ordinateur de découvrir automatiquement une imprimante réseau ou un autre appareil sur le même réseau local, sans serveur DNS central — chaque appareil répond directement à une requête envoyée au groupe multicast local.
Commandes & code
Multicast
# Unicast : un émetteur -> un récepteur
# Broadcast : un émetteur -> TOUS les hôtes du segment (IPv4 uniquement, IPv6 ne l'a pas)
# Multicast : un émetteur -> UN GROUPE d'abonnés volontaires, quelle que soit leur position réseau
# Plage d'adresses IPv4 multicast réservée : 224.0.0.0/4
224.0.0.0 à 224.0.0.255 # réservé au trafic de contrôle local (protocoles de routage, etc.)
224.0.1.0 à 238.255.255.255 # multicast "global", routable inter-réseaux
239.0.0.0 à 239.255.255.255 # portée administrative (usage privé, comme les IP RFC1918)
# En IPv6 : le multicast remplace ENTIÈREMENT le broadcast
ff02::1 # tous les nœuds du lien local
ff02::2 # tous les routeurs du lien local# --- IGMP (Internet Group Management Protocol) : un hôte "s'abonne" à un groupe multicast ---
ip maddr show # groupes multicast auxquels la machine est abonnée (couche 2/3)
# S'abonner à un groupe multicast et écouter le trafic reçu (test avec socat)
socat UDP4-RECVFROM:5000,ip-add-membership=239.1.1.1:eth0,fork -
# Émettre du trafic multicast vers ce groupe (depuis une autre machine)
echo "message de test" | socat - UDP4-DATAGRAM:239.1.1.1:5000,ip-multicast-ttl=1
# --- TTL multicast : contrôle la portée de propagation, pas juste la durée de vie du paquet ---
# TTL 0 -> reste sur la machine émettrice uniquement
# TTL 1 -> limité au segment local (défaut le plus courant)
# TTL 32 -> limité au site/organisation
# TTL 255 -> non restreint (traverse tous les routeurs qui le permettent)
# --- PIM (Protocol Independent Multicast) : routage multicast ENTRE réseaux ---
# PIM-SM (Sparse Mode) : le routeur ne transmet le flux QUE là où il y a des abonnés actifs
# (le mode par défaut en pratique — évite d'inonder tout le réseau par défaut)
# Vérifier le support multicast d'une interface et son état IGMP
ip link show eth0 | grep -i multicast
cat /proc/net/igmp # groupes IGMP actifs vus par le noyau# --- Cas d'usage réels du multicast ---
# - Diffusion vidéo IPTV en entreprise/opérateur (un flux, des milliers de récepteurs)
# - Découverte de service : mDNS (224.0.0.251, port 5353) -> Bonjour/Avahi, imprimantes réseau
# - Protocoles de routage eux-mêmes : OSPF utilise 224.0.0.5/224.0.0.6 pour ses annonces
# - Synchronisation de cluster bas niveau (heartbeat, élection de leader dans certains systèmes)# Débogage mDNS (Bonjour/Avahi) très présent sur les réseaux locaux modernes
avahi-browse -a # liste tous les services mDNS découverts sur le LAN
avahi-resolve -n imprimante.local # résout un nom .local via mDNS
# Capture du trafic multicast avec tcpdump
sudo tcpdump -i eth0 -n 'dst net 224.0.0.0/4'
sudo tcpdump -i eth0 -n port 5353 # spécifiquement le trafic mDNSRésumé
- Le multicast (
224.0.0.0/4en IPv4,ff00::/8en IPv6) diffuse à un groupe d'abonnés volontaires, ni un seul hôte ni tout le segment. - IGMP gère l'abonnement d'un hôte à un groupe ; PIM route le flux multicast entre réseaux en ne l'envoyant que là où il y a des abonnés.
- mDNS (port 5353) est l'usage multicast le plus rencontré au quotidien : découverte de service sur un LAN, sans serveur DNS central.
Exercices pratiques
Mission : diagnostiquer un flux vidéo multicast qui ne franchit pas les sites
Objectif : Expliquer pourquoi un flux multicast peut fonctionner localement mais pas entre réseaux, en combinant portée TTL, IGMP et PIM.
Contexte
Une entreprise diffuse un flux de formation en multicast vers 200 postes via l'adresse 239.1.1.1 avec un TTL de 32. Le flux fonctionne parfaitement sur le site principal, mais un site distant relié par VPN, où un administrateur a désactivé PIM sur les routeurs intermédiaires (en laissant IGMP actif localement), ne reçoit rien.