Il traffico di rete non sembra lasciare il trunk

Sono in procinto di mettere in scena alcuni nuovi server di virtualizzazione e parte di questo è quello di ottenere alcuni tubi con larghezza di banda più elevata. L'obiettivo finale è quello di collegare 4 porte GigE in un unico trunk che trasporta traffico con tag 802.1q. Posso arrivare così lontano, tuttavia ho riscontrato uno strano problema. Ma prima, un diagramma.

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

Tutti gli switch sono switch HP ProCurve 2910al e non sono sovrapposti. Client2 nel diagramma sopra è nella stessa VLAN di VM1. Client1 si trova in una VLAN diversa. Per la macchina VM (CentOS 6) sia iptables che SELinux sono stati disabilitati.

Il mio problema è che quando è coinvolto il trunking, il traffico di rete bidirezionale è impossibile quando si parla con una macchina client. TCPDUMP mostra che i ping vengono ricevuti da loro e che i pacchetti ECHO REPLY vengono inviati, ma l'host di macchine virtuali non li vede mai. Allo stesso tempo, se provo a eseguire il ping della VM da un computer client, non funziona. Il fatto che non riesco a eseguire il ping di client2, che si trova sulla stessa sottorete, suggerisce che qualcosa è complicato nel livello della rete da qualche parte.

Stranamente, dall'host di macchine virtuali posso eseguire il ping degli IP del gateway su uno degli switch. Se uso una singola interfaccia, tutto funziona bene sia con che senza tag VLAN. Se rilevo semplicemente una singola interfaccia e accendo il tagging VLAN su quell'interfaccia, posso andare ovunque. Costruisci un bagagliaio e io sono limitato allo switch-fabric.

Il tipo di tronco non sembra importare. Al momento sono configurati con trunk di modalità 0 (balance-rr), sebbene l'utilizzo di LACP / 802.1qa si comporti allo stesso modo.

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

Questa è la configurazione VLAN su SW2 lassù. La definizione VLAN 70 di SW1 ha "ip address" definito su di esso. Lo snippet sopra riportato è nella modalità completamente non trunked. Quando sono trunked:

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

La versione 802.1qa / LACP scambia la definizione trunk per, trunk 35-36,38,40 Trk16 lacpma come ho detto, non cambia la presentazione del problema.

Client2 è in realtà collegato a SW1, ma inserirlo nella tabella avrebbe reso la formattazione più complicata. In ogni caso, l'unica cosa nella stanza Interface è una namedirettiva; è elencato come untaggedporta nella stanza vlan 70 per SW1.

Cosa mi sto perdendo?

Dopo un lungo dibattito in chat che ha coinvolto MikeyB , Pauska e ChrisS , il problema è stato duplice:

1. Un possibile bug in CentOS 6 non stava cambiando le opzioni del modulo per il bondingmodulo come parte di service network restart, quindi non stava monitorando le mie modifiche tra la modalità LACP (4) e roundrobin (0).
2. La modalità Round-Robin non ama lavorare con gli switch ProCurve.

Una volta ho forzato l'interfaccia legata alla modalità LACP / 802.1qa tramite questo comando:

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

Sia il server che lo switch stavano parlando. A quel punto, a partire da una sola interfaccia abilitata sullo switch, il traffico ha iniziato a funzionare normalmente. Abilitando una seconda, una terza e infine la quarta interfaccia, tutto il traffico continuava a funzionare.

In definitiva, la modalità LACP è ciò che ha fatto funzionare le cose. L'indizio era che la modalità round-robin funzionava quando c'era una sola porta switch abilitata nel trunk. Il server sopravvive al riavvio e viene visualizzato nella modalità corretta. Tuttavia, a service network restartnon rende effettiva la MODE="4"parte del ifcfg-bond0file in /etc/sysconfig/network-scripts/. Se tale modalità cambia, rimarrà ciò che è stato impostato all'avvio (o più probabilmente, il tempo di caricamento del bondingmodulo del modulo).

Hai nella tua configurazione:

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

Non dovrebbe essere:

   untagged Trk16
   tagged Trk1-Trk2,Trk5,Trk8