OVH, well known French provider of Bare-metal machines, public clouds and all that jazz offers, as they should, a service for allocating public IPs to your servers, VMs and containers.
Recently renamed “Additional IPs” it used to be called “IP Failover”.
The way this service works can be disconcerting as the documentation is scarce, imprecise and inconstant and most of all, it does not explain how and why things are done the way they are. Add on top of that recent evolution on the network stack (netplan, we are looking at you) and you’re close to certain to loose your sanity.
Fear not, Garaia’s team is here to help :-). And in the end, you’ll see that OVH actually offers added flexibility.
What is going on with OVH MAC addresses ?
That’s where most of the confusion comes from : Why does OVH offers optional MAC addresses ? Do you have to use it ?
So without getting into the details, MAC (Layer2) precedes IP (Layer3) in the networking. That is to say that your computer first announces its MAC on a network and then gets or sets an IP. In short, OVH made the choice to filter all data by MAC Address.
So if you have a virtual network interface in your VM/Container that announces its own MAC address on the network, you are out of luck as OVH will not be capable of routing anything to you.
But LXD has a simple answer to this
Indeed routed interfaces in LXD are exactly made for this. You attach another IP to a container but it is broadcasting your host MAC address. OVH knows on which port of which switch to direct the frames and LXD’s internal routing then … routes everything from an to your container (or VM).
It’s really as simple as this
# replace container-name, your-host-interface and fail.over.i.p
# with your own values
lxc config device add container-name eth1 nic nictype=routed parent=your-host-interface ipv4.address=fail.over.i.p
lxc restart container-nameYour host interface can be something like enp33s0f0. To be sure, just type ip -a and check where the public IP your main server appears, that is the one.
But wait, you forgot the gateway
Nope… You’ll route fine with your host’s gateway.
Virtual MAC is really for Proxmox (and others)
Proxmox uses a bridge configured in such a way that the virtual MAC of every VM/Container is announced… So no routed NIC for you.
But you can also set the MAC address of your container/VM, and that’s where OVH virtual MACs come in play. OVH will issue a MAC and associate it with the port of your bare-metal server and the IP.
This article is not about Proxmox, but for the interested reader, the procedure is straightforward enough :
- Open your VM/Container network settings
- Set your MAC your address/24 and the gateway (the gateway address is your ip adress with 254 as the last three digits xxx.xxx.xxx.254
- Restart your network/vm/container
What about providers that automatically assign a MAC to their IPs
Some providers will give you an IP with a fixed MAC associated. How would you manage this in LXD ?
Possibly the same way as before
It is possible that the provider does not actually filter frames by MAC address even if they provide one for other reasons. So you could try a routed NIC and see how it goes.
MACVLAN to the rescue
But in most cases, if you are provided with a MAC, you need to use it. And LXD way to get a LAN IP, whilst broadcasting a specific MAC is MACVLAN.
It works basically the same way as a routed NIC, with the added constraint that your Bare-Metal host and your VM/Container will not be able to resolve each other (via network that is, you can still shell, push, etc from the host of course). VMs and containers will keep their connectivity though, so not a problem except in corner cases.
Resources
https://documentation.ubuntu.com/lxd/en/latest/reference/devices_nic/