Comment 13 for bug 2017889

Revision history for this message
Maximilian Sesterhenn (msnatepg) wrote :

I checked the flows, they are there:
# ovs-ofctl dump-flows br-ex
 cookie=0x3e6, duration=3539.673s, table=0, n_packets=66, n_bytes=5676, priority=1000,ipv6,in_port="patch-provnet-f",dl_src=fa:16:3e:8b:50:7b,ipv6_src=SRCv6 actions=mod_dl_dst:0a:7a:cc:07:f5:bf,output:"veth-ovs-12"
 cookie=0x3e6, duration=3539.480s, table=0, n_packets=2909, n_bytes=248847, priority=1000,ip,in_port="patch-provnet-f",dl_src=fa:16:3e:8b:50:7b,nw_src=SRCv4 actions=mod_dl_dst:0a:7a:cc:07:f5:bf,output:"veth-ovs-12"
 cookie=0x0, duration=227838.466s, table=0, n_packets=11347, n_bytes=11704353, priority=0 actions=NORMAL

My packet capture above makes the issue more obviously:
My instance has no L2 resolution (no MAC for the IPv6 gateway) and all ICMP NS attempts are failing. That makes sense as proxy_ndp only works if it was configured beforehand, which is not the case for the IPv6 gateway.

Maybe you could check using tcpdump -ni any INSTANCE_IPv6_ADDRESS from where the NA messages are coming?
You would have to clear the cache once the tcpdump is running: ip -s -s neigh flush all