We recently lost SNAT from our floating IPs. The reason for this seems to be that a jump from the snat chain to the float-snat chain goes missing when a router is processed.
For example, I have a devstack with two VMs. The floating IPs are 172.24.4.227 and 172.24.4.228. The router's default SNAT address is 172.24.4.226. When I ping from one to the other, I see the source SNAT is the default SNAT. This is the output of tcpdump on the router's internal interface.
19:13:42.552877 IP 10.0.0.3 > 172.24.4.228: ICMP echo request, id 16641, seq 5, length 64
19:13:42.552903 IP 172.24.4.226 > 10.0.0.4: ICMP echo request, id 16641, seq 5, length 64
19:13:42.553221 IP 10.0.0.4 > 172.24.4.226: ICMP echo reply, id 16641, seq 5, length 64
19:13:42.553230 IP 172.24.4.228 > 10.0.0.3: ICMP echo reply, id 16641, seq 5, length 64
I expect to see this instead:
19:18:06.046647 IP 10.0.0.3 > 172.24.4.228: ICMP echo request, id 17153, seq 0, length 64
19:18:06.056681 IP 172.24.4.227 > 10.0.0.4: ICMP echo request, id 17153, seq 0, length 64
19:18:06.067306 IP 10.0.0.4 > 172.24.4.227: ICMP echo reply, id 17153, seq 0, length 64
19:18:06.068098 IP 172.24.4.228 > 10.0.0.3: ICMP echo reply, id 17153, seq 0, length 64
When it is working, my router's snat chain looks like this:
Chain neutron-l3-agent-snat (1 references)
target prot opt source destination
neutron-l3-agent-float-snat all -- 0.0.0.0/0 0.0.0.0/0
SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:172.24.4.226
When it is broken, it looks like this:
Chain neutron-l3-agent-snat (1 references)
target prot opt source destination
SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:172.24.4.226
Fix proposed to branch: master
Review: https:/