Bonjour,

C'est vendredi, et pourtant je n'ai pas de trop à proposer :)

Il était une fois Linux, le multicast et VXLAN (et un chouia de BGP). Mon
cas de figure est peut-être simplissime à résoudre et je n'ai pas encore lu
la bonne page de manuel à ce propos, donc si au final j'obtiens un RTFM
avec la référence qui va bien, je suis preneur !

Je teste le setup décrit plus bas, et c'est sur la partie multicast que
c'est drôle. La version courte : avec VXLAN (au moins), il semble que
quoique je fasse, le noyau semble envoyer les trames multicast sur toutes
les interfaces réseau, peu importe que j'ai cherché à le désactiver ou pas.
Le trafic étant généré par le noyau et non par un processus qui puisse être
influencé, je sèche après avoir testé quelques pistes.

Je cherche à réduire au maximum la couche L2 au minimum du setup.

Deux machines (et une gw qui n'a pas d'importance), chacune avec eth0 et
eth1, et Bird :
- host1 : eth0 / 192.168.50.5/28, eth1 / 192.168.50.20/28, lo:1 /
192.168.100.2/32
- host2 : eth0 / 192.168.50.6/28, eth1 / 192.168.50.21/28, lo:1 /
192.168.100.3/32
- gw : 192.168.50.1/28, 192.168.50.17/28 et 192.168.100.1/32 et ses propres
uplinks
- du BGP entre tout ce petite monde (Bird sur host1 et host2). gw annonce
la default route, chacun annonce sa loopback et plus tard d'autres routes
- plutôt qu'avoir une redondance en L2 au travers d'un trunk/LAG/portgroup,
ça se passe en L3, rien de transcendant jusque là.
- Ubuntu Xenial (16.04), avec un noyau 4.4.0-47

A présent je veux ajouter du VXLAN sans mettre (pour le moment) de
contrôleur. Avant même de vouloir faire annoncer le VXLAN sur un groupe
multicast depuis la loopback (et profiter de la redondance L3), je commence
par tester le fonctionnement plus simple. Et déjà là, ça coince :

Lorsque je fais ceci :
# ip link add vxlan10 type vxlan id 10 group 239.0.0.10 ttl 4  dstport 4789
dev eth0
# ip link set vxlan10 up

Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis
192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. Idem en configurant
vers eth1 plutôt qu'eth0. Idem en ayant préalablement saisi ces commandes
avant l'ajout de vxlan10 :
# ip link set eth1 multicast off
# ip link set eth1 allmulticast off
# route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0

A noter qu'utiliser "ip link add ... local 192.168.255.2" fonctionne comme
je le le souhaite (ce qui est mon objectif au départ) mais malgré, le
trafic multicast part partout, que je puisse le maîtriser sur une évolution
"d'archi".

Suis-je en mode neuneu ou bien c'est plus subtile ?


-- 
Baptiste Malguy

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à