Re: how to compute predictable network interface names?
Hi Christian, On 02/24/17 12:43, Christian Seiler wrote: > > udev will then rename the device once it encounters it. > > In newer udev versions, it will use some (but not all) settings from > systemd.link files. The other settings are interpreted by > systemd.networkd. (And if you don't use that or don't have that > installed, they will be ignored.) That's also the reasnon why those > files are in a systemd directory, even though udev interprets some > parts of them - since the matching of interfaces is identical for > the purposes of udev and systemd-networkd, systemd developers decided > it would be simpler to have just one configuration file that is read > by both. (udev and systemd are both in the same repository, even > though you can use udev without systemd.) > Thats a bad choice. Now the man page is not installed on "udev-only" systems, because the package maintainer recognized it as a "systemd" man page. #857270 > > No. net.ifnames=0 will have udev completely ignore NamePolicy here > and not rename the interface at all. > Is there a policy option telling udev/systemd to not touch the interface names? AFAIU that should be easy to implement, but there is no "NamePolicy=keep" described in systemd.link(5) (or I was too blind to see). Regards Harri
Re: how to compute predictable network interface names?
On 02/24/2017 10:10 AM, Harald Dunkel wrote: > On 02/23/2017 04:25 PM, Christian Seiler wrote: >> >> There's a policy which are going to be preferred. man 5 systemd.link >> tells you what the options are and /lib/systemd/network/99-default.link >> tells you what the default setting is (the first successful one is >> used). > > Of course I stumbled over this one: > > % man 5 systemd.link > No manual entry for systemd.link in section 5 > > Now I got confused: Who is responsible for renaming the NIC names? > Is this a systemd feature, is this the job of udev, or are the NICs > renamed by the kernel very early at boot time? Shouldn't I get the > same predictable name for eth0, no matter what? udev is responsible. The kernel drivers give the NIC a name initially, and they can mark that name as being "persistent" or not. The vast majority of drivers do not mark the name as being persistent. The names the kernel returns will typically be something like eth0, etc. udev will then rename the device once it encounters it. In newer udev versions, it will use some (but not all) settings from systemd.link files. The other settings are interpreted by systemd.networkd. (And if you don't use that or don't have that installed, they will be ignored.) That's also the reasnon why those files are in a systemd directory, even though udev interprets some parts of them - since the matching of interfaces is identical for the purposes of udev and systemd-networkd, systemd developers decided it would be simpler to have just one configuration file that is read by both. (udev and systemd are both in the same repository, even though you can use udev without systemd.) >> On my Stretch system that is: >> >> NamePolicy=kernel database onboard slot path >> > > AFAIU > NamePolicy=kernel > > makes sure that net.ifnames=0 given on the kernel command line > works. Is this correct? No. net.ifnames=0 will have udev completely ignore NamePolicy here and not rename the interface at all. NamePolicy=kernel will most likely never trigger on any system you have (it has never triggered on any system I have), it's for the case where the kernel driver says "yeah, the name I chose is already a name that's going to be persistent". This will never be interfaces like eth0, etc. I suspect this is mostly for SoC-type devices which have one onboard network interface that's fixed and thus will always have the same name. >> 'kernel' and 'database' are likely going to fail in most cases (kernel >> means the kernel indicates that the name used so far is already >> predictable, which it only does for very special hardware, probably >> embedded or similar, and database means that there's an entry in the >> udev hardware database, which you'd have to do manually, because I >> don't know of any upstream rules), so basically it's the following >> logic: >> >> - first try ID_NET_NAME_ONBOARD >> - if that doesn't exist, try ID_NET_NAME_SLOT >> - if that doesn't exist, try ID_NET_NAME_PATH >> > Not to forget > > - if that doesn't exist, use INTERFACE >From the code logic, sure, but you'll be hard-pressed to find an interface that doesn't have ID_NET_NAME_PATH set. ;-) Regards, Christian
Re: how to compute predictable network interface names?
On 02/24/2017 10:10 AM, Harald Dunkel wrote: > > Now I got confused: Who is responsible for renaming the NIC names? > Is this a systemd feature, is this the job of udev, or are the NICs > renamed by the kernel very early at boot time? Shouldn't I get the > same predictable name for eth0, no matter what? > PS: Assuming the hardware isn't changed, of course. Harri
Re: how to compute predictable network interface names?
On 02/23/2017 04:25 PM, Christian Seiler wrote: > > There's a policy which are going to be preferred. man 5 systemd.link > tells you what the options are and /lib/systemd/network/99-default.link > tells you what the default setting is (the first successful one is > used). Of course I stumbled over this one: % man 5 systemd.link No manual entry for systemd.link in section 5 Now I got confused: Who is responsible for renaming the NIC names? Is this a systemd feature, is this the job of udev, or are the NICs renamed by the kernel very early at boot time? Shouldn't I get the same predictable name for eth0, no matter what? > On my Stretch system that is: > > NamePolicy=kernel database onboard slot path > AFAIU NamePolicy=kernel makes sure that net.ifnames=0 given on the kernel command line works. Is this correct? > 'kernel' and 'database' are likely going to fail in most cases (kernel > means the kernel indicates that the name used so far is already > predictable, which it only does for very special hardware, probably > embedded or similar, and database means that there's an entry in the > udev hardware database, which you'd have to do manually, because I > don't know of any upstream rules), so basically it's the following > logic: > > - first try ID_NET_NAME_ONBOARD > - if that doesn't exist, try ID_NET_NAME_SLOT > - if that doesn't exist, try ID_NET_NAME_PATH > Not to forget - if that doesn't exist, use INTERFACE Thanx very much for your detailed response. Harri
Re: how to compute predictable network interface names?
On Thu, Feb 23, 2017, at 10:16, Harald Dunkel wrote:
> On 02/16/2017 12:47 PM, Christian Seiler wrote:
> >
> > On a system with predictable names running? Or on a system
> > pre-upgrade?
> >
>
> Its more "pre-installation". I boot a USB stick and run
> my own installer (using debootstrap or creating a clone).
> The NIC name is needed to setup /etc/network/interfaces.
> I know how the interfaces are named using the old scheme,
> but the predictable names are hard to guess.
>
Debian used to assign network devices based on MAC address.
If you want to continue doing something like that, use the
kernel boot parameter
net.ifnames=0
and create your own udev rule. For example:
/etc/udev/rules.d/76-netnames.rules:
# Create custom network interface names based on MAC address.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:25:86:61:87",
NAME="net0"
This rule will assign the Ethernet adapter with MAC address 00:11:25:86:61:87
the interface name net0. Reference the interface by this name in
/etc/network/interfaces.
I hope this helps.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Re: how to compute predictable network interface names?
On 02/23/2017 04:16 PM, Harald Dunkel wrote: > On 02/16/2017 12:47 PM, Christian Seiler wrote: >> >> On a system with predictable names running? Or on a system >> pre-upgrade? >> > > Its more "pre-installation". I boot a USB stick and run > my own installer (using debootstrap or creating a clone). > The NIC name is needed to setup /etc/network/interfaces. > I know how the interfaces are named using the old scheme, > but the predictable names are hard to guess. > >> Because if you have a system that's being upgraded at the >> moment, the following command _might_ work _after_ you've >> upgraded udev and _before_ you've rebooted the system. >> >> udevadm info /sys/class/net/eth4 >> >> Look at ID_NET_NAME there. >> > > I found 3 for eth0 on my desktop PC: > > E: ID_NET_NAME_MAC=enx54bef70930bd > E: ID_NET_NAME_ONBOARD=eno1 > E: ID_NET_NAME_PATH=enp0s25 > > For a server with 6 NICs I got for eth4 > > E: ID_NET_NAME_MAC=enx0cc47a860566 > E: ID_NET_NAME_PATH=enp4s0f2 > E: ID_NET_NAME_SLOT=ens261f2 > > A wild guess would be it is "ID_NET_NAME_PATH" unless there is > a "ID_NET_NAME_ONBOARD" ? I understand that this is the fragile > part. There's a policy which are going to be preferred. man 5 systemd.link tells you what the options are and /lib/systemd/network/99-default.link tells you what the default setting is (the first successful one is used). On my Stretch system that is: NamePolicy=kernel database onboard slot path 'kernel' and 'database' are likely going to fail in most cases (kernel means the kernel indicates that the name used so far is already predictable, which it only does for very special hardware, probably embedded or similar, and database means that there's an entry in the udev hardware database, which you'd have to do manually, because I don't know of any upstream rules), so basically it's the following logic: - first try ID_NET_NAME_ONBOARD - if that doesn't exist, try ID_NET_NAME_SLOT - if that doesn't exist, try ID_NET_NAME_PATH Regards, Christian
Re: how to compute predictable network interface names?
On 02/16/2017 12:47 PM, Christian Seiler wrote: > > On a system with predictable names running? Or on a system > pre-upgrade? > Its more "pre-installation". I boot a USB stick and run my own installer (using debootstrap or creating a clone). The NIC name is needed to setup /etc/network/interfaces. I know how the interfaces are named using the old scheme, but the predictable names are hard to guess. > Because if you have a system that's being upgraded at the > moment, the following command _might_ work _after_ you've > upgraded udev and _before_ you've rebooted the system. > > udevadm info /sys/class/net/eth4 > > Look at ID_NET_NAME there. > I found 3 for eth0 on my desktop PC: E: ID_NET_NAME_MAC=enx54bef70930bd E: ID_NET_NAME_ONBOARD=eno1 E: ID_NET_NAME_PATH=enp0s25 For a server with 6 NICs I got for eth4 E: ID_NET_NAME_MAC=enx0cc47a860566 E: ID_NET_NAME_PATH=enp4s0f2 E: ID_NET_NAME_SLOT=ens261f2 A wild guess would be it is "ID_NET_NAME_PATH" unless there is a "ID_NET_NAME_ONBOARD" ? I understand that this is the fragile part. Nice tip, thanx very much Harri
Re: how to compute predictable network interface names?
On Thu, Feb 16, 2017 at 12:47:25PM +0100, Christian Seiler wrote: > On a system with predictable names running? Or on a system > pre-upgrade? > > Because if you have a system that's being upgraded at the > moment, the following command _might_ work _after_ you've > upgraded udev and _before_ you've rebooted the system. > > udevadm info /sys/class/net/eth4 > > Look at ID_NET_NAME there. > > Can't really test that though, since I don't have a setup > with the old scheme that I still need to upgrade, so this > might not work at all. I'm a bit confused here. On a system that's upgraded from jessie to stretch, why would the interface names change at all? The old eth0 style names are recorded in /etc/udev/rules.d/70-persistent-net.rules and the interfaces continue to come up as eth0, etc. Are you talking about a scenario where you upgrade to stretch and then add a new NIC? But even then it still wouldn't make sense, because you wouldn't have had a previous "eth4" name that you want to map to a new name. You'd just get the new name. Or are you talking about a hypothetical scenario where you upgrade to stretch and then remove the contents of /etc/udev/rules.d/70-persistent-net.rules, but before you do that, you want to see what the interfaces will become? That seems... quite odd to me. Why not just leave the interfaces alone?
Re: how to compute predictable network interface names?
On 02/16/2017 12:24 PM, Harald Dunkel wrote: > I understand that the predictable nic names can be turned off > using > > net.ifnames=0 > > on the kernel command line, but I wonder if there is a shell > script to actually predict the "enpYsZ" from the old style > "ethX" initially assigned by the kernel? Something like > > % predict_nic eth4 > enp12s1 On a system with predictable names running? Or on a system pre-upgrade? Because if you have a system that's being upgraded at the moment, the following command _might_ work _after_ you've upgraded udev and _before_ you've rebooted the system. udevadm info /sys/class/net/eth4 Look at ID_NET_NAME there. Can't really test that though, since I don't have a setup with the old scheme that I still need to upgrade, so this might not work at all. If your system has already switched to the new scheme, then 'eth4' is meaningless once the devices have been renamed, so you don't really know. Also, the reason why the new scheme was introduced is that on some systems ethX is not reproducible: the order in which the devices are found by the kernel can change (especially if you have USB devices, but also in other cases) so 'eth4' is often ambivalent anyway. If you have some other information on identifying the device (such as the device's MAC address), you can identify it that way by looking for the interface with that MAC and name it something yourself. For example, you could create a file [1] /etc/systemd/network/10-uplink.link with the following contents: [Match] MACAddress=xx:yy:zz:gg:hh:ii [Link] Name=uplink This way the network interface with the specified MAC address is now called "uplink" instead of "enp12s1" or whatever it was previously. You can also match by PCI paths (udevadm info's ID_PATH attribute) and matching supports wildcards. See the manpage for systemd.link for further details. Regards, Christian [1] This works even on non-systemd systems with udev because *.link files are interpreted by udev's builtin and _not_ by systemd, so technically the location is a bit misleading.
how to compute predictable network interface names?
Hi folks, I understand that the predictable nic names can be turned off using net.ifnames=0 on the kernel command line, but I wonder if there is a shell script to actually predict the "enpYsZ" from the old style "ethX" initially assigned by the kernel? Something like % predict_nic eth4 enp12s1 There are some recipes I found on the net, but they all appear questionable or "this_vendor systems only" or work only for X=0 or look just like some attempt to start yet another flame war. Parsing dmesg output seems to be the most stable solution I found by now. Every helpful comment is highly appreciated. Regards Harri
