I get into this bug when debug something else. My concern it not that fixed ip is returned.
If I ping from a vm in a host other than the host of floating ip, I can get the reply of floating ip.
$ ping 172.168.1.51 -c 1 -W 1
PING 172.168.1.51 (172.168.1.51): 56 data bytes
64 bytes from 172.168.1.51: seq=0 ttl=61 time=8.911 ms
The source vm doesn't have a floating ip associated. And the request goes this way.
Source VM ---> Shared NAT at centralized router -> fip namespace -> qrouter namespace-> dest VM
The behavior should be consistent no matter if it is a multi-host DVR use case.
I think the multi-host DVR use case mentioned above gets the right result from a wrong reason. The request from an internal IP to a floatingip should be DNAT to the associated fixed IP, and then routes to the router interface. That is the most common case for Neutron routers.
I get into this bug when debug something else. My concern it not that fixed ip is returned.
If I ping from a vm in a host other than the host of floating ip, I can get the reply of floating ip.
$ ping 172.168.1.51 -c 1 -W 1
PING 172.168.1.51 (172.168.1.51): 56 data bytes
64 bytes from 172.168.1.51: seq=0 ttl=61 time=8.911 ms
The source vm doesn't have a floating ip associated. And the request goes this way.
Source VM ---> Shared NAT at centralized router -> fip namespace -> qrouter namespace-> dest VM
The behavior should be consistent no matter if it is a multi-host DVR use case.
I think the multi-host DVR use case mentioned above gets the right result from a wrong reason. The request from an internal IP to a floatingip should be DNAT to the associated fixed IP, and then routes to the router interface. That is the most common case for Neutron routers.