Hello,
I've recently updated my laptop to F31. Then I was no longer able to ssh into it. After a little debugging... it turns out my laptop was not getting the expected ip address from DHCP. The reason for that was the MAC address it was sending to dhcpd had change!!! Looking at the interfaces
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.1.175 netmask 255.255.0.0 broadcast 172.31.255.255 inet6 fe80::98f9:f0d0:4b79:cdaa prefixlen 64 scopeid 0x20<link> ether 3a:00:66:8a:dd:b9 txqueuelen 1000 (Ethernet) RX packets 259601 bytes 112149182 (106.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256704 bytes 39319273 (37.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 8c:16:45:fe:c1:f1 txqueuelen 1000 (Ethernet) RX packets 355186 bytes 134328851 (128.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256743 bytes 40395059 (38.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xec200000-ec220000
The bridge0 interface has as different MAC that the enp0s31f6 interface. How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1) is set in the ifcfg-bridge0_slave_1.
What has changed and where is the bridge MAC address coming from???
tia,
steved.
On 31/01/2020 14:28, Steve Dickson wrote:
I've recently updated my laptop to F31. Then I was no longer able to ssh into it. After a little debugging... it turns out my laptop was not getting the expected ip address from DHCP. The reason for that was the MAC address it was sending to dhcpd had change!!! Looking at the interfaces
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.1.175 netmask 255.255.0.0 broadcast 172.31.255.255 inet6 fe80::98f9:f0d0:4b79:cdaa prefixlen 64 scopeid 0x20<link> ether 3a:00:66:8a:dd:b9 txqueuelen 1000 (Ethernet) RX packets 259601 bytes 112149182 (106.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256704 bytes 39319273 (37.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 8c:16:45:fe:c1:f1 txqueuelen 1000 (Ethernet) RX packets 355186 bytes 134328851 (128.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256743 bytes 40395059 (38.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xec200000-ec220000
The bridge0 interface has as different MAC that the enp0s31f6 interface. How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1) is set in the ifcfg-bridge0_slave_1.
How are you managing your network? NetworkManager? systemd-networkd? The old network rc script?
I know there was a change with systemd-networkd in a recent release so that it now creates a unique but persistent MAC for bridges and maybe other systems like NetworkManager have done the same?
Tom
On 1/31/20 9:55 AM, Tom Hughes wrote:
On 31/01/2020 14:28, Steve Dickson wrote:
I've recently updated my laptop to F31. Then I was no longer able to ssh into it. After a little debugging... it turns out my laptop was not getting the expected ip address from DHCP. The reason for that was the MAC address it was sending to dhcpd had change!!! Looking at the interfaces
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.1.175 netmask 255.255.0.0 broadcast 172.31.255.255 inet6 fe80::98f9:f0d0:4b79:cdaa prefixlen 64 scopeid 0x20<link> ether 3a:00:66:8a:dd:b9 txqueuelen 1000 (Ethernet) RX packets 259601 bytes 112149182 (106.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256704 bytes 39319273 (37.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 8c:16:45:fe:c1:f1 txqueuelen 1000 (Ethernet) RX packets 355186 bytes 134328851 (128.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 256743 bytes 40395059 (38.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xec200000-ec220000
The bridge0 interface has as different MAC that the enp0s31f6 interface. How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1) is set in the ifcfg-bridge0_slave_1.
How are you managing your network? NetworkManager? systemd-networkd? The old network rc script?
Using systemctl status it appears NetworkManager is active and systemd-networkd is not so I guess NetworkManager is doing the management
I know there was a change with systemd-networkd in a recent release so that it now creates a unique but persistent MAC for bridges and maybe other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?
tia,
steved.
On 31/01/2020 15:23, Steve Dickson wrote:
I know there was a change with systemd-networkd in a recent release so that it now creates a unique but persistent MAC for bridges and maybe other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?
I believe this is the relevant NEWS entry:
https://github.com/systemd/systemd/blob/master/NEWS#L926
I think the idea is to ensure that a bridge always has the same address, as by default it gets the address of whichever slave happens to join first - that's fine in the common case where there is one address added at boot and then others come and go but may be non-deterministic if multiple addresses are added at boot time.
Tom
On 31/01/2020 15:29, Tom Hughes wrote:
On 31/01/2020 15:23, Steve Dickson wrote:
I know there was a change with systemd-networkd in a recent release so that it now creates a unique but persistent MAC for bridges and maybe other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?
I believe this is the relevant NEWS entry:
https://github.com/systemd/systemd/blob/master/NEWS#L926
I think the idea is to ensure that a bridge always has the same address, as by default it gets the address of whichever slave happens to join first - that's fine in the common case where there is one address added at boot and then others come and go but may be non-deterministic if multiple addresses are added at boot time.
Actually thinking about it the MAC address policy comes from a link unit so is applied by udev and isn't systemd-networkd specific.
There is an example in that NEWS entry of a link unit to turn this off and go back to the old behaviour.
Tom
On 1/31/20 10:31 AM, Tom Hughes wrote:
On 31/01/2020 15:29, Tom Hughes wrote:
On 31/01/2020 15:23, Steve Dickson wrote:
I know there was a change with systemd-networkd in a recent release so that it now creates a unique but persistent MAC for bridges and maybe other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?
I believe this is the relevant NEWS entry:
https://github.com/systemd/systemd/blob/master/NEWS#L926
I think the idea is to ensure that a bridge always has the same address, as by default it gets the address of whichever slave happens to join first - that's fine in the common case where there is one address added at boot and then others come and go but may be non-deterministic if multiple addresses are added at boot time.
Actually thinking about it the MAC address policy comes from a link unit so is applied by udev and isn't systemd-networkd specific.
There is an example in that NEWS entry of a link unit to turn this off and go back to the old behaviour.
Thanks for the info!!
steved.
-
Steve Dickson -
Tom Hughes