Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct.
Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng <pengxu...@gmail.com> wrote: > Carl, > > Thanks a lot for your reply! > > 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 > _send_gratuitous_arp_packet call are wrapped by "if not is_ha" condition. > > Xu Han > > > > On 09/04/2014 06:06 AM, Carl Baldwin wrote: > > 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] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py > > On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng <pengxu...@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" <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.orghttp://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 > > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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