Network Connectivity Loss in RHEL VMs Due to MAC Address Binding Conflicts.

Products

VMware vSphere ESXi VMware vCenter Server

Issue/Introduction

Random loss of network connectivity and SSH access occurs on RHEL 9 virtual machines, frequently after a guest reboot.
Packet captures indicate ARP requests are transmitted, but gateway connectivity is lost.
Inspection of the Guest OS reveals NetworkManager connection profiles have the MAC address bind to two different virtual network interfaces.
Comparing the specified GUEST OS network configuration of the virtual machine shows the mismatch as below.

- The NetworkManager connection profile explicitly binds the network interface profile named eth0.nmconnection (with an internal ID of ens192) to <MAC_ADDRESSES_A>.
- The actual physical interface named eth0 currently holds <MAC_ADDRESSES_B>. Because the MAC addresses do not match, NetworkManager refuses to apply the IPv4 configuration (address1=...) to eth0. It only has a generic link-local IPv6 address.
  [root@<REDHAT_HOSTNAME> ~]# cat /etc/NetworkManager/system-connections/eth0.nmconnection
  [connection]
  id=ens192
  uuid=<####-#####-########-####>
  type=ethernet
  autoconnect-priority=-999
  [ethernet]
  mac-address=<MAC_ADDRESSE_A>
  [ipv4]
  address1=<##.##.##.##>/##
  method=manual
- As shown in the output below for the ifconfig or ip address , a separate interface named ens192 has claimed <MAC_ADDRESSES_A>

[root@REDHAT_HOSTNAME> ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether <MAC_ADDRESSES_B> brd ff:ff:ff:ff:ff:ff
inet6 <####::###:####:####:####/64>/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether <MAC_ADDRESSES_A> brd ff:ff:ff:ff:ff:ff
inet <##.##.##.##>/24 brd <##.##.##.##> scope global noprefixroute ens192
valid_lft forever preferred_lft forever

Environment

VMware vSphere ESXi

VMware vCenter Server

Cause

The connectivity loss is caused by a custom udev rule deployed within the RHEL Standard Operating Environment (SOE) that conflicts with multi-NIC virtual machine configurations.
From a VMware perspective, ESXi provisions virtual NICs (vNICs) and assigns MAC addresses in the .vmx file, presenting them to the Guest OS via virtual network interface.
Natively, RHEL uses Consistent Network Device Naming to map the virtual PCIe slot and MAC directly to a persistent interface name (e.g., ens192).
When a custom udev rule forces legacy naming or overrides the binding, it breaks the 1:1 mapping between the vSphere vNIC and the Guest OS connection profile.
Consequently, during the boot process, the Guest OS NetworkManager fails to bind the IP configuration to the correct, active vNIC, causing the VM to lose network connectivity on the vSphere network.

Resolution

To resolve this issue, engage Red Hat Support to perform the following:

Review the Guest OS network configuration and validate the MAC address mappings.
Identify and remove any conflicting custom udev rules from the RHEL SOE causing interface swapping on multi-NIC systems.
Correct the stale or duplicate NetworkManager connection profiles to map accurately to the vSphere vNIC MAC addresses.

Additional Information

Packet capture on ESXi using the pktcap-uw tool