nic enumeration
in [Kernel]
|
Prev: Fix uninitialized variable warning in do_one_initcall
Next: net/ipv4/ip_output.c: Removal of unused variable in ip_fragment()
From: Michael Di Domenico on 7 Jul 2010 18:30 I have an issue where I have an onboard NIC with effectively three ports, no other NIC ports/chips are in the system Nic0: xx:xx:xx:00:00:02 Nic1: xx:xx:xx:00:00:01 IPMI: xx:xx:xx:00:00:03 When I boot RedHat Linux, Nic1 becomes Eth0 and Nic0 becomes Eth1. I understand there is a disconnect between BIOS and linux on which device should get which Eth, as well as, what ensues when you have PCI cards along side onboard ports. What I'm curious about is how/why Linux actually decides Nic1 should be Eth0? My theory is it starts on the lowest MAC address and works up, depending partly on driver load order. Given the above scenario, swapping the MAC addresses between Nic1 and Nic0 would clear this issue. Can anyone confirm or deny this? Or explain/point me to, how it actually works. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Kroth on 7 Jul 2010 18:50 Michael Di Domenico <mdidomenico4(a)gmail.com> 2010-07-07 18:25: > I have an issue where I have an onboard NIC with effectively three > ports, no other NIC ports/chips are in the system > > Nic0: xx:xx:xx:00:00:02 > Nic1: xx:xx:xx:00:00:01 > IPMI: xx:xx:xx:00:00:03 > > When I boot RedHat Linux, Nic1 becomes Eth0 and Nic0 becomes Eth1. > > I understand there is a disconnect between BIOS and linux on which > device should get which Eth, as well as, what ensues when you have PCI > cards along side onboard ports. > > What I'm curious about is how/why Linux actually decides Nic1 should be Eth0? > > My theory is it starts on the lowest MAC address and works up, > depending partly on driver load order. > > Given the above scenario, swapping the MAC addresses between Nic1 and > Nic0 would clear this issue. > > Can anyone confirm or deny this? Or explain/point me to, how it actually works. Look into udev. It should maintain some rules that dictate that mapping. If not you can potentially write/alter some to make it do what you want/expect. On my systems the place to look is generally here: /etc/udev/rules.d (user rules) /lib/udev/rules.d (system rules) There may be others. Cheers, Brian
From: Steve Fink on 7 Jul 2010 19:20 On Wed, Jul 7, 2010 at 3:25 PM, Michael Di Domenico <mdidomenico4(a)gmail.com> wrote: > What I'm curious about is how/why Linux actually decides Nic1 should be Eth0? > > My theory is it starts on the lowest MAC address and works up, > depending partly on driver load order. I may be spewing misinformation here, but my understanding of how this works is that the specific ordering is pretty much random. It's rather unlikely to be based on MAC address value, except accidentally; it's probably just whatever comes up first when it enumerates the interfaces, which could easily be timing-dependent. (From personal experience, two identical but physically separate NICs will come up in a different order on every boot. Your case may be more consistent.) The first time it does this, though, it records the MAC address into the appropriate ifcfg-* script. From then on, at boot time it checks the MAC address of each interface as it comes up. If it mismatches with what is recorded in the ifcfg-* script, then it skips that name and tries using the next. In other words, all you should have to do is set HWADDR appropriately in the the ifcfg-* scripts and it should do the right thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Domsch on 7 Jul 2010 21:30 On Wed, Jul 07, 2010 at 06:25:53PM -0400, Michael Di Domenico wrote: > I have an issue where I have an onboard NIC with effectively three > ports, no other NIC ports/chips are in the system > > Nic0: xx:xx:xx:00:00:02 > Nic1: xx:xx:xx:00:00:01 > IPMI: xx:xx:xx:00:00:03 > > When I boot RedHat Linux, Nic1 becomes Eth0 and Nic0 becomes Eth1. > > I understand there is a disconnect between BIOS and linux on which > device should get which Eth, as well as, what ensues when you have PCI > cards along side onboard ports. > > What I'm curious about is how/why Linux actually decides Nic1 should be Eth0? > > My theory is it starts on the lowest MAC address and works up, > depending partly on driver load order. > > Given the above scenario, swapping the MAC addresses between Nic1 and > Nic0 would clear this issue. > > Can anyone confirm or deny this? Or explain/point me to, how it actually works. http://lwn.net/Articles/356900/ And on a system where you can use udev rules, the 70-persistent-net.rules file can be used to make them constant, by using the MAC address to force the names to be what you want. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Loke, Chetan on 8 Jul 2010 16:50
> -----Original Message----- > From: linux-kernel-owner(a)vger.kernel.org [mailto:linux-kernel- > owner(a)vger.kernel.org] On Behalf Of Matt Domsch > Sent: July 07, 2010 9:21 PM > > http://lwn.net/Articles/356900/ > > And on a system where you can use udev rules, the > 70-persistent-net.rules file can be used to make them constant, by > using the MAC address to force the names to be what you want. > Ok, but can we achieve the renaming w/o a reboot? > -- > Matt Domsch Chetan Loke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |