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.
http://linux.die.net/man/8/arping
https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py
Thoughts?
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:
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py
thanks,
Robert
On 8/27/14, 1:03 AM, "Xuhan Peng" <pengxu...@gmail.com
<mailto:pengxu...@gmail.com>> 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, please?
[1] https://bugs.launchpad.net/neutron/+bug/1357068
[2] https://review.openstack.org/#/c/114437/
[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html
Thanks,
Xu Han
-Anthony
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
