Open Stack

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 http://tools.ietf.org/html/rfc5798#section-4.1 and the 
actions backup router should take after failover is documented here: 
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate 
messaging sending and periodic message sending is documented here: 
http://tools.ietf.org/html/rfc5798#section-2.4

Since the keepalived manager support for L3 HA is merged: 
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 
supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, 
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.
>
>
>
>     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" <pengxuhan at gmail.com
>>         <mailto:pengxuhan at 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 at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140902/294acae4/attachment.html>