> -----Original Message----- > From: Jan Engelhardt [mailto:jengelh@xxxxxxxxxx] > Sent: Wednesday, January 13, 2010 11:52 PM > To: Domsch, Matt > Cc: John Haxby; net-tools@xxxxxxxxxxxx; Bernd Eckenfels; K, Narendra; > shemminger@xxxxxxxxxxxxxxxxxxxx; netfilter-devel@xxxxxxxxxxxxxxx; > jgarzik@xxxxxxxxxxxxxxxxxxxxx; 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
