We have been having discussions in the netdev list about creating multiple names for the network interfaces to bring determinism into the way network interfaces are named in the OSes. In specific, "eth0 in the OS does not always map to the integrated NIC Gb1 as labelled on the chassis".
http://marc.info/?l=linux-netdev&m=125510301513312&w=2 - (Re: PATCH: Network Device Naming mechanism and policy) http://marc.info/?l=linux-netdev&m=125619338904322&w=2 - ([PATCH] udev: create empty regular files to represent net)
As a result of those discussions, we propose an installer based solution.
Installers as of now allow the discovered network interfaces to be configured. This solution proposes to provide an option for the users to either retain the default naming convention that the kernel now has, i.e ethN names or rename the network interfaces based on the chassis label, MAC addresses, Driver name and any other naming convention. Here is how the modified network configuration wizard would look during the os installation process -
---------- Network Configuration ------------------------
Default [ ] | SMBIOS Names [x] | Driver Names [] | MAC Names [] ----------------------------------------------------------------------- eth0 | Addin_NIC_1 | ice0 | ----------------------------------------------------------------------- eth1 | Embedded_NIC_1 | bce0 | ----------------------------------------------------------------------- eth2 | Embedded_NIC_2 | bce1 | ----------------------------------------------------------------------- eth3 | Embedded_NIC_3 | bce2 | ----------------------------------------------------------------------- eth4 | Embedded_NIC_4 | bce3 | -----------------------------------------------------------------------
------------ | Next | ------------
[ ice0 - Intel Controller 0, bce0 - Broadcom Controller 0 ]
1. In addition to the default ethN names the user can check against the available naming conventions and the wizard would show the names the interfaces will be renamed to. 2. The moment the user hits the Next button all interfaces are renamed as per the Naming convention they have selected. 3. Any further network communication would be using the new names. 4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
This way the OS names of network interfaces would have a co-relation to the chassis names. Irrespective of what the OS names the integrated port one, i.e eth0 or eth1, Embedded_NIC_1 will always refer to the integrated port 1, bringing in determinism.
Additional Reference: http://marc.info/?l=linux-hotplug&m=125692284431543&w=2 http://marc.info/?l=linux-netdev&m=125683519310462&w=2 http://marc.info/?l=linux-netdev&m=125754944814387&w=2 http://marc.info/?l=linux-hotplug&m=125536996902867&w=2
With regards, Narendra K
On Fri, 2009-11-27 at 03:42 -0600, Narendra K wrote:
We have been having discussions in the netdev list about creating multiple names for the network interfaces to bring determinism into the way network interfaces are named in the OSes. In specific, "eth0 in the OS does not always map to the integrated NIC Gb1 as labelled on the chassis".
http://marc.info/?l=linux-netdev&m=125510301513312&w=2 - (Re: PATCH: Network Device Naming mechanism and policy) http://marc.info/?l=linux-netdev&m=125619338904322&w=2 - ([PATCH] udev: create empty regular files to represent net)
As a result of those discussions, we propose an installer based solution.
Very cool. Thanks for your continued hard work on this stuff :) Do you have proof of concept Anaconda patches available?
Jon.
Narendra K (Narendra_K@dell.com) said:
Installers as of now allow the discovered network interfaces to be configured. This solution proposes to provide an option for the users to either retain the default naming convention that the kernel now has, i.e ethN names or rename the network interfaces based on the chassis label, MAC addresses, Driver name and any other naming convention. Here is how the modified network configuration wizard would look during the os installation process -
---------- Network Configuration ------------------------
Default [ ] | SMBIOS Names [x] | Driver Names [] | MAC Names []
eth0 | Addin_NIC_1 | ice0 |
eth1 | Embedded_NIC_1 | bce0 |
eth2 | Embedded_NIC_2 | bce1 |
eth3 | Embedded_NIC_3 | bce2 |
eth4 | Embedded_NIC_4 | bce3 |
------------ | Next | ------------
[ ice0 - Intel Controller 0, bce0 - Broadcom Controller 0 ]
- In addition to the default ethN names the user can check against the available naming conventions and the wizard would show the names the interfaces will be renamed to.
- The moment the user hits the Next button all interfaces are renamed as per the Naming convention they have selected.
- Any further network communication would be using the new names.
- Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
That's a horrible interface to show the user when a large portion of them do not care at all. (Also, not sure why netdev@vger cares about the implementation details of OS installers.)
Bill
Please don't send mails like this to anaconda-devel-list and netdev at the same time. The lists serve two completely unrelated purposes.
On 11/27/2009 04:42 AM, Narendra K wrote:
... I think the UI suggested here is really bad, as is the process behind it. Adding a "pick your network device name" step anywhere in anaconda, even in kickstart, is a bad plan. A better plan would be something like:
1) make kickstart accept various different names by using libnetdevname or something similar 2) make libnetdevname capable of telling us a reasonable name for an interface for user display (i.e. smbios name with spaces instead of _ or somesuch) 3) display and log those names (and /possibly/ the real interface name) where appropriate, which might include something like a "details" section describing a particular interface.
- In addition to the default ethN names the user can check against
the available naming conventions and the wizard would show the names the interfaces will be renamed to.
What ever happened to the plan of making OS tools (i.e. anaconda, NetworkManager, and ifup, but not necessarily ifconfig) use libnetdevname to do this translation, and leaving the kernel names like they've always been, which people are used to and people who aren't effected by won't have to deal with, and having libnetdevname do the entire translation itself in userland? This is what mdomsch and I discussed on Oct 30th.
I'm getting tired of the cycle of:
1) dell comes up with a suggestion 2) people don't like the way they're doing it 3) dell goes away and talks amongst themselves 4) dell comes up with a suggestion that ignores the feedback 5) goto step 2.
- The moment the user hits the Next button all interfaces are
renamed as per the Naming convention they have selected. 3. Any further network communication would be using the new names. 4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
Renaming the devices is exactly what we were trying to get around by making userland tools use libnetdevname.
This way the OS names of network interfaces would have a co-relation to the chassis names.
You mean the kernel name here, not the "OS" name. And in general, changing the kernel names isn't something we want. That's why we went down the whole aliasing route in the first place!
We aren't trying to come up with new rocks to carry; we sent the proposal Peter and I discussed to netdev to have char devices; we got shot down, and GregKH suggested this installer-based approach... Installer guys hate it. Repeat. :-(
-- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux
-----Original Message----- From: Peter Jones [mailto:pjones@redhat.com] Sent: Monday, November 30, 2009 3:09 PM To: Discussion of Development and Customization of the Red Hat Linux Installer Cc: Iyer, Shyam; Hargrave, Jordan; Rose, Charles; Domsch, Matt Subject: Re: [PROPOSAL]: Support Alternate Network Device Naming Schemes
Please don't send mails like this to anaconda-devel-list and netdev at the same time. The lists serve two completely unrelated purposes.
On 11/27/2009 04:42 AM, Narendra K wrote:
... I think the UI suggested here is really bad, as is the process behind it. Adding a "pick your network device name" step anywhere in anaconda, even in kickstart, is a bad plan. A better plan would be something like:
1) make kickstart accept various different names by using libnetdevname or something similar 2) make libnetdevname capable of telling us a reasonable name for an interface for user display (i.e. smbios name with spaces instead of _ or somesuch) 3) display and log those names (and /possibly/ the real interface name) where appropriate, which might include something like a "details" section describing a particular interface.
- In addition to the default ethN names the user can check against
the available naming conventions and the wizard would show the names the interfaces will be renamed to.
What ever happened to the plan of making OS tools (i.e. anaconda, NetworkManager, and ifup, but not necessarily ifconfig) use libnetdevname to do this translation, and leaving the kernel names like they've always been, which people are used to and people who aren't effected by won't have to deal with, and having libnetdevname do the entire translation itself in userland? This is what mdomsch and I discussed on Oct 30th.
I'm getting tired of the cycle of:
1) dell comes up with a suggestion 2) people don't like the way they're doing it 3) dell goes away and talks amongst themselves 4) dell comes up with a suggestion that ignores the feedback 5) goto step 2.
- The moment the user hits the Next button all interfaces are
renamed as per the Naming convention they have selected. 3. Any further network communication would be using the new names. 4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
Renaming the devices is exactly what we were trying to get around by making userland tools use libnetdevname.
This way the OS names of network interfaces would have a co-relation to the chassis names.
You mean the kernel name here, not the "OS" name. And in general, changing the kernel names isn't something we want. That's why we went down the whole aliasing route in the first place!
anaconda-devel@lists.stg.fedoraproject.org