Open Stack

Does running the python script with ip netns exec not work correctly?

On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng <pengxuhan at gmail.com> wrote:
> Hi,
>
> 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 scapy:
>
> http://www.secdev.org/projects/scapy/
>
> http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf
>
>
> 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?
>
> Thanks,
> Xu Han
>
>
> On 09/05/2014 05:46 PM, Xu Han Peng wrote:
>
> Carl,
>
> 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.
>
> 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.
>
> Xu Han
>
>
> On 09/05/2014 03:04 AM, Carl Baldwin wrote:
>
> 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 <pengxuhan at 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 <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
>
>
>
> _______________________________________________
> 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
>



-- 
Kevin Benton