Numan Siddique wrote: > On Fri, Nov 16, 2018 at 11:03 PM Gregory Smith <[email protected]> wrote: > > > See RFC 2131, section 4.3.2. When handling a DHCPREQUEST message, the > > server should validate that the client's requested IP matches the > > offered IP. > > When we added the native DHCP support in OVN, we primarily had > OpenStack in mind and wanted to get rid of neutron dhcp agent service. > In the case of OpenStack, when a port is created, the IP address is > assigned to it by the Neutron IPAM. This IP address will most likely > will remain the same for the port. So we added a simple native DHCP > implementation. > > I want to understand the use case for this requirement. Can you please > give more details. Does a CMS update the address of a logical port at > a later point of time ?
We’ve been cloning windows VMs, and we’ve observed that the clone sometimes requests its parent’s IP address during boot, despite having been assigned a new adapter MAC address. The Windows DHCP client gets confused when it gets a DHCPACK for a different address, and reacts by repeating its original DHCPREQUEST. After a few retries, it gives up and uses the old address. It never sends a DHCPDISCOVER. By contrast, when the Windows DHCP client recieves a DHCPNAK, it immediately sends a DHCPDISCOVER to discover its new address. Regarding OpenStack: I understand that it is not common to change a Neutron port's IP address assignment, but this is certainly a supported workflow. Are there any other parts of OVN that assume the port's IP address assignment is immutable? Greg _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
