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.

4 replies on “OVH server loses Internet connectivity after 1 hour”

  1. Please do you have any hint or configuration to setup a Bridge but with a IP FAILOVER from OVH ? your configuration work but i need to use FO ip address to KVM VM by it own.

    Thanks a lot for your help and article

  2. Sorry I am writing this on a wrong place, but wanted some help from you.
    I live in a remote location and travel out of my country frequently. I miss my entertainment while away from home. I was using vpn server hosted on a data centre, but now most of data centre IP addresses are blocked. I recently came across you trick 77 on github and thought of trying it by using my home for HAProxy and data centre server for Dnsmasq, I have tried to work it out, but some how HAProxy does not work, if you have any old configs or scripts or a brief guide it will help me.
    Your help is appreciated.

  3. Dear Jan,
    thanks for your post. I was searching today for 6 hours to get the reason for the network blackout and then I found your article. Many thanks for sharing. I am using Debian “Bullseye”.

  4. 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.

Comments are closed.