[PROPOSAL]: Alias names for network interfaces

[PROPOSAL]: Alias names for network interfaces

[Narendra_K]

Hello,

[Please let me know if I have missed copying relevant list]

We have been having discussions in the netdev list and
anaconda-devel-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 labeled
on the chassis". This resulted in failures where user space expected the
port with link up to be "eth0", which in many cases would not be the
case. 
For example, installers and firewall. 

For more information on the issue please refer to
http://linux.dell.com/wiki/index.php/Oss/libnetdevname.

* For every network interface ethN, create a corresponding
/dev/net/ethN, which is a char device node, with minor number as the
interface index of the device.
And create symbolic links to this node under /dev/netdev/ such as
/dev/netdev/by-chassis-label/Embedded_NIC_1 which are based on smbios
names of the interfaces. 
Irrespective of what the OS names the port "Gb1" as,
/dev/netdev/by-chassis-label/Embedded_NIC_1 would always point to the
right interface with link up

http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Proposal_1:

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)

It was suggested that an installer based approach be adopted

* Installer would provide options to the users to name the interfaces
based on different naming conventions such as

a)Chassis label - For Ex: Embedded_NIC_1[23..]
b)Driver based names - For Ex: bce0, bce1 etc

https://www.redhat.com/archives/anaconda-devel-list/2009-November/msg005
16.html
https://www.redhat.com/archives/anaconda-devel-list/2009-December/msg000
27.html

This was not favored too. These discussions resulted in a solution where
the alias names for network devices be implemented
completely in user space. In this solution libnetdevname would be
suggesting the alias names for network interfaces based on the bios
given
names for the interfaces. The bios names for the network interfaces are
available via smbios tables.

http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Proposal_2


The solution would have below mentioned components - 


1. A library which would provide the following functionality.

    * Given an alias name, it would return the kernel name
    * Given a kernel name, provide a list of aliases
    * Tell us which alias is descriptive for a given kernel name, which
in this case will be Embedded_NIC_N 

2. User space tools like ifconfig, ip and iptables would support these
aliases such as Embedded_NIC_1 in addition to the ethN names.
These tools would call upon the library to map the Embedded_NIC_1 to a
ethN name. This would help bring in determinism in the way 
network interfaces are referred so that tools that expect determinism do
not fail.

For example - 

/sbin/ifconfig Embedded_NIC_1
/sbin/ip Embedded_NIC_N

Embedded_NIC_1 would always refer to the Integrated Port 1 on the system
Chassis labelled "Gb1" irrespective of how it is named by
the kernel and the library would provide this mapping. 


This solution would not need the kernel names of the network interfaces
(i.e ethN) to be changed. Here is how an example patch would 
look like - 

+	if (netdev_alias_to_kernel_name(alias_name,kernel_ifname) < 0) {
+                show_alias_name_usage();
+	}
+        strncpy(ifname, kernel_ifname, IFNAMSIZ);


where alias_name is "Embedded_NIC_N" and kernel name is ethN which is
returned by the library after it maps the bios given name to the 
kernel name of the network interface.( Here are some example patches for
ethtool, ip and net-tools which were written for char device node
solution. The patches to implement new proposal would look similar -

http://linux.dell.com/libnetdevname/patches/net-tools-1.60_libnetdevname
.patch
http://linux.dell.com/libnetdevname/patches/ethtool-6_libnetdevname.patc
h
http://linux.dell.com/libnetdevname/patches/iproute2-2.6.29_libnetdevnam
e.patch )


We would like to know the views of the upstream maintainers of the tools
about this proposal.

With regards,
Narendra K
Linux Engineering

Re: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Thursday 2009-12-17 14:54, Narendra_K@Dell.com wrote:

>We have been having discussions in the netdev list and
>anaconda-devel-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 labeled
>on the chassis". This resulted in failures where user space expected the
>port with link up to be "eth0", which in many cases would not be the
>case. 
>For example, installers and firewall. 

I concur, with one exception: if, considering a single multi-port
card, I get interface names in reverse to what is printed on the
adapter. That looks like a manufacturer fail.

The firewall does not care. Just keep the name constant, which is
what udev's 70-persistent-net.rules already does.

>* Installer would provide options to the users to name the interfaces
>based on different naming conventions such as
>
>a)Chassis label - For Ex: Embedded_NIC_1[23..]
>b)Driver based names - For Ex: bce0, bce1 etc

As far as I can tell, all (Ethernet) driver names default
to ethX (or wlanX) only.

>For example - 
>
>/sbin/ifconfig Embedded_NIC_1
>/sbin/ip Embedded_NIC_N
>
>http://linux.dell.com/libnetdevname/patches/net-tools-1.60_libnetdevname
>.patch
>http://linux.dell.com/libnetdevname/patches/ethtool-6_libnetdevname.patc
>h
>http://linux.dell.com/libnetdevname/patches/iproute2-2.6.29_libnetdevnam
>e.patch )
>
>We would like to know the views of the upstream maintainers of the tools
>about this proposal.

The development of net-tools has long ceased (since 2001), except
that no one seems to notice and everybody still applies voltage to a
dead horse. It's only going to smell bad.

Re: [PROPOSAL]: Alias names for network interfaces

[Bernd Eckenfels]

On Thu, Dec 17, 2009 at 03:48:02PM +0100, Jan Engelhardt wrote:
> The development of net-tools has long ceased (since 2001), except
> that no one seems to notice and everybody still applies voltage to a
> dead horse. It's only going to smell bad.

Anyway: I think it is good to give interfaces a stable name by the installer
of the distribution. Isnt that what ifrename is used for?

I am not sure what the patch is supposed to do?

Greetings
Bernd

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> 
> On Thu, Dec 17, 2009 at 03:48:02PM +0100, Jan Engelhardt wrote:
> > The development of net-tools has long ceased (since 2001), except
> > that no one seems to notice and everybody still applies voltage to a
> > dead horse. It's only going to smell bad.
> 
> Anyway: I think it is good to give interfaces a stable name by the
> installer
> of the distribution. Isnt that what ifrename is used for?
> 
> I am not sure what the patch is supposed to do?
> 

The installer solution involved renaming the network interface names
from ethN to something else based on the naming convention that the user
specified. For example, if the user chose "smbios names" as the the
naming convention then all ethN would be renamed to Embedded_NIC_N.
ifconfig would show Embedded_NIC_N instead of ethN. 

I suppose the ifrename would rename network interfaces from ethN to ethN
and that would cause issues. The current proposal aims at providing non
ethN aliases like Embedded_NIC_N which would be mapped to an ethN name
by the proposed library (such as libnetdevname) which can then be used
for further operations. The SMBIOS tables provide these names and as the
BIOS would name the integrated port 1 of the system Embedded_NIC_1
always, irrespective of how the OS names it (i.e eth0 or eth1). This
brings in determinism into the way interfaces are referred to.

Current installer implementations do provide a way for persistency by
associating MAC addressees, but they do not have a way to assure
expected naming.

With regards,
Narendra K

RE: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Friday 2009-12-18 14:19, Narendra_K@Dell.com wrote:
>> 
>> Anyway: I think it is good to give interfaces a stable name by the
>> installer of the distribution. Isnt that what ifrename is used
>> for?
>> 
>> I am not sure what the patch is supposed to do?
>
>The installer solution involved renaming the network interface names
>from ethN to something else based on the naming convention that the user
>specified. For example, if the user chose "smbios names" as the the
>naming convention then all ethN would be renamed to Embedded_NIC_N.
>ifconfig would show Embedded_NIC_N instead of ethN. 
>
>I suppose the ifrename would rename network interfaces from ethN to ethN
>and that would cause issues.

What issues?

>The current proposal aims at providing non
>ethN aliases like Embedded_NIC_N which would be mapped to an ethN name
>by the proposed library (such as libnetdevname) which can then be used
>for further operations.

What is wrong with just renaming the actual interface? In fact you
could use udev itself for just that. /lib/udev/write_net_rules,
and instead of continuing to use the name the kernel set aside,
let it call out to smbios and voilà, your
/etc/udev/rules.d/70-persistent-net.rules would then show something
like:

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:20:18:8c:ce:70",
NAME="PCI_NIC_0"

That is not hard, and has the nice side effect of propagating through
all possible programs, because it is the actual interface name rather
than some alias for which you would need a library first.
In short, I would see PCI_NIC_0 in iptraf. Today.

>The SMBIOS tables provide these names and as the
>BIOS would name the integrated port 1 of the system Embedded_NIC_1
>always, irrespective of how the OS names it (i.e eth0 or eth1). This
>brings in determinism into the way interfaces are referred to.
>Current installer implementations do provide a way for persistency by
>associating MAC addressees, but they do not have a way to assure
>expected naming.

Mapping MACs to interface names is a sort of determinism -- it
remains the same over time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PROPOSAL]: Alias names for network interfaces

[Domsch, Matt]

On Fri, Dec 18, 2009 at 07:42:22AM -0600, Jan Engelhardt wrote:
> What is wrong with just renaming the actual interface? In fact you
> could use udev itself for just that.

a) The disk image then becomes 'stateful' with respect to MAC
addresses for NICs.  It breaks the scenario of hardware maintenance
whereby you remove the disks from one server, plug them into an
identical server, and power it back on.  Or replacing a NIC.  Or
booting the same image on multiple systems.

b) I'd really like to be able to use the platform-defined name
(e.g. Embedded_NIC_1) early in the installers, long before udev would
have set up 70-persistent-net.rules, for doing network-based installs.
The syslinux IPAPPEND 2 option is quite helpful I'll admit, but that
only sets up a deterministic mapping for one of the N NICs in a system
(N>=4 commonplace on all our servers).

c) it requires the user to make a choice as to what they want that
one-and-only name to be, either at install time (which the anaconda
team rejected), or later (meaning it's not really the one-and-only
name).

> Mapping MACs to interface names is a sort of determinism -- it
> remains the same over time.

Only so long as you don't replace any hardware components.

With the method we're proposing, the image remains stateless with respect to MAC addresses.

Thanks,
Matt

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

Re: [PROPOSAL]: Alias names for network interfaces

[Domsch, Matt]

On Fri, Dec 18, 2009 at 07:42:22AM -0600, Jan Engelhardt wrote:
> >I suppose the ifrename would rename network interfaces from ethN to ethN
> >and that would cause issues.
> 
> What issues?

historically, udev would wind up with NICs named:

eth0
eth0_rename
eth2
eth2_rename

instead of eth[0-4].  The renames running in parallel would conflict.
I'm told that DavidZ fixed this a recent udev, but I haven't
confirmed this is the case.

Regardless, this begs the question of how to name newly added NICs.
Today's method involves a human fixing up 70-persistent-net.rules to
match what they want it to be.  I hate that, when the platform itself
can provide a perfectly good answer.

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

Re: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Friday 2009-12-18 15:08, Domsch, Matt wrote:
>On Fri, Dec 18, 2009 at 07:42:22AM -0600, Jan Engelhardt wrote:
>> >I suppose the ifrename would rename network interfaces from ethN to ethN
>> >and that would cause issues.
>> 
>> What issues?
>
>historically, udev would wind up with NICs named:
>
>eth0
>eth0_rename
>eth2
>eth2_rename
>
>instead of eth[0-4].  The renames running in parallel would conflict.
>I'm told that DavidZ fixed this a recent udev, but I haven't
>confirmed this is the case.
>
>Regardless, this begs the question of how to name newly added NICs.
>Today's method involves a human fixing up 70-persistent-net.rules to
>match what they want it to be.  I hate that, when the platform itself
>can provide a perfectly good answer.

Of course. If the user chose to want SMBIOS names by default,
why not.

Except when the BIOS manufacturer left the SMBIOS info blank again.

Re: [PROPOSAL]: Alias names for network interfaces

[Stephen Hemminger]

On Fri, 18 Dec 2009 18:49:15 +0530
<Narendra_K@Dell.com> wrote:

> The installer solution involved renaming the network interface names
> from ethN to something else based on the naming convention that the user
> specified. For example, if the user chose "smbios names" as the the
> naming convention then all ethN would be renamed to Embedded_NIC_N.
> ifconfig would show Embedded_NIC_N instead of ethN.

Renaming away from ethN causes some applications like net-snmp to get confused,
and others have special sorting rules based on existing model (like quagga).

I would argue that the "ethN" convention is part of existing system
ABI and should not get changed in a visible way to applications.


-- 

RE: [PROPOSAL]: Alias names for network interfaces

[Jordan_Hargrave]

One proposal we are looking at is a kernel change to add an extra attribute to the /sys/devices/pciXXX directories.  SMBIOS Type 9 and 41 contain mapping between slot number/device name and PCI BDF.  Creating an extra attribute called 'slotname' or 'smbiosname' would allow accessing the desired name by /sys/class/net/ethX/device/smbiosname


--jordan Hargrave
Dell Enterprise Linux Engineering

-----Original Message-----
From: Jan Engelhardt [mailto:jengelh@medozas.de] 
Sent: Friday, December 18, 2009 8:15 AM
To: Domsch, Matt
Cc: K, Narendra; be-mail2009@lina.inka.de; net-tools@lina.inka.de; shemminger@osdl.org; netfilter-devel@vger.kernel.org; jgarzik@users.sourceforge.net; Rose, Charles; Hargrave, Jordan; Shandilya, Sandeep K
Subject: Re: [PROPOSAL]: Alias names for network interfaces


On Friday 2009-12-18 15:08, Domsch, Matt wrote:
>On Fri, Dec 18, 2009 at 07:42:22AM -0600, Jan Engelhardt wrote:
>> >I suppose the ifrename would rename network interfaces from ethN to ethN
>> >and that would cause issues.
>> 
>> What issues?
>
>historically, udev would wind up with NICs named:
>
>eth0
>eth0_rename
>eth2
>eth2_rename
>
>instead of eth[0-4].  The renames running in parallel would conflict.
>I'm told that DavidZ fixed this a recent udev, but I haven't
>confirmed this is the case.
>
>Regardless, this begs the question of how to name newly added NICs.
>Today's method involves a human fixing up 70-persistent-net.rules to
>match what they want it to be.  I hate that, when the platform itself
>can provide a perfectly good answer.

Of course. If the user chose to want SMBIOS names by default,
why not.

Except when the BIOS manufacturer left the SMBIOS info blank again.

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> On Fri, 18 Dec 2009 18:49:15 +0530
> <Narendra_K@Dell.com> wrote:
> 
> > The installer solution involved renaming the network interface names
> > from ethN to something else based on the naming convention that the
> user
> > specified. For example, if the user chose "smbios names" as the the
> > naming convention then all ethN would be renamed to Embedded_NIC_N.
> > ifconfig would show Embedded_NIC_N instead of ethN.
> 
> Renaming away from ethN causes some applications like net-snmp to get
> confused,
> and others have special sorting rules based on existing model (like
> quagga).
> 
> I would argue that the "ethN" convention is part of existing system
> ABI and should not get changed in a visible way to applications.

Stephen,

Thanks. What are your views on the current proposal we are making where
ethN names are not changed (or renamed) and libnetdevname would suggest
alias names for the ethN names ( and also alias to ethN names) in user
space. Applications like ip, ethtool etc can use these aliases, make
calls to libnetdevname and get the ethN name. 

Libnetdevname would read from sysfs the smbios names of the network
interface devices as Jordan mentioned
(/sys/class/net/ethX/device/smbiosname). Would this be acceptable ?

With regards,
Narendra K

Re: [PROPOSAL]: Alias names for network interfaces

[Stephen Hemminger]

On Mon, 21 Dec 2009 22:58:09 +0530
<Narendra_K@Dell.com> wrote:

> > On Fri, 18 Dec 2009 18:49:15 +0530
> > <Narendra_K@Dell.com> wrote:
> > 
> > > The installer solution involved renaming the network interface names
> > > from ethN to something else based on the naming convention that the
> > user
> > > specified. For example, if the user chose "smbios names" as the the
> > > naming convention then all ethN would be renamed to Embedded_NIC_N.
> > > ifconfig would show Embedded_NIC_N instead of ethN.
> > 
> > Renaming away from ethN causes some applications like net-snmp to get
> > confused,
> > and others have special sorting rules based on existing model (like
> > quagga).
> > 
> > I would argue that the "ethN" convention is part of existing system
> > ABI and should not get changed in a visible way to applications.
> 
> Stephen,
> 
> Thanks. What are your views on the current proposal we are making where
> ethN names are not changed (or renamed) and libnetdevname would suggest
> alias names for the ethN names ( and also alias to ethN names) in user
> space. Applications like ip, ethtool etc can use these aliases, make
> calls to libnetdevname and get the ethN name. 
> 
> Libnetdevname would read from sysfs the smbios names of the network
> interface devices as Jordan mentioned
> (/sys/class/net/ethX/device/smbiosname). Would this be acceptable ?

I have no need or use for them, but if it doesn't break other things
then sure.

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> > > On Fri, 18 Dec 2009 18:49:15 +0530
> > > <Narendra_K@Dell.com> wrote:
> > >
> > > > The installer solution involved renaming the network interface
> names
> > > > from ethN to something else based on the naming convention that
> the
> > > user
> > > > specified. For example, if the user chose "smbios names" as the
> the
> > > > naming convention then all ethN would be renamed to
> Embedded_NIC_N.
> > > > ifconfig would show Embedded_NIC_N instead of ethN.
> > >
> > > Renaming away from ethN causes some applications like net-snmp to
> get
> > > confused,
> > > and others have special sorting rules based on existing model
(like
> > > quagga).
> > >
> > > I would argue that the "ethN" convention is part of existing
system
> > > ABI and should not get changed in a visible way to applications.
> >
> > Stephen,
> >
> > Thanks. What are your views on the current proposal we are making
> where
> > ethN names are not changed (or renamed) and libnetdevname would
> suggest
> > alias names for the ethN names ( and also alias to ethN names) in
> user
> > space. Applications like ip, ethtool etc can use these aliases, make
> > calls to libnetdevname and get the ethN name.
> >
> > Libnetdevname would read from sysfs the smbios names of the network
> > interface devices as Jordan mentioned
> > (/sys/class/net/ethX/device/smbiosname). Would this be acceptable ?
> 
> I have no need or use for them, but if it doesn't break other things
> then sure.

Jeff / netfilter-devel,

It would greatly help to know your views on this proposal.

With regards,
Narendra K

Re:[PROPOSAL]: Alias names for network interfaces

[Narendra K]

> > > > > ifconfig would show Embedded_NIC_N instead of ethN.
> > > >
> > > > Renaming away from ethN causes some applications like net-snmp to
> > get
> > > > confused,
> > > > and others have special sorting rules based on existing model
> (like
> > > > quagga).
> > > >
> > > > I would argue that the "ethN" convention is part of existing
> system
> > > > ABI and should not get changed in a visible way to applications.
> > >
> > > Stephen,
> > >
> > > Thanks. What are your views on the current proposal we are making
> > where
> > > ethN names are not changed (or renamed) and libnetdevname would
> > suggest
> > > alias names for the ethN names ( and also alias to ethN names) in
> > user
> > > space. Applications like ip, ethtool etc can use these aliases, make
> > > calls to libnetdevname and get the ethN name.
> > >
> > > Libnetdevname would read from sysfs the smbios names of the network
> > > interface devices as Jordan mentioned
> > > (/sys/class/net/ethX/device/smbiosname). Would this be acceptable ?
> > 
> > I have no need or use for them, but if it doesn't break other things
> > then sure.
> 
> Jeff / netfilter-devel,
> 
> It would greatly help to know your views on this proposal.

The proposal is to enhance iptables (and other tools which might fail if
integrated port 1 does not get named as eth0) to support something like

iptables -A INPUT -i Embedded_NIC_1 -j ACCEPT 

in addition to what it already supports 

iptables -A INPUT -i eth0 -j ACCEPT.

Below is how the iptables code that handles the "-i ethN" would look
like (Only a part of the code to demonstrate the idea shown here) -

diff -Naru iptables-1.4.5/xtables.c iptables-1.4.5-new/xtables.c
--- iptables-1.4.5/xtables.c	2010-01-12 02:47:16.293249537 +0530
+++ iptables-1.4.5-new/xtables.c	2010-01-13 06:14:12.130185117 +0530
@@ -455,8 +455,8 @@
 void xtables_parse_interface(const char *arg, char *vianame,
 			     unsigned char *mask)
 {
-	int vialen = strlen(arg);
 	unsigned int i;
+	static char kernel_name[IFNAMSIZ];
 
 	memset(mask, 0, IFNAMSIZ);
 	memset(vianame, 0, IFNAMSIZ);
@@ -466,7 +466,11 @@
 			   "interface name `%s' must be shorter than IFNAMSIZ"
 			   " (%i)", arg, IFNAMSIZ-1);
 
-	strcpy(vianame, arg);
+	if (netdev_alias_to_kernel_name(arg, kernel_name) < 0)
+		show_alias_name_usage();
+	
+	strcpy(vianame, kernel_name);
+	int vialen = strlen(kernel_name);
 	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
 		memset(mask, 0, IFNAMSIZ);
 	else if (vianame[vialen - 1] == '+') {


where kernel_name is the ethN name that will be returned by a library
like libnetdevname which will map the user supplied "Embedded_NIC_1"
name to the corresponding ethN name, thus bringing in determinism while
referring to the network interfaces.

Netfilter-devel, would this be acceptable ?

With regards,
Narendra K

Re:[PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Tuesday 2010-01-12 20:49, Narendra K wrote:
>
>The proposal is to enhance iptables (and other tools which might fail if
>integrated port 1 does not get named as eth0) to support something like
>[...]
>Below is how the iptables code that handles the "-i ethN" would look
>like (Only a part of the code to demonstrate the idea shown here) -
>
>diff -Naru iptables-1.4.5/xtables.c iptables-1.4.5-new/xtables.c
>--- iptables-1.4.5/xtables.c	2010-01-12 02:47:16.293249537 +0530
>+++ iptables-1.4.5-new/xtables.c	2010-01-13 06:14:12.130185117 +0530
>@@ -455,8 +455,8 @@
> void xtables_parse_interface(const char *arg, char *vianame,
> 			     unsigned char *mask)
> {
>-	int vialen = strlen(arg);
> 	unsigned int i;
>+	static char kernel_name[IFNAMSIZ];
> 
> 	memset(mask, 0, IFNAMSIZ);
> 	memset(vianame, 0, IFNAMSIZ);
>@@ -466,7 +466,11 @@
> 			   "interface name `%s' must be shorter than IFNAMSIZ"
> 			   " (%i)", arg, IFNAMSIZ-1);
> 
>-	strcpy(vianame, arg);
>+	if (netdev_alias_to_kernel_name(arg, kernel_name) < 0)
>+		show_alias_name_usage();
>+	
>+	strcpy(vianame, kernel_name);
>+	int vialen = strlen(kernel_name);
> 	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
> 		memset(mask, 0, IFNAMSIZ);
> 	else if (vianame[vialen - 1] == '+') {

That code, even if snippet, needs more work.

(iptables is not too great on multithread safety, but do we have to
make it worse by adding static buffers? And unchecked strcpy, what
should BPF think of us?)

>where kernel_name is the ethN name that will be returned by a library
>like libnetdevname which will map the user supplied "Embedded_NIC_1"
>name to the corresponding ethN name, thus bringing in determinism while
>referring to the network interfaces.
>
>Netfilter-devel, would this be acceptable ?

I tried to look at libnetdevname. There is a gitweb, but no
git-clone. I think that they library should possibly use netlink
and libtool. And other remarks.

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> On Tuesday 2010-01-12 20:49, Narendra K wrote:
> >
> >The proposal is to enhance iptables (and other tools which might fail
> if
> >integrated port 1 does not get named as eth0) to support something
> like
> >[...]
> >Below is how the iptables code that handles the "-i ethN" would look
> >like (Only a part of the code to demonstrate the idea shown here) -
> >
> >diff -Naru iptables-1.4.5/xtables.c iptables-1.4.5-new/xtables.c
> >--- iptables-1.4.5/xtables.c	2010-01-12 02:47:16.293249537 +0530
> >+++ iptables-1.4.5-new/xtables.c	2010-01-13 06:14:12.130185117
+0530
> >@@ -455,8 +455,8 @@
> > void xtables_parse_interface(const char *arg, char *vianame,
> > 			     unsigned char *mask)
> > {
> >-	int vialen = strlen(arg);
> > 	unsigned int i;
> >+	static char kernel_name[IFNAMSIZ];
> >
> > 	memset(mask, 0, IFNAMSIZ);
> > 	memset(vianame, 0, IFNAMSIZ);
> >@@ -466,7 +466,11 @@
> > 			   "interface name `%s' must be shorter than
> IFNAMSIZ"
> > 			   " (%i)", arg, IFNAMSIZ-1);
> >
> >-	strcpy(vianame, arg);
> >+	if (netdev_alias_to_kernel_name(arg, kernel_name) < 0)
> >+		show_alias_name_usage();
> >+
> >+	strcpy(vianame, kernel_name);
> >+	int vialen = strlen(kernel_name);
> > 	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
> > 		memset(mask, 0, IFNAMSIZ);
> > 	else if (vianame[vialen - 1] == '+') {
> 
> That code, even if snippet, needs more work.
> 
> (iptables is not too great on multithread safety, but do we have to
> make it worse by adding static buffers? And unchecked strcpy, what
> should BPF think of us?)
> 

Thanks. Sure, I would address these concerns.

> >where kernel_name is the ethN name that will be returned by a library
> >like libnetdevname which will map the user supplied "Embedded_NIC_1"
> >name to the corresponding ethN name, thus bringing in determinism
> while
> >referring to the network interfaces.
> >
> >Netfilter-devel, would this be acceptable ?
> 
> I tried to look at libnetdevname. There is a gitweb, but no
> git-clone. I think that they library should possibly use netlink
> and libtool. And other remarks.

I would look into why git clone isn't working. Please find the latest
libnetdevname tar file here -
http://linux.dell.com/libnetdevname/permalink/
The implementation is for char device node solution we proposed earlier.
It would be extended to handle the current proposal if it is acceptable.

With regards,
Narendra K

Re: [PROPOSAL]: Alias names for network interfaces

[Bernd Eckenfels]

Hello,

On Wed, Jan 13, 2010 at 12:17:16PM +0530, Narendra_K@Dell.com wrote:
> The implementation is for char device node solution we proposed earlier.
> It would be extended to handle the current proposal if it is acceptable.

For the record: I still dont like the idea to add another namespace (besides
interface index number and kernel names (possibly renamed)) to network
devices (especially in usermode), however if nobody else objects I will keep
quiet and accept the patches.

One thing for the library: the smbname of the devices can be the default
alias, but please allow usermode to configure patterns (based on driver,
mac) or maps for using even better interface names. The quality of system
management informations, especially when mixing hardware, tends to be less
than optimal.

Gruss
Bernd
-- 
  (OO)     -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
 ( .. )    ecki@{inka.de,linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  eckes@IRCNet  v:+497211603874  f:+49721151516129
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PROPOSAL]: Alias names for network interfaces

[Patrick McHardy]

Narendra K wrote:
>>>>>> ifconfig would show Embedded_NIC_N instead of ethN.
>>>>> Renaming away from ethN causes some applications like net-snmp to
>>> get
>>>>> confused,
>>>>> and others have special sorting rules based on existing model
>> (like
>>>>> quagga).
>>>>>
>>>>> I would argue that the "ethN" convention is part of existing
>> system
>>>>> ABI and should not get changed in a visible way to applications.
>>>> Stephen,
>>>>
>>>> Thanks. What are your views on the current proposal we are making
>>> where
>>>> ethN names are not changed (or renamed) and libnetdevname would
>>> suggest
>>>> alias names for the ethN names ( and also alias to ethN names) in
>>> user
>>>> space. Applications like ip, ethtool etc can use these aliases, make
>>>> calls to libnetdevname and get the ethN name.
>>>>
>>>> Libnetdevname would read from sysfs the smbios names of the network
>>>> interface devices as Jordan mentioned
>>>> (/sys/class/net/ethX/device/smbiosname). Would this be acceptable ?
>>> I have no need or use for them, but if it doesn't break other things
>>> then sure.
>> Jeff / netfilter-devel,
>>
>> It would greatly help to know your views on this proposal.
> 
> The proposal is to enhance iptables (and other tools which might fail if
> integrated port 1 does not get named as eth0) to support something like
> 
> iptables -A INPUT -i Embedded_NIC_1 -j ACCEPT 
> 
> in addition to what it already supports 
> 
> iptables -A INPUT -i eth0 -j ACCEPT.
> 
> Below is how the iptables code that handles the "-i ethN" would look
> like (Only a part of the code to demonstrate the idea shown here) -
> 
> diff -Naru iptables-1.4.5/xtables.c iptables-1.4.5-new/xtables.c
> --- iptables-1.4.5/xtables.c	2010-01-12 02:47:16.293249537 +0530
> +++ iptables-1.4.5-new/xtables.c	2010-01-13 06:14:12.130185117 +0530
> @@ -455,8 +455,8 @@
>  void xtables_parse_interface(const char *arg, char *vianame,
>  			     unsigned char *mask)
>  {
> -	int vialen = strlen(arg);
>  	unsigned int i;
> +	static char kernel_name[IFNAMSIZ];
>  
>  	memset(mask, 0, IFNAMSIZ);
>  	memset(vianame, 0, IFNAMSIZ);
> @@ -466,7 +466,11 @@
>  			   "interface name `%s' must be shorter than IFNAMSIZ"
>  			   " (%i)", arg, IFNAMSIZ-1);
>  
> -	strcpy(vianame, arg);
> +	if (netdev_alias_to_kernel_name(arg, kernel_name) < 0)
> +		show_alias_name_usage();

Is this able to deal with non-existant devices?

> +	
> +	strcpy(vianame, kernel_name);
> +	int vialen = strlen(kernel_name);
>  	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
>  		memset(mask, 0, IFNAMSIZ);
>  	else if (vianame[vialen - 1] == '+') {
> 
> 
> where kernel_name is the ethN name that will be returned by a library
> like libnetdevname which will map the user supplied "Embedded_NIC_1"
> name to the corresponding ethN name, thus bringing in determinism while
> referring to the network interfaces.
> 
> Netfilter-devel, would this be acceptable ?

What I don't like very much is that you can't decide whether to
map the interface names back in order to display a rule the same
way it was specified. Anyone looking at the output will have to
know the alias mapping, which seems to defeat the purpose of
this patch.

Re: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Wednesday 2010-01-13 14:24, Patrick McHardy wrote:
>> 
>> The proposal is to enhance iptables (and other tools which might fail if
>> integrated port 1 does not get named as eth0) to support something like
>[...]
>> +	strcpy(vianame, kernel_name);
>> +	int vialen = strlen(kernel_name);
>>  	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
>>  		memset(mask, 0, IFNAMSIZ);
>>  	else if (vianame[vialen - 1] == '+') {
>> 
>> 
>> where kernel_name is the ethN name that will be returned by a library
>> like libnetdevname which will map the user supplied "Embedded_NIC_1"
>> name to the corresponding ethN name, thus bringing in determinism while
>> referring to the network interfaces.
>> 
>> Netfilter-devel, would this be acceptable ?
>
>What I don't like very much is that you can't decide whether to
>map the interface names back in order to display a rule the same
>way it was specified. Anyone looking at the output will have to
>know the alias mapping, which seems to defeat the purpose of
>this patch.

By definition, the mapping from aliases to real names is not
bijective, thus not always unambiguously reversible. That also means
there will be problems if either side of a mapping disappears - say,
across a reboot - you are in for some local DoS. That of course also
holds for regular network interface names, but only if you do not use
udev to give them a persistent name.

Re: [PROPOSAL]: Alias names for network interfaces

[Stephen Hemminger]

On Wed, 13 Jan 2010 14:43:26 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:

> 
> On Wednesday 2010-01-13 14:24, Patrick McHardy wrote:
> >> 
> >> The proposal is to enhance iptables (and other tools which might fail if
> >> integrated port 1 does not get named as eth0) to support something like
> >[...]
> >> +	strcpy(vianame, kernel_name);
> >> +	int vialen = strlen(kernel_name);
> >>  	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
> >>  		memset(mask, 0, IFNAMSIZ);
> >>  	else if (vianame[vialen - 1] == '+') {
> >> 
> >> 
> >> where kernel_name is the ethN name that will be returned by a library
> >> like libnetdevname which will map the user supplied "Embedded_NIC_1"
> >> name to the corresponding ethN name, thus bringing in determinism while
> >> referring to the network interfaces.
> >> 
> >> Netfilter-devel, would this be acceptable ?
> >
> >What I don't like very much is that you can't decide whether to
> >map the interface names back in order to display a rule the same
> >way it was specified. Anyone looking at the output will have to
> >know the alias mapping, which seems to defeat the purpose of
> >this patch.
> 
> By definition, the mapping from aliases to real names is not
> bijective, thus not always unambiguously reversible. That also means
> there will be problems if either side of a mapping disappears - say,
> across a reboot - you are in for some local DoS. That of course also
> holds for regular network interface names, but only if you do not use
> udev to give them a persistent name.

Is there a tool to do:
   netdevtoalias eth0
and
   netdevfromalias Embedded_NIC_1



-- 

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
> Sent: Wednesday, January 13, 2010 9:57 PM
> To: Jan Engelhardt
> Cc: Patrick McHardy; K, Narendra; be-mail2009@lina.inka.de; net-
> tools@lina.inka.de; netfilter-devel@vger.kernel.org;
> jgarzik@users.sourceforge.net; Rose, Charles; Domsch, Matt; Iyer,
> Shyam; Hargrave, Jordan; Shandilya, Sandeep K
> Subject: Re: [PROPOSAL]: Alias names for network interfaces
> 
> On Wed, 13 Jan 2010 14:43:26 +0100 (CET)
> Jan Engelhardt <jengelh@medozas.de> wrote:
> 
> >
> > On Wednesday 2010-01-13 14:24, Patrick McHardy wrote:
> > >>
> > >> The proposal is to enhance iptables (and other tools which might
> fail if
> > >> integrated port 1 does not get named as eth0) to support
something
> like
> > >[...]
> > >> +	strcpy(vianame, kernel_name);
> > >> +	int vialen = strlen(kernel_name);
> > >>  	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
> > >>  		memset(mask, 0, IFNAMSIZ);
> > >>  	else if (vianame[vialen - 1] == '+') {
> > >>
> > >>
> > >> where kernel_name is the ethN name that will be returned by a
> library
> > >> like libnetdevname which will map the user supplied
> "Embedded_NIC_1"
> > >> name to the corresponding ethN name, thus bringing in determinism
> while
> > >> referring to the network interfaces.
> > >>
> > >> Netfilter-devel, would this be acceptable ?
> > >
> > >What I don't like very much is that you can't decide whether to
> > >map the interface names back in order to display a rule the same
> > >way it was specified. Anyone looking at the output will have to
> > >know the alias mapping, which seems to defeat the purpose of
> > >this patch.
> >
> > By definition, the mapping from aliases to real names is not
> > bijective, thus not always unambiguously reversible. That also means
> > there will be problems if either side of a mapping disappears - say,
> > across a reboot - you are in for some local DoS. That of course also
> > holds for regular network interface names, but only if you do not
use
> > udev to give them a persistent name.
> 
> Is there a tool to do:
>    netdevtoalias eth0
> and
>    netdevfromalias Embedded_NIC_1

Stephen,

Yes, the tool is part of the solution. The proposal involves three parts
- (more details here
http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Proposal_2: )

1. Library

The library would provide the following functionality.

    * Alias to kernel name
    * Given a kernel name, provide a list of aliases
    * Tell us which alias is descriptive for a given kernel name, which
in this case will be Embedded_NIC_N

2.Command line tool which can be used in scripting

    * Given an alias, fetch the kernel name of the device
    * For a given kernel name, fetch the list of aliases
    * Tell us which alias is descriptive

3.Kernel

	* The smbios strings would need to be exported to the kernel, so
that tools and the library need not have root permissions to read the
smbios strings.

Patrick,

If I understand your point correctly, you are saying that if a rule is
specified in the command line as below

iptables -A INPUT -i Embedded_NIC_1 -j ACCEPT, then if the rule is saved
by iptables-save the rule would look like 

iptables -A INPUT -i ethN -j ACCEPT and there is no way to know what the
corresponding Embedded_NIC_1 name is. 

If this is correct, then I agree. I suppose that this concern can be
addressed in one of these ways, if I am not missing
something - 

a) The command line tool I mentioned above (point 2)would tell us the
ethN -> Embedded_NIC_N mapping
b) Or the iptables-save needs to be enhanced to save Embedded_NIC_N
format instead of ethN by making a call to
libnetdevname to get that mapping ( ethN -> Embedded_NIC_1).

With regards,
Narendra K

Re: [PROPOSAL]: Alias names for network interfaces

[John Haxby]

On 13/01/10 11:04, Bernd Eckenfels wrote:
> Hello,
>
> On Wed, Jan 13, 2010 at 12:17:16PM +0530, Narendra_K@Dell.com wrote:
>    
>> The implementation is for char device node solution we proposed earlier.
>> It would be extended to handle the current proposal if it is acceptable.
>>      
> For the record: I still dont like the idea to add another namespace (besides
> interface index number and kernel names (possibly renamed)) to network
> devices (especially in usermode), however if nobody else objects I will keep
> quiet and accept the patches.
>    

I am less than enthusiastic about the idea as well.  I've come across 
numerous userspace scripts and whatnot that have enough trouble with the 
default route not being through "eth0" let alone anything more 
complex.   Aliases are going to cause a lot of problems for a lot of 
people for little actual gain.

jch

Re: [PROPOSAL]: Alias names for network interfaces

[Domsch, Matt]

On Wed, Jan 13, 2010 at 11:22:32AM -0600, John Haxby wrote:
> On 13/01/10 11:04, Bernd Eckenfels wrote:
> > Hello,
> >
> > On Wed, Jan 13, 2010 at 12:17:16PM +0530, Narendra_K@Dell.com wrote:
> >    
> >> The implementation is for char device node solution we proposed earlier.
> >> It would be extended to handle the current proposal if it is acceptable.
> >>      
> > For the record: I still dont like the idea to add another namespace (besides
> > interface index number and kernel names (possibly renamed)) to network
> > devices (especially in usermode), however if nobody else objects I will keep
> > quiet and accept the patches.
> >    
> 
> I am less than enthusiastic about the idea as well.  I've come across 
> numerous userspace scripts and whatnot that have enough trouble with the 
> default route not being through "eth0" let alone anything more 
> complex.   Aliases are going to cause a lot of problems for a lot of 
> people for little actual gain.

The "actual gain" is to provide a deterministic method of naming
network devices, in a stateless manner (e.g. w/o hard-coding MAC
addresses).  We don't have deterministic naming today.  It only gets
worse as we add more NIC ports.

The kernel doesn't provide deterministic naming.

Renaming from ethN to ethM is racy; often we wind up with devices named
'eth0_rename'.

Stephen noted (echoed in Bernd's comment) that the ethN namespace is
effectively an ABI (and certainly the 15-character IFNAMESZ is).
Userspace tools today expect ethN names.

So:
a) we can't rely on ethN being meaningful from boot.
b) we can't rename ethN to ethM without racing
c) we can't rename ethN to anything else

what choice do we have left?  Aliases in some form or another, that
can be meaningful.

Changing the kernel to handle aliasing has been rejected.  So we're
trying to do it entirely in userspace.

We're trying to be the least intrusive to applications as we can be,
but we'll need a small change to a lot of apps (as noted earlier in
this thread as an example).  We're open to how best do to that.  If
this proposal isn't acceptable, please advise including methods that
would be acceptable.

Thanks,
Matt


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

Re: [PROPOSAL]: Alias names for network interfaces

[Stephen Hemminger]

On Wed, 13 Jan 2010 17:22:32 +0000
John Haxby <john.haxby@oracle.com> wrote:

> On 13/01/10 11:04, Bernd Eckenfels wrote:
> > Hello,
> >
> > On Wed, Jan 13, 2010 at 12:17:16PM +0530, Narendra_K@Dell.com wrote:
> >    
> >> The implementation is for char device node solution we proposed earlier.
> >> It would be extended to handle the current proposal if it is acceptable.
> >>      
> > For the record: I still dont like the idea to add another namespace (besides
> > interface index number and kernel names (possibly renamed)) to network
> > devices (especially in usermode), however if nobody else objects I will keep
> > quiet and accept the patches.
> >    
> 
> I am less than enthusiastic about the idea as well.  I've come across 
> numerous userspace scripts and whatnot that have enough trouble with the 
> default route not being through "eth0" let alone anything more 
> complex.   Aliases are going to cause a lot of problems for a lot of 
> people for little actual gain.

I am worried about the user space change version as well.
Especially since many of the network tools (snmp, quagga, ...) have
to be cross-platform and this is not likely to get a warm reception from
BSD and Solaris users.

Re: [PROPOSAL]: Alias names for network interfaces

[Bernd Eckenfels]

On Wed, Jan 13, 2010 at 11:46:10AM -0600, Domsch, Matt wrote:
> The "actual gain" is to provide a deterministic method of naming
> network devices, in a stateless manner (e.g. w/o hard-coding MAC
> addresses).  We don't have deterministic naming today.  It only gets
> worse as we add more NIC ports.

You can use ifrename or udev to rename an interface with kernel abi based on
your exported smb name (or other things like mac-based rules).

This can be done in the boot script and will be used to all tools.
Those tools requiring the ethX name are broken anyway and should be fixed.

Gruss
Bernd

Re: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Wednesday 2010-01-13 18:46, Domsch, Matt wrote:
>> 
>> I am less than enthusiastic about the idea as well.  I've come across 
>> numerous userspace scripts and whatnot that have enough trouble with the 
>> default route not being through "eth0" let alone anything more 
>> complex.   Aliases are going to cause a lot of problems for a lot of 
>> people for little actual gain.
>
>The "actual gain" is to provide a deterministic method of naming
>network devices, in a stateless manner (e.g. w/o hard-coding MAC
>addresses).  We don't have deterministic naming today.  It only gets
>worse as we add more NIC ports.
>
>The kernel doesn't provide deterministic naming.
>
>Renaming from ethN to ethM is racy; often we wind up with devices named
>'eth0_rename'.
>
>Stephen noted (echoed in Bernd's comment) that the ethN namespace is
>effectively an ABI (and certainly the 15-character IFNAMESZ is).
>Userspace tools today expect ethN names.

Let's get things straight at least. Userspace does not expect eth#.
You may get away with claiming feature-incompleteness if your program
has no idea of tun#, sit# gre# and such, but there is also wlan#,
tap#, and others that are a link/ether device. If a program relies on
eth#, it is broken and should either be fixed or left dead in its
corner.

>So:
>a) we can't rely on ethN being meaningful from boot.
>b) we can't rename ethN to ethM without racing

In practice you should be.

rename eth0 -> eth0_rename
do {
} while (rename eth0_rename eth1 == EEXIST);

Yes it is a race, but eth1 will move out of the way - given you have
udev scripts properly set up so as to rename any unknown interface
out of the way to make room for eth1. Interfaces which do have a
mapping will get renamed anyway.

Re: [PROPOSAL]: Alias names for network interfaces

[Patrick McHardy]

Narendra_K@Dell.com wrote:
> Patrick,
> 
> If I understand your point correctly, you are saying that if a rule is
> specified in the command line as below
> 
> iptables -A INPUT -i Embedded_NIC_1 -j ACCEPT, then if the rule is saved
> by iptables-save the rule would look like 
> 
> iptables -A INPUT -i ethN -j ACCEPT and there is no way to know what the
> corresponding Embedded_NIC_1 name is. 
> 
> If this is correct, then I agree. I suppose that this concern can be
> addressed in one of these ways, if I am not missing
> something - 
> 
> a) The command line tool I mentioned above (point 2)would tell us the
> ethN -> Embedded_NIC_N mapping
> b) Or the iptables-save needs to be enhanced to save Embedded_NIC_N
> format instead of ethN by making a call to
> libnetdevname to get that mapping ( ethN -> Embedded_NIC_1).

Yeah, that could be done (but optionally please). What you can't
do however is display these two rules

iptables ... -i eth0 ...
iptables ... -i Embedded_NIC_N ...

the same way they were entered since you either map back or you don't.
I guess we can live with that though ...

Re: [PROPOSAL]: Alias names for network interfaces

[Patrick McHardy]

Jan Engelhardt wrote:
> On Wednesday 2010-01-13 18:46, Domsch, Matt wrote:
>>> I am less than enthusiastic about the idea as well.  I've come across 
>>> numerous userspace scripts and whatnot that have enough trouble with the 
>>> default route not being through "eth0" let alone anything more 
>>> complex.   Aliases are going to cause a lot of problems for a lot of 
>>> people for little actual gain.
>> The "actual gain" is to provide a deterministic method of naming
>> network devices, in a stateless manner (e.g. w/o hard-coding MAC
>> addresses).  We don't have deterministic naming today.  It only gets
>> worse as we add more NIC ports.
>>
>> The kernel doesn't provide deterministic naming.
>>
>> Renaming from ethN to ethM is racy; often we wind up with devices named
>> 'eth0_rename'.
>>
>> Stephen noted (echoed in Bernd's comment) that the ethN namespace is
>> effectively an ABI (and certainly the 15-character IFNAMESZ is).
>> Userspace tools today expect ethN names.
> 
> Let's get things straight at least. Userspace does not expect eth#.
> You may get away with claiming feature-incompleteness if your program
> has no idea of tun#, sit# gre# and such, but there is also wlan#,
> tap#, and others that are a link/ether device. If a program relies on
> eth#, it is broken and should either be fixed or left dead in its
> corner.

I agree, this is simply broken. iptraf is one of these sad examples
which has been annoying me for years.

Re: [PROPOSAL]: Alias names for network interfaces

[Jan Engelhardt]

On Thursday 2010-01-14 09:44, Patrick McHardy wrote:
>> 
>> Let's get things straight at least. Userspace does not expect eth#.
>> You may get away with claiming feature-incompleteness if your program
>> has no idea of tun#, sit# gre# and such, but there is also wlan#,
>> tap#, and others that are a link/ether device. If a program relies on
>> eth#, it is broken and should either be fixed or left dead in its
>> corner.
>
>I agree, this is simply broken. iptraf is one of these sad examples
>which has been annoying me for years.
>
Well, iptraf is only half-broken. Run it with the -u option,
and you get your interfaces.

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> -----Original Message-----
> From: Jan Engelhardt [mailto:jengelh@medozas.de]
> Sent: Wednesday, January 13, 2010 11:52 PM
> To: Domsch, Matt
> Cc: John Haxby; net-tools@lina.inka.de; Bernd Eckenfels; K, Narendra;
> shemminger@linux-foundation.org; netfilter-devel@vger.kernel.org;
> jgarzik@users.sourceforge.net; Rose, Charles; Iyer, Shyam; Hargrave,
> Jordan; Shandilya, Sandeep K
> Subject: Re: [PROPOSAL]: Alias names for network interfaces
> 
> 
> On Wednesday 2010-01-13 18:46, Domsch, Matt wrote:
> >>
> >> I am less than enthusiastic about the idea as well.  I've come
> across
> >> numerous userspace scripts and whatnot that have enough trouble
with
> the
> >> default route not being through "eth0" let alone anything more
> >> complex.   Aliases are going to cause a lot of problems for a lot
of
> >> people for little actual gain.
> >
> >The "actual gain" is to provide a deterministic method of naming
> >network devices, in a stateless manner (e.g. w/o hard-coding MAC
> >addresses).  We don't have deterministic naming today.  It only gets
> >worse as we add more NIC ports.
> >
> >The kernel doesn't provide deterministic naming.
> >
> >Renaming from ethN to ethM is racy; often we wind up with devices
> named
> >'eth0_rename'.
> >
> >Stephen noted (echoed in Bernd's comment) that the ethN namespace is
> >effectively an ABI (and certainly the 15-character IFNAMESZ is).
> >Userspace tools today expect ethN names.
> 
> Let's get things straight at least. Userspace does not expect eth#.
> You may get away with claiming feature-incompleteness if your program
> has no idea of tun#, sit# gre# and such, but there is also wlan#,
> tap#, and others that are a link/ether device. If a program relies on
> eth#, it is broken and should either be fixed or left dead in its
> corner.
> 

I am aware of many data center scenarios where lot of systems(large
numbers) are already pre-wired where Integrated Port 1 is connected to 
public network and Integrated Port 2 is connected to private network.
With the existing OS image, Integrated Port 1 is eth0 and Integrated
Port 2 is eth1. So everything is working as expected. Now there is a
need to upgrade to a new OS image and with this image Integrated Port 1
gets named eth1
and Integrated Port 2 gets eth0. Scripts (for example firewall) are
written for a scenario of Integrated Port 1 (eth0) is public 
network and Integrated Port 2 (eth1) as private network. 

Also, in case of large scale image based deployment scenarios embedding
HWADDR in config files or udev rules is not an option. Though HWADDR
helps in 
ensuring persistency in naming, it doesn't help in achieving expected
naming. 

I might be missing something, but I think this is the real issue. So by
referring to interfaces by their BIOS given name Embedded_NIC_1 will
always refer to the right interface irrespective of whether it is eth0
or eth1. I think which of the tools need to be modified and which need
to be left out of this can be debated.

With regards,
Narendra K

Re: [PROPOSAL]: Alias names for network interfaces

[Marco Innocenti]

Narendra_K@Dell.com wrote:
> Also, in case of large scale image based deployment scenarios embedding
> HWADDR in config files or udev rules is not an option. Though HWADDR
> helps in 
> ensuring persistency in naming, it doesn't help in achieving expected
> naming.

HWADDR is not the only way to use udev to name a network interface. You 
can do something like:

SUBSYSTEM=="net", SUBSYSTEMS=="pci", KERNELS=="0000:04:00.0", NAME="eth0"
SUBSYSTEM=="net", SUBSYSTEMS=="pci", KERNELS=="0000:06:00.0", NAME="eth1"


> 
-- 
**********************************************************************
Marco Innocenti              Dipartimento Sistemi E Tecnologie
CINECA                       phone:+39 0516171553 / fax:+39 0516132198
Via Magnanelli 6/3           e-mail: innocenti@cineca.it
40033 Casalecchio di Reno    Bologna (Italia)
**********************************************************************

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> -----Original Message-----
> From: Marco Innocenti [mailto:m.innocenti@cineca.it]
> Sent: Monday, January 18, 2010 10:37 PM
> To: K, Narendra
> Cc: jengelh@medozas.de; Domsch, Matt; john.haxby@oracle.com; net-
> tools@lina.inka.de; be-mail2010@lina.inka.de; shemminger@linux-
> foundation.org; netfilter-devel@vger.kernel.org;
> jgarzik@users.sourceforge.net; Rose, Charles; Iyer, Shyam; Hargrave,
> Jordan; Shandilya, Sandeep K
> Subject: Re: [PROPOSAL]: Alias names for network interfaces
> 
> Narendra_K@Dell.com wrote:
> > Also, in case of large scale image based deployment scenarios
> embedding
> > HWADDR in config files or udev rules is not an option. Though HWADDR
> > helps in
> > ensuring persistency in naming, it doesn't help in achieving
expected
> > naming.
> 
> HWADDR is not the only way to use udev to name a network interface.
You
> can do something like:
> 
> SUBSYSTEM=="net", SUBSYSTEMS=="pci", KERNELS=="0000:04:00.0",
> NAME="eth0"
> SUBSYSTEM=="net", SUBSYSTEMS=="pci", KERNELS=="0000:06:00.0",
> NAME="eth1"

Sure, but this would again introduce state. And that might not help in a
heterogeneous environment.

With regards,
Narendra K

Re: [PROPOSAL]: Alias names for network interfaces

[Stephen Hemminger]

On Tue, 19 Jan 2010 23:02:19 +0530
<Narendra_K@Dell.com> wrote:

> Sure, but this would again introduce state. And that might not help in a
> heterogeneous environment.

Hetrogeneous with what? Other OS's; sorry I don't care what Windows, Solaris,
HP-UX or anything else uses as a rule. The point is to do the right thing.

-- 

Re: [PROPOSAL]: Alias names for network interfaces

[Bernd Eckenfels]

On Tue, Jan 19, 2010 at 02:31:39PM -0800, Stephen Hemminger wrote:
> > Sure, but this would again introduce state. And that might not help in a
> > heterogeneous environment.
> 
> Hetrogeneous with what? Other OS's; sorry I don't care what Windows, Solaris,
> HP-UX or anything else uses as a rule. The point is to do the right thing.

I dont see "state" introduced:

a) you export the smb name of the interface to userspace
b) you use a (usersace) init script to use existing kernel api to rename the
interface (to it's  smbname or anything else you want)

Gruss
Bernd

RE: [PROPOSAL]: Alias names for network interfaces

[Narendra_K]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
> Sent: Wednesday, January 20, 2010 4:02 AM
> To: K, Narendra
> Cc: m.innocenti@cineca.it; jengelh@medozas.de; Domsch, Matt;
> john.haxby@oracle.com; net-tools@lina.inka.de; be-
> mail2010@lina.inka.de; netfilter-devel@vger.kernel.org;
> jgarzik@users.sourceforge.net; Rose, Charles; Iyer, Shyam; Hargrave,
> Jordan; Shandilya, Sandeep K
> Subject: Re: [PROPOSAL]: Alias names for network interfaces
> 
> On Tue, 19 Jan 2010 23:02:19 +0530
> <Narendra_K@Dell.com> wrote:
> 
> > Sure, but this would again introduce state. And that might not help
> in a
> > heterogeneous environment.
> 
> Hetrogeneous with what? Other OS's; sorry I don't care what Windows,
> Solaris,
> HP-UX or anything else uses as a rule. The point is to do the right
> thing.

Sorry for not being clear. Heterogeneous with different hardware (like
Dell, HP etc, I was not referring to OSes, ) and a udev rule like 
SUBSYSTEM=="net", SUBSYSTEMS=="pci", KERNELS=="0000:04:00.0",
NAME="eth0"
will not help as 0000:04:00.0 (or any other bus,device,function) might
not be a network device 
in all the systems or it might not exist. A single OS image which has to
be installed on multiple systems would
have to be more generic than that.

With regards,
Narendra K