OVH networking
OVH uses statically routed addresses with a mandatory virtual MAC per additional IP. Any MAC mismatch makes OVH cut off the server’s network within minutes, so the bridge configuration below clones the physical NIC’s MAC.
OVH-specific facts
Section titled “OVH-specific facts”These apply to every example below:
- Bridge name:
br0. Avoidvirbr0, which libvirt’s default network already uses. - IPv4 is
/32. OVH gives you a single IPv4 inside a /24, but the host owns one address. Configure it as/32with an on-link route to the gateway. Using/24makes the kernel believe other addresses in the block are LAN neighbors when they are not. - IPv4 gateway is the
.254of the /24. For198.51.100.59the gateway is198.51.100.254. - IPv6 is a routed
/64(High Grade and Scale servers get a/56; Kimsufi servers get a single/128instead). Configure the host’s IPv6 address with the/64prefix, not/128. The gateway is the same prefix with the last block of the network part replaced byffand the host part set toff:ff:ff:ff: for2001:db8:303:9a3b::1the gateway is2001:db8:303:9aff:ff:ff:ff:ff(leading zeros may be dropped). The gateway sits outside your/64, so the IPv6 default route also needson-link. - Virtual MACs. Each additional IP assigned to an instance needs a virtual MAC generated in the OVH control panel (pick the “vmware” type, any name). The instance NIC must use that MAC, otherwise OVH filters the traffic.
- One VM, several IPs, one MAC. If a single instance owns more than one OVH IP, every one of those IPs must be tied to the same virtual MAC in the OVH panel.
- Use OVH resolvers in production:
213.186.33.99(IPv4) and2001:41d0:3:163::1(IPv6). - Interface names in the examples (
eno1) are examples. Replace with your real default interface fromip route | grep default.
Bridge mode
Section titled “Bridge mode”OVH’s own network documentation does not cover a host bridge configuration, since bridging is specific to the hypervisor, not to OVH’s network. The configuration below is VirtConsole’s recommended setup for a KVM host.
Replace the addresses, gateway and MAC below with your own. The examples use documentation values (198.51.100.59, gateway 198.51.100.254, 2001:db8:303:9a3b::1, MAC 02:00:00:aa:bb:cc).
OVH’s Debian 12 templates are cloud-init based and ship netplan, with IPv6 delivered as a routed /64 and IPv4 over DHCP at first boot. Replace the cloud-init netplan file with:
network: version: 2 renderer: networkd ethernets: eno1: dhcp4: no dhcp6: no optional: true match: macaddress: 02:00:00:aa:bb:cc set-name: eno1 bridges: br0: interfaces: [eno1] macaddress: 02:00:00:aa:bb:cc addresses: - 198.51.100.59/32 - 2001:db8:303:9a3b::1/64 routes: - to: 0.0.0.0/0 via: 198.51.100.254 on-link: true - to: "::/0" via: "2001:db8:303:9aff:ff:ff:ff:ff" on-link: true nameservers: addresses: [213.186.33.99, 2001:41d0:3:163::1] parameters: stp: false forward-delay: 0Apply with netplan apply.
If you installed the server from a custom image rather than an OVH template, there may be no netplan renderer available. Use ifupdown’s /etc/network/interfaces instead, with the same addresses, gateways and pointopoint/on-link equivalents shown on the Hetzner networking page.
List the active connections with nmcli connection show, then read the physical NIC’s MAC:
nmcli connection show "System eno1" | grep mac-addressCreate a bridge that clones it:
nmcli connection add type bridge con-name br0 ifname br0nmcli connection modify br0 ipv4.addresses '198.51.100.59/32' ipv4.gateway '198.51.100.254' ipv4.dns '213.186.33.99' ipv4.method manualnmcli connection modify br0 +ipv4.routes '198.51.100.254/32'nmcli connection modify br0 ipv6.addresses '2001:db8:303:9a3b::1/64' ipv6.gateway '2001:db8:303:9aff:ff:ff:ff:ff' ipv6.dns '2001:41d0:3:163::1' ipv6.method manualnmcli connection modify br0 +ipv6.routes '2001:db8:303:9aff:ff:ff:ff:ff/128'nmcli connection modify 'System eno1' master br0nmcli connection modify br0 connection.autoconnect-slaves 1nmcli connection modify br0 ethernet.cloned-mac-address 02:00:00:aa:bb:ccnmcli connection up br0 && nmcli connection up 'System eno1'The extra +ipv4.routes and +ipv6.routes entries do the same job as netplan’s on-link: true: they tell NetworkManager the gateway is directly reachable even though it sits outside the host’s prefix.
Replace the default /etc/netplan/50-cloud-init.yaml with:
network: version: 2 renderer: networkd ethernets: eno1: match: macaddress: 02:00:00:aa:bb:cc dhcp4: no dhcp6: no bridges: br0: macaddress: 02:00:00:aa:bb:cc interfaces: - eno1 dhcp4: no dhcp6: no addresses: - 198.51.100.59/32 - 2001:db8:303:9a3b::1/64 routes: - to: 0.0.0.0/0 via: 198.51.100.254 on-link: true - to: "::/0" via: "2001:db8:303:9aff:ff:ff:ff:ff" on-link: true nameservers: addresses: - 213.186.33.99 - 2001:41d0:3:163::1Apply with:
netplan applyGuest configuration
Section titled “Guest configuration”Instances also need static configuration; OVH does not offer DHCP for additional IPs. The instance NIC must use the virtual MAC created for that IP in the OVH control panel, never the host’s own MAC. The example below uses the documentation value 198.51.100.80 for the additional IP, with the same .254 gateway as the host.
network: version: 2 ethernets: eth0: dhcp4: no addresses: - 198.51.100.80/32 routes: - to: 0.0.0.0/0 via: 198.51.100.254 on-link: true nameservers: addresses: [213.186.33.99]auto eth0iface eth0 inet staticaddress 198.51.100.80netmask 255.255.255.255gateway 198.51.100.254nmcli connection modify eth0 ipv4.address '198.51.100.80/32'nmcli connection modify eth0 ipv4.gateway '198.51.100.254'nmcli connection modify eth0 ipv4.dns '213.186.33.99'nmcli connection modify eth0 ipv4.method manualnmcli connection up eth0In VirtConsole, configure the subnet with the .254 of the server’s /24 as the gateway and 255.255.255.255 as the netmask, then attach the additional IP with its virtual MAC to the instance.
Common problems
Section titled “Common problems”- The server loses network minutes after boot. A MAC mismatch. The bridge must clone the physical NIC’s MAC, and every instance IP needs its virtual MAC from the OVH panel.
- One instance with several OVH IPs keeps dropping. The IPs are tied to different virtual MACs. Point them all at the same MAC.

