Thank you Thomas and Brian for the quick response and for the explanations!!
No snarkyness found Brian😊 I am happy and honored you guys responded so quickly. I'll try my best to explain:
Our scenario is in large the following:
We already have a complex network(and servers) which hosts various workloads from various projects. We plan to use openstack to extend/replace part of this workload so opnstack will be a part of our existing network. Even if openstack can fully isolate internal networking, we plan to treat the openstack project-networks as an extension of our current network(we will use overlay though, not flat network), with no overlapping Ips between openstack project networks or the exterior. It is easier for us to manage this way.
We already use a central dhcp server for our network that handles all IP allocation(also dns etc.) and it's our "source of truth" for ip allocation, where we do all the configs, reservations, access and so on. That is the reason we would also like it to be in sync with whatever Ips are allocated in openstack so we can have a global picture.
As we are new to openstack there is probably a lot of things we don't yet fully understand.
We definitely want port security because, from what I understand, it is a prerequisite for adding security groups to instances and we definitely want to do that.
So if that is the only way to achieve dhcp relay(disabling port sec), we'll probably drop the idea and maybe just try to update our central, external dhcp server with the IP's that the VMs in OS take(I saw there is an openstack bluecat plugin for that - to be tested).

All the best,
Andrei

Banque Pictet & Cie SA

Route des Acacias 60 1211 Geneva 73 - Switzerland

Tel. +41 58 323 2323

Fax. +41 58 323 2324

pictet.com

-----Original Message-----
From: Brian Haley <haleyb.dev@gmail.com>
Sent: mercredi, 16 avril 2025 23:34
To: Thomas Goirand <zigo@debian.org>; Andrei RADU <aradu@pictet.com>; OpenStack Discuss <openstack-discuss@lists.openstack.org>
Subject: [External] Re: Is DHCP relay in Openstack

Hi Andrei,

On 4/16/25 4:29 PM, Thomas Goirand wrote:
> Hi Andrei,
>
> On 4/16/25 12:23, Andrei RADU wrote:
>> Hello,
>>
>> This is my first interaction with Openstck mailinglists so hopefully
>> I am sending this question to the correct place😊
>
> That's the correct place. Welcome!
>
>> The question is simple: does Openstack(Neutron) natively support DHCP
>> relay?
>
> Short answer: currently, no, and it's not a good idea to do that
> anyways. See below for more details.

Thanks for answering Thomas, and I would agree it's probably not a good idea to support DHCP relays. That said, the Neutron team is always willing to talk about new features if there is a good need behind it - like there is some functionality we just cannot get with what we have.

>> We have currently a (test) deployment using OVS driver but we may
>> think switching to OVN. We would like to use an external DHCP
>> server(BlueCat) that is already handling the rest of our network DHCP.

OVN has a built-in DHCP server, and with ML2/OVS you can use DHCP in a distributed config, both of which do all the work directly on the compute nodes. That greatly simplifies the architecture, so I'm not sure we'd want to undo that.

So the question comes down to "what problem are you trying to solve?".
Please don't take that in a snarky way can't think of a better way to ask it.

Thanks,

-Brian

>> I could not find anything related to this in docs.
>>
>> I found this spec:
>> https://review.opendev.org/c/openstack/neutron-specs/ +/105660
>> <https://review.opendev.org/c/openstack/neutron-specs/+/105660> which
>> seems to have been abandoned.
>
> It also shows in the spec: Neutron doesn't only provide a DHCP (using
> dnsmasq, by the way), it also provides tenant isolation. Meaning that
> for example, 2 projects may use the same 10.0.0.0/24 subnet range
> without any collision.
>
> To achieve this, Neutron makes sure that VMs cannot use IPs that they
> don't "own", and does this by checking the IP vs the MAC address given
> to the VM. Any traffic that's not matching the pair will be dropped by
> OpenVSwitch. This makes sure it's impossible to do IP spoofing.
>
> Under this condition, Neutron must know *in advance* what IP address
> the DHCP server will provide to the VM, and therefore, using a DHCP
> relay to an external DHCP server that Neutron doesn't control is not a
> good idea, unless one sacrifice the security I described above (in
> Neutron, that's called "port security", which can be disabled by an
> admin, but not a normal user).
>
> So, with port security off, it should be possible to bind a DHCP relay
> in a VM of a subnet, but I would not recommend doing this at all, as
> anyone would be able to do IP spoofing then. So there's no need to ask
> something special from OpenStack Neutron, just deploy that if you
> don't care about port security.
>
> I hope the above answers correctly to your question. If not, I'm sure
> someone else will correct what I wrote (to the best of my knowledge).
>
> Cheers,
>
> Thomas Goirand (zigo)
>

 

 

This message is not intended for persons who are citizens of, domiciled or resident in, or entities registered in a country or jurisdiction in which its distribution, publication, provision or use would violate current laws and regulations. The content of this message is confidential and may be read and/or used only by the recipient of this message. For information about personal data protection, please refer to the Pictet Group’s Privacy Notice available at www.pictet.com/privacynotice. If you have received this e-mail message in error, please destroy it and delete it from your computer. The Pictet Group may not be held liable for the use, transmission or treatment of the content of this message. The recipient of this message remains solely liable for any form of reproduction, copying, disclosure, modification and/or publication of the content. No liability whatsoever will be incurred by the Pictet Group. The recipient of this message agrees to comply with the applicable laws and regulations in the jurisdictions where they use the information contained herein.