<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Carl,<br>
<br>
Thanks a lot for your reply!<br>
<br>
If I understand correctly, in VRRP case, keepalived will be
responsible for sending out GARPs? By checking the code you
provided, I can see all the
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
_send_gratuitous_arp_packet call are wrapped by "if not is_ha"
condition. <br>
<br>
Xu Han<br>
<br>
<br>
<div class="moz-cite-prefix">On 09/04/2014 06:06 AM, Carl Baldwin
wrote:<br>
</div>
<blockquote
cite="mid:CALiLy7qoR4BQwwHdoo+78cHWYewfv4gmU-X8ya2GmpyQpOjyhg@mail.gmail.com"
type="cite">
<pre wrap="">It should be noted that "send_arp_for_ha" is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router. The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention. It did not send anything on
the internal network ports.
VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.
Hope this helps avoid confusion in this discussion.
Carl
[1] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py">https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py</a>
On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng <a class="moz-txt-link-rfc2396E" href="mailto:pengxuhan@gmail.com"><pengxuhan@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Anthony,
Thanks for your reply.
If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
with IPv6 included, the servers should be auto-configured with the active
router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be no need
to use two LLAs for default route of a subnet unless load balance is
required.
When the backup router become the master router, the backup router should be
responsible for sending out an unsolicited ND neighbor advertisement with
the associated LLA (the previous master's LLA) immediately to update the
bridge learning state and sending out router advertisement with the same
options with the previous master to maintain the route and bridge learning.
This is shown in <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-4.1">http://tools.ietf.org/html/rfc5798#section-4.1</a> and the
actions backup router should take after failover is documented here:
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-6.4.2">http://tools.ietf.org/html/rfc5798#section-6.4.2</a>. The need for immediate
messaging sending and periodic message sending is documented here:
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-2.4">http://tools.ietf.org/html/rfc5798#section-2.4</a>
Since the keepalived manager support for L3 HA is merged:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/68142/43">https://review.openstack.org/#/c/68142/43</a>. And keepalived release 1.2.0
supports VRRP IPv6 features ( <a class="moz-txt-link-freetext" href="http://www.keepalived.org/changelog.html">http://www.keepalived.org/changelog.html</a>, see
Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
satisfy our requirement here and if that will cause any conflicts with
RADVD.
Thoughts?
Xu Han
On 08/28/2014 10:11 PM, Veiga, Anthony wrote:
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.
<a class="moz-txt-link-freetext" href="http://linux.die.net/man/8/arping">http://linux.die.net/man/8/arping</a>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py">https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py</a>
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:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py">https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py</a>
thanks,
Robert
On 8/27/14, 1:03 AM, "Xuhan Peng" <a class="moz-txt-link-rfc2396E" href="mailto:pengxuhan@gmail.com"><pengxuhan@gmail.com></a> 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] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/neutron/+bug/1357068">https://bugs.launchpad.net/neutron/+bug/1357068</a>
[2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/114437/">https://review.openstack.org/#/c/114437/</a>
[3] <a class="moz-txt-link-freetext" href="http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html">http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html</a>
Thanks,
Xu Han
-Anthony
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>