Bridge réseau sur serveur OVH

Support Debian
#1

Bonjour à tous!

Je souhaite installer LXC sur un serveur avec un bridge réseau pour connecter chaque conteneur.
Pour l’install pas de souci, par-contre c’est au niveau de la configuration du réseau que ca pèche.
J’ai suivit en autre ce tuto wiki.debian.org/fr/LXC/SimpleBridge, mais qu’en est-il de la configuration du bridge pour l’ipv6?

Car après avoir rajouté le bridge br0, je perd la possibilité ipv6.
Je suis sur une jessie 8.3

La conf d’origine

/etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
 iface eth0 inet static
         address 37.187.56.XX
         netmask 255.255.255.0
         network 37.187.56.0
         broadcast 37.187.56.255
         gateway 37.187.56.254

 iface eth0 inet6 static
         address 2001:41d0:b:XX::
         netmask 64
         post-up /sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0
         post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff
         pre-down /sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff
         pre-down /sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0

Le ping v4 et v6 fonctionne

ping6 -c 3 free.fr
PING free.fr(www.free.fr) 56 data bytes
64 bytes from www.free.fr: icmp_seq=1 ttl=57 time=6.91 ms
64 bytes from www.free.fr: icmp_seq=2 ttl=57 time=6.92 ms
64 bytes from www.free.fr: icmp_seq=3 ttl=57 time=6.91 ms


--- free.fr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.912/6.916/6.920/0.096 ms

Après ajout du bridge

# The loopback network interface
auto lo
iface lo inet loopback

auto br0
iface br0 inet static
        address 37.187.56.XX
        netmask 255.255.255.0
        network 37.187.56.0
        broadcast 37.187.56.255
        gateway 37.187.56.254
        bridge_ports eth0
        bridge_fd 0

iface br0 inet6 static
        address 2001:41d0:b:XX::
        netmask 64
        post-up /sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0
        post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0

Le ping v4 fonctionne

# ping -c 2 free.fr 
PING free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=57 time=6.90 ms
64 bytes from www.free.fr (212.27.48.10): icmp_seq=2 ttl=57 time=6.88 ms

--- free.fr ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 6.882/6.893/6.904/0.011 ms

Mais pas le v6

# ping6 -c 3 free.fr 
PING free.fr(www.free.fr) 56 data bytes

--- free.fr ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

Des idées?

Antoine

#2

Ca fait longtemps que je n’ai pas configuré de bridge, et jamais touché à l’ipv6 (je sais, c’est pas bien), mais juste à l’oeil, je dirais qu’en remplaçant eth0 par br0 partout, ça devrait aller mieux. :wink:
[edit: sauf dans la déclaration du bridge_ports, bien sûr]

#3

Merci mattotop pour la suggestion.
J’ai tenté sans succès.

iface br0 inet6 static
        address 2001:41d0:b:XX::
        netmask 64
        post-up /sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev br0
        post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev br0

Pas mieux :frowning:

ping6 -c 3 www.free.fr
PING www.free.fr(www.free.fr) 56 data bytes

--- www.free.fr ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
#4

Donne la sortie de
ip addr ip -6 route

As-tu besoin de mettre eth0 dans le pont ? Cela implique qu’OVH t’a donné des adresses IP publiques pour les conteneurs LXC.

#5

Salut Pascal, merci pour ta réponse.

Voici le résultat des commandes

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 60:a4:4c:42:dd:c4 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 60:a4:4c:42:dd:c4 brd ff:ff:ff:ff:ff:ff
    inet 37.187.56.XX/24 brd 37.187.56.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::62a4:4cff:fe42:XX/64 scope link 
       valid_lft forever preferred_lft forever

# ip -6 route
2001:41d0:b:XX:ff:ff:ff:ff dev eth0  metric 1024 
fe80::/64 dev br0  proto kernel  metric 256 
default via 2001:41d0:b:XX:ff:ff:ff:ff dev eth0  metric 1024

Concernant ta question, ce que je comprend c’est que sans IP Failover ce n’est pas possible?
Au final je voulais que mes conteneurs LXC aient qu’une ipv6 pour y accéder en ssh par exemple et qu’ils passent par le bridge de l’hôte pour accéder au net…mais je ne suis pas sur de moi.

#6

Les changements dans le fichier interfaces n’ont pas été pris en compte : les routes IPv6 sont toujours sur eth0 et br0 n’a pas d’adresse IPv6 globale. Comment as-tu reconfiguré les interfaces après avoir modifié le fichier ? Redémarrage du serveur ?

Une remarque concernant l’adresse 2001:41d0:b:XX:: : c’est l’adresse anycast de routeur réservée pour le préfixe 2001:41d0:b:XX::/64, elle ne devrait pas être configurée en tant qu’adresse unicast.

Le failover n’a rien à voir là-dedans.

Si OVH alloue un préfixe /64 complet à ton serveur (a priori oui vu la façon atypique de configurer l’IPv6), c’est peut-être possible mais je ne sais pas comment OVH route de ce préfixe. Il pourrait être suffisant de faire du routage IPv6 et d’exclure eth0 du pont.

#7

Ok j’ai ajouter le br0 à la conf de l’ipv6 dans le fichier interfaces et j’ai redémarré le serveur

iface br0 inet6 static
        address 2001:41d0:b:04d6::
        netmask 64
        post-up /sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev br0
        post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev br0

C’est un peu mieux mais toujours pas de default route sur br0

# ip -6 route
2001:41d0:b:4d6::/64 dev br0  proto kernel  metric 256 
2001:41d0:b:4ff:ff:ff:ff:ff dev eth0  metric 1024 
fe80::/64 dev br0  proto kernel  metric 256 
default via 2001:41d0:b:4ff:ff:ff:ff:ff dev eth0  metric 1024

J’ai même tenté de rajouter “dev br0” sur à la fin de la ligne “post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff” mais sans succès.
Toujours impossible de contacter des sites en ipv6

# ping6 -c 3 free.fr
PING free.fr(www.free.fr) 56 data bytes

--- free.fr ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
#8

C’est-à-dire ? Peux-tu montrer le contenu actuel complet du fichier interfaces ?
Les routes IPv6 sur eth0 viennent forcément de quelque part, elles n’ont pas pu survivre à un redémarrage complet.

#9

Mon fichier interfaces complet

# The loopback network interface
auto lo
iface lo inet loopback

auto br0
iface br0 inet static
        address 37.187.56.XX
        netmask 255.255.255.0
        network 37.187.56.0
        broadcast 37.187.56.255
        gateway 37.187.56.254
        bridge_ports eth0
        bridge_fd 0

iface br0 inet6 static
        address 2001:41d0:b:04d6::
        netmask 64
        post-up /sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev br0
        post-up /sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev br0
#10

Quelque chose m’échappe, car je ne vois pas comment ce fichier seul peut produire des routes IPv6 sur eth0.
Tu es sûr que le serveur a redémarré (uptime) ?
C’est bien le fichier /etc/network/interfaces, pas une copie placée ailleurs ?

#11

Je te confirme que la machine a bien redémarré et que c’est bien le bon fichier

#12

Pourtant je viens de tester ton fichier, et contrairement à toi j’obtiens le résultat attendu avec toutes les routes sur br0.

#13

aouvrard : Est-ce que tu as pris en compte la remarque de PascalHambourg concernant le fait que l’adresse 2001:41d0:b:04d6:: est une adresse anycast de routeur et qu’elle ne devrait pas être utilisée ?

Tu peux la remplacer par 2001:41d0:b:04d6::1 ou 2001:41d0:b:04d6::1337 ou un peu ce que tu veux, mais pas la laisser avec tous les bits de la partie adresse à zéro.
Une fois l’adresse changée, appliquer la configuration ou redémarrer histoire d’être certain.

Ensuite, si tu pouvais nous redonner la configuration IPv6 avec, par exemple, les commandes :

ip -6 addr show ip -6 route show

Accessoirement, quel est le kernel utilisé par le serveur ? Je veux dire, OVH installe Debian en utilisant un kernel propre à OVH mais pas celui du projet Debian. Vérifier avec uname -a .
On pourrait imaginer qu’un problème vienne de là.

–
AnonymousCoward

#14

Bonjour,
Le problème est résolu en forcant la conf du réseau au démarrage.
Attention les yeux!:slight_smile:

# nano /etc/rc.local
/sbin/ip -family inet6 route del 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0
/sbin/ip -family inet6 route add 2001:41d0:b:04ff:ff:ff:ff:ff dev br0
/sbin/ip -family inet6 route del default via 2001:41d0:b:04ff:ff:ff:ff:ff dev eth0
/sbin/ip -family inet6 route add default via 2001:41d0:b:04ff:ff:ff:ff:ff dev br0

C’est un peu sale mais ca marche.
Avez-vous une solution plus propre?

Au passage, j’hésite a passer sur une version testing du kernel (et seulement lui) pour avoir les dernières avancé sur LXC en terme de stabilité et de sécurité, c’est conseillé pour un serveur de prod? LXC semble encore un peu jeune.