This bug still shows up, adding more info after some investigation:


1. A server is created and a FIP is associated to it:

Tempest log:

2018-04-12 17:38:26,073 6080 INFO     [tempest.lib.common.rest_client] Request (TestServerBasicOps:test_server_basic_ops): 202 POST http://198.72.124.116/compute/v2.1/servers/d98c0fd9-e92c-4fd6-8391-e4452b7b32ae/action 1.282s
2018-04-12 17:38:26,074 6080 DEBUG    [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'X-Auth-Token': '<omitted>', 'Accept': 'application/json'}
Body: {"addFloatingIp": {"address": "172.24.5.5"}}


neutron-server log:
The dnat_and_snat NAT entry is added (fixed IP is 10.1.0.9):

Apr 12 17:38:25.418601 ubuntu-xenial-inap-mtl01-0003484549 neutron-server[25773]: DEBUG ovsdbapp.backend.ovs_idl.transaction [-] Running txn command(idx=2): AddNATRuleInLRouterCommand(lrouter=neutron-57884ee5-47a6-4587-949d-b066f5ea56c3, columns={'external_ip': '172.24.5.5', 'external_ids': {'neutron:router_name': 'neutron-57884ee5-47a6-4587-949d-b066f5ea56c3', 'neutron:fip_id': '20b39da8-413d-48f6-8d14-e0cc18a59a74', 'neutron:revision_number': '1', 'neutron:fip_port_id': '3846002b-ac5b-4a8e-b323-1117df6aa5a2'}, 'type': 'dnat_and_snat', 'logical_ip': '10.1.0.9'}) {{(pid=25866) do_commit /usr/local/lib/python2.7/dist-packages/ovsdbapp/backend/ovs_idl/transaction.py:84}}


br-int flows:

ARP entry looks good (table=9) with the MAC of the gateway port:

Apr 12 17:38:38.077970 ubuntu-xenial-inap-mtl01-0003484549 sh[23566]:  cookie=0xfdc62a55, duration=12.576s, table=9, n_packets=0, n_bytes=0, idle_age=12, priority=90,arp,reg14=0x1,metadata=0x5c,arp_tpa=172.24.5.5,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],mod_dl_src:fa:16:3e:83:d5:0d,load:0xfa163e83d50d->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xac180505->NXM_OF_ARP_SPA[],load:0x1->NXM_NX_REG15[],load:0x1->NXM_NX_REG10[0],resubmit(,32)

Note the n_packets=0, this flow never got hit.

However in table=12 we would expect to see the dnat action and we see it for the fixed IP address but to a different FIP (in a different datapath), so the DNAT action is not there.

Apr 12 17:38:38.116595 ubuntu-xenial-inap-mtl01-0003484549 sh[23566]:  cookie=0xca5b11b2, duration=29.150s, table=12, n_packets=5, n_bytes=370, idle_age=12, priority=100,ip,reg14=0x1,metadata=0x57,nw_dst=172.24.5.7 actions=ct(commit,table=13,zone=NXM_NX_REG11[0..15],nat(dst=10.1.0.9))


This means that traffic directed to 172.24.5.5 will never reach the instance as the flow is not installed.


tcpdump logs:

I would expect to see ARP responses for the FIP but i don't see any:

Apr 12 17:38:31.367332 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]: 17:38:31.086964 76:17:ae:71:f2:47 > fa:16:3e:a1:de:ed, ethertype ARP (0x0806), length 42: Request who-has 172.24.5.5 tell 172.24.5.1, length 28
Apr 12 17:38:31.367518 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]:         0x0000:  0001 0800 0604 0001 7617 ae71 f247 ac18  ........v..q.G..
Apr 12 17:38:31.367672 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]:         0x0010:  0501 0000 0000 0000 ac18 0505            ............
Apr 12 17:38:32.367372 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]: 17:38:32.090962 76:17:ae:71:f2:47 > fa:16:3e:a1:de:ed, ethertype ARP (0x0806), length 42: Request who-has 172.24.5.5 tell 172.24.5.1, length 28
Apr 12 17:38:32.367679 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]:         0x0000:  0001 0800 0604 0001 7617 ae71 f247 ac18  ........v..q.G..
Apr 12 17:38:32.367929 ubuntu-xenial-inap-mtl01-0003484549 tcpdump[23418]:         0x0010:  0501 0000 0000 0000 ac18 0505            ............


At this point, there's been a patch that has prevented devstack from collecting OVS dbs so I can't tell how the NB db looks like.


For some reason, adding the snat_and_dnat rule to OVN isn't working as expected. It's still obscure to me why the ARP responder flow in table 9 doesn't get hit.