I am looking into a very strange behavior. I updated my machine from 42.3 to 15.0 and with this the network config got weird. I see two dhcp requests for the same eth0 resulting in 2 different addresses for the same interface… This results in an angry switchport
No clue what can possibly go wrong, config looks good to me, even throwing away all interfaces and setting up freshly does not change the behavior. When looking with wireshark there is the first bootp, including hostname/prefered IP and after the response there is another bootp request with the identical hostname but another prefered ip, which will be granted as well.
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
inet6 ::1/128 scope host
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 xx:xx:xx:xx:xx:c2 brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.222.140/22 brd xxx.xxx.223.255 scope global noprefixroute dynamic eth0
valid_lft 2369sec preferred_lft 2369sec
inet xxx.xxx.221.215/22 brd xxx.xxx.223.255 scope global secondary noprefixroute eth0
valid_lft forever preferred_lft forever
…couple of more interfaces without problems (static config)…]
ifstatus eth0
eth0 up
link: #2, state up, mtu 1500
type: ethernet, hwaddr xx:xx:xx:xx:xx:c2
config: compat:suse:/etc/sysconfig/network/ifcfg-eth0
leases: ipv4 dhcp granted
leases: ipv6 dhcp requesting
addr: ipv4 xxx.xxx.222.140/22
addr: ipv4 xxx.xxx.221.215/22 [dhcp]
route: ipv4 default via xxx.xxx.220.1 proto dhcp
Is this a virtual machine or a physical machine?
Although we shouldn’t see corrupted network interfaces in openSUSE when moving from one network to another, it’s because of special work done for our distro. If something didn’t work right or the Guest is some other distro, you’ll see multiple ethX interfaces (usually eth0 and eth1, both assigned to the same hardware device) but none working because of messed up MAC addresses.
And, although you think you only have one eth0,
It’s highly likely that if you look closely at the properties of your DHCP requests, you’ll see different MAC addresses (That is what the DHCP server relies upon for allocating DHCP leases).
Verify you only have one valid eth0 in YaST > System > Network Settings.
You might also check whether anything looks amiss in
/etc/sysconfig/network/
You should see only one etch0 file (maybe a backup), there shouldn’t be any “slave” interfaces and that file ordinarily shouldn’t have a MAC address entry.
If in the end you see absolutely nothing wrong on your openSUSE, then you should try expiring or deleting the leases on the Server, allowing the DHCP request to generate a brand new lease.
If you have Guests,
Then it can be important to know
What virtualization is used
The type of network connection of each Guest.
I’ve found that with some virtualization, external network services like DHCP sometimes don’t understand the encapsulated traffic when multiple VMs are directed to the same IP address. Of course, even if you don’t have any running Guests, your HostOS virtualization services are still running.
I’d recommend your next step should be to stop your virtualization services altogether to narrow down whether what you see is related to your virtualization. How you might do that depends on the virtualization technology you have installed.
Thanks for pointing me to this, but it looks like the bug describes getting NO ipv4 address whilst my system gets 2! And unfortunately 2 is 1 more than my switchport will allow. Nevertheless, will try switching to the old rfc tomorrow, but I doubt this will solve my problem.
In ‘/etc/sysconfig/network/dhcp’ please try the following settings:
## Type: yesno
## Default: no
#
# Send a DHCPRELEASE to the server (sign off the address)? (yes|no)
# This may lead to getting a different address/hostname next time an address
# is requested. But some servers require it.
#
DHCLIENT_RELEASE_BEFORE_QUIT="yes"
## Type: yesno
## Default: no
#
# Send a DHCPv6 RELEASE to the server (sign off the address)? (yes|no)
# This may lead to getting a different address/hostname next time an address
# is requested. But some servers require it.
#
DHCLIENT6_RELEASE_BEFORE_QUIT="yes"
Please set the IPv6 value even if you’re not using IPv6 on your LAN …
The topic in this thread was somehow missleading, and with wiked asking for one IP using DHCP the system somehow ended up in NetworkManager requesting another one short after. Sinde wicked and the newer standard for sonding client data was not understood by our DHCP server this ended in the result that the NetworkManager resquest ended up with another address…
So - the fix was twofold - follow the linked post and tell the DHCPClient to use the old format to transmit the dlient data to the server and get rid of NetworkManager (which should, according to Yast and the use of wicked, have been not used anyhow).
Thanks for all the suggestions - everything is working properly again
I’ve discovered that with some virtualization, outside system administrations like DHCP some of the time don’t comprehend the epitomized activity when various VMs are coordinated to a similar IP address. Obviously, regardless of whether you don’t have any running Guests, your HostOS virtualization administrations are as yet running.
I’d prescribe your subsequent stage ought to be to stop your virtualization benefits by and large to limit whether what you see is identified with your virtualization. How you may do that relies upon the virtualization innovation you have introduced.
