Fedora 31 Network Strangeness

[Steve Dickson]

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.

[Tom Hughes]

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

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Steve Dickson]

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.

[Tom Hughes]

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

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Tom Hughes]

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

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Steve Dickson]

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.