Le multicast

Le multicast, ou multidiffusion, permet la diffusion vers plusieurs partenaires sur un réseau. Ces partenaires ont, en plus de leur adresse IP de classe A, B ou C (adresse privée), une adresse de multicast : l'adresse de groupe. Cette adresse est de classe D, c'est à dire qu'elle se trouve dans la plage allant de 224.0.0.0 jusqu'à 239.255.255.255.

Lorsqu'une application s'adresse à une adresse de groupe, tous les éléments du réseau (ordinateur, imprimante, switch managable, routeur, etc.) qui font partie de ce groupe réceptionne la trame TCP/IP.

Pour simplifier on peut dire que le multicast est un broadcast sélectif.

On parle de multicast statique lorsque, dans un même réseau, on définit une adresse de groupe pour atteindre certains éléments du réseau.
C'est à dire que les différents éléments du réseau sont configurés pour accepter des trames TCP/IP adressées à une adresse de groupe.

On peut imaginer, par exemple, un cluster de PC au sein d'un réseau. Pour la communication entre ces PC, sachant que le nombre de PC pourrait être amené à varier, le plus simple est de définir une adresse unique à laquelle tous les PC du cluster répondent : une adresse de groupe ⇒ le multicast est né.
Le fait de n'avoir qu'une seule adresse permet de ne pas avoir à gérer la liste des adresses IP de tous les PC du cluster. Il suffit qu'un PC fasse partie du groupe multicast pour faire partie du cluster.
En parlant de cluster, le multicast est utilisable pour heartbeat

Le noyau Linux que vous utilisez doit être compilé avec l'option CONFIG_IP_MULTICAST activée. pour le vérifier :

cat /boot/config-`uname -r` | grep CONFIG_IP_MULTICAST

CONFIG_IP_MULTICAST=y

Si CONFIG_IP_MULTICAST=n, vous devez recompiler votre noyau en activant cette option ou en installer une version avec cette option activée.

Par défaut Ubuntu est configuré de sorte de ne pas activer les fonctions multicast. Pour vérifier cela :

sysctl net.ipv4.icmp_echo_ignore_broadcasts

net.ipv4.icmp_echo_ignore_broadcasts = 1

Les fonctionnalités multicast sont déactivées.
Pour les activer :

sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

net.ipv4.icmp_echo_ignore_broadcasts = 0

Vérifions que le multicast est fonctionnel :

ping 224.0.0.1 -c 3

PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 192.168.1.141: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=1.94 ms (DUP!)
64 bytes from 192.168.1.141: icmp_seq=2 ttl=64 time=0.025 ms
64 bytes from 192.168.1.200: icmp_seq=2 ttl=64 time=1.76 ms (DUP!)
64 bytes from 192.168.1.141: icmp_seq=3 ttl=64 time=0.024 ms

--- 224.0.0.1 ping statistics ---
3 packets transmitted, 3 received, +2 duplicates, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.024/0.760/1.949/0.898 ms

→ Explications : l'adresse IP 224.0.0.1 est une adresse pour atteindre tous les partenaires du réseau qui "savent faire" du multicast.
l'adresse IP de mon PC est 192.168.1.141, mon PC répond. Mais l'adresse 192.168.1.200 répond aussi au ping, c'est mon routeur ADSL, il "sait faire" du multicast et donc il répond à l'adresse 224.0.0.1 lui aussi.

Pour faire en sorte que cette modification reste même après un redémarrage, il faut éditer le fichier /etc/sysctl.conf et remplacer

# Ignore ICMP broadcasts
#net.ipv4.icmp_echo_ignore_broadcasts = 1

par

# Ignore ICMP broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 0

Pour rejoindre (Join) l'adresse de groupe 239.0.0.10 :

sudo smcroute -j eth0 239.0.0.10

Pour quiter (Leave) l'adresse de groupe 239.0.0.10 :

sudo smcroute -l eth0 239.0.0.10

Pour l'exemple, j'ai utilisé une machine virtuelle dans VMware-player qui est membre de l'adresse de groupe 239.0.0.10. J'ai fait en sorte que la carte virtuelle vmnet8 qui relie mon PC au PC virtuel dans VMware-player rejoigne la même adresse de groupe, puis j'ai "pinger" cette adresse pour vérifier.
Avant l'opération, seul le PC virtuel répond au ping. Puis mon PC rejoint l'adresse de groupe. Et enfin les 2 PC répondent au ping.

ping 239.0.0.10 -c 3 -I vmnet8

PING 239.0.0.10 (239.0.0.10) from 192.168.214.1 vmnet8: 56(84) bytes of data.
64 bytes from 192.168.214.10: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 192.168.214.10: icmp_seq=2 ttl=64 time=0.303 ms
64 bytes from 192.168.214.10: icmp_seq=3 ttl=64 time=0.415 ms

--- 239.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.303/0.440/0.602/0.123 ms

sudo smcroute -j vmnet8 239.0.0.10
ping 239.0.0.10 -c 3 -I vmnet8

PING 239.0.0.10 (239.0.0.10) from 192.168.214.1 vmnet8: 56(84) bytes of data.
64 bytes from 192.168.214.1: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 192.168.214.10: icmp_seq=1 ttl=64 time=0.329 ms (DUP!)
64 bytes from 192.168.214.1: icmp_seq=2 ttl=64 time=0.047 ms
64 bytes from 192.168.214.10: icmp_seq=2 ttl=64 time=0.326 ms (DUP!)
64 bytes from 192.168.214.1: icmp_seq=3 ttl=64 time=0.046 ms

--- 239.0.0.10 ping statistics ---
3 packets transmitted, 3 received, +2 duplicates, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.042/0.158/0.329/0.138 ms

(source)