Re:[PROPOSAL]: Alias names for network interfaces

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

[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

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

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

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

[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

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