Eu tenho duas VMs confiáveis idênticas configuradas com o dhcp para eth1. Eu instalei o mgen e configurei os scripts mgen para que os dois trocassem 1 mensagem multicast por segundo por 360 segundos. Uma VM pára de receber pacotes após 260 segundos (o Tempo Limite do Grupo de Rastreio IGMP). A segunda VM continua recebendo mensagens durante todo o período.
Eu tenho o mesmo problema se eu usar VMs idênticas do CentOS 6.5.
Por que um trabalho? Por que o outro timeout e nunca se recupera?
Configuração;
-
Através do dashboard havana, criei uma rede com uma sub-rede 10.16.1 / 24, gateway desativado, dhcp ativado com o intervalo 10.16.1.100,10.16.1.120.
-
Lançou 2 instâncias confiáveis, cada uma com dois NICS; eth0 para minha interface pública regular e eth1 para a sub-rede 10.16.1 / 24.
-
Conectado a cada VM e criado o eth1.cfg, configurado para o dhcp
auto eth1
iface eth1 inet dhcp
-
ifup eth1 em cada vm
-
apt-get instala o mgen em cada vm
-
configure uma VM com este script mgen
0.0 JOIN 224.225.1.104 INTERFACE eth1
0.0 LISTEN UDP 5104
10.0 ON 1 UDP SRC 5002 DST 224.225.1.103/5103 PERIODIC [1 512]
370.0 LEAVE 224.225.1.104
370.0 OFF 1
-
Configure a outra VM com script complementar
0.0 JOIN 224.225.1.103 INTERFACE eth1
0.0 LISTEN UDP 5103
10.0 ON 1 UDP SRC 5002 DST 224.225.1.104/5104 PERIODIC [1 512]
370.0 LEAVE 224.225.1.103
350.0 OFF 1
-
definir rota em cada VM
ip route add 224.225.1/24 dev eth1
-
executar script em cada VM simultaneamente
mgen input mcast.mgn
Como o mgen é executado, ele imprime as mensagens recebidas da outra VM. Uma VM chega a 260 segundos e pára de receber;
18:50:35.414601 RECV proto>UDP flow 1 seq 251 src 10.16.1.103/5002 dst 224.225.1.103/5103 sent 18:50:35.304360 size 512
18:52:04.672731 OFF flow 1 srcPort 5002 dst 224.225.1.104/5104
O outro conclui como esperado;
18:52:04.563455 RECV proto UDP flow 1 seq 341 src 10.16.1.104/5002 dst 224.225.1.104/5104 sent 18:52:04.672341 size 512
18:52:05.305505 OFF flow 1 srcPort 5002 dst 224.225.1.103/5103
O que dá?
UPDATE
O uso do wireshark na VM bem-sucedida mostra o seguinte tráfego IGMP.
ObservequeaVMbem-sucedidaestáusandooIGMPv2,enquantoafalhausaoIGMPv3.EunãoentendoissocomoVMssãocriadosdeformaidêntica-mesmaimagemdebase-osmesmoscomandosdeconfiguração-etc.
Alémdisso,realizouacapturawiresharkdaVMcomfalha.Curiosamente,nãocapturanenhumdospacotesIGMPv2.Issoprovavelmenteexplicaporqueelenuncarespondeàconsultadeassociação.
Deacordocom esta postagem , o IGMPv3 deve ser compatível com versões anteriores da v2. No entanto, usei essas informações para forçar a VM com falha a também usar o IGMPv2 e executei outra captura wireshark. O resultado foi que a VM com falha ainda não recebe a consulta de participação IGMP.