[RFE] Automatically allow incoming DHCP traffic for networks which uses external dhcp server

Bug #1785213 reported by Slawek Kaplonski
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Triaged
Wishlist
Slawek Kaplonski

Bug Description

Use Case:
User wants to use provider network with some external dhcp server.
Now he need to add proper security group rule to allow incoming dhcp traffic to his instances.

Proposed solution:
Add new attribute to network, something like "external-dhcp".
Ports connected to this network, will automatically have added to iptables rule to allow incoming dhcp traffic.

Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Some more details why I want to add something like that below.

Sometime there is need that instance to live in the same address space as e.g. dedicated servers in organization's network.
Two DHCP server in the same pool are bound to collide some time.
So the option here might be to use external DHCP server which will assign IPs for all devices in network.

Possible other option might be to use different pools of IPs in subnet used in Neutron and in external DHCP server for dedicated servers, but that is sometimes not a viable solution.
Sometimes You can't easilly make sure that in a live production environment you have a slice which is free and falls into a normal range.

So other solution might be to use only external dhcp server for all: dedicated servers and OpenStack instances.
There is of course question how to make external dhcp server aware of what IPs should be assigned to OS instances but IMO that can be done e.g. in DHCP server by adding some plugin which can ask Neutron API for such API. So it's doable but implementation of this should not be the case of this RFE.
I just think that would be good to add such flag to external network to make this setting more clear than configuring Security group rules - which are necessary for incoming traffic now but aren't necessary for outgoing DHCP request.

Revision history for this message
Miguel Lavalle (minsel) wrote :

So, at this point, your proposal boils down to implementing the "external-dhcp" attribute in networks. Is my understanding correct?

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Yes. Basically that would be the result of this change. Additional parameter "external-dhcp" added to network and allowed traffic from external dhcp server for all ports in such network.

Miguel Lavalle (minsel)
Changed in neutron:
status: New → Triaged
Miguel Lavalle (minsel)
tags: added: rfe-triaged
removed: rfe
Revision history for this message
Nate Johnston (nate-johnston) wrote :

Does this assume the external existence of a dhcp_proxy or "ip helper" to encapsulate the DHCP broadcast and forward it to an external IP? Or does it's operation work differently based on network type i.e. provider networks work differently from tenant networks?

Revision history for this message
Akihiro Motoki (amotoki) wrote :

IIUC, the motivation of the proposal is to let neutron know IP address(es) of DHCP server(s) even if an external DHCP server is used so that iptables rules for DHCP server(s) can be installed automatically.

One possible way to achieve this is to create neutron ports with network:dhcp device_owner and let neutron know neutron that there is no need to provision dhcp servers (usually implemented by dnsmasq). From this point, a new attribute like 'external_dhcp' makes sense to me.

I am okay so far.

I'd like to raise several points.

- It loos odd that the network resource has 'external_dhcp' attribute. The subnet looks better to me. THe subnet resource has 'enable_dhcp' attribute already.
- How does the new attribute 'external_dhcp' affect IPv6 address allocation (SLAAC/DHCPv6-stateless/stateful)? For IPv6, a combination of ipv6_ra_mode and ipv6_address_mode declares whether RA router and/or DHCP server are OpenStack managed or not.

Revision history for this message
Akihiro Motoki (amotoki) wrote :
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Akihiro:
- I agree that subnet would be better place to put this new attribute instead of network,

- About IPv6 - I don't think it will impact IPv6 allocation in any way - this proposal is only about allowing user to tell explicitly that ports which have got IPs from specific subnet should have allowed incoming DHCP traffic from external networks, nothing else.
Today it can be also done by configuring proper security group rules for port but that IMO is not very intuitive and that's why I propose this additional attribute.

This proposal is only to add specific firewall rule(s) for ports which have IPs from subnet with this new flag set to True.
To avoid problems with "internal" and "external" DHCP servers for one subnet I think it would be good to allow setting this to true only if "enable_dhcp" is set to False for subnet.

Does it makes sense for You?

Revision history for this message
Nate Johnston (nate-johnston) wrote :

If a customer wanted to use both this feature and neutron-fwaas would there be a way for fwaas to be notified about this? Or are you thinking that this feature would just be incompatible with fwaas?

Revision history for this message
Miguel Lavalle (minsel) wrote :

Drivers team decided to ask in the operators mailing list whether this proposal is worth pursuing. Slawek to send question to the operators mailing list

tags: added: rfe-postponed
removed: rfe-triaged
Revision history for this message
Nate Johnston (nate-johnston) wrote :

Question for later if this is revived: Does turning things over to an external dhcp server assume disabling all ipam functionality for that subnet? Otherwise Neutron would assign an IP from it's pool that would never be used.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.