Linux est, bien sûr (doutez-vous de cela ?), pleinement compatible avec le multicast niveau 2. Il satisfait toutes les exigences liées à l'envoi, à la réception et au routage (grâce à mrouter) des datagrammes multicast.

Si vous désirez émettre et recevoir des paquets IP multicast, vous devez activer l'option « IP: multicasting » lors de la configuration de votre noyau. Si vous désirez aussi que votre Linux agisse tel un routeur multicast, vous aurez alors besoin d'activer le routage multicast du noyau en sélectionnant « IP: forwarding/gatewaying » (transfert/passerelle), « IP: multicast routing » (routage multicast) et « IP: tunneling » (tunnel), cette dernière option est nécessaire car les nouvelles versions de mrouted peuvent aussi retransmettre les paquets au travers de tunnels IP ; les datagrammes IP multicast sont alors encapsulés dans des datagrammes unicast. Il est nécessaire d'établir des tunnels entre des hôtes multicast s'ils sont séparés par un réseau ou par plusieurs routeurs incapables de transférer des datagrammes multicast. (mrouted est un service qui implémente un algorithme de routage multicast -politique de routage- et informe le noyau sur la façon de router les datagrammes multicast.

Certaines versions du noyau considèrent le routage multicast comme étant « EXPERIMENTAL », de ce fait vous devez activer l'option « Prompt for development and/or incomplete code/drivers » dans la section « Code maturity level options ».

Si, durant l'exécution de mrouted, le trafic généré sur le réseau (où est connectée votre station linux) est correctement transféré aux autres réseaux, mais il vous est impossible de « voir » le trafic des autres réseaux sur votre réseau local, vérifiez alors si vous recevez des messages d'erreur du protocole ICMP. Il s'agit d'une erreur due, le plus fréquemment, à la non activation de l'IP tunneling de votre routeur Linux. C'est le genre d'erreur qui paraît stupide lorsque vous la connaissez mais, croyez moi, cela prend beaucoup de temps pour la détecter quand vous l'ignorez, car il n'y a pas de raison apparente signifant la cause de l'erreur. Un renifleur (ou « sniffeur ») s'avère utile dans ce genre de situation.

Vous trouverez plus d'informations dans la section politiques de routage et techniques de retransmission ; mrouted et les tunnels sont aussi expliqués dans la section consacrée à MBone et la section applications multicast.

Une fois votre nouveau noyau compilé et installé, vous devez définir une route par défaut pour votre trafic multicast. Ce qui revient à ajouter une route au réseau 224.0.0.0.

Le problème auquel le plus de personnes font face à ce stade de la configuration est la valeur du masque à appliquer. Si vous avez lu précédemment l'excellent NET-3-HOWTO de Terry Dawson, il ne vous sera pas difficile de trouver la bonne valeur. Comme expliqué, le masque de sous réseau est un nombre codé sur 32 bits rempli avec des « 1 » sur la partie réseau de votre adresse IP, et avec des « 0 » sur la partie hôte. En référence à la section 2.1 une adresse multicast de classe D n'a pas de division réseau/hôte. À la place, il a un groupe d'identification codé sur 28 bits et un identifiant de classe D codé sur 4 bits. Le masque de sous réseau voulu est donc 11110000000000000000000000000000 ou d'une manière plus facilement lisible : 240.0.0.0. De ce fait la commande complète est :

route add 224.0.0.0 netmask 240.0.0.0 dev eth0

Selon la version de votre programme route, il peut être nécessaire d'ajouter l'option -net après l'option add.

Dans l'exemple, nous supposons que l'interface eth0 supporte le multicast et, si rien d'autre n'est spécifié, nous voulons que le trafic multicast sorte par cette interface. Si cela n'est pas votre cas, changez alors le paramètre dev de manière appropriée.

Le système de fichiers /proc s'avère utile une fois encore : il est possible de vérifier dans le fichier /proc/net/igmp les groupes auxquels votre machine est actuellement connectée.