Sounds impressive! :-D
On 1 September 2014 23:52, 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 > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-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