Le trafic réseau ne semble pas quitter le coffre

Je suis en train de mettre en place de nouveaux servers de virtualisation, et une partie de cela est d'get des tuyaux de bande passante plus élevés. Le but ultime est de lier 4 ports GigE dans un seul coffre transportant le trafic 802.1q marqué. Je peux aller jusqu'à ce point, mais j'ai rencontré un problème étrange. 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 se trouve dans le même VLAN que VM1. Client1 se trouve dans un VLAN différent. Pour la machine VM (CentOS 6), iptables et SELinux ont été désactivés.

Mon problème réside dans le fait que le trafic bidirectionnel est impossible lors de la conversation avec une machine Client. TCPDUMP montre que les pings sont reçus par eux et les packages ECHO REPLY sont envoyés, mais l'hôte VM ne les voit jamais. Dans le même time, si j'essaie de faire un ping sur la machine virtuelle à partir d'une machine client, cela ne fonctionne pas non plus. Le fait que je ne peux pas faire de ping client2, qui se trouve sur le même sous-réseau, suggère que quelque chose soit vif dans la couche réseau quelque part.

Curieusement, à partir de l'hôte VM, je peux faire un ping sur les IP de la passerelle sur l'un des commutateurs. Si j'utilise une seule interface, tout fonctionne bien avec et sans marquage VLAN. Si je lier une seule interface et faire un marquage VLAN sur cette interface, je peux aller n'importe où. Créez un coffre, et je suis limité à l'équipement de commutation.

Le type de coffre ne semble pas important. À l'heure actuelle, ils sont configurés avec le mode 0 troncs (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à-bas. La définition de VLAN 70 de SW1 a la "adresse IP" définie sur elle. L'extrait ci-dessus se trouve dans le mode totalement non chargé. Quand je suis tronqué:

 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 traduit la définition du trunk 35-36,38,40 Trk16 lacp pour le trunk 35-36,38,40 Trk16 lacp mais, comme je l'ai dit, ne change pas la présentation du problème.

Client2 est en fait connecté à SW1, mais le placement dans le tableau aurait rendu le formatting plus difficile. En tout cas, la seule chose dans la strophe Interface est une directive de name ; Il est répertorié comme un port untagged dans la stroïme vlan 70 pour SW1.

Qu'est-ce qui me manque?

2 Solutions collect form web for “Le trafic réseau ne semble pas quitter le coffre”

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

  1. Un bug possible dans CentOS 6 ne modifiait pas les options de module pour le module de bonding dans le cadre du service network restart de service network restart , de sorte qu'il ne suivait pas mes modifications entre le mode LACP (4) et Roundrobin (0).
  2. Le mode Round-Robin ne veut pas fonctionner avec les commutateurs ProCurve.

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

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

Le server et le commutateur parlaient. À ce stade, à partir d'une seule interface activée sur le commutateur, le trafic a commencé à fonctionner normalement. En activant une seconde, une troisième et enfin, les quasortingème interfaces ont tous fonctionné.

En fin de count, le mode LACP est ce qui a fait fonctionner les choses. L'indice était que le mode round-robin fonctionnait lorsqu'il n'y avait qu'un seul commutateur activé dans le Trunk. Le server survit à un redémarrage et se lève dans le bon mode. Cependant, un service network restart ne provoque pas la partie MODE="4" du ifcfg-bond0 dans /etc/sysconfig/network-scripts/ pour prendre effet. Si ce mode change, il restra ce qui a été défini lors du démarrage (ou plus probablement, le time de chargement du module du module de bonding ).

Vous avez dans votre configuration:

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

Ne serait-ce pas:

  untagged Trk16 tagged Trk1-Trk2,Trk5,Trk8 
  • Comment maximiser le téléchargement en parallèle de S3
  • Recommandations matérielles / liste de pièces pour une boîte NAS ZFS moderne et silencieuse - édition 2011-février [fermé]
  • Problèmes d'arborescence dans un environnement HP ProCurve partagé
  • Tout laboratoire de networking gratuit?
  • Comment modifier le comportement de la diffusion globale (255.255.255.255) sur Windows?
  • forcer le trafic de proxy à s'orienter via une interface de dongle 3G spécifique
  • Utilisation sélective d'un proxy transparent par connection
  • Incohérence dans la gestion des connexions TCP et HTTP
  • Le service réseau échoue lors du démarrage dans SLES 10.2, ce qui peut entraîner des problèmes de client NFS
  • On me request de prendre en charge la cartographie de plusieurs keys SSL sur une seule IP, mais je pense que c'est une mauvaise idée. Ai-je tort?
  • Ressources requirejses réseau ou Active Directory non disponibles
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.