Re: [openstack-dev] Status of Neutron IPv6 dual stack
Harm, We were not able to enable dual stack with l3 routers in Juno release. You may need to wait for Kilo to see if that can be pushed in. Xu Han — Xu Han Peng (xuhanp) On Sat, Nov 22, 2014 at 3:03 AM, Harm Weites h...@weites.com wrote: Hi, We're running Juno since a few weeks now, is it now possible to go dual stack with l3-routers or are there some pieces missing and should I wait for Kilo? -Harm On 08/19/2014 07:08 PM, Dane Leblanc (leblancd) wrote: Hi Harm: Unfortunately I haven’t had time to complete the changes yet. Even if/when these changes are completed, it’s unlikely that this blueprint will get approved for Juno, but I’ll see what I can do. Thanks, Dane *From:*Harm Weites [mailto:h...@weites.com] *Sent:* Tuesday, August 19, 2014 12:53 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack Thiago, My old setup was dual-stacked, simply using a flat linuxbridge. It's just that I now realy would like to separate multiple tenants using L3 routers, which should be easy (dual stacked) to achieve once Dane's work is completed. Did you find the time to commit those required changes for that yet Dane? Regards, Harm op 16-08-14 23:33, Martinx - ジェームズ schreef: Guys, Just for the record, I'm using IceHouse in a Dual-Stacked environment (with security groups working) but, Instance's IPv6 address are static (no upstream SLAAC, arrived in Juno-2, I think) and the topology is `VLAN Provider Networks`, no Neutron L3 Router. Where each VLAN have v4/v6 addrs, same upstream router (also dual-stacked - still no radvd enabled). Looking forward to start testing L3 + IPv6 in K... Best, Thiago On 16 August 2014 16:21, Harm Weites h...@weites.com mailto:h...@weites.com wrote: Hi Dane, Thanks, that looks promising. Once support for multiple v6 addresses on gateway ports is added I'll be happy to give this a go. Should it work just fine with an otherwise Icehouse based deployment? Regards, Harm op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: Hi Harm: Can you take a look at the following, which should address this: https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes There are some diffs out for review for this blueprint: https://review.openstack.org/#/c/113339/ but the change to support 1 V4 + multiple V6 addresses on a gateway port hasn't been added yet. I should be adding this soon. There was a request for a Juno feature freeze exception for this blueprint, but there's been no response, so this may not get approved until K release. -Dane -Original Message- From: Harm Weites [mailto:h...@weites.com mailto:h...@weites.com] Sent: Saturday, August 16, 2014 2:22 PM To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] Status of Neutron IPv6 dual stack Hi, Given the work on [1] has been abandoned, I'm wondering what the current status of going dual stack is. Of course, given Neutron got something like that on it's roadmap. The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of something similar to achieve a dual stack network. What are the options, if any? To my knowledge it all comes down to supporting multiple exterior interfaces (networks) on a l3-agent, which is currently limited to just 1: either IP4 or IP6. [1] https://review.openstack.org/#/c/77471/ [2] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port Regards, Harm ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
[openstack-dev] [Neutron] IPv6 team summit meetup
Hey, Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)? We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go to lunch together after that. Xu Han — Sent from Mailbox for iPhone___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Can Neutron VPNaaS work with strongswan? (Openswan removed from Debian)
There is a blueprint for supporting StrongSwan in Kilo release: https://review.openstack.org/#/c/101457/ Xu Han — Xu Han Peng (xuhanp) On Sun, Oct 12, 2014 at 12:26 PM, Thomas Goirand z...@debian.org wrote: Hi, As you may know, OpenSwan has been largely unmaintained in Debian, and then was removed from Testing, and then Sid last summer. OpenSwan had some unaddressed security issues, and removing it from Debian was IMO the correct thing to do. Ubuntu followed, and Utopic doesn't have OpenSwan anymore either. Though there's StrongSwan, which is apparently an alternative. But can Neutron work with it? If not, how much work would it be to make Neutron use StrongSwan instead of OpenSwan, and could the maintainers of the VPNaaS people do this be worked on for Kilo? BTW, why not using something as popular as OpenVPN, which has more chances to be well maintained? Cheers, Thomas Goirand (zigo) ___ 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] [neutron][IPv6] Neighbor Discovery for HA
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. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Not support dnsmasq 2.63?
We bumped the minimum version of dnsmasq to 2.63 a while ago by this code change: https://review.openstack.org/#/c/105378/ However, currently we still kind of support earlier version of dnsmasq because we only give a warning and don't exit the program when we find dnsmasq version is less than the minimum version. This causes some confusion and complicates the code since we need to take care different syntax of dnsmasq of different version in dhcp code (Note that the previous version doesn't support tag). I wonder what's your opinion on NOT supporting dnsmasq version less than 2.63 in Juno? I think we can prompt error message and exit the program when we detect invalid version but I would like to gather more thoughts on this one. Thanks, Xu Han ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [Spec freeze exception] Support Stateful and Stateless DHCPv6 by dnsmasq
Thanks Kyle and everyone for supporting this! Will try the best to make the code ready for Juno-3. Xu Han — Sent from Mailbox for iPhone On Fri, Jul 25, 2014 at 11:06 PM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 24, 2014 at 8:46 PM, CARVER, PAUL pc2...@att.com wrote: Collins, Sean wrote: On Wed, Jul 23, 2014 at 12:06:06AM EDT, Xu Han Peng wrote: I would like to request one Juno Spec freeze exception for Support Stateful and Stateless DHCPv6 by dnsmasq BP. The spec is under review: https://review.openstack.org/#/c/102411/ Code change for this BP is submitted as well for a while: https://review.openstack.org/#/c/106299/ I'd like to +1 this request, if this work landed in Juno, this would mean Neutron would have 100% support for all IPv6 subnet attribute settings, since slaac support landed in J-2. +1 on this from me too. It's getting more and more difficult to keep claiming OpenStack will have IPv6 any day now and not having it in Juno will hurt credibility a lot. IPv4 address space is basically gone. ATT has a fair amount of it but even we're feeling the pinch. A lot of companies have it worse. NAT is a mediocre stop-gap at best. We've been running IPv6 in production for well over a year. Our pre-OpenStack environments support IPv6 where needed even though we have a lot of IPv4 running where we aren't feeling immediate pressure. We're having to turn internal applications away from our OpenStack based cloud because they require IPv6 and we can't provide it. We're actively searching for workarounds but none of them are attractive. I've given a spec exception to this, and targeted this work at Juno-3 as medium priority. Given that at the start of Juno we agreed to get to IPV6 parity in Juno, this one falls into the community work area for exceptions. Thanks, Kyle ___ 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
Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency
Sorry to interrupt this discussion. Sean, Since I'm working the neutron client code change, by looking at your code change to nova client, looks like only X-Auth-Token is taken care of in http_log_req. There is also password in header and token id in response. Any particular reason that they are not being taken care of? Thanks, Xu Han — Sent from Mailbox for iPhone On Fri, Jun 13, 2014 at 8:47 AM, Gordon Chung chu...@ca.ibm.com wrote: I'm hoping we can just ACK this approach, and get folks to start moving patches through the clients to clean this all up. just an fyi, in pyCADF, we obfuscate tokens similar to how credit cards are handled: by capturing a percentage of leading and trailing characters and substituting the middle ie. 4724 8478. whatever we decide here, i'm all for having a consistent way of masking and minimising tokens in OpenStack. cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
Robert, I have plan to file a BP to add egress rule to stop RA sending from VM. However, we will still need rules to dropped rogue RA for provider network RA, right? There is no other ways we can tell which RA is legitimate from OpenStack's perspective except using the LLA gateway provided by network admin. Thoughts? Xuhan On Thu, May 8, 2014 at 8:22 PM, Robert Li (baoli) ba...@cisco.com wrote: Hi Xuhan, I agree that such subnet shouldn’t be allowed to be added in a neutron router. However, I have some reservations in creating a subnet with an external LLA gateway address. First of all, it seems that the sole purpose of providing the gateway IP is to install an RA rule to permit RAs from that gateway. Secondly, what if the gateway IP needs to be changed? Would that incur updates in the neutron subnets that refer to it? I think that we need a better strategy for RA spoofing. Currently, rogue RAs are dropped at the receiving end. Would it be better to stop them at the source and to allow RAs being SENT from the legitimate sources only? thanks, Robert On 4/25/14, 5:46 AM, Xuhan Peng pengxu...@gmail.com wrote: Sean and Robert, Sorry for replying this late, but after giving this a second thought, I think it makes sense to not allow a subnet with a LLA gateway IP address to be attached to a neutron router for the following reasons: 1. A subnet with LLA address gateway specified is only used to receive RA from provider router. I could not think of any other use case that a user want to specify LLA address gateway for an Neutron subnet. 2. Attach a subnet with LLA (or even any address outside subnet's cidr) will cause the port have two LLA (or another address outside subnet's cidr) on the subnet gateway port (qr-). This will confuse dnsmasq about binding with which address. 3. For allowing RA sending from dnsmasq on gateway port, we can use ip command to get the LLA. Currently I use calculation method to get the source address, but I will improve it to use ip command to make sure the source IP is right. Thoughts? If we all agree, I will open a bug to disallow subnet with gateway outside CIDR be attached to a router. Xuhan On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) ba...@cisco.comwrote: Hi Sean, Unless I have missed something, this is my thinking: -- I understand that the goal is to allow RAs from designated sources only. -- initially, xuhanp posted a diff for https://review.openstack.org/#/c/72252. And my comment was that subnet that was created with gateway ip not on the same subnet can't be added into the neutron router. -- as a result, https://review.openstack.org/#/c/76125/ was posted to address that issue. With that diff, LLA would be allowed. But a consequence of that is a gateway port would end up having two LLAs: one that is automatically generated, the other from the subnet gateway IP. -- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if openstack native RA is enabled, then the automatically generated LLA will be used; and if it's not enabled, it will use the external gateway's LLA. And the diff seems to indicate this LLA comes from the subnet's gateway IP. -- Therefore, the change of https://review.openstack.org/#/c/76125/ seems to be able to add the gateway IP as an external gateway. -- Thus, my question is: should such a subnet be allowed to add in a router? And if it should, what would the semantics be? If not, proper error should be provided to the user. I'm also trying to figure out the reason that such a subnet needs to be created in neutron (other than creating L2 ports for VMs). -- Another thought is that if the RA is coming from the provider net, then the provider net should have installed mechanisms to prevent rogue RAs from entering the network. There are a few RFCs that address the rogue RA issue. see inline as well. I hope that I didn't confuse you guys. Thanks, Robert On 3/25/14 2:18 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: During the review[0] of the patch that only allows RAs from known addresses, Robert Li brought up a bug in Neutron, where a IPv6 Subnet could be created, with a link local address for the gateway, that would fail to create the Neutron router because the IP address that the router's port would be assigned, was a link local address that was not on the subnet. This may or may have been run before force_gateway_on_subnet flag was introduced. Robert - if you can give us what version of Neutron you were running that would be helpful. [Robert] I'm using the latest Here's the full text of what Robert posted in the review, which shows the bug, which was later filed[1]. This is what I've tried, creating a subnet with a LLA gateway address: neutron subnet-create --ip-version 6 --name myipv6sub --gateway fe80::2001:1 mynet :::/64 Created a new subnet
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
Sean and Robert,
Sorry for replying this late, but after giving this a second thought, I
think it makes sense to not allow a subnet with a LLA gateway IP address to
be attached to a neutron router for the following reasons:
1. A subnet with LLA address gateway specified is only used to receive RA
from provider router. I could not think of any other use case that a user
want to specify LLA address gateway for an Neutron subnet.
2. Attach a subnet with LLA (or even any address outside subnet's cidr)
will cause the port have two LLA (or another address outside subnet's cidr)
on the subnet gateway port (qr-). This will confuse dnsmasq about
binding with which address.
3. For allowing RA sending from dnsmasq on gateway port, we can use ip
command to get the LLA. Currently I use calculation method to get the
source address, but I will improve it to use ip command to make sure the
source IP is right.
Thoughts? If we all agree, I will open a bug to disallow subnet with
gateway outside CIDR be attached to a router.
Xuhan
On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) ba...@cisco.com wrote:
Hi Sean,
Unless I have missed something, this is my thinking:
-- I understand that the goal is to allow RAs from designated sources
only.
-- initially, xuhanp posted a diff for
https://review.openstack.org/#/c/72252. And my comment was that subnet
that was created with gateway ip not on the same subnet can't be added
into the neutron router.
-- as a result, https://review.openstack.org/#/c/76125/ was posted to
address that issue. With that diff, LLA would be allowed. But a
consequence of that is a gateway port would end up having two LLAs: one
that is automatically generated, the other from the subnet gateway IP.
-- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if
openstack native RA is enabled, then the automatically generated LLA will
be used; and if it's not enabled, it will use the external gateway's LLA.
And the diff seems to indicate this LLA comes from the subnet's gateway
IP.
-- Therefore, the change of https://review.openstack.org/#/c/76125/
seems to be able to add the gateway IP as an external gateway.
-- Thus, my question is: should such a subnet be allowed to add in a
router? And if it should, what would the semantics be? If not, proper
error should be provided to the user. I'm also trying to figure out the
reason that such a subnet needs to be created in neutron (other than
creating L2 ports for VMs).
-- Another thought is that if the RA is coming from the provider net, then
the provider net should have installed mechanisms to prevent rogue RAs
from entering the network. There are a few RFCs that address the rogue RA
issue.
see inline as well.
I hope that I didn't confuse you guys.
Thanks,
Robert
On 3/25/14 2:18 PM, Collins, Sean sean_colli...@cable.comcast.com
wrote:
During the review[0] of the patch that only allows RAs from known
addresses, Robert Li brought up a bug in Neutron, where a
IPv6 Subnet could be created, with a link local address for the gateway,
that would fail to create the Neutron router because the IP address that
the router's port would be assigned, was a link local
address that was not on the subnet.
This may or may have been run before force_gateway_on_subnet flag was
introduced. Robert - if you can give us what version of Neutron you were
running that would be helpful.
[Robert] I'm using the latest
Here's the full text of what Robert posted in the review, which shows
the bug, which was later filed[1].
This is what I've tried, creating a subnet with a LLA gateway address:
neutron subnet-create --ip-version 6 --name myipv6sub --gateway
fe80::2001:1 mynet :::/64
Created a new subnet:
+--+
+
| Field | Value |
+--+
+
| allocation_pools | {start: :::1, end:
::::::fffe} | | cidr | :::/64 | |
dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1
| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | |
ip_version | 6 | | name | myipv6sub | | network_id |
9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id |
fa96d90f267b4a93a5198c46fc13abd9 |
+--+
+
openstack@devstack-16:~/devstack$ neutron router-list
+--+-+--
---+
| id | name | external_gateway_info
|
+--+-+--
---+
| 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {network_id:
02673c3c-35c3-40a9-a5c2-9e5c093aca48, enable_snat: true}
|
Re: [openstack-dev] [Neutron][IPv6] Agenda for tomorrow - please add topics
Sean, I've added Salvatore's code review of Hide ipv6 subnet API attributes to our discussion list. https://review.openstack.org/#/c/85869/ Xuhan On Tue, Apr 8, 2014 at 4:49 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: Hi, I've added a section for tomorrow's agenda, please do add topics that you'd like to discuss. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_8th -- Sean M. Collins ___ 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] [Neutron] DHCP address being SNAT by L3 agent
Hi Neutron stackers, I have a question about how to fix the problem of DHCP port address being SNAT by L3 agent. I have my neutron DHCP agent and L3 agent running on the same network node, and I disabled namespace usage in both agent configuration. I have one router created with one external network and one internal network attached. After enable the security group settings, I found that VMs on the compute node cannot get DHCP message from dnsmasq on DHCP port of network node. After future investigation by tcpdump the package from network node DHCP port, I figured the source IP in the DHCP message sending from DHCP port has been SNAT'ed into the external gateway IP address by L3 agent. Therefore, the security group rule to allow DHCP sending from internal DHCP address doesn't work anymore. Chain neutron-vpn-agen-snat (1 references) target prot opt source destination neutron-vpn-agen-float-snat all -- anywhere anywhere SNAT all -- 10.1.1.0/24 anywhere to:192.168.1.113 DHCP port address 10.1.1.2 is in the cidr of source IP being SNAT'ed. This only happens when DHCP agent and L3 agent is on the same node and they both have namespace disabled. To fix this, I think we can either: 1. Add a return rule before the SNAT rule for DHCP port so the SNAT won't be applied for DHCP port. 2. break the source cidr of the SNAT rule into IP ranges to exclude DHCP address. What's your opinion on this? Xuhan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [IPv6] Supporting upstream RAs
Sean, Sure. Thanks for fixing this. Xuhan On Tue, Apr 8, 2014 at 3:42 PM, Da Zhao Y Yu d...@cn.ibm.com wrote: Hi Sean, That's OK for me, thanks for your work. Thanks Best Regards Yu Da Zhao(于大钊) -- Cloud Solutions OpenStack Development China Systems Technology Laboratory in Beijing Email: d...@cn.ibm.com Tel: (86)10-82450677 -- ___ 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
Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
Martinx, Here is Shi Xiong's patch link: https://review.openstack.org/#/c/70649/ If you can use git, you can try: git fetch https://review.openstack.org/openstack/neutronrefs/changes/49/70649/15 git format-patch -1 --stdout FETCH_HEAD It may cause some code merge effort after you apply the patch. Xuhan On Wed, Apr 2, 2014 at 2:33 AM, Martinx - ジェームズ thiagocmarti...@gmail.comwrote: Guys! I would like to do this: 1- Create and maintain a Ubuntu PPA Archive to host Neutron with IPv6 patches (from Nephos6 / Shixiong?). Why? Well, I'm feeling that Neutron with native and complete IPv6 support will be only available in October (or maybe later, am I right?) but, I really need this (Neutron IPv6) ASAP, so, I'm volunteering myself to create / maintain this PPA for Neutron with IPv6, until it reaches mainline. To be able to achieve it, I just need to know which files do I need to patch (the diff), then repackage Neutron deb packages but, I'll need help here, because I don't know where are those Neutron IPv6 patches (links?)... Let me know if there are interest on this... Thanks! Thiago ___ 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
Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group
Thanks all for your comments! Do you guys think we can have a summit session to discuss the next steps? I can prepare a spec if needed. Thanks, Xuhan — Xu Han Peng (xuhanp) On Sat, Mar 8, 2014 at 3:19 AM, Akihiro Motoki amot...@gmail.com wrote: Hi Robert, Thanks for the clarification. I understand the motivation. I think the problem can be split into two categories: (a) user configurable rules vs infra enforced rule, and (b) DHCP/RA service exists inside or outside of Neutron Regarding (a), I believe DHCP or RA related rules is better to be handled by the infra side because it is required to ensure DHCP/RA works well. I don't think it is a good idea to delegate users to configure rule to allow them. It works as long as DHCP/RA service works inside OpenStack. This is the main motivation of my previous question. On the other hand, there is no way to cooperate with DHCP/RA services outside of OpenStack at now. This blocks the usecase in your mind. It is true that the current Neutron cannot works with dhcp server outside of neutron. I agree that adding a security group rule to allow RA is reasonable as a workaround. However, for a long time solution, it is better to explore a way to configure infra-required rules. Thanks, Akihiro On Sat, Mar 8, 2014 at 12:50 AM, Robert Li (baoli) ba...@cisco.com wrote: Hi Akihiro, In the case of IPv6 RA, its source IP is a Link Local Address from the router's RA advertising interface. This LLA address is automatically generated and not saved in the neutron port DB. We are exploring the idea of retrieving this LLA if a native openstack RA service is running on the subnet. Would SG be needed with a provider net in which the RA service is running external to openstack? In the case of IPv4 DHCP, the dhcp port is created by the dhcp service, and the dhcp server ip address is retrieved from this dhcp port. If the dhcp server is running outside of openstack, and if we'd only allow dhcp packets from this server, how is it done now? thanks, Robert On 3/7/14 12:00 AM, Akihiro Motoki amot...@gmail.com wrote: I wonder why RA needs to be exposed by security group API. Does a user need to configure security group to allow IPv6 RA? or should it be allowed in infra side? In the current implementation DHCP packets are allowed by provider rule (which is hardcoded in neutron code now). I think the role of IPv6 RA is similar to DHCP in IPv4. If so, we don't need to expose RA in security group API. Am I missing something? Thanks, Akihiro On Mon, Mar 3, 2014 at 10:39 PM, Xuhan Peng pengxu...@gmail.com wrote: I created a new blueprint [1] which is triggered by the requirement to allow IPv6 Router Advertisement security group rule on compute node in my on-going code review [2]. Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow Router Advertisement coming from network node or provider network to VM on compute node, we need to specify ICMP type to only allow RA from known hosts (network node dnsmasq binded IP or known provider gateway). To implement this and make the implementation extensible, maybe we can add an additional table name SecurityGroupRuleData with Key, Value and ID in it. For ICMP type RA filter, we can add key=icmp-type value=134, and security group rule to the table. When other ICMP type filters are needed, similar records can be stored. This table can also be used for other firewall rule key values. API change is also needed. Please let me know your comments about this blueprint. [1] https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-f ilter [2] https://review.openstack.org/#/c/72252/ Thank you! Xuhan Peng ___ 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
Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group
Sean, you are right. It doesn't work at all. So I think short term goal is to get that fixed for ICMP and long term goal is to write an extension as Amir pointed out? On Wed, Mar 5, 2014 at 1:55 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, Mar 04, 2014 at 12:01:00PM -0500, Brian Haley wrote: On 03/03/2014 11:18 AM, Collins, Sean wrote: On Mon, Mar 03, 2014 at 09:39:42PM +0800, Xuhan Peng wrote: Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow If I am not mistaken, I believe that when you use the ICMP protocol type, you can use the port range specs to limit the type. https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py#L309 http://i.imgur.com/3n858Pf.png I assume we just have to check and see if it applies to ICMPv6? I tried using horizon to add an icmp type/code rule, and it didn't work. Before: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN After: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN I'd assume I'll have the same error with v6. I am curious what's actually being done under the hood here now... Looks like _port_arg just returns an empty array when hte protocol is ICMP? https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L328 Called by: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L292 -- Sean M. Collins ___ 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
Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group
I opened a bug [1] and submitted a patch [2] to solve this short term (hopefully for Icehouse) [1] https://bugs.launchpad.net/neutron/+bug/1289088 [2] https://review.openstack.org/#/c/78835/ Xuhan On Thu, Mar 6, 2014 at 5:42 PM, Xuhan Peng pengxu...@gmail.com wrote: Sean, you are right. It doesn't work at all. So I think short term goal is to get that fixed for ICMP and long term goal is to write an extension as Amir pointed out? On Wed, Mar 5, 2014 at 1:55 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, Mar 04, 2014 at 12:01:00PM -0500, Brian Haley wrote: On 03/03/2014 11:18 AM, Collins, Sean wrote: On Mon, Mar 03, 2014 at 09:39:42PM +0800, Xuhan Peng wrote: Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow If I am not mistaken, I believe that when you use the ICMP protocol type, you can use the port range specs to limit the type. https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py#L309 http://i.imgur.com/3n858Pf.png I assume we just have to check and see if it applies to ICMPv6? I tried using horizon to add an icmp type/code rule, and it didn't work. Before: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN After: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN I'd assume I'll have the same error with v6. I am curious what's actually being done under the hood here now... Looks like _port_arg just returns an empty array when hte protocol is ICMP? https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L328 Called by: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L292 -- Sean M. Collins ___ 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] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group
I created a new blueprint [1] which is triggered by the requirement to allow IPv6 Router Advertisement security group rule on compute node in my on-going code review [2]. Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow Router Advertisement coming from network node or provider network to VM on compute node, we need to specify ICMP type to only allow RA from known hosts (network node dnsmasq binded IP or known provider gateway). To implement this and make the implementation extensible, maybe we can add an additional table name SecurityGroupRuleData with Key, Value and ID in it. For ICMP type RA filter, we can add key=icmp-type value=134, and security group rule to the table. When other ICMP type filters are needed, similar records can be stored. This table can also be used for other firewall rule key values. API change is also needed. Please let me know your comments about this blueprint. [1] https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-filter [2] https://review.openstack.org/#/c/72252/ Thank you! Xuhan Peng ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] New Subnet options editable?
Abishek, The two attributes are editable if you look at Sean's patch https://review.openstack.org/#/c/52983/27/neutron/api/v2/attributes.py. The allow_put is set to be True for these two attributes. Xuhan On Sat, Mar 1, 2014 at 2:26 AM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi, I just wanted to find out if the ipv6_ra_mode and ipv6_address_mode fields are editable using neutron subnet-update? Or are they meant to be non-editable fields like the cidr addresses? Thanks! On 2/28/14 10:55 AM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi, I just wanted to find out if anyone had been able to test using Horizon? Was everything ok? Additionally wanted to confirm - the two modes can be updated too yes when using neutron subnet-update? Thanks! On 2/18/14 12:58 PM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi shshang, all, I have some preliminary Horizon diffs available and if anyone would be kind enough to patch them and try to test the functionality, I'd really appreciate it. I know I'm able to create subnets successfully with the two modes but if there's anything else you'd like to test or have any other user experience comments, please feel free to let me know. The diffs are at - https://review.openstack.org/74453 Thanks!! ___ 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
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Randy, I may need some time to review your latest code change to the blueprint you mentioned. But I think we can discuss this in the coming IPv6 sub team meeting. Xuhan On Mon, Mar 3, 2014 at 11:20 AM, Randy Tuttle randy.m.tut...@gmail.comwrote: Hi Yuhan Sorry I am slow to respond, but I was catching up on some emails and found this one from you. Regarding your comments on the RA from the router gateway port... I disagree that the LLA for the qg- interface is (or should be) the gateway for the tenant's subnet. On the contrary, it should be the LLA of the qr- to which the dnsmasq binds [2]. Using [1] as a starting point, packets arriving on the qr- interface are routed across (via linux) in the qrouter-namespace, taking the default route (gateway-ip) as specified in [1] to unknown destinations. In a future release, we may need to consider implementing support for accepting RA from service providers' upstream routers on the qg- interface, but whether we allow a SLAAC address on the external gateway port needs further discussion (perhaps a topic for the IPv6 sub-team IRC). SLAAC requires a /64 subnet which might be considered a bit of overkill for what's typically a point-to-point connection. Let's see about adding it to the topics to discuss. Cheers, Randy [1] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port [2] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace On Thu, Feb 27, 2014 at 12:49 AM, Xuhan Peng pengxu...@gmail.com wrote: As the follow up action of IPv6 sub-team meeting [1], I created a new blueprint [2] to store both IPv6 LLA and GUA address on router interface port. Here is what it's about: Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA can be sent from both openstack controlled dnsmasq or existing devices. RA From dnsmasq: gateway ip that dnsmasq binds into should be link local address (LLA) according to [4]. This means we need to pass the LLA of the created router internal port (i.e. qr-) to dnsmasq spawned by openstack dhcp agent. In the mean while, we need to assign an GUA to the created router port so that the traffic from external network can be routed back using the GUA of the router port as the next hop into the internal subnet. Therefore, we will need some change to the current logic to leverage both LLA and GUA on router port. RA from existing device on the same link which is not controlled by openstack: dnsmasq will not send RA in this case. RA is sending from subnet's gateway address which should also be LLA according to [4]. Allowing subnet's gateway IP to be LLA is enough in this case. Current code works when force_gateway_on_subnet = False. RA from router gateway port (i.e. qg-): the LLA of the gateway port (qg-) should be set as the gateway of tenant subnet to get the RA from that. This could be potentially calculated by [5] or by other methods in the future considering privacy extension. However, this will make the tenant network gateway port qr- useless. Therefore, we also need code change to current router interface attach logic. If you have any comments on this, please let me know. [1] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html [2] https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [4] http://tools.ietf.org/html/rfc4861 [5] https://review.openstack.org/#/c/56184/ ___ 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
Re: [openstack-dev] [Neutron][IPv6]
Randy, I haven't checked the code detail yet, but I have a general question about this blueprint. Considering multiple external networks on L3 agent is supported [1]. Do you think it's still necessary to use separate subnets on one external network for IPv4 and IPv6 instead of using two external networks? [1] https://review.openstack.org/#/c/59359/ Thanks! Xuhan On Mon, Mar 3, 2014 at 10:47 AM, Randy Tuttle randy.m.tut...@gmail.comwrote: Hi all. Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on an external gateway port of a tenant's router (l3_agent). It implements [2]. Please, if you would, have a look and provide any feedback. I would be grateful. Cheers, Randy [1]. https://review.openstack.org/#/c/77471/ [2]. https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port ___ 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
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Robert, Thanks for your comments! See my replies inline. On Thu, Feb 27, 2014 at 9:56 PM, Robert Li (baoli) ba...@cisco.com wrote: Hi Xuhan, Thank you for your summary. see comments inline. --Robert On 2/27/14 12:49 AM, Xuhan Peng pengxu...@gmail.com wrote: As the follow up action of IPv6 sub-team meeting [1], I created a new blueprint [2] to store both IPv6 LLA and GUA address on router interface port. Here is what it's about: Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA can be sent from both openstack controlled dnsmasq or existing devices. RA From dnsmasq: gateway ip that dnsmasq binds into should be link local address (LLA) according to [4]. This means we need to pass the LLA of the created router internal port (i.e. qr-) to dnsmasq spawned by openstack dhcp agent. In the mean while, we need to assign an GUA to the created router port so that the traffic from external network can be routed back using the GUA of the router port as the next hop into the internal subnet. Therefore, we will need some change to the current logic to leverage both LLA and GUA on router port. [Robert]: in this case, a LLA address is automatically created based on the gateway port's MAC address (EUI64 format). If it's determined that the gateway port is enabled with IPv6 (due to the two modes), then an RA rule can be installed based on the gateway port's automatic LLA. if a service VM is running on the same subnet that supports IPv6 (either by RA or DHCPv6), then the service VM is attached to a neutron port on the same subnet (the gateway port). In this case, the automatic LLA on that port can be used to install the RA Rule. This is actually the same as in the dnsmasq case: use the gateway port's automatic LLA. [Xuhan] I agree there is no need to create another LLA for gateway port in this case since one is automatically created. We can probably use the calculation method introduced by this patch ( https://review.openstack.org/#/c/56184/) to accomplish this, and create a RA rule based on this address. As you pointed out in my code review, the ICMPv6 type filter is not supported by current security group. We will need a new blueprint to enable this. I will try to create one soon. RA from existing device on the same link which is not controlled by openstack: dnsmasq will not send RA in this case. RA is sending from subnet's gateway address which should also be LLA according to [4]. Allowing subnet's gateway IP to be LLA is enough in this case. Current code works when force_gateway_on_subnet = False. [Robert] if it's a provider network, the gateway already exists. I believe that the behavior of the --gateway option in the subnet API is to indicate the gateway's true IP address and install default route. In the IPv6 case, however, due to the existence of RA, the gateway doesn't have to be provided. In this case, a neutron gateway port doesn't have to be created, either. Installing a RA rule to prevent RA from malicious source should be done explicitly. A couple of methods may be considered. For example, an option such as --alow-ra LLA can be introduced in the subnet API, or the security group rule can be enhanced to allow specification of message type so that a RA rule can be incorporated. [Xuhan] This is a problem that we may not be able to solve in Icehouse considering the time left. However, I think the gateway port is not created until we attach the subnet on the router. Therefore, for a workaround in Icehouse, we can allow LLA as the gateway IP passed to subnet creation, so RA from the provider network gateway LLA can also be allowed. The logic to create RA rule can looks like this: 1. if gateway ip of a subnet is GUA (when dnsmasq or a service VM is sending RA): calculate the gateway port's LLA based on port's MAC address, then allow RA from this LLA. 2. if gateway ip of a subnet is LLA (for provider network existing gateway) allow RA from this LLA. In next release, we can evaluate how to allow RA from existing gateway in a better way. Thoughts? In any case, I don't believe that the gateway behavior should be modified. In addition, I don't think that this functionality (IPv6 RA rule) has to be provided right now, but can be introduced when it's completely sorted out. The above is just my two cents. thanks. RA from router gateway port (i.e. qg-): the LLA of the gateway port (qg-) should be set as the gateway of tenant subnet to get the RA from that. This could be potentially calculated by [5] or by other methods in the future considering privacy extension. However, this will make the tenant network gateway port qr- useless. Therefore, we also need code change to current router interface attach logic. If you have any comments on this, please let me know. [1] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25
Re: [openstack-dev] [Neutron][IPv6]
Here is a list of related blueprint and bug patches: Create new IPv6 attributes for Subnets https://review.openstack.org/#/c/52983/ Ensure entries in dnsmasq belong to a subnet using DHCP https://review.openstack.org/#/c/64578/ Calculate stateless IPv6 address https://review.openstack.org/#/c/56184/ Add support to DHCP agent for BP ipv6-two-attributes https://review.openstack.org/#/c/70649/ Permit ICMPv6 RAs only from known routers https://review.openstack.org/#/c/72252/ Allow LLA as router interface of IPv6 subnet https://review.openstack.org/#/c/76125/ Create new IPv6 attributes for Subnets by client https://review.openstack.org/#/c/75871/ Make sure dnsmasq can distinguish IPv6 address from MAC address https://review.openstack.org/#/c/75355/ On Thu, Feb 27, 2014 at 9:04 AM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Sean and the team: Do we have a list of code reviews and a list of BPs submitted by Neutron IPv6 sub-team targeting at Icehouse 3? Would appreciate everybody's help to compose a list so we won't overlook anything, especially the deadline is next Friday. Thanks! Shixiong *Shixiong Shang* *!--- Stay Hungry, Stay Foolish ---!* ___ 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] [Neutron] DOWN and INACTIVE status in FWaaS and LBaaS
Hello, This email is triggered by the comments I received in my patch [1] when trying to fix bug [2]. The problem I was trying to fix is that current firewall remains in status ACTIVE after admin state is changed to DOWN. My plan is to change the status of firewall from ACTIVE to DOWN when admin state is down, as other network resource is doing currently. But I noticed besides DOWN state, INACTIVE state is also used in FWaaS and LBaaS. So I hope someone can help me understand any background of this. If this is not particularly by design and inconsistent with other network resource, I can open a bug to fix this in FWaaS and LBaaS. Thanks, Xu Han [1]: https://review.openstack.org/#/c/73944/ [2]: https://launchpad.net/bugs/1279213 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DOWN and INACTIVE status in FWaaS and LBaaS
Oleg, Thanks a lot for your quick response! I will open a bug to address that soon. For the LBaaS part, probably I will just make the fix dependent on the code review you mentioned. Xu Han On Wed, Feb 26, 2014 at 6:43 PM, Oleg Bondarev obonda...@mirantis.comwrote: Hi, For LBaaS the background is simple: it uses statuses from neutron/plugins/common/constants.py and INACTIVE was there initially while DOWN appeared later (with VPNaaS first commit). So LBaaS doesn't use DOWN at all. As for INACTIVE, it is currently used only for members that stop responding to health checks. Also there is a patch on review (https://review.openstack.org/#/c/55032) which sets INACTIVE status for resources with admin state down. My personal opinion is that we can easily fix that for LBaaS and replace INACTIVE with DOWN to be consistent with other network resources. Thanks, Oleg On Wed, Feb 26, 2014 at 1:50 PM, Xuhan Peng pengxu...@gmail.com wrote: Hello, This email is triggered by the comments I received in my patch [1] when trying to fix bug [2]. The problem I was trying to fix is that current firewall remains in status ACTIVE after admin state is changed to DOWN. My plan is to change the status of firewall from ACTIVE to DOWN when admin state is down, as other network resource is doing currently. But I noticed besides DOWN state, INACTIVE state is also used in FWaaS and LBaaS. So I hope someone can help me understand any background of this. If this is not particularly by design and inconsistent with other network resource, I can open a bug to fix this in FWaaS and LBaaS. Thanks, Xu Han [1]: https://review.openstack.org/#/c/73944/ [2]: https://launchpad.net/bugs/1279213 ___ 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] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
As the follow up action of IPv6 sub-team meeting [1], I created a new blueprint [2] to store both IPv6 LLA and GUA address on router interface port. Here is what it's about: Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA can be sent from both openstack controlled dnsmasq or existing devices. RA From dnsmasq: gateway ip that dnsmasq binds into should be link local address (LLA) according to [4]. This means we need to pass the LLA of the created router internal port (i.e. qr-) to dnsmasq spawned by openstack dhcp agent. In the mean while, we need to assign an GUA to the created router port so that the traffic from external network can be routed back using the GUA of the router port as the next hop into the internal subnet. Therefore, we will need some change to the current logic to leverage both LLA and GUA on router port. RA from existing device on the same link which is not controlled by openstack: dnsmasq will not send RA in this case. RA is sending from subnet's gateway address which should also be LLA according to [4]. Allowing subnet's gateway IP to be LLA is enough in this case. Current code works when force_gateway_on_subnet = False. RA from router gateway port (i.e. qg-): the LLA of the gateway port (qg-) should be set as the gateway of tenant subnet to get the RA from that. This could be potentially calculated by [5] or by other methods in the future considering privacy extension. However, this will make the tenant network gateway port qr- useless. Therefore, we also need code change to current router interface attach logic. If you have any comments on this, please let me know. [1] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html [2] https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [4] http://tools.ietf.org/html/rfc4861 [5] https://review.openstack.org/#/c/56184/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] NAT64 Discussion
In previous Neutron IPv6 team meeting, we discussed the requirement of providing NAT64 in OpenStack to facilitate the communication between IPv6 and IPv4 hosts. For example, from tenant IPv6 network to external traditional IPv4 network. I was suggested to initiate a discussion in ML to gather all forks thoughts. I wonder if this is a fairly common requirement and what is the good way to add this possibility to OpenStack. Several ways we mentioned in previous sub-team meeting: 1. Add to current Neutron L3 This was also asked by Martinx in [1]. 2. Run as service VM 3. Maybe even a new sub-project/project dedicated for address translation I also want to mention that NAT64 may not be the only requirement to communicate between IPv6 and IPv4 hosts. 6in4 tunneling and other methods are als candidates. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-January/023265.html Your comments are appreciated! Xuhan Peng (irc: xuhanp) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Validating Addressing and Routing configuration
For Question 1, I think we can allow potential use cases (even OpenStack doesn't support it for now), but we should not permit the combinations of modes which don't make any sense. For Question 2, for modes which don't make sense, I think error messages and return code are needed. For mode combinations which require external RA or DHCP, I think it's not OpenStack's job to check the external configurations so we can just configure as the mode suggested in OpenStack and leave the user/admin to configure the external server. Xuhan On Tue, Feb 11, 2014 at 4:38 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: During last week's IRC meeting, we ran into a question about validating the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for IPv6 networks. This brought up a few issues, but after mulling it over for a while I think it breaks down into 2 distinct questions. Question 1) Should we allow the user to build a potentially broken network, knowing that there may be a use case we haven't covered? The example of this is a service VM or corner case where it's absolutely mandatory that an administrator use an external routing/addressing mechanism that doesn't fit under our configuration options. I was asked to put together a list of cases where a potentially invalid configuration for OpenStack is still valid when external entities are in use. One of these is setting ipv6_address_mode to stateful and ipv6_ra_mode to none. Normally, this means a neutron network would never have addressed clients as no RA means no address. However, a provider network with an external router would provide this. So having the addressing mode in any state without an RA is still valid. The opposite case would also be true, where an external source could be providing dhcpv6 information. In this case, addressing could be set to off, but RA could be set to stateful/stateless. The only case where I see a collision is where the two attributes are on but in entirely different modes. For example, RA set to SLAAC but addressing set to stateful. Question 2) How do we alert the user of either a potentially invalid configuration or a configuration that we have blocked? Something else that came up in a Review[2] was that we need to honor enable_dhcp and alert the user as well. Per ijw[3], we are supposed to treat enable_dhcp as an overriding flag. If it's set to false, we don't even check the other two attributes, because we should be disabling addressing for this network. I think the answer to #2 should apply here as well, but I wanted to point out that we should be treating enable_dhcp = False as a killswitch. [1] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [2] https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py [3] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014 -01-21-14.00.log.html timestamp 14:23:54 ___ 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
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Shixiong, I'm fine with the current two modes design. — Xu Han Peng (xuhanp) On Sat, Jan 25, 2014 at 5:17 AM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any decisions yet? Shixiong On Jan 23, 2014, at 7:45 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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
Re: [openstack-dev] [neutron] ML2 vlan type driver does not honor network_vlan_ranges
In my opinion the provider network extension can also be used for mapping
the tenant network directly to the physical network. For example, as shown
in the official admin guide openvswitch scenario1 [1], we can configure
tenant network to use segmentation id 101 to connect to VLAN 101 of
physical switch.
$ neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101
For this kind of use case, I think it makes sense to enforce the
segmentation id in the range of network_vlan_range in ml2_conf.ini
[1]
http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html#under_the_hood_openvswitch_scenario1
On Fri, Jan 17, 2014 at 5:31 AM, Henry Gessau ges...@cisco.com wrote:
network_vlan_ranges is a 'pool' of vlans from which to pick a vlans for
tenant networks. Provider networks are not confined to this pool. In fact,
I
believe it is a more common use-case that provider vlans are outside the
pool so that they do not conflict with tenant vlan allocation.
-- Henry
On Thu, Jan 16, at 3:45 pm, Paul Ward wpw...@us.ibm.com wrote:
In testing some new function I've written, I've unsurfaced the problem
that
the ML2 vlan type driver does not enforce the vlan range specified in the
network_vlan_ranges option in ml2_conf.ini file. It is properly
enforcing
the physical network name, and even checking to be sure the
segmentation_id
is valid in the sense that it's not outside the range of ALL valid vlan
ids.
But it does not actually enforce that segmentation_id is within the vlan
range specified for the given physical network in network_vlan_ranges.
The fix I propose is simple. Add the following check to
/neutron/plugins/ml2/drivers/type_vlan.py
(TypeVlanDriver.validate_provider_segment()):
range_min, range_max =
self.network_vlan_ranges[physical_network][0]
if segmentation_id not in range(range_min, range_max):
msg = (_(segmentation_id out of range (%(min)s through
%(max)s)) %
{'min': range_min,
'max': range_max})
raise exc.InvalidInput(error_message=msg)
This would go near line 182 in
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vlan.py
.
One question I have is whether self.network_vlan_ranges[physical_network]
could actually be an empty list rather than a tuple representing the vlan
range. I believe that should always exist, but the documentation is not
clear on this. For reference, the corresponding line in ml2_conf.ini is
this:
[ml2_type_vlan]
network_vlan_ranges = default:1:4093
Thanks in advance to any that choose to provide some insight here!
___
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] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC? From the attached POC result link, the reason is stated as: Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! Can Randy or Shixiong explain this more? Thanks! Xuhan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
15UTC is 23PM in China, not ideal, but I am OK with that :-) On Fri, Dec 20, 2013 at 8:20 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: I'm easy. On 20 December 2013 00:47, Randy Tuttle randy.m.tut...@gmail.com wrote: Any of those times suit me. Sent from my iPhone On Dec 19, 2013, at 5:12 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Thoughts? I know we have people who are not able to attend at our current time. -- Sean M. Collins ___ 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
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Ian, thanks for asking! I replied in the other thread. It works for me! On Fri, Dec 20, 2013 at 8:23 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: Xuhan, check the other thread - would 1500UTC suit? On 19 December 2013 01:09, Xuhan Peng pengxu...@gmail.com wrote: Shixiong and guys, The sub team meeting is too early for china IBM folks to join although we would like to participate the discussion very much. Any chance to rotate the time so we can comment? Thanks, Xuhan On Thursday, December 19, 2013, Shixiong Shang wrote: Hi, Ian: I agree with you on the point that the way we implement it should be app agnostic. In addition, it should cover both CLI and Dashboard, so the system behavior should be consistent to end users. The keywords is just one of the many ways to implement the concept. It is based on the reality that dnsmasq is the only driver available today to the community. By the end of the day, the input from customer should be translated to one of those mode keywords. It doesn't imply the same constants have to be used as part of the CLI or Dashboard. Randy and I had lengthy discussion/debating about this topic today. We have straw-man proposal and will share with the team tomorrow. That being said, what concerned me the most at this moment is, we are not on the same page. I hope tomorrow during sub-team meeting, we can reach consensus. If you can not make it, then please set up a separate meeting to invite key placeholders so we have a chance to sort it out. Shixiong On Dec 18, 2013, at 8:25 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- Ian. ___ 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
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Shixiong and guys,
The sub team meeting is too early for china IBM folks to join although we
would like to participate the discussion very much. Any chance to rotate
the time so we can comment?
Thanks, Xuhan
On Thursday, December 19, 2013, Shixiong Shang wrote:
Hi, Ian:
I agree with you on the point that the way we implement it should be app
agnostic. In addition, it should cover both CLI and Dashboard, so the
system behavior should be consistent to end users.
The keywords is just one of the many ways to implement the concept. It is
based on the reality that dnsmasq is the only driver available today to the
community. By the end of the day, the input from customer should be
translated to one of those mode keywords. It doesn't imply the same
constants have to be used as part of the CLI or Dashboard.
Randy and I had lengthy discussion/debating about this topic today. We
have straw-man proposal and will share with the team tomorrow.
That being said, what concerned me the most at this moment is, we are not
on the same page. I hope tomorrow during sub-team meeting, we can reach
consensus. If you can not make it, then please set up a separate meeting to
invite key placeholders so we have a chance to sort it out.
Shixiong
On Dec 18, 2013, at 8:25 AM, Ian Wells
ijw.ubu...@cack.org.ukjavascript:_e({}, 'cvml', 'ijw.ubu...@cack.org.uk');
wrote:
On 18 December 2013 14:10, Shixiong Shang
sparkofwisdom.cl...@gmail.comjavascript:_e({}, 'cvml',
'sparkofwisdom.cl...@gmail.com');
wrote:
Hi, Ian:
I won’t say the intent here is to replace dnsmasq-mode-keyword BP.
Instead, I was trying to leverage and enhance those definitions so when
dnsmasq is launched, it knows which mode it should run in.
That being said, I see the value of your points and I also had lengthy
discussion with Randy regarding this. We did realize that the keyword
itself may not be sufficient to properly configure dnsmasq.
I think the point is that the attribute on whatever object (subnet or
router) that defines the behaviour should define the behaviour, in
precisely the terms you're talking about, and then we should find the
dnsmasq options to suit. Talking to Sean, he's good with this too, so
we're all working to the same ends and it's just a matter of getting code
in.
Let us discuss that on Thursday’s IRC meeting.
Not sure if I'll be available or not this Thursday, unfortunately. I'll
try to attend but I can't make promises.
Randy and I had a quick glance over your document. Much of it parallels
the work we did on our POC last summer, and is now being addressed across
multiple BP being implemented by ourselves or with Sean Collins and IBM
team's work. I will take a closer look and provide my comments.
That's great. I'm not wedded to the details in there, I'm actually more
interested that we've covered everything.
If you have blueprint references, add them as comments - the
ipv6-feature-parity BP could do with work and if we get the links together
in one place we can update it.
--
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org javascript:_e({}, 'cvml',
'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
Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options
I think slaac was original excluded to make --enable-ra not specified when only slaac is given to an subnet's dhcp mode. However, when I checked the example conf file of dnsmasq: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example enable-ra is explained as: # Do router advertisements for all subnets where we're doing DHCPv6 # Unless overriden by ra-stateless, ra-names, et al, the router # advertisements will have the M and O bits set, so that the clients # get addresses and configuration from DHCPv6, and the A bit reset, so the # clients don't use SLAAC addresses. #enable-ra are we using --enable-ra and ra-stateless, ra-names at the same time correctly? On Tue, Dec 17, 2013 at 8:27 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, guys: I am reading the code in “constants.py” file as part of Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options”. One thing captured my eyes is the definition of “RA_MODES”, which excluded “slaac” mode. If my understanding of “RA_MODES” is correct, i.e. the modes leverage RA, then “slaac” mode should be included. Am I correct? Thanks! Shixiong ___ 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
