O tráfego de rede não parece deixar o tronco

Question

Estou no processo de preparar alguns novos servidores de virtualização, e parte disso é conseguir alguns canais de largura de banda maior neles. O objetivo final é ligar 4 portas GigE em um único tronco que transporta o tráfego marcado 802.1q. Eu posso chegar tão longe, no entanto eu me deparei com um problema estranho. Mas primeiro, um diagrama.

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

Todos os switches são switches HP ProCurve 2910al e não estão empilhados. O Client2 no diagrama acima está na mesma VLAN que a VM1. Client1 está em uma VLAN diferente. Para a máquina VM (CentOS 6), tanto o iptables quanto o SELinux foram desativados.

Meu problema é que, quando o entroncamento está envolvido, o tráfego de rede bidirecional é impossível quando se está falando com uma máquina cliente. TCPDUMP mostra que os pings são recebidos por eles e os pacotes ECHO REPLY são enviados, mas o host da VM nunca os vê. Ao mesmo tempo, se eu tentar fazer ping na VM a partir de uma máquina cliente, ela também não funcionará. O fato de eu não conseguir fazer ping no client2, que está na mesma sub-rede, sugere que algo está errado na camada de rede em algum lugar.

Estranhamente, no host da VM, posso fazer o ping dos IPs do gateway em qualquer um dos switches. Se eu usar uma única interface, tudo funcionará bem com e sem a marcação de VLAN. Se eu apenas ligar uma única interface e ativar a marcação de VLAN nessa interface, posso ir a qualquer lugar. Construa um tronco e estou limitado ao switch-fabric.

O tipo de tronco não parece importar. No momento, eles estão configurados com troncos do modo 0 (balance-rr), embora o uso do LACP / 802.1qa se comporte da mesma maneira.

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

Essa é a configuração da VLAN no SW2 lá em cima. A definição VLAN 70 do SW1 tem o "endereço IP" definido nele. O trecho acima está no modo totalmente não-truncado. Quando sou entroncado:

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

A versão 802.1qa / LACP troca a definição de tronco por trunk 35-36,38,40 Trk16 lacp , mas como eu disse, não altera a apresentação do problema.

O Client2 está realmente conectado ao SW1, mas colocá-lo no gráfico tornaria a formatação mais complicada. Em qualquer caso, a única coisa na sub-rotina Interface é uma diretiva name ; está listado como untagged port na sub-rotina vlan 70 para SW1.

O que estou perdendo?

    

Answer 1

Após um longo debate no bate-papo envolvendo MikeyB , Pauska e ChrisS , o problema acabou sendo duplo:

1. Um possível bug no CentOS 6 não estava alterando as opções do módulo bonding como parte de service network restart , então não estava monitorando minhas alterações entre o modo LACP (4) e roundrobin (0).
2. O modo Round-Robin não gosta de trabalhar com switches ProCurve.

Uma vez eu forcei a interface vinculada ao modo LACP / 802.1qa através deste comando:

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

Tanto o servidor quanto o switch estavam conversando. Nesse ponto, começando com apenas uma interface ativada no switch, o tráfego começou a funcionar normalmente. Ativando uma segunda, terceira e, finalmente, a quarta interface manteve o tráfego funcionando.

Por fim, o modo LACP é o que faz as coisas funcionarem. A pista era que o modo round-robin funcionava quando havia apenas uma porta de switch habilitada no Tronco. O servidor sobrevive a uma reinicialização e aparece no modo correto. No entanto, um service network restart não faz com que a parte MODE="4" do arquivo ifcfg-bond0 em /etc/sysconfig/network-scripts/ tenha efeito. Se esse modo mudar, permanecerá o que foi definido na inicialização (ou mais provavelmente, o tempo de carregamento do módulo bonding ).

    

Answer 2

Você tem em sua configuração:

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

Não deveria ser assim:

   untagged Trk16
   tagged Trk1-Trk2,Trk5,Trk8