O Openstack parece não mapear corretamente os IPs internos para a rede local

Question

Eu tenho uma questão muito confusa que não consigo resolver.

Eu segui um guia de Loic Dachary ao instalar o Openstack Folsom no Wheezy e o implantei em dois hosts: um nó de cluster e minha estação de trabalho.

Nesses dois hosts, estou executando um aplicativo de teste de desempenho que se comunica de um host para o outro da seguinte maneira:

Aseguirestãoastabelasderoteamentoparaohostdonó,aestaçãodetrabalhoeasVMsinternas:

( Nota : a entrada 10.0.1.0 era para uma interface de rede adicional. Ela acabou sendo desnecessária e não está em nenhuma das VMs. Por isso, ela não tem impacto, já que nada está sendo encaminhado para o destino 10.0.1.x)

Agora, meu problema é o seguinte:

O aplicativo de benchmarking inicia uma chamada RMI de uma das VMs na estação de trabalho (digamos, 10.0.0.2) para uma das VMs no nó (digamos, 172.23.3.100).

Entendo que o seguinte deve ocorrer:

1. A máquina virtual vê a rota de rede 172.23.x.x de desgin e passa pela rota padrão 10.0.0.1 (o host de computação da estação de trabalho)

2. O novo serviço de rede vê que o 10.0.0.2 está mapeado para algum IP (digamos, 172.23.12.1) na rede local. Por isso, muda o IP de origem para isso.

3. O host da estação de trabalho vê o destino 172.23.x.x e faz o roteamento de 172.23.1.1 até 172.23.3.8.

4. Nova rede vê o IP e, como o mapeamento diz, 172.23.3.100 - > 10.0.0.7 existe, ele muda o destino para 10.0.0.7.

5. A VM no nó com IP interno 10.0.0.7 obtém a solicitação da VM da estação de trabalho. (@ 172.23.12.1).

Isso funciona bem. O pedido real é enviado. No entanto, há algo errado com a resposta.

Aqui está o log do meu aplicativo executado logo após o envio da solicitação:

RemoteException was: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
->      java.rmi.ConnectIOException: Exception creating connection to: 10.0.0.7; nested exception is:
->      java.net.NoRouteToHostException: No route to host

Portanto, deve ser o caso em que o nó VM respondeu com sua origem sendo 10.0.0.7. Em outras palavras, o serviço de rede nova nunca alterou o IP de origem da VM do nó para seu endereço 172.23.x.x roteável!

Como isso é possível? Ambas as máquinas virtuais podem fazer ping em si mesmas (node-gt; workstation, workstation- > node), e não vejo nada de errado com as tabelas de roteamento.

O fator ímpar somente que eu posso ver é a seguinte informação traceroute:

VM da estação de trabalho - > Node

root@client-01:~# traceroute 172.23.3.8
traceroute to 172.23.3.8 (172.23.3.8), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.406 ms  0.399 ms  0.390 ms
 2  172.23.3.8 (172.23.3.8)  0.381 ms  0.378 ms  0.422 ms
root@client-01:~#

VM do nó - > Estação de trabalho

root@idleserver-vm:~# traceroute 172.23.19.176
traceroute to 172.23.19.176 (172.23.19.176), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.741 ms  0.676 ms  0.657 ms
 2  172.23.19.176 (172.23.19.176)  0.643 ms  0.638 ms  0.626 ms
root@idleserver-vm:~#

Isso funciona bem. No entanto ...

VM do nó - > VM da estação de trabalho

root@idleserver-vm:~# traceroute client01
traceroute to client01 (172.23.12.1), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.808 ms  0.739 ms  0.721 ms
 2  client01 (172.23.12.1)  0.707 ms  0.702 ms  0.688 ms
 3  * * *
 4  * * *
 5  * * *

VM da estação de trabalho - > VM do nó

root@client-01:~# traceroute idleserver
traceroute to idleserver (172.23.3.105), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.296 ms  0.239 ms  0.224 ms
 2  idleserver (172.23.3.105)  0.213 ms  0.200 ms  0.189 ms
 3  * * *
 4  * * *
 5  * * *

Estas não parecem receber uma resposta da VM final, provavelmente pelo mesmo motivo. No entanto, os pings funcionam bem:

root@client-01:~# ping idleserver
PING idleserver (172.23.3.105) 56(84) bytes of data.
64 bytes from idleserver (172.23.3.105): icmp_req=1 ttl=62 time=1.02 ms
64 bytes from idleserver (172.23.3.105): icmp_req=2 ttl=62 time=0.914 ms


root@idleserver-vm:~# ping client01
PING client01 (172.23.12.1) 56(84) bytes of data.
64 bytes from client01 (172.23.12.1): icmp_req=1 ttl=62 time=0.675 ms
64 bytes from client01 (172.23.12.1): icmp_req=2 ttl=62 time=0.875 ms

O que o mundo poderia estar acontecendo aqui?

EDITAR : Depois de falar com o administrador da rede, ele me ajudou a resolver um pouco o problema. Parece que a nova-network não está deixando os pacotes UDP passar corretamente, portanto o traceroute está falhando. Usando o seguinte:

root@idleserver-vm:~# traceroute -T client01
traceroute to client01 (172.23.12.1), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.766 ms  0.756 ms  0.748 ms
 2  client01 (172.23.12.1)  0.737 ms  0.728 ms  0.720 ms
 3  client01 (172.23.12.1)  1.046 ms  1.046 ms  1.034 ms

Eu faço tenho portas UDP abertas tanto na VM de recebimento quanto na VM solicitante (eu também tentei portas específicas que tenho certeza que estão abertas), então eu não acho que poderia ser uma questão portuária.

(PS. Eu postei isso em ask.Openstack também na esperança de obter mais visualizações e uma resolução mais rápida)