Openstack, похоже, не отображает внутренние IP-адреса в локальной сети должным образом

У меня очень запутанная проблема, которую я не могу решить.

Я последовал за гидом Лоик Дачари при установке Openstack Folsom на Wheezy и развернул его на двух хостах: узле кластера и моей рабочей станции.

На этих двух хостах я запускаю приложение для тестирования производительности, которое обменивается данными от одного хоста к другому следующим образом:

Ниже приведены таблицы маршрутизации для узла узла, рабочей станции и внутренних виртуальных машин:

(Заметка: запись 10.0.1.0 была для дополнительного сетевого интерфейса. В итоге он оказался ненужным и не установлен ни на одной из виртуальных машин. Следовательно, это не имеет никакого значения, поскольку ничего не направляется в пункт назначения 10.0.1.x)

Теперь моя проблема заключается в следующем:

Приложение для тестирования запускает вызов RMI от одной из виртуальных машин на рабочей станции (скажем, 10.0.0.2) к одной из виртуальных машин на узле (скажем, 172.23.3.100).

Насколько я понимаю, должно произойти следующее:

ВМ видит целевой сетевой маршрут 172.23.x.x и проходит маршрут по умолчанию 10.0.0.1 (вычислительный узел рабочей станции)
Сетевая служба nova видит, что 10.0.0.2 отображается на некоторый IP (скажем, 172.23.12.1) в локальной сети. Таким образом, он меняет исходный IP-адрес на этот.
Хост рабочей станции видит пункт назначения 172.23.x.x и маршрутизирует через 172.23.1.1 на 172.23.3.8.
Сеть Nova видит IP-адрес, и, поскольку в отображении указано, что существует 172.23.3.100 -> 10.0.0.7, оно меняет пункт назначения на 10.0.0.7.
ВМ на узле с внутренним IP-адресом 10.0.0.7 получает запрос от ВМ рабочей станции. (@ 172.23.12.1).

Это прекрасно работает. Фактический запрос будет отправлен. Однако в ответе что-то не так.

Вот журнал моего запуска приложения сразу после отправки запроса:

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

Таким образом, должно быть, что виртуальная машина узла ответила, что ее источник - 10.0.0.7. Другими словами, сетевая служба nova никогда не меняла исходный IP-адрес виртуальной машины узла на его маршрутизируемый адрес 172.23.x.x!

Как это возможно? Обе виртуальные машины могут пинговать себя (узел-> рабочая станция, рабочая станция-> узел), и я не вижу ничего плохого в таблицах маршрутизации.

В только Странный фактор, который я вижу, - это следующая информация о трассировке:

ВМ рабочей станции -> Узел

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:~#

Узел ВМ -> Рабочая станция

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:~#

Они отлично работают. тем не мение...

Узловая ВМ -> ВМ рабочей станции

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  * * *

ВМ рабочей станции -> ВМ узла

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  * * *

Кажется, что они не получают ответа от конечной виртуальной машины, вероятно, по той же причине. Однако пинги работают нормально:

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

Что, черт возьми, здесь может происходить?

РЕДАКТИРОВАТЬ: Поговорив с администратором сети, он немного помог мне решить проблему. Похоже, что nova-network неправильно пропускает UDP-пакеты, поэтому traceroute не работает. Используя следующее:

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

я делать Открыты UDP-порты как на принимающей, так и на запрашивающей ВМ (я также пробовал определенные порты, которые, как я знаю наверняка, открыты), поэтому я не думаю, что это может быть проблема с портом.

(PS. Я также разместил это на ask.Openstack в надежде получить больше просмотров и более быстрое разрешение)