dhcp should never be enabled for a router external net

In a discussion over the maling list (or a review, can't remember) we made the point that an external network can be used, in some circustances, directly by instances. For instance an user might want to deploy its own router, or a load balancer, or any other appliance requiring a public and a private interface.

Keeping that in mind, we might want to still use dhcp on external networks. Even if they are directly connect on a segment outside of quantum scope, the dhcp server will only respond to requests coming from quantum vms - so we won't risk it distributing quantum addresses to the rest of the world.

The current process for associating a floating IP also ensures it is removed from the allocation pool, so VMs with VIF on the external network won't get it.

We can change the default behaviour for dhcp_enable. On way of doing this would be setting the default to ATTR_NOT_SPECIFIED, and then setting it in the plugin.

The db base plugin would set it to True if it is not specified, whereas plugins deriving from it and the l3 mixin should instead look at the value of router:external before making a decision.

Very good point Salvatore. With that in mind, I would argue that we probably shouldn't make a code change, as it is valid in some configurations. I don't like the idea of switching a default value based on what extensions are enabled, so I'd probably just document that if you're creating an external network that is ONLY used as an external network (i.e., never for VMs) we suggest setting use_dhcp=False. Does that seem reasonable? If so, let's mark the bug as invalid.

[Expired for quantum because there has been no activity for 60 days.]

waking this bug up because while the solution was to document, there should be a pointer to the document in question so that the issue is not brought up in the future.

Hi Dan and Salvatore,

I have looked through the docs and have found a sentence in http://docs.openstack.org/draft/install-guide-obs/neutron-initial-networks.html as follows:
"You should disable DHCP on this subnet because instances do not connect directly to the external network and floating IP addresses require manual assignment.".

Do you think this explains the scenario or should it contain an additional sentence to describe when DHCP could be used for an external network?

Thanks,
Martin

I think the information in the install guide is not entirely correct, as attaching instances directly to the external network is a valid use case. Perhaps I'm being too pedantic here, but the concept should be that unless one plans to deploy directly instances leveraging DHCP on the external network, DHCP should be disabled.

Just for the sake of pedantry, the same remarks could be made in the openstack networking guide (http://docs.openstack.org/networking-guide)

Hi Salvatore,

Thanks for the feedback.

As discussed on IRC, I will update the sentence as follows: ""DHCP should be disabled on an external network unless instances are to be deployed on the external network."

Cheers,
Martin

I talked to the doc team on IRC and the doc mentioned above ( http://docs.openstack.org/draft/install-guide-obs/neutron-initial-networks.html) is now replaced by: http://docs.openstack.org/draft/install-guide-obs/neutron.html. The content has changed and no longer contains the text mentioned.

I have therefore decided to add the text to the networking guide (http://docs.openstack.org/networking-guide) as mentioned by Salvatore.

Patch https://review.openstack.org/#/c/234196/ abandoned until networking guide team plans on adding a scenario where you can boot on external networks.

Moving this away from "In Progress" to "Confirmed" for now.

Has anyone tested this scenario? I'm concerned there may be a problem here.

I will look

I don't understand the issue. Connecting to an external network works fine as long as you aren't using the 'external_network_bridge' option in the L3 agents.

Attempting to clarify...

During initial development of the networking guide somewhere in the Icehouse-Juno days, we didn't see a demand for "hybrid" architectures that support attaching a VM to public/provider and private/project networks. However, recent trends indicate an interest in hybrid architectures because they offer the most flexibility.

For Liberty, the installation guide architecture supports two networking options. Both options support attaching a VM to a public/provider network... the most simple way to deploy neutron, but does not support self-service networking. The second option augments the first option by adding the L3 agent to support self-service networking and attaching a VM to a private/project network with a router, floating IP address, etc.

The networking guide (currently continuous release) supports a variety of scenarios or networking architectures. Scenarios that traditionally provide self-service networking currently only support attaching a VM to a private/project network to reduce complexity and arguably push deployers toward "true" cloud networking. Technically, the only limiting factor is the lack of a provider network interface on the compute nodes and some additional configuration. We either need to modify the existing scenarios with self-service networking to enable attaching a VM to a public/provider network or create additional hybrid scenarios. I lean toward the former because it reduces information overload (to many choices with subtle differences) and minimizes duplication of content. However, it increases complexity (especially diagrams and packet flows) of an already difficult topic for our audience to understand.

I'm not sure I understand how the two scenarios diverged so much that it wouldn't be as simple as explaining that the 'external' checkbox allows tenants to attach routers to it and the 'shared' checkbox allows tenants to attach VMs to it.

Even in the tenant networking case, an admin can create VMs on the external network without it being shared for other tenants. At a minimum that should be made clear in the guide because we don't want to perpetuate the idea that the external networks are any different from normal networks.

In the legacy and L3HA scenarios, external networks are different because they only physically connect to network nodes and therefore prevent attaching a VM on a compute node to them.

Don't we have an explanation of bridge mappings somewhere? Maybe we need a separate section that makes it obvious that a VM can attach to any physical network as long as a bridge_mapping is present for it on the compute node it's scheduled to.

Regardless, this bug should be marked as opinion for Neutron or reassigned to docs. This scenario is perfectly valid and I have tested it many times. Just because the opinionated deployment scenarios in the guide don't cover this doesn't mean there is any issue.

Yep, definitely a documentation issue rather than a neutron issue.

Technically speaking, nothing disallows to deploy vms on ext-nets even if i doubt that's the aim of ext-nets.

According to the discussion, i update the bug status to invalid

Closing this bug in favor of [1], which has been opened to track the creation of a new deployment scenario to cover this case.

[1] https://bugs.launchpad.net/openstack-manuals/+bug/1662478