☰

Openstack 似乎无法正确将内部 IP 映射到本地网络

tag-icon • tag-icon routing nat openstack nova-network
Openstack 似乎无法正确将内部 IP 映射到本地网络

我有一个非常令人困惑的问题，似乎无法解决。

我遵循了洛伊克达查里在 Wheezy 上安装 Openstack Folsom，并将其部署在两台主机上：一个集群节点和我的工作站。

在这两台主机上，我运行一个基准测试应用程序，该应用程序以以下方式从一台主机与另一台主机进行通信：

图片描述

以下是节点主机、工作站和内部虚拟机的路由表：

图片描述

（笔记：10.0.1.0 条目用于附加网络接口。它最终变得不再需要，并且未在任何虚拟机上启动。因此，它没有影响，因为没有任何东西被路由到目标 10.0.1.x)

现在，我的问题如下：

基准测试应用程序从工作站上的一台虚拟机（例如 10.0.0.2）启动 RMI 调用到节点上的一台虚拟机（例如 172.23.3.100）。

据我了解，应该发生以下情况：

  1. VM 看到目标 172.23.xx 网络路由并通过默认路由 10.0.0.1（工作站计算主机）

  2. nova 网络服务发现 10.0.0.2 已映射到本地网络上的某个 IP（例如 172.23.12.1）。因此它将源 IP 更改为该 IP。

  3. 工作站主机看到目的地 172.23.xx 并通过 172.23.1.1 路由到 172.23.3.8。

  4. Nova 网络看到 IP，并且由于映射 172.23.3.100 -> 10.0.0.7 存在，它将目标更改为 10.0.0.7。

  5. 内部 IP 为 10.0.0.7 的节点上的 VM 从工作站 VM 获得请求。(@ 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.xx 地址！

这怎么可能？两个虚拟机都可以 ping 自己（节点->工作站，工作站->节点），而且我没有发现路由表有任何问题。

这仅有的我能看到的奇怪因素是以下跟踪路由信息：

工作站虚拟机 -> 节点

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

由于同样的原因，这些似乎没有从终端虚拟机获得回复。但是，Ping 工作正常：

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 上发布了此问题，希望获得更多浏览量并更快地得到解决）

相关内容