Predictable interface names are a new thing. The most common argument made is that they are not really predictable though, depending on the point of view. How about making interface names predictable and meaningful in the same time?
Most admins will probably think of udev right now, which previously was heavily used to achieve exactly that. In times of systemd the new hotness are .link files which provide similar capabilities and allow even more options to be set for interfaces.
To mimic the behavior we were used to have by udev, to (re)name interfaces identified by their MAC addresses, we have to create one ini-style .link file for every interface. As it should be a persistent configuration we should place them in /etc/systemd/network/.
Note, that the file name has to end with .link otherwise the file will be ignored. Further note, that the default .link file is named 99-default.link and will handle every interface not handled by any other .link file evaluated before 99-default.link was read; evaluation happens in lexical order, so make sure your files are named accordingly. See the first paragraph of the man page for more details.
An example could be named /etc/systemd/network/42-vlan1017.link and look like this:
[Match] MACAddress=52:54:f2:04:10:17 [Link] Name=vlan1017
After rebuilding the initial ramdisk (on Debian systems run update-initramfs -k all -u) the interface with the given MAC address will be named vlan1017 after a reboot. Bam, simple as that.
These files obviously can be easily generated by some kind of automation (SaltStack, Ansible, Chef, …) reading data from a DCIM like netbox.
Pitfalls
This simple approach might fail if virtual interfaces (VLANs, bridges) will be created on top of a renamed interface as the newly created interfaces might have the same MAC address. This can be mitigated by adding a match for the driver providing the interface:
[Match] MACAddress=52:54:f2:04:10:17 Driver=virtio_net [Link] Name=vlan1017
That way only interfaces matching the MAC address and the driver will be renamed and virtual interfaces will be left alone as they are provided by a different driver.
Note that the driver you can find at /sys/class/net/<iface>/device/driver may not be the one you need to put in here. ethtool -i <iface> seems to be the reliable source. One example where these two show different values are the Mellanox ConnectX NICs, where /sys will show mlx4_core and ethtool -i will show mlx4_en.
Disable all the offloading
.link files can do even more. It’s possible to disable certain offloading features on interfaces as well, which will come in handy if the box in question is forwarding traffic. The man page currently lists those knobs for tweaking offloading features which might make the difference between 4KB/s and 40MB/s (or more):
TCPSegmentationOffload= The TCP Segmentation Offload (TSO) when true enables TCP segmentation offload. Takes a boolean value. Defaults to "unset". GenericSegmentationOffload= The Generic Segmentation Offload (GSO) when true enables generic segmentation offload. Takes a boolean value. Defaults to "unset". UDPSegmentationOffload= The UDP Segmentation Offload (USO) when true enables UDP segmentation offload. Takes a boolean value. Defaults to "unset". GenericReceiveOffload= The Generic Receive Offload (GRO) when true enables generic receive offload. Takes a boolean value. Defaults to "unset". LargeReceiveOffload= The Large Receive Offload (LRO) when true enables large receive offload. Takes a boolean value. Defaults to "unset".