Un petit problème de route ?

Hello,

Sur mes machines virtuelles, j’ai noté une certaine lenteur à l’établissement d’une connexion ssh. Voici les routes du serveur Xen sur lesquelles sont mes VM (où xenbrX sont des ponts):

[quote]xen:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.0.128.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr1128
10.0.128.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.176.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr1176
0.0.0.0 10.0.128.254 0.0.0.0 UG 0 0 0 eth0
xen:~# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 xenbr1128
localnet * 255.255.255.0 U 0 0 0 eth0
10.0.176.0 * 255.255.255.0 U 0 0 0 xenbr1176
default 10.0.128.254 0.0.0.0 UG 0 0 0 eth0[/quote]

Y a pas une route en trop ?

Merci !

Cette table de routage contient effectivement deux routes contradictoires de même poids (ou métrique) pour la destination 10.0.128.0/24, une par l’interface xenbr1128 et une par l’interface eth0. Le noyau ne sachant pas laquelle est la bonne, il en utilise une et tant pis si ce n’est pas la bonne, il ne va pas essayer l’autre. Cela entraîne non pas des lenteurs mais des pertes de connectivité avec les machines qui sont du “mauvais” côté.

Si l’interface eth0 fait partie d’un pont (brctl show), elle ne devrait pas avoir de routes associées.

Yop,

J’ai l’impression qu’il y a une coquille dans ta table de routage. Accéder au reseau 10.0.128.0/24 depuis xenbr1128 ou eth0, pourquoi pas mais la solution n’est pas forcément optimisée.
Je pense que le retard que tu perçois est du au longest match.

en fait, eth0 me sert pour l’administration de mon serveur, à savoir que cette interface est aussi sur le réseau 10.0.128.0/24.
Eth1 récupère l’agrégat de lien et dispatche vers les ponts xenbr1128 et xenbr1176 qui sont utilisés par xen ensuite pour les VM.

D’après vous, ma table devrait ressembler à quoi du coup ?

Comment ça, “aussi” ? Tu veux dire que le pont xenbr1128 et eth0 sont connectés indépendamment l’un de l’autre au même réseau ? Si oui, dans quel but ?

Oui, mon eth0 a sa patte dans le vlan 1128. J’aurais pu mettre cette patte dans un autre vlan, mais ça a été celui là. Et le hasard a voulu que j’ai à monter des VM qui se sont trouvées dans le même vlan que eth0.

Y a pas d’intérêt particulier en soit, il fallait que je choisisse un vlan pour eth0 j’ai pris le 1128. Et à côté j’ai eu des machines à déclarer dans ce même vlan, c’est tout.

J’aurais pu n’utiliser qu’une interface physique en agrégat de lien et utiliser une interface virtuelle de mon pont xenbr1128 pour retrouver mon serveur xen, mais je me suis dis que tant qu’à avoir 2 interfaces physique, autant jouer la carte de la sécurité et faire ça proprement.

Je comprends pas ce qui choque.

La méthode pour connecter “proprement” plusieurs interfaces physiques au même réseau c’est l’agrégation de liens (bonding). Cela apporte de la redondance et/ou de l’équilibrage de charge. La connexion indépendante comme tu sembles l’avoir fait n’apporte ni l’une ni l’autre : c’est toujours une seule et même interface qui est utilisée pour émettre le trafic IP, et si elle a un défaut, le noyau ne basculera pas automatiquement sur l’autre.

Je vois, je me répète, l’idée est de faire quelquechose dans l’immédiat de vraiment simple : une interface pour l’admin de mon serveur et l’autre pour l’agrégat et diffuser tous mes vlans.

Du coup dans l’immédiat je ne vais pas faire de bonding, même si je pense que ce serait la meilleurs solution à long terme.

Pour en revenir à mes routes du coup, quelle solution voyez-vous ? à part de mettre eth0 sur un vlan que je ne retrouverai pas dans mes vm.

Une interface dédiée à l’administration n’a de sens que si elle est connectée à un réseau séparé dédié à l’administration, ce qui ne semble pas être le cas ici. Pour moi elle ne sert à rien en l’état, tu peux la désactiver (il faudra juste déplacer la route par défaut sur le pont).

Ok, oui, inutile de me casser la tête, ma table de routage est bonne en soit, le problème vient de mes choix au niveau des interfaces. Je vais passer ça sur un vlan à part, ce sera propre et plus logique.