Open Stack

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 <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 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
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://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/20140904/d9708500/attachment.html>