dhcp should never be enabled for a router external net
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Invalid
|
Medium
|
Cedric Brandily | ||
openstack-manuals |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
it doesn't make sense in the existing model, as the router IPs and the floating IPs allocated from an external net never make DHCP requests.
I don't believe there is any significant additional harm caused by this though, other than unneeded CPU churn from DHCP agent and dnsmasq, and a burned IP address allocated for a DHCP port.
One tricky issue is that DHCP is enabled by default, so the question is whether we should fail if the user does not explicitly disable it when creating a network, or if we should just automatically set it to False. Unfortunately, I don't think we can tell the difference between a this value default to true and it being explicitly set to true, so it seems that if we want to prevent it from being set to true in the API, we should require it to be set to False. We also need to prevent it from being set to True on an update.
Another option would be to ignore the value set in the API and just have the DHCP agent ignore networks for which router:external =True.
Changed in quantum: | |
milestone: | none → folsom-rc1 |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in quantum: | |
milestone: | folsom-rc1 → none |
Changed in neutron: | |
assignee: | nobody → Martin Hickey (martin-hickey) |
Changed in neutron: | |
status: | Confirmed → In Progress |
Changed in openstack-manuals: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
milestone: | none → mitaka |
Changed in openstack-manuals: | |
milestone: | mitaka → newton |
Changed in openstack-manuals: | |
milestone: | newton → ocata |
tags: | added: networking-guide |
Changed in openstack-manuals: | |
milestone: | ocata → none |
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.