Bug 669805

Summary: NIC ordering extremely non-logical
Product: [Fedora] Fedora Reporter: joshua
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: harald, jcm, jonathan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-19 17:44:49 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
INCORRECT untouched 70-persistent-net.rules file
incorrect sosreport from machine
unchanged /etc/udev/rules.d/70-persistent-net.rules none

Description joshua 2011-01-14 15:37:12 EST
Description of problem:

We have two built-in, on-board 1gig NICs, and 4 dual port 10gig NICs.

Yet somehow the onboard NICs are eth1 and eth4... surely this isn't correct.  Shouldn't they at least be logically ordered next to each other?  Notice the MAC ordering... even the dual ports aren't near each other.  This has to be a bug:

[root@mb02-004 ~]# ifconfig -a | grep eth
eth0      Link encap:Ethernet  HWaddr 00:1B:21:71:AE:88  
eth1      Link encap:Ethernet  HWaddr 00:25:90:08:A7:06  
eth2      Link encap:Ethernet  HWaddr 00:1B:21:71:AE:89  
eth3      Link encap:Ethernet  HWaddr 00:1B:21:71:B0:1C  
eth4      Link encap:Ethernet  HWaddr 00:25:90:08:A7:07  
eth5      Link encap:Ethernet  HWaddr 00:1B:21:71:B0:1D  
eth6      Link encap:Ethernet  HWaddr 00:1B:21:71:8C:A4  
eth7      Link encap:Ethernet  HWaddr 00:1B:21:71:8C:A5  
eth8      Link encap:Ethernet  HWaddr 00:1B:21:71:90:A4  
eth9      Link encap:Ethernet  HWaddr 00:1B:21:71:90:A5  

[root@mb02-004 ~]# ls -l /sys/class/net/eth*/device
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth0/device -> ../../../0000:02:00.0
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth1/device -> ../../../0000:01:00.0
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth2/device -> ../../../0000:02:00.1
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth3/device -> ../../../0000:03:00.0
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth4/device -> ../../../0000:01:00.1
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth5/device -> ../../../0000:03:00.1
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth6/device -> ../../../0000:85:00.0
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth7/device -> ../../../0000:85:00.1
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth8/device -> ../../../0000:86:00.0
lrwxrwxrwx 1 root root 0 Jan 13 12:29 /sys/class/net/eth9/device -> ../../../0000:86:00.1

Version-Release number of selected component (if applicable):

F14 x86_64, any kernel (but using

How reproducible:

Nothing special... just do an install or a kickstart on a machine with such hardware.
Comment 1 joshua 2011-01-14 15:38:33 EST
Created attachment 473583 [details]
INCORRECT untouched 70-persistent-net.rules file
Comment 2 joshua 2011-01-14 15:42:44 EST
Created attachment 473584 [details]
incorrect sosreport from machine
Comment 3 joshua 2011-01-14 15:44:41 EST
I've attached an unmodified copy of the 70-persistent-net.rules file.  It appears that the ordering of the NICs is messed up because of this file... however, I'm not sure what *creates* this file in the first place.  This may be an anaconda bug if it is created by the installer... I'm just not sure
Comment 4 joshua 2011-01-14 15:52:55 EST
Created attachment 473586 [details]
Comment 5 joshua 2011-01-14 15:54:19 EST
Created attachment 473587 [details]
unchanged /etc/udev/rules.d/70-persistent-net.rules

Comment 6 Jon Masters 2011-01-15 21:12:04 EST
PCI enumeration is default depth first, so that will play a part (given your topology) in seeing this gap. Another issue is that drivers are loaded in parallel in Fedora, which can also cause gaps in other cases, but usually would result in multiple devices of the same type still getting sequential numbering.

There's no bug here. There's never been a guarantee that devices would be numbered sequentially, or would not change randomly. An existing hack allows you to assign configuration by MAC so that you get some consistency. Much better, though, is a new feature called biosdevname in F-15 that will allow some systems to name Ethernet devices according to the manufacturer-supplied chassis names. This requires that you have recent hardware (especially Dell hardware), that supports Type 41 of the SMBIOS specification. If you do, you're in luck.

Comment 7 joshua 2011-01-19 17:44:49 EST
Alright, fair enough, thank you