Le trafic réseau ne semble pas quitter le coffre

Je suis en train de mettre en place de nouveaux serveurs de virtualisation, et une partie de cela consiste à y intégrer des canaux à bande passante plus élevée. Le but ultime est de lier 4 ports GigE en une seule ligne réseau transportant le trafic balisé 802.1q. Je peux aller aussi loin, mais j'ai rencontré un étrange problème. Mais d'abord, un diagramme.

----------       ----------  1GbE trunks 
|        | 10GbE |        | ------------- --------
|  SW1   |-------|   SW2  | ------------- | VM1  |
|        |       |        | ------------- --------
----------       ----------
     |                |  1GbE  -----------
     | 1GbE           |--------| client2 |
     |                         -----------
----------
|        | 1GbE -----------
|  SW3   |------| client1 |
|        |      -----------
----------

Tous les commutateurs sont des commutateurs HP ProCurve 2910al et ne sont pas empilés. Client2 dans le diagramme ci-dessus est dans le même VLAN que VM1. Client1 est dans un VLAN différent. Pour la machine virtuelle (CentOS 6), iptables et SELinux ont été désactivés.

Mon problème est que lorsque la jonction est impliquée, le trafic réseau bidirectionnel est impossible lors de la conversation avec l'une des machines clientes. TCPDUMP montre que les pings sont reçus par eux et que les paquets ECHO REPLY sont envoyés, mais l'hôte VM ne les voit jamais. Dans le même temps, si j'essaie d'envoyer une requête ping à la machine virtuelle à partir d'une machine cliente, cela ne fonctionne pas non plus. Le fait que je ne puisse pas cingler client2, qui se trouve sur le même sous-réseau, suggère que quelque chose est foutu quelque part dans la couche réseau.

Étrangement, à partir de l'hôte VM, je peux envoyer une requête ping aux IP de passerelle sur l'un des commutateurs. Si j'utilise une seule interface, tout fonctionne bien avec et sans marquage VLAN. Si je lie simplement une interface unique et active le balisage VLAN sur cette interface, je peux aller n'importe où. Construisez un tronc, et je suis limité à la matrice de commutation.

Le type de coffre ne semble pas avoir d'importance. À l'heure actuelle, ils sont configurés avec des lignes réseau en mode 0 (balance-rr), bien que l'utilisation de LACP / 802.1qa se comporte de la même manière.

vlan 70 
   name "Virtualization Subnet" 
   untagged 35,36,38,40 
   tagged Trk1-Trk2,Trk5,Trk8 
   no ip address 
   jumbo 
   exit 

C'est la configuration VLAN sur SW2 là-haut. La définition du VLAN 70 de SW1 a "l'adresse IP" définie dessus. L'extrait ci-dessus est en mode entièrement libre. Quand je suis coincé:

trunk 35-36,38,40 Trk16 trunk
vlan 70 
   name "Virtualization Subnet" 
   tagged Trk1-Trk2,Trk5,Trk8,Trk16
   no ip address 
   jumbo 
   exit 

La version 802.1qa / LACP échange la définition du tronc, trunk 35-36,38,40 Trk16 lacpmais comme je l'ai dit, ne change pas la présentation du problème.

Client2 est en fait connecté à SW1, mais le placer dans le graphique aurait rendu le formatage plus délicat. Dans tous les cas, la seule chose dans la strophe Interface est une namedirective; il est répertorié comme un untaggedport dans la strophe vlan 70 pour SW1.

Qu'est-ce que je rate?

Après un long débat sur le chat impliquant MikeyB , Pauska et ChrisS , le problème a fini par être double:

1. Un bogue possible dans CentOS 6 ne modifiait pas les options du module pour le bondingmodule service network restart, donc il ne suivait pas mes changements entre le mode LACP (4) et roundrobin (0).
2. Le mode Round-Robin n'aime pas fonctionner avec les commutateurs ProCurve.

Une fois que j'ai forcé l'interface liée au mode LACP / 802.1qa via cette commande:

ifconfig bond0 down
echo "4" > /sys/class/net/bond0/bonding/mode
ifconfig bond0 up

Le serveur et le commutateur parlaient tous les deux. À ce stade, à partir d'une seule interface activée sur le commutateur, le trafic a commencé à fonctionner normalement. L'activation d'une deuxième, troisième et enfin, la quatrième interface a maintenu le trafic en état de marche.

En fin de compte, le mode LACP est ce qui a fait fonctionner les choses. L'indice était que le mode à tour de rôle fonctionnait lorsqu'il n'y avait qu'un seul port de commutateur activé dans le coffre. Le serveur survit à un redémarrage et revient dans le mode correct. Toutefois, a service network restartne fait pas prendre effet à la MODE="4"partie du ifcfg-bond0fichier /etc/sysconfig/network-scripts/. Si ce mode change, il restera ce qui a été défini au démarrage (ou plus probablement, le temps de chargement du bondingmodule du module).

Vous avez dans votre config:

trunk 35-36,38,40 Trk16 trunk
vlan 70 
   name "Virtualization Subnet" 
   tagged Trk1-Trk2,Trk5,Trk8,Trk16
   no ip address 
   jumbo 
   exit 

Cela ne devrait-il pas être:

   untagged Trk16
   tagged Trk1-Trk2,Trk5,Trk8