I’ve talked about predictable network names (and seemingly unpredictable ones) on the blog before, but some readers asked me how they could alter the network naming to fit a particular situation. Oddly enough, my Supermicro 5028D-T4NT has a problem with predictable names and it’s a great example to use here. The problem There’s plenty of detail in my post about the Supermicro 5028D-T4NT, but the basic gist is that something within the firmware is causing the all of the network cards in the server to show up as onboard.
Earlier today, I wrote a post about my first thoughts on the Supermicro 5028D-T4NT server. The 10Gb interfaces on the server came up with the names eth0 and eth1. That wasn’t what I expected. There’s tons of detail on the problem in the blog post as well as the Github issue. Kay Sievers gave a hint about how to adjust the interfacing naming in a more granular way than simply disabling the predictable network names.
I talked a bit about systemd’s network device name in my earlier post about systemd-networkd and bonding and I received some questions about how systemd rolls through the possible names of network devices to choose the final name. These predictable network device names threw me a curveball last summer when I couldn’t figure out how the names were constructed. Let’s walk through this process. What’s in a name? Back in the systemd-networkd bonding post, I dug into a dual port Intel network card that showed up in a hotplug slot:
I’ve written about systemd-networkd in the past and how easy it can be to set up new network devices and tunnels. However, the documentation on systemd-networkd with bonding is a bit lacking (but I have a pull request pending for that). Rackspace’s OnMetal Servers are a good place to test since they have bonded networks configured by default. They’re also quite fast and always fun for experiments. To get started, head on over to the Rackspace Cloud control panel and build a compute-1 OnMetal server and choose Fedora 22 as your operating system.