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. 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<https://launchpad.net/~quantum-core> > Post to : > [email protected].**net<[email protected]> > Unsubscribe : > https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> > More help : > https://help.launchpad.net/**ListHelp<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
