OVH server loses Internet connectivity after 1 hour

I have a dedicated server at OVH on which I’m hosting a few KVM guests. Recently, I upgraded the OS to Debian 11 Bullseye. The upgrade went without a hitch but the host consistently started to lose Internet connectivity after 1 hour (a bit less actually, +-56 minutes) after a restart. I was able ping the default gateway though at all times, but nothing else behind this first hop. The KVM guests were unaffected (since bridged and using their pre-defined MAC address), and IPv6 kept working on the host as well. It was only IPv4 connectivity that got lost (beyond the switch), always after an hour after a reboot. Very strange! It took me quite a while to figure out the root cause. I suspected a problem with the hosts MAC address and started pinging a public IP address while running tcpdump with the -e parameter. That’s when I noticed that the ping was sent with the MAC address of my br0 bridge instead of the physical interface’s MAC address. Here’s what happened: starting with Debian Bullseye, bridges get randomly generated MAC addresses assigned. While in Debian 10 Buster, the bridge’s MAC address was inherited from the physical interface associated with the bridge.

The solution was to manually set the bridge’s MAC address to the same address as the physical interface using the hwaddress instruction:

rename eno1=eth0
auto eth0
iface eth0 inet manual 
auto br0
iface br0 inet static
  hwaddress ether 0a:c4:7a:42:53:e2 # <-- from eth0
  address 5.196.nnn.nnn
  network 5.196.nnn.nnn
  broadcast 5.196.nnn.nnn
  gateway 5.196.nnn.nnn
  bridge_ports eth0
  bridge_fd 0
  bridge_stp off
  bridge_maxwait 0

It looks like OVH’s switch in front of my server was allowing unknown MAC addresses passing through, but only for an hour and then silently dropped all IPv4 packets until the next NIC reset. Yeah, obviously OVH’s support was clueless even though the hint about the 56 minutes and then losing access should have been a strong pointer for them. That’s why I’m posting the solution here, hopefully it helps someone else with the same problem.

Join the Conversation

1 Comment

Your email address will not be published. Required fields are marked *

  1. I had the same issue upgrading from Proxmox6 to Proxmox7.
    Linux Bridge MAC-Address Change
    With Proxmox VE 7 / Debian Bullseye, a new systemd version is used, that changes how the MAC addresses of Linux network bridge devices are calculated:

    MACAddressPolicy=persistent was extended to set MAC addresses based on the device name. Previously addresses were only based on the ID_NET_NAME_* attributes, which meant that interface names would never be generated for virtual devices. Now a persistent address will be generated for most devices, including in particular bridges.

    A unique and persistent MAC address is now calculated using the bridge name and the unique machine-id (/etc/machine-id), which is generated at install time.

    Please either ensure that any ebtable or similar rules that use the previous bridge MAC-Address are updated or configure the desired bridge MAC-Address explicitly, by switching to ifupdown2 and adding hwaddress to the respective entry in /etc/network/interfaces.