300 vues

Multicast sur FreeDMR – Mise en oeuvre

Multicast sur FreeDMR – Mise en oeuvre

Nous avons vu dans les précédents articles les principes du Multicast et du réseau de transport. Il est temps de passer à la pratique.

Partie 1 : Le réseau de transport

Commençons par établir le réseau de transport des trames multicast. Pour cela, il faut installer Openvswitch.

apt-get install openvswitch-switch

Pour vérifier que tout s’est bien déroulé, vous devriez, en tapant la commande ovs-vsctl show , obtenir quelque chose comme ceci :

ovs_version: « 2.13.1 »  , selon la version.

On va maintenant créer notre switch virtuel :

ovs-vsctl add-br br0  => Création du bridge

ovs-vsctl set Bridge br0 mcast_snooping_enable=true   => Activation du multicast snooping (ça évite que les trames multicast ne se propagent sur tous les ports d’un switch inutilement

ovs-vsctl set Bridge br0 rstp_enable=true  => Activation du Rapid Spaning Tree Protocol (On évite des boucles intempestives)

Nota : il est important de respecter les dénominations ci-dessus.

Maintenant passons aux définitions des tunnels GRE. Considérons que nous avons dans le réseau 3 serveurs, A, B et C.

Serveur A :

Vers B :

ovs-vsctl add-port br0 A-B  => Ajout du port « A-B » sur le bridge br0. On peut utiliser le nom que l’on souhaite. Mais pour être plus parlant et identifier par la suite de où vers où vont les tunnels, il est préférable d’utiliser par convention <nom_du_serveur_local>-<nom_du_serveur_distant>

ovs-vsctl set Port A-B other_config:rstp-enable=enable other_config:mcast-snooping-flood=true  => Activation du multicast snooping et du RSTP pour ce port

ovs-vsctl set Interface A_B type=gre options:remote_ip=<IP_du_serveur_B> options:local_ip=<IP_du serveur_A> options:key=<XXXX>  => Définition du tunnel VPN de type GRE. On mettra ce que l’on veut pour la clé key, l’essentiel étant que ce soit la même clé sur le serveur B.

Vers C :

On répète les commandes ci-dessus :

ovs-vsctl add-port br0 A-C

ovs-vsctl set Port A-C other_config:rstp-enable=enable other_config:mcast-snooping-flood=true

ovs-vsctl set Interface A-C type=gre options:remote_ip=<IP_du_serveur_C> options:local_ip=<IP_du_serveur_A> options:key=<YYYY>

Il faut maintenant attribuer une adresse IP à notre interface br0. Editons le fichier interfaces :

nano /etc/network/interfaces

et ajoutons ceci :

auto br0

iface br0 inet static

                address 10.0.CCC.DDD

                netmask 255.255.0.0

Par convention, les IP adoptent toutes le même format dans le réseau, pour des raisons de cohérence et éviter des doublons. On remplacera CCC par le MCC du pays dans lequel se trouve le serveur. Si le MCC est supérieur à 254, on trouvera un compromis (exemple pour le Portugal dont le MCC est 268, on a choisi 168). Pour DDD, le choix est libre. Pour des raisons mnémotechniques, en France, on a choisi de mettre les numéros de département (exemple pour les Yvelines : 10.0.208.78).

Un fois le fichier interfaces modifié, on entre la commande suivante :

systemctl restart networking

En tapant la commande « ifconfig », on doit voir notre bridge dans la liste qui s’affiche.

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 10.0.208.78  netmask 255.255.0.0  broadcast 10.0.255.255

        ether fe:ba:ca:4b:8b:49  txqueuelen 1000  (Ethernet)

        RX packets 56630207  bytes 5709470269 (5.7 GB)

        RX errors 0  dropped 1  overruns 0  frame 0

        TX packets 4383774  bytes 501994439 (501.9 MB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Sur la première ligne, on voit UP, RUNNING : Le bridge est présent et actif.

Multicast : le bridge est capable de gérer les trames multicast (cela tombe bien, on veut travailler en Multicast !)

On procède de la même façon pour les serveurs B et C.

Serveur B :

ovs-vsctl add-br br0

ovs-vsctl set Bridge br0 mcast_snooping_enable=true

ovs-vsctl set Bridge br0 rstp_enable=true

ovs-vsctl add-port br0 B-A

ovs-vsctl set Port B-A other_config:rstp-enable=enable other_config:mcast-snooping-flood=true

ovs-vsctl set Interface B-A type=gre options:remote_ip=<IP_du_serveur_A> options:local_ip=<IP_du_serveur_B> options:key=<XXXX>

ovs-vsctl add-port br0 B-C

ovs-vsctl set Port B-C other_config:rstp-enable=enable other_config:mcast-snooping-flood=true

ovs-vsctl set Interface B-C type=gre options:remote_ip=<IP_du_serveur_C> options:local_ip=<IP_du_serveur_B> options:key=<ZZZZ>

Attribuer l’adresse IP du bridge br0 comme nous avons fait pour le serveur A

Serveur C :

ovs-vsctl add-br br0

ovs-vsctl set Bridge br0 mcast_snooping_enable=true

ovs-vsctl set Bridge br0 rstp_enable=true

ovs-vsctl add-port br0 C-A

ovs-vsctl set Port C-A other_config:rstp-enable=enable other_config:mcast-snooping-flood=true

ovs-vsctl set Interface C-A type=gre options:remote_ip=<IP_du_serveur_A> options:local_ip=<IP_du_serveur_C> options:key=<YYYY>

ovs-vsctl add-port br0 C-B

ovs-vsctl set Port C-B other_config:rstp-enable=enable other_config:mcast-snooping-flood=true

ovs-vsctl set Interface C-B type=gre options:remote_ip=<IP_du_serveur_B> options:local_ip=<IP_du_serveur_C> options:key=<ZZZZ>

Enfin, attribuer l’adresse IP du bridge br0 comme nous avons fait pour le serveur A

Sur chaque serveur, on peut verifier les configurations effectuées, avec la commande « ovs-vsctl show », qui doit donner par exemple pour le serveur A :

    Bridge br0

        fail_mode: standalone

        Port A-B

            Interface A-B

                type: gre

                options: {key= »XXXX », local_ip= »<IP_du_serveur_A », remote_ip= »<IP_du_serveur_B »}

        Port A-C

            Interface A-C

                type: gre

                options: {key= »YYYY », local_ip= »<IP_du_serveur_A> », remote_ip= »<IP_du_serveur_C> »}

        Port br0

            Interface br0

                type: internal

    ovs_version: « 2.13.1 »

Pour vérifier que les serveurs communiquent bien ensemble, testons avec ping :

root@test:/# ping 10.0.208.78

PING 10.0.208.78 (10.0.208.78) 56(84) bytes of data.

64 bytes from 10.0.208.78: icmp_seq=1 ttl=64 time=87.4 ms

64 bytes from 10.0.208.78: icmp_seq=2 ttl=64 time=36.8 ms

^C

— 10.0.208.78 ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 1002ms

rtt min/avg/max/mdev = 36.827/62.098/87.369/25.271 ms

Les 3 adresses de notre réseau doivent répondre sans perte de packet.

Nous avons terminé avec la partie setup du réseau de transport Multicast. Le réseau France étant existant, il est très simple de s’y raccorder en contactant le ou les sysops des serveurs avec lesquels on veut établir des tunnels GRE.

Partie 2 : Autres paramétrages du serveur

Installer java, qui sera nécessaire pour faire fonctionner le convertisseur Unicast/Multicast :

apt-get install default-jre

Controller le nom du serveur. Le prompt du serveur ressemble à ceci :

root@vpsxxxxxxx:/un_repertoire/un_autre_repertoire#

ll va falloir personnaliser le nom du serveur, qui est utilisé par le convertisseur. Donner un nom différent, comme par exemple le nom du pays, de la région, de votre animal de compagnie, etc.

Mais en aucun cas ne donner de nom de domaine. On prend par exemple « limousin ».

Editer le fichier hostname :

nano /etc/hostname

Remplacer le nom existant par limousin

Redémarrer le serveur pour prise en compte. Au prompt, on doit avoir :

root@limousin:/un_repertoire/un_autre_repertoire#

Modifier ensuite le fichier hosts :

nano /etc/hosts

On a ceci :

127.0.0.1       localhost

#The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost   ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

ff02::3 ip6-allhosts

etc…

Ajouter en première ligne :

<IP_de_votre_serveur>                <nom_de_votre_serveur>

Dans le cas du limousin, cela donne :

123.456.789.012               limousin

127.0.0.1                             localhost

Autre étape, autoriser le serveur à fonctionner comme un routeur. Pour cela, éditer le fichier sysctl.conf

nano /etc/sysctl.conf

##############################################################3

# Functions previously found in netbase

#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)

# Turn on Source Address Verification in all interfaces to

# prevent some spoofing attacks

net.ipv4.conf.default.rp_filter=0

net.ipv4.conf.all.rp_filter=0

# Uncomment the next line to enable TCP/IP SYN cookies

# See http://lwn.net/Articles/277146/

# Note: This may impact IPv6 TCP sessions too

#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6

#  Enabling this option disables Stateless Address Autoconfiguration

#  based on Router Advertisements for this host

#net.ipv6.conf.all.forwarding=1

……….

Modifier les lignes en rouge  comme indiqué, et sauvegarder le fichier.

Pour prise en compte immédiate, taper la commande :

sysctl -p

Partie 3 : Configuration de FreeDMR

Editer le fichier de configuration hblink.cfg (ou freedmr.cfg). Dans la section des openbridges, insérer ce qui suit :

[OBP-MULTICAST]

MODE: OPENBRIDGE

ENABLED: True

IP :<IP_du_serveur>

PORT: 62997

NETWORK_ID: <l’ID que vous voulez>

PASSPHRASE: PASSWORD

TARGET_IP: 127.0.0.1

TARGET_PORT: 62999

BOTH_SLOTS: True

USE_ACL: True

SUB_ACL: DENY:1

TGID_ACL: PERMIT:ALL

RELAX_CHECKS: True

ENHANCED_OBP: False

Les valeurs ci-dessus doivent être respectées.

Redémarrer le Bridge.

Partie 4 : Le convertisseur Unicast/Multicast

Placer le fichier multicast.jar dans le répertoire de votre choix. Ce fichier peut être obtenu sur simple demande, soit au travers du formulaire de contact du site freedmr.fr, soit par e-mail à f1sca@sfr.fr

Démarrer le convertisseur depuis son répertoire, avec la commande :

java -jar ./multicast.jar &

Vous devriez commencer à recevoir le trafic multicast. Pour vérifier, tapez la commande :

tcpdump -i br0

Vous devriez voir les trames circulant sur le réseau de transport.

Bon trafic.

Pour toute question ou besoin d’aide, utilisez le formulaire ou contactez les sysops des serveurs.

F1SCA Jean-Marc

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *