Comment 7 for bug 1667756

This bug is related to this other one [0].

When namespaces are created, ipv6 forwarding is enabled by default on them [1].
Setting the IPv6 procfs forwarding entry value causes the specified network interface to join or leave 3 multicast address groups (link-local all-routers multicast group (ff02::2), interface-local all routers multicast group (ff01::2), and site-local all routers multicast group (ff05::2)). So, when enabled, we'll see traffic such as Multicast Listener query/response packets:

==QUERY==
16:45:41.010437 08:81:f4:a6:dc:01 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) fe80:52:0:136c::fe > ff02::1: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener querymax resp delay: 10000 addr: ::
==RESPONSE==
16:45:41.843696 fa:16:3e:a7:ae:63 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) :: > ff02::2: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2

So the solution to avoid this behavior on backup instances is to disable the forwarding entry in the procfs for the gateway interface. However, this is not enough to stop seeing traffic as it may still send neighbor solicitations/advertisements:

09:29:09.669712 fa:16:3e:a7:ae:63 > 33:33:ff:a7:ae:63, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) :: > ff02::1:ffa7:ae63: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2620:52:0:136c:f816:3eff:fea7:ae63

09:29:09.670352 fa:16:3e:a7:ae:63 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) 2620:52:0:136c:f816:3eff:fea7:ae63 > ff02::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2620:52:0:136c:f816:3eff:fea7:ae63, Flags [router, override]
   destination link-address option (2), length 8 (1): fa:16:3e:a7:ae:63
     0x0000: fa16 3ea7 ae63

For this, accept_ra procfs entry has to be set to 0. Neutron code only sets it to '2' right now but it never sets it to 0 when the router transitions to standby.

[0] https://bugs.launchpad.net/neutron/+bug/1669765
[1] https://github.com/openstack/neutron/blob/master/neutron/agent/l3/namespaces.py#L97