[openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

Martinx - ジェームズ thiagocmartinsc at gmail.com
Wed Sep 3 22:13:16 UTC 2014


Sounds impressive!   :-D


On 1 September 2014 23:52, Xu Han Peng <pengxuhan at gmail.com> wrote:

>  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> 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 listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-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/20140903/a3900664/attachment.html>


More information about the OpenStack-dev mailing list