Bug 1767132

Summary:	Neutron incorrectly releasing IP addresses (DCHP Release) for Windows & Ubuntu instances.
Product:	Red Hat OpenStack	Reporter:	Siggy Sigwald <ssigwald>
Component:	openstack-neutron	Assignee:	Rodolfo Alonso <ralonsoh>
Status:	CLOSED NOTABUG	QA Contact:	Eran Kuris <ekuris>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	amuller, chrisw, njohnston, scohen
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-25 15:48:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Siggy Sigwald 2019-10-30 18:24:10 UTC

This is a follow up to BZ 1723116. Even with the provided OSP10 hotfix in that case, I can see DHCPRELEASE messages in /var/log/messages that don't correspond to deleted VMs.

I still do see the same "DHCPNAK : lease not found" messages in /var/log/messages as well, but am questioning why is this message occurring anyway. For a given VM, the IP address is only in the dhcp "leases" file on 1 out of 3 controllers. Why is this "lease not found" message  occuring on controllers which may not be the primary to hold lease IP for that VM? Also am seeing the "DHCPRELEASE : ...unknown lease" message in /var/log/messages. Shouldn't the only DHCPRELEASE message come from VMs getting deleted?

As such, in Production, there are large amounts of VMs (difficult to determine which ones unless customer brings it up) which are losing network connectivity briefly until their lease comes back. We have not rolled the provided hotfix to production, until we verify why the "lease not found" and "DHCPRELEASE" messages are still happening in the pre-prod environment which has the hotfix RPM's installed.

Please see the other case for additional details. It is still not clear what is supposed to be fixed in that hotfix. What is the log file message we should be looking for to indicate this issue?

Comment 4 Siggy Sigwald 2019-11-23 19:44:55 UTC

- Customer indicates there's a microsoft update that apparently solves the issue[1].
- Custome ris currently testing.

[1]https://support.microsoft.com/en-us/help/3004537/dhcp-client-always-includes-option-61-in-the-dhcp-request-in-windows-8 
Thanks

Comment 7 Red Hat Bugzilla 2023-09-18 00:18:05 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days