Hi, >>>>> Date: Wed, 23 Jan 2013 23:42:55 -0800 >>>>> From: Dan Wendlandt <[email protected]> >>>>> Subject: Re: [Quantum-core] communication between unconnected >>>>> subnetswithout namespace > > Hi guys, > > Sorry, I've had this half-written for a while. > > Thanks for bringing this up Akihiro. This is a topic we discussed a long > time ago, but let die. > Based on those discussions, I think the issues are even more substantial > than what you mention. > > First, some context from those not familiar with the details. > > Bboth the quantum-l3-agent and quantum-dhcp-agent where originally designed > focused on a model > where they only used namespaces. This means that the IP interfaces used by > the agents are > completely disconnected not just from other router namespaces, but also from > the "root" namespace > (this is the namespace you associate with the standard IP connectivity of the > host, i.e., the one > you see when running ifconfig from a shell). > > However, some older platforms (e.g., RHEL) don't support namespaces (or > perhaps have kernel > support, but do not support the userspace utilities that we use to manipulate > namespaces, see: > http://docs.openstack.org/trunk/openstack-network/admin/content/ch_limitations.html). > As a > result, we added a flag, use_namespaces, to control this behavior. > https://github.com/openstack/ > quantum/blob/master/etc/l3_agent.ini#L23 > > However, if namespace are not use at all, the IP interfaces created by the l3 > and dhcp agents are > all in the root namespace with zero isolation. The issue you mention (using > the DHCP as the > gateway IP to reach another subnet when one is supposed to be on a isolated > network) is just one > example. It would also be the case that tenants with access to the quantum > router would also be > able to reach any subnet the the physical box running the l3-agent is > connected to (e.g., a > management network). Likewise, if either DHCP or routing is running without > namspaces, any > services running on the box and bound to the 0.0.0.0 address (e.g., SSH) > would likely also be > exposed to VMs on the logical network, since the 0.0.0.0 listening address > would include the IP > address of the DHCP server. I believe both of the latter items are still a > problem even if you do > not run dhcp + l3 together on a server with namespaces disabled.
Thanks for clarifying the issues. I agree with your description. I think the issues can be categorized into two: (a) isolation between tenants and a provider, and (b) isolation among tenants (networks) The former is what Dan mentionded and the latter is what I wrote. To address (a), we need to setup static iptables rules appropriately: - Allow INPUT to management L4 ports only from a management network. - Disallow FORWARD from/to an interface connected to a management network. Concrete examples in the doc would be helpful. I may miss some required rules. If so please correct me. Regarding address (b), it cannot be addressed by static rules and we need to avoid to run dhcp-agent and l3-agent on a server. Akihiro > If people agree with the above descriptions, let's file an urgent doc bug on > this, and get it > pushed. There are some potential code work-arounds (e.g., pushing down > iptables filters to > restoring the required isolation) that we could explore if desirable, though > I would much prefer > that we are able to converge on using a single namespace-based design that > does not require extra > bagge for isolation. > > Dan > > On Fri, Jan 11, 2013 at 6:24 AM, Gary Kotton <[email protected]> wrote: > > On 01/11/2013 02:30 PM, Akihiro MOTOKI wrote: > > Hi folks, > > I have noticed that there is a case two subnets not connected > each other via a router can communicate each other > by changing default gateway to the IP address of the DHCP servers > in a setup where l3-agent and dhcp-agent run on a same host without > namespace. > > A simple solution to avoid it is to run l3-agent and dhcp-agent on > different hosts. > Is there any other good solution? > > IMO, this is a limitation without namespace on deployment > rather than a bug of quantum and should be documented in the guide. > > This sounds reasonable. Maybe this should be documented. > > What do you think? > > Thanks, > Akihiro > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
