openstack: o vms trocando multicast em eth1 falha quando alguém sofre IGMP timeout

1

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.

    
por CAB 27.08.2014 / 21:15

2 respostas

0

É necessário adicionar uma regra de firewall para permitir o IGMP na VM.

Em Havana / Horizon Access & amp; Segurança, edite as regras padrão e adicione uma nova regra;

  • Regra: outro protocolo
  • Direção: Ingress
  • Protocolo IP: 2
  • Remoto: CIDR
  • CIDR: 0.0.0.0/0
por CAB 29.08.2014 / 19:13
0

Pode haver um erro de copiar + colar, mas você pode ter um erro na instrução de adição de rota que você postou. A rota para todo o intervalo de multicast é: 224.0.0.0/4

A declaração de rota que você postou pode funcionar também, mas o primeiro octeto da sua declaração está errado (você tem 225 em vez de 224).

    
por user96328 28.08.2014 / 02:35