Nós temos uma configuração aqui com cerca de 30 Dom0s rodando o Xen 4.0.3 com um kernel Dom0 de 2.6.32.57 x86_64.
(Nós vimos o mesmo comportamento com o Xen 4.0.1 e com o kernel 2.6.32.2X anteriormente)
Às vezes, de repente, o xen pára de adicionar vifs para DOMs novos (ou migrados) corretamente. Interfaces estão lá, adicionadas à ponte correta, mas a bridge-port nunca recebe tráfego. Todas as interfaces neste momento já conectadas funcionam sem problemas. Isso acontece com todas as pontes no dom0 ao mesmo tempo (temos 11 pontes para 11 vlans e 4 interfaces físicas por host, stp nas pontes desativadas).
Se isso acontecer, eu vejo isso no log ao adicionar uma interface através do xen, o que parece estar faltando a ponte que está inserindo o estado de encaminhamento para as interfaces recém-adicionadas:
[809766.761058] device r624-eth0 entered promiscuous mode
[809766.773664] br-vlan2801: port 1(r624-eth0) entering learning state
[809766.857665] device r624-eth1 entered promiscuous mode
[809766.872226] br-vlan2802: port 2(r624-eth1) entering learning state
[809768.377613] blkback: ring-ref 8, event-channel 8, protocol 2 (x86_32-abi)
[809776.810481] r624-eth0: no IPv6 routers present
[809777.870549] r624-eth1: no IPv6 routers present
O IP de r624-eth0 não pode ser pingado depois. tcpdump -i br-vlan2801 mostra as solicitações ARP do host com ping, tcpdump -i r624-eth0 não mostra nada. Assim, os pacotes chegam à ponte, mas não são encaminhados para o vif (no meu entender). Derrubar a ponte via ifconfig br-vlan2801 down não ajuda - mas excluir e recriar a ponte resolve o problema. Isso me leva à conclusão de que Xen não faz parte do problema aqui.
Se eu apenas reiniciar a interface da ponte via ifconfig br-vlan2801 down / up , vejo isso:
Jul 5 16:43:52 kernel: [811367.029655] br-vlan2159: port 4(b434-eth1) entering disabled state
Jul 5 16:43:52 kernel: [811367.029893] br-vlan2159: port 3(d434-eth1) entering disabled state
Jul 5 16:43:52 kernel: [811367.030121] br-vlan2159: port 2(w434-eth1) entering disabled state
Jul 5 16:43:52 kernel: [811367.030350] br-vlan2159: port 1(eth0.2159) entering disabled state
Jul 5 16:44:15 kernel: [811389.818841] br-vlan2159: port 4(b434-eth1) entering learning state
Jul 5 16:44:15 kernel: [811389.819076] br-vlan2159: port 3(d434-eth1) entering learning state
Jul 5 16:44:15 kernel: [811389.819307] br-vlan2159: port 2(w434-eth1) entering learning state
Jul 5 16:44:15 kernel: [811389.819536] br-vlan2159: port 1(eth0.2159) entering learning state
Jul 5 16:44:25 kernel: [811399.959567] br-vlan2159: no IPv6 routers present
Se eu excluir a ponte e reconfigurá-la, vejo isso quando a ponte aparece novamente:
Jul 5 16:47:23 kernel: [811578.178683] br-vlan2159: port 4(w434-eth1) entering learning state
Jul 5 16:47:23 kernel: [811578.178917] br-vlan2159: port 3(eth0.2159) entering learning state
Jul 5 16:47:23 kernel: [811578.179146] br-vlan2159: port 2(d434-eth1) entering learning state
Jul 5 16:47:23 kernel: [811578.179374] br-vlan2159: port 1(b434-eth1) entering learning state
Jul 5 16:47:34 kernel: [811588.789566] br-vlan2159: no IPv6 routers present
Jul 5 16:47:38 kernel: [811593.178568] br-vlan2159: port 4(w434-eth1) entering forwarding state
Jul 5 16:47:38 kernel: [811593.178801] br-vlan2159: port 3(eth0.2159) entering forwarding state
Jul 5 16:47:38 kernel: [811593.179029] br-vlan2159: port 2(d434-eth1) entering forwarding state
Jul 5 16:47:38 kernel: [811593.179255] br-vlan2159: port 1(b434-eth1) entering forwarding state
Depois disso, a ponte e todas as interfaces conectadas a ela estão funcionando como esperado.
Como acontece com todas as pontes ao mesmo tempo, eu não culpo as ferramentas brctl para isso, mas algo mais profundo dentro do kernel. Como isso acontece de forma aleatória e apenas a cada dois meses, não tenho a possibilidade de fazer uma verificação cruzada com um kernel mais novo.
A principal questão (no meu entender) é: por que a ponte não está entrando no estado de avanço nas portas recém-adicionadas / configuradas?