Le trafic réseau ne semble pas quitter le coffre


8

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?


Pouvez-vous publier la strophe VLAN de vos commutateurs Procurve? Et aussi quels ports l'hyperviseur (alias VM) 1, les clients 1 et 2 utilisent?
jftuga

@jftuga Les strophes ont été entrées.
sysadmin1138

Pour les commutateurs sw1,2,3, tous les ports de liaison montante (vers d'autres commutateurs) sont-ils étiquetés dans le vlan 70? Aussi, que vous montre Tracert?
jftuga

@jftuga Oui, tous les liens inter-commutateurs sont partagés et balisés. SW3 n'a PAS de VLAN 70 dessus. Traceroute montre peu d'intérêt, la trace meurt au saut quand il arriverait à l'hôte VM. De plus, à partir du commutateur lui-même, je ne peux pas envoyer de requête ping à l'adresse IP de l'hôte VM lorsqu'elle est partagée. Je vais voir si je peux mettre quelque chose en place pour renifler cet ensemble de ports partagés.
sysadmin1138

Vous dites que c'est une VM, comme dans Virtual Machine? Exécutez-vous cela sur ESX (i)?
pauska

Réponses:


7

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).


Heureux de vous aider :)
MikeyB

Heureux de voir que vous avez résolu ce problème.
jftuga

Une question et une réponse très professionnelles. Lié pour aider quelqu'un.
artifex

0

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

Eh bien, il y a une erreur dans le message d'origine, mais pas ce que vous proposez. Sous la configuration non partagée, il devrait y avoir un "Trk16 non marqué" sur le vlan 70.
pauska

J'ai également essayé cette variante. Les deux variantes fonctionnent de la même manière, ne fonctionnent pas. L'utilisation de untagged 35-36,38,40et les tagged 35-36,38,40...deux fonctionnent tant que je n'essaie pas d'agréger les interfaces sur le serveur Linux. untagged Trk16et les tagged Trk16...deux ne fonctionnent pas.
sysadmin1138

Vous exécutez Xen? Est-ce que Centos 6 débloque toujours les définitions d'interface? Je me souviens d'un problème que j'ai eu où les interfaces vlan ont été créées à partir de l'interface incorrecte (le phys au lieu du pont ou vice-versa) et des choses étranges se sont produites.
MikeyB
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.