Open Stack

-- (rebroadcast to dev community from prior unicast discussion) --

Hi Nir

Sorry if the description is misleading. Didn't want a large title, and hoped that the description would provide those additional details to clarify the real goal of what's included and what's not included.

#1. Yes, it's only the gateway port. With that said, there are a series of BP that are being worked to support the dual-stack use case (although not necessarily dependent on each other) across Neutron, including internal ports facing the tenant.
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword
https://blueprints.launchpad.net/neutron/+spec/neutronclient-support-dnsmasq-mode-keyword
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-relay-agent
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless

I'd suggest popping into the ipv6-subteam's meetings [1] and having further discussions about this as well.  We've been working on address allocation for the most part, but routing and service integration will need to be the next step.



#2. Surely it's possible to have multiple v4 and v6 [global] addresses on the interface, but for the gateway port, I don't have a specific use case. To remain consistent with current feature capability (single v4 IP), I continue to restrict a single IP from each flavor. With that said, there's nothing technically preventing this. It can be done; however, the CLI and Horizon would likely need significant changes. Right now, the code is written such that it explicitly prevents it. As I mentioned before, I actually had to add code in to disallow multiple addresses of the same flavor and send back an error to the user. Of course, we can evolve it in the future if a use-case warrants it.

The use case is for networks that rely on IP allocations for security.  You may want a pair of separate routed blocks on the same network for, say, a public network for the web server to get through a policy to the Internet, but a separate address to get to an internal-only database cluster somewhere.  I'm not saying it's the greatest way to do things, but I am sure there are people running networks this way.  The alternative would be to spin up another port on another network and configure another gateway port as well.



Thanks
Randy



On Thu, Jan 9, 2014 at 4:16 AM, Nir Yechiel <nyechiel at redhat.com<mailto:nyechiel at redhat.com>> wrote:
Hi Randy,

I don't have a specific use case. I just wanted to understand the scope here as the name of this blueprint ("allow multiple subnets on gateway port for router") could be a bit misleading.

Two questions I have though:

1. Is this talking specifically about the gateway port to the provider's next-hop router or relevant for all ports in virtual routers as well?
2. There is a fundamental difference between v4 and v6 address assignment. With IPv4 I agree that one IP address per port is usually enough (there is the concept of secondary IP, but I am not sure it's really common). With IPv6 however you can sure have more then one (global) IPv6 on an interface. Shouldn't we support this?


Thanks,
Nir

________________________________
From: "Randy Tuttle" <randy.m.tuttle at gmail.com<mailto:randy.m.tuttle at gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Cc: rantuttl at cisco.com<mailto:rantuttl at cisco.com>
Sent: Tuesday, December 31, 2013 6:43:50 PM
Subject: Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router


Hi Nir

Good question. There's absolutely no reason not to allow more than 2 subnets, or even 2 of the same IP versions on the gateway port. In fact, in our POC we allowed this (or, more specifically, we did not disallow it). However, for the gateway port to the provider's next-hop router, we did not have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron today, only a single subnet is allowed per interface (either v4 or v6). So all we are doing is opening up the gateway port to support what it does today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the gateway port (and same network/vlan). Our principle use case is to enable IPv6 in an existing IPv4 environment.

Do you have a specific use case requiring 2 or more of the same IP-versioned subnets on a gateway port?

Thanks
Randy


On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel <nyechiel at redhat.com<mailto:nyechiel at redhat.com>> wrote:
Hi,

With regards to https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port, can you please clarify this statement: "We will disallow more that two subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets".
The use case for dual-stack with one IPv4 and one IPv6 address associated to the same port is clear, but what is the reason to disallow more than two IPv4/IPv6 subnets to a port?

Thanks and happy holidays!
Nir



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-Anthony

[1] https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/6b7302de/attachment.html>