Estou tentando criar duas VMs confiáveis com IPs estáticos para eth1, mas os pings entre os endereços estáticos falham.
- Via dashboard havana, criei uma rede com sub-rede 10.16.1/24, gateway desabilitado, dhcp habilitado com faixa 10.16.1.100,10.16.1.120.
- Lançadas 4 instâncias, cada uma com dois NICS; eth0 para minha interface pública regular e eth1 para a sub-rede 10.16.1/24.
- logado em duas VMs e criado eth1.cfg, configurado para dhcp
auto eth1 iface eth1 inet dhcp
- logado nas outras duas VMs e criado o eth1.cfg, configurado com informações estáticas
auto eth1 iface eth1 inet estático endereço 10.16.1.2 máscara de rede 255.255.255.0
- ifup eth1 em cada VM
De cada VM configurada com DHCP, posso executar ping na outra VM configurada com DHCP, mas não nas VMs configuradas estaticamente.
Nas VMs configuradas estaticamente, não consigo executar ping em nenhuma outra VM.
Também tentei criar um roteador para a rede e adicionar uma interface 10.16.1.254. Mas isso não causou nenhuma mudança aparente. Também não consigo executar ping no roteador de nenhuma das VMs.
o que estou perdendo?
Responder1
É difícil responder sem mais informações. Como você está na mesma rede, não espero que as regras de firewall sejam um problema.
Você está usando nêutron ou nova. Você pode verificar se todos os serviços de nêutrons estão funcionando bem?
neutron agent-list
Talvez valha a pena ativar o DHCP, para que você possa pelo menos verificar se a rede está funcionando.
Além disso, as VMs estão localizadas no mesmo hipervisor físico ou estão espalhadas por dois. Se eles estiverem espalhados por dois, você está usando VLANs e configurou seu switch para suportá-lo?
Vale ressaltar que a configuração estática de IPs, não reservados pelo Openstack, funcionava antes do Icehouse, mas mudanças nessa versão podem causar problemas.
No nó de computação que hospeda uma das VMs, se você executar
iptables -S | more
Pesquise a saída pelo endereço MAC de suas VMs, por exemplo, o meu é 'FA:16:3E:D0:1A:5D'
Você verá alguma saída como esta:
-A neutron-openvswi-see719639-9 -s 192.168.0.83/32 -m mac --mac-source FA:16:3E:BB:75:7E -j RETURN
-A neutron-openvswi-see719639-9 -j DROP
Isso significa que ele aceitará apenas pacotes para o endereço MAC destinado a 192.168.0 .83/32.
Responder2
Acredito que isso seja consistente com minha experiência anterior ao tentar ter um endereço IP configurado estaticamente em uma rede habilitada para DHCP de nêutrons. Pelo que me lembro, o que você está tentando fazer funciona se o DHCP tiver sido desabilitado para aquela rede de nêutrons específica, mas não funcionará se estiver habilitado.
Neste último caso, será criada uma porta de nêutrons para esta interface VM com o endereço IP atribuído. Se você configurasse estaticamente sua VM convidada para corresponder a este IP e sub-rede, funcionaria. Se você tentar configurar estaticamente seu convidado para um IP diferente do IP no banco de dados de nêutrons, isso não acontecerá. No mínimo, esta é uma forma de proteção contra falsificação de IP, pois não permitiria que você representasse o IP de outra VM na mesma rede e geralmente é uma boa proteção para se ter.
Então, uma opção é usar uma rede com DHCP = desabilitado para sua rede. Outra opção é configurar estaticamente a VM para o mesmo IP atribuído pelo neutron.
Outra anedota: em um caso, conectei uma rede externa a uma rede openstack por meio de uma VLAN específica. Esta rede tinha apenas servidores físicos configurados estaticamente e nenhum servidor DHCP. A rede do lado openstack que criei com DHCP=enabled. Fiz isso usando um alocador_range restrito, para alocar IPs que não entrariam em conflito com IPs estáticos existentes no mesmo CIDR. Como o neutron gerencia apenas portas em ponte para VMs, isso significava que outros dispositivos configurados estaticamente na rede (fora do controle openstack/neutron) poderiam se comunicar com as VMs com DHCP nesta rede. Porém, essa configuração não permitiria que você ativasse uma combinação de VMs/convidados estáticos e DHCP na mesma rede de nêutrons que tem DHCP = habilitado.