Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but I am 
pretty sure it's for HA setup to broadcast the router's own change since the 
arping is controlled by "send_arp_for_ha" config. By checking the man page of 
arping, you can find the "arping -A" we use in code is sending out ARP REPLY 
instead of ARP REQUEST. This is like saying "I am here" instead of "where are 
you". I didn't realized this either until Brain pointed this out at my code 
review below.

That’s what I was trying to say earlier.  Sending out the RA is the same 
effect.  RA says “I’m here, oh and I’m also a router” and should supersede the 
need for an unsolicited NA.  The only thing to consider here is that RAs are 
from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs for 
the RA of the standby to work.  So far as I know, I think there’s still a bug 
out on this since you can only have one gateway per subnet.


Xu Han

On 08/27/2014 10:01 PM, Veiga, Anthony wrote:

Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router 
ports, from a neutron router. I’m not sure why it’s sent to the router ports 
(internal network). My understanding for arping to the gateway port is that it 
is needed for proper NAT operation. Since we are not planning to support ipv6 
NAT, so this is not required/needed for ipv6 any more?

I agree that this is no longer necessary.

There is an abandoned patch that disabled the arping for ipv6 gateway port:


On 8/27/14, 1:03 AM, "Xuhan Peng" 
<<>> wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to 
start a discussion about how to support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet for HA 
doesn't work for IPv6 subnet gateways. This is because neighbor discovery 
instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor 
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers 
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called 
ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other 
linux distributions.

There are comments in yesterday's meeting that it's the new router's job to 
send out RA and there is no need for neighbor discovery. But we didn't get 
enough time to finish the discussion.

Because OpenStack runs the l3 agent, it is the router.  Instead of needing to 
do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new 
router for the same prefix would accomplish the same, without having to resort 
to a special package to generate unsolicited NA packets.  RAs must be generated 
from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd 
now.  The HA failover simply needs to start the proper radvd process on the 
secondary gateway and resume normal operation.

Can you comment your thoughts about how to solve this problem in this thread, 




Xu Han


OpenStack-dev mailing list<>

OpenStack-dev mailing list

Reply via email to