Linux Archive - : Support Alternate Network Device Naming Schemes

Linux Archive (http://www.linux-archive.org/)

- Ubuntu User (http://www.linux-archive.org/ubuntu-user/)

- - : Support Alternate Network Device Naming Schemes (http://www.linux-archive.org/ubuntu-user/286903-support-alternate-network-device-naming-schemes.html)

Narendra K

11-27-2009 08:11 AM

: Support Alternate Network Device Naming Schemes

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Narendra K

11-27-2009 08:42 AM

: Support Alternate Network Device Naming Schemes

Jon Masters

11-30-2009 04:07 PM

: Support Alternate Network Device Naming Schemes

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.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Bill Nottingham

11-30-2009 05:34 PM

: Support Alternate Network Device Naming Schemes

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 ]
>
> 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.

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Peter Jones

11-30-2009 08:08 PM

: 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.

> 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.

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.

> 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!

--
Peter

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

11-30-2009 09:24 PM

: Support Alternate Network Device Naming Schemes

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.

> 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.

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.

> 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!

--
Peter

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Narendra K

12-01-2009 03:35 PM

: Support Alternate Network Device Naming Schemes

> > ---------- 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.
>
> That's a horrible interface to show the user when a large portion of
> them do not care at all.

In that case, it could look like below so that users would get to see
the new names only when they choose a naming convention and if the user
retains the default scheme, he need not see the names associated with
other naming conventions-

---------- Network Configuration ------------------------

The current config settings for each interface are listed next to each
device name. Unconfigured interfaces are shown as UNCONFIGURED. To con
figure each interface, hilight it and choose edit. When you are finished
prese OK to continue
eth0: Activate on boot, DHCP
eth2: UNCONFIGURED
eth3: UNCONFIGURED
eth4: UNCONFIGURED

-------- ------ --------
| Edit | | OK | | Back |
-------- ------ --------

We could move the "Edit, OK and Back" forward a little and instead,
provide the option of choosing a naming convention here as below -

Choose a naming convention -

Default [] SMBIOS Names [x] Driver names [] MAC Names []
---------- -------
| Details | | Next |
-------- -------
The "details" would provide a description of how the names
are determined.

The next screen would look like

Default SMBIOS Names
eth0: Embedded_NIC_1 Activate on boot, DHCP
eth2: Embedded_NIC_2 UNCONFIGURED
eth3: Embedded_NIC_3 UNCONFIGURED
eth4: Embedded_NIC_4 UNCONFIGURED

-------- ------ --------
| Edit | | OK | | Back |
-------- ------ --------

What are your views on this ?

With regards,
Narendra K

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Narendra K

12-01-2009 03:59 PM

: Support Alternate Network Device Naming Schemes

>
> ... 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.
>

Libnetdevname is needed when we have to map pathnames like
/dev/netdev/by-chassis-label/Embedded_NIC_1 to ethN names. Since we do
not have these pathnames, libnetdevname is useless here.Biosdevname
can suggest names to anaconda which can be shown to the users.

>
> 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!

The idea of multiple names for network interface devices, which allows
the ethN names to remain unaltered, was not accepted. An installer based
fix was suggested. Hence this proposal.

With regards,
Narendra K

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Peter Jones

12-01-2009 06:38 PM

: Support Alternate Network Device Naming Schemes

On 12/01/2009 11:59 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.
>>
>
> Libnetdevname is needed when we have to map pathnames like
> /dev/netdev/by-chassis-label/Embedded_NIC_1 to ethN names. Since we do
> not have these pathnames, libnetdevname is useless here.Biosdevname
> can suggest names to anaconda which can be shown to the users.

Sure, we don't have those because udev doesn't have that logic. But the idea
behind libnetdevname can still be applied without that, though it makes the
library /somewhat/ more complex. There's nothing about the translation of "Embedded_NIC_1" to "if_index 0" that can't be entirely done in userland,
is there?

>> 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!
>
> The idea of multiple names for network interface devices, which allows
> the ethN names to remain unaltered, was not accepted. An installer based
> fix was suggested. Hence this proposal.

I don't understand why the response to "we won't do this in the kernel" is
"pick an entirely different model" rather than "move more of the logic to
the library". I think the model we had talked about with kernel aliasing
will still work, even though the implementation isn't as clean from any of
our points of view - libnetdevname simply has to do all the alias translation
itself, and applications supporting aliases have to use it instead of simply
consulting the udev database[1]. But that doesn't mean we can't use essentially
the same usage model and UI we'd talked about before.

I think any UI that has the user selecting which sort of thing they'd like
to use is bad. I think the right answer is really:

1) provide a library which can:
a) identify a kernel interface name for a given alias
b) provide a list of aliases for a given kernel interface name
c) tell us which alias is "descriptive", which in dell's
case means the SMBIOS name
2) provide a command line tool suitable for use in scripting to:
a) tell us the kernel name for a given alias
b) list aliases for a given kernel interface name
c) tell us which kernel name is "descriptive"
3) modify kickstart handlers to allow users to specify whichever kernel name
or alias is they want, and simply error if it's not a name the library
can resolve
4) modify anaconda's UI to display the "descriptive" name most of the time,
and possibly add some "more details" sorts of UI elements to say "by the
way, that devices is named eth0 in the kernel and is port 3 on
/sys/devices/pci0000:00/blah (i.e. list the aliases)
5) make other tools, such as ifup and NetworkManager, use the "descriptive" name
where appropriate.

[1]: in reality, we could also provide a udev rule that calls into a
small application which asks the library for a list of aliases for
$device, and create udev db files that way. I don't care, but that might
be stepping on Kay's toes a bit more than we'd prefer.

--
Peter

First things first -- but not necessarily in that order.
-- The Doctor

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

"Domsch, Matt"

12-07-2009 05:11 PM

: Support Alternate Network Device Naming Schemes

So I got some time to talk with Bill and Peter about this at FUDCon
(advantages of being face-to-face).

A few thoughts came up.
1) we need to run the idea of the patches to ifconfig, net-tools,
etc. by the upstream maintainers. If they shoot us down on those,
we're back to square one.

2) libnetdevname will grow to effectively do what biosdevname does
today, which is to get the list of smbios strings for each PCI device,
and let us use those strings. There would be no persistence - the
list is calculated all the time.

3) to avoid needing the above tools + libnetdevname needing to have
root privilages to be able to read /dev/mem to read the SMBIOS table,
we should expose the SMBIOS strings in sysfs. Yes, that's a kernel
patch, but other similar smbios data is getting exposed in sysfs all
the time.

3a) the string goes in a new file related to the PCI device.
3b) some cards like chelsio have 2 ethernet ports, but only one PCI
device. Our SMBIOS string model doesn't account for this. :-(
3c) may want /sys/firmware/smbios_pci/{strings} ->
/sys/devices/pci... so we don't have to walk all of sysfs looking
for the strings.

doing so, biosdevname goes away completely.

4) this doesn't change the netdevice name, doesn't
change the kernel net/ code, and doesn't use udev at all. But it
also doesn't provide us a way to add user-defined persistent aliases.
For that, we would need libnetdevname to maintain its own alias
database in /var/lib/. I'm fine adding this later.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

All times are GMT. The time now is 01:34 PM.