Routage sur deux interfaces réseaux et martian sources

Support Debian
#1

Bonjour,

j’ai une machine XEN sur laquelle j’ai deux interfaces en bridge dans le même réseau.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto xenbr0
iface xenbr0 inet static
        address 192.168.A.A1/24
        gateway 192.168.A.GW
        bridge_ports enp1s0

iface enp2s0f0 inet manual

auto xenbr1
iface xenbr1 inet static
        address 192.168.A.A2/24
        gateway 192.168.A.GW
        bridge_ports enp2s0f0

je reçois énormément de messages martian sources d’une machine avec partage CIFS sur la deuxième interface bridge xenbr1.

En faisant un ip route:

# ip route
default via 192.168.1.254 dev xenbr0 onlink
192.168.1.0/24 dev xenbr0 proto kernel scope link src 192.168.1.105
192.168.1.0/24 dev xenbr1 proto kernel scope link src 192.168.1.106

je pense que cette situation est due au fait qu’ayant déclaré la même gawteway sur les deux interfaces, le routage passe de façon principale par xenbr0 'où les messages.

Mon soucis c’est que je veux que la gateway soit définie même si xenbr0 ne monte pas pour une raison ou une autre. Mon seul moyen est donc de faire un post-up sur xenbr1 pour monter la GW si celle-ci n’est pas déjà montée par xenbr0, et inversement sur xenbr0.

Serait-ce plutôt un script dans ifup.d?

#2

Avant toute chose, est-ce que tu pourrais mettre un extrait de log montrant ces « martian sources » ? En indiquant aussi la machine sur laquelle ces messages apparaissent.

Sinon, nous allons avoir du mal à comprendre.

–
AnonymousCoward

#3

La machine est out pour le moment, donc pas moyen d’avoir les logs.
les logs sont de ce type là:

:40:37 example2 kernel: IPv4: martian source 255.255.255.255 from 10.140.249.4, on dev eth1
May 22 03:40:37 example2 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 56 ad 59 09 08 00 .......PV.Y.

donc ce sont des paquets qui arrivent sur la deuxièmème interface.
sauf que mon routage pour un réseau identique se retrouve sur les deux interfaces, c’est ce qui je pense déclenche ces logs.

#4

Cela ne vaut pas les vrais logs mais c’est déjà ça.

Sur quelle machine ce genre de message serait généré ? Sur l’hyperviseur XEN ou sur une machine virtuelle hébergée sur l’hyperviseur ?

Si c’est sur l’hyperviseur, est-ce que tu peux nous dire quel est l’intérêt que tu trouves au fait d’avoir deux bridges séparés pour attacher les VMs ?
Je veux dire, pourquoi ne pas avoir un seul bridge qui serait raccordé à ton réseau physique par une agrégation de liens ? Même si tu ne disposes pas forcément d’un switch manageable pour du LACP, tu peux éventuellement utiliser un bonding « balance-alb » / mode 6 (je n’ai pas testé).

–
AnonymousCoward

#5

Bonne question, à partir de cet hyperviseur (c’est lui qui génère ces logs), je voulais que mes VMs soient en NAT avec deux groupes de VMs dans deux réseaux différents, et attacher chaque groupe chacun à une interface.

mais je pourrais effectivement faire une agrégation. Mais une interface est en 2,5GB et l’autre en 1GB.

#6

Pourquoi ?

Prévisible. Quelles sont les valeurs de /proc/sys/net/ipv4/conf/{all,xenbr0,xenbr1}/log_martians ?
Tu as essayé de mettre net.ipv4…conf.xenbr{0,1}.arp_ignore=1 ?

Pourquoi ne monterait-il pas ?

Non, ce n’est pas l’hyperviseur qui génère ces logs, c’est un des OS invités (dom0 ou domU).

Alors pourquoi fais-tu des ponts avec des interfaces physiques ?

#7

log martian est activé c’est volontaire, j’avais simplement oublié le problème de routes par defaut qui pose effectivement le problème.

Si l’interface est HS la gateway ne montera pas via le fichier /etc/network/interfaces, car la GW n’est definie que sur xenbr0.
si je declare la même GW sur xenbr1, alors ça va générer des logs martians. ce qui est normal, notament sur les broadcasts.

Il n’y a pas d’OS invité pour le moment il n’y a que le host.

les ponts sont pour la virtualisation, j’ai repris le How to XEN. Avoir deux sous-réseaux distinct pour les VM, et chaque sous reseau passant par une des interfaces. Car à terme, il est possible que chaque interface ne soit pas connecté au même équipement réseau.

#8

Pourquoi faire ? Cela n’a pas de sens dans un contexte de routage asymétrique.

Pas très clair. Le concept même de « monter » pour une passerelle m’échappe.
D’autre part, si une interface physique est HS, alors ce sont toutes les communications au travers du pont auquel elle est attachée (et donc des VM attachées à ce pont) qui sont affectées, et pas seulement les communications de la machine elle-même.

Si tu veux de la tolérance de panne, pourquoi ne pas faire du bonding ?

Il n’y a pas de host avec Xen, seulement l’hyperviseur (Xen) et les systèmes paravirtualisés (le dom0 que tu confonds avec le host et les domU que tu appelles les VM).

J’ai bien compris, mais cela ne répond pas à ma question : pourquoi mets-tu des interfaces physiques dans les ponts alors que tu dis vouloir faire du NAT (sur l’interface physique je suppose) qui est quand même plus simple à gérer en routage qu’en pontage ?

Pour le moment ce n’est pas le cas puisque les deux interfaces physiques sont connectées au même réseau.