<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
As we talked in last IPv6 sub-team meeting, I was able to construct
and send IPv6 unsolicited neighbor advertisement for external
gateway interface by python tool <b>scapy</b>:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<a href="http://www.secdev.org/projects/scapy/">http://www.secdev.org/projects/scapy/</a><br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<a
href="http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf">http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf</a><br>
<br>
<br>
However, I am having trouble to send this unsolicited neighbor
advertisement in a given namespace. All the current namespace
operations leverage ip netns exec and shell command. But we cannot
do this to scapy since it's python code. Can anyone advise me on
this?<br>
<br>
Thanks,<br>
Xu Han<br>
<br>
<div class="moz-cite-prefix">On 09/05/2014 05:46 PM, Xu Han Peng
wrote:<br>
</div>
<blockquote cite="mid:54098668.5080908@gmail.com" type="cite">Carl,
<br>
<br>
Seem so. I think internal router interface and external gateway
port GARP are taken care by keepalived during failover. And if HA
is not enable, _send_gratuitous_arp is called to send out GARP.
<br>
<br>
I think we will need to take care IPv6 for both cases since
keepalived 1.2.0 support IPv6. May need a separate BP. For the
case HA is enabled externally, we still need unsolicited neighbor
advertisement for gateway failover. But for internal router
interface, since Router Advertisement is automatically send out by
RADVD after failover, we don't need to send out neighbor
advertisement anymore.
<br>
<br>
Xu Han
<br>
<br>
<br>
On 09/05/2014 03:04 AM, Carl Baldwin wrote:
<br>
<blockquote type="cite">Hi Xu Han,
<br>
<br>
Since I sent my message yesterday there has been some more
discussion
<br>
in the review on that patch set. See [1] again. I think your
<br>
assessment is likely correct.
<br>
<br>
Carl
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py">https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py</a>
<br>
<br>
On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng
<a class="moz-txt-link-rfc2396E" href="mailto:pengxuhan@gmail.com"><pengxuhan@gmail.com></a> wrote:
<br>
<blockquote type="cite">Carl,
<br>
<br>
Thanks a lot for your reply!
<br>
<br>
If I understand correctly, in VRRP case, keepalived will be
responsible for
<br>
sending out GARPs? By checking the code you provided, I can
see all the
<br>
_send_gratuitous_arp_packet call are wrapped by "if not is_ha"
condition.
<br>
<br>
Xu Han
<br>
<br>
<br>
<br>
On 09/04/2014 06:06 AM, Carl Baldwin wrote:
<br>
<br>
It should be noted that "send_arp_for_ha" is a configuration
option
<br>
that preceded the more recent in-progress work to add VRRP
controlled
<br>
HA to Neutron's router. The option was added, I believe, to
cause the
<br>
router to send (default) 3 GARPs to the external gateway if
the router
<br>
was removed from one network node and added to another by some
<br>
external script or manual intervention. It did not send
anything on
<br>
the internal network ports.
<br>
<br>
VRRP is a different story and the code in review [1] sends
GARPs on
<br>
internal and external ports.
<br>
<br>
Hope this helps avoid confusion in this discussion.
<br>
<br>
Carl
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py">https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py</a>
<br>
<br>
On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng
<a class="moz-txt-link-rfc2396E" href="mailto:pengxuhan@gmail.com"><pengxuhan@gmail.com></a> wrote:
<br>
<br>
Anthony,
<br>
<br>
Thanks for your reply.
<br>
<br>
If HA method like VRRP are used for IPv6 router, according to
the VRRP RFC
<br>
with IPv6 included, the servers should be auto-configured with
the active
<br>
router's LLA as the default route before the failover happens
and still
<br>
remain that route after the failover. In other word, there
should be no need
<br>
to use two LLAs for default route of a subnet unless load
balance is
<br>
required.
<br>
<br>
When the backup router become the master router, the backup
router should be
<br>
responsible for sending out an unsolicited ND neighbor
advertisement with
<br>
the associated LLA (the previous master's LLA) immediately to
update the
<br>
bridge learning state and sending out router advertisement
with the same
<br>
options with the previous master to maintain the route and
bridge learning.
<br>
<br>
This is shown in
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-4.1">http://tools.ietf.org/html/rfc5798#section-4.1</a> and the
<br>
actions backup router should take after failover is documented
here:
<br>
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-6.4.2">http://tools.ietf.org/html/rfc5798#section-6.4.2</a>. The need for
immediate
<br>
messaging sending and periodic message sending is documented
here:
<br>
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5798#section-2.4">http://tools.ietf.org/html/rfc5798#section-2.4</a>
<br>
<br>
Since the keepalived manager support for L3 HA is merged:
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/68142/43">https://review.openstack.org/#/c/68142/43</a>. And keepalived
release 1.2.0
<br>
supports VRRP IPv6 features (
<a class="moz-txt-link-freetext" href="http://www.keepalived.org/changelog.html">http://www.keepalived.org/changelog.html</a>, see
<br>
Release 1.2.0 | VRRP IPv6 Release). I think we can check if
keepalived can
<br>
satisfy our requirement here and if that will cause any
conflicts with
<br>
RADVD.
<br>
<br>
Thoughts?
<br>
<br>
Xu Han
<br>
<br>
<br>
On 08/28/2014 10:11 PM, Veiga, Anthony wrote:
<br>
<br>
<br>
<br>
Anthony and Robert,
<br>
<br>
Thanks for your reply. I don't know if the arping is there for
NAT, but I am
<br>
pretty sure it's for HA setup to broadcast the router's own
change since the
<br>
arping is controlled by "send_arp_for_ha" config. By checking
the man page
<br>
of arping, you can find the "arping -A" we use in code is
sending out ARP
<br>
REPLY instead of ARP REQUEST. This is like saying "I am here"
instead of
<br>
"where are you". I didn't realized this either until Brain
pointed this out
<br>
at my code review below.
<br>
<br>
<br>
That’s what I was trying to say earlier. Sending out the RA
is the same
<br>
effect. RA says “I’m here, oh and I’m also a router” and
should supersede
<br>
the need for an unsolicited NA. The only thing to consider
here is that RAs
<br>
are from LLAs. If you’re doing IPv6 HA, you’ll need to have
two gateway IPs
<br>
for the RA of the standby to work. So far as I know, I think
there’s still
<br>
a bug out on this since you can only have one gateway per
subnet.
<br>
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://linux.die.net/man/8/arping">http://linux.die.net/man/8/arping</a>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py">https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py</a>
<br>
<br>
Thoughts?
<br>
<br>
Xu Han
<br>
<br>
<br>
On 08/27/2014 10:01 PM, Veiga, Anthony wrote:
<br>
<br>
<br>
Hi Xuhan,
<br>
<br>
What I saw is that GARP is sent to the gateway port and also
to the router
<br>
ports, from a neutron router. I’m not sure why it’s sent to
the router ports
<br>
(internal network). My understanding for arping to the gateway
port is that
<br>
it is needed for proper NAT operation. Since we are not
planning to support
<br>
ipv6 NAT, so this is not required/needed for ipv6 any more?
<br>
<br>
<br>
I agree that this is no longer necessary.
<br>
<br>
<br>
There is an abandoned patch that disabled the arping for ipv6
gateway port:
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py">https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py</a>
<br>
<br>
thanks,
<br>
Robert
<br>
<br>
On 8/27/14, 1:03 AM, "Xuhan Peng" <a class="moz-txt-link-rfc2396E" href="mailto:pengxuhan@gmail.com"><pengxuhan@gmail.com></a>
wrote:
<br>
<br>
As a follow-up action of yesterday's IPv6 sub-team meeting, I
would like to
<br>
start a discussion about how to support l3 agent HA when IP
version is IPv6.
<br>
<br>
This problem is triggered by bug [1] where sending gratuitous
arp packet for
<br>
HA doesn't work for IPv6 subnet gateways. This is because
neighbor discovery
<br>
instead of ARP should be used for IPv6.
<br>
<br>
My thought to solve this problem turns into how to send out
neighbor
<br>
advertisement for IPv6 routers just like sending ARP reply for
IPv4 routers
<br>
after reading the comments on code review [2].
<br>
<br>
I searched for utilities which can do this and only find a
utility called
<br>
ndsend [3] as part of vzctl on ubuntu. I could not find
similar tools on
<br>
other linux distributions.
<br>
<br>
There are comments in yesterday's meeting that it's the new
router's job to
<br>
send out RA and there is no need for neighbor discovery. But
we didn't get
<br>
enough time to finish the discussion.
<br>
<br>
<br>
Because OpenStack runs the l3 agent, it is the router.
Instead of needing
<br>
to do gratuitous ARP to alert all clients of the new MAC, a
simple RA from
<br>
the new router for the same prefix would accomplish the same,
without having
<br>
to resort to a special package to generate unsolicited NA
packets. RAs must
<br>
be generated from the l3 agent anyway if it’s the gateway, and
we’re doing
<br>
that via radvd now. The HA failover simply needs to start the
proper radvd
<br>
process on the secondary gateway and resume normal operation.
<br>
<br>
<br>
Can you comment your thoughts about how to solve this problem
in this
<br>
thread, please?
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/neutron/+bug/1357068">https://bugs.launchpad.net/neutron/+bug/1357068</a>
<br>
<br>
[2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/114437/">https://review.openstack.org/#/c/114437/</a>
<br>
<br>
[3]
<a class="moz-txt-link-freetext" href="http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html">http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html</a>
<br>
<br>
Thanks,
<br>
Xu Han
<br>
<br>
<br>
<br>
-Anthony
<br>
<br>
<br>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
</blockquote>
_______________________________________________
<br>
OpenStack-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>