udev biosdevname 70-persistent-net.rules
A network security analysis and monitoring toolkit Linux distribution.
Brought to you by:
pblankenbaker,
rwhalb
Need I say more? What a cluster.
Have you guys modified the settings for this somewhere?
The reason I ask is I have scoured the net looking for an aswer to the mess. The mess being I can't control
my nics. I cant stand this, I have 4 nics or three to start with but when I add a fourth there is no telling where it might assign itself, could be eth0 could be eth2 etc. AAARRGGG. I got this worked out in f15 by modifying the /etc/udev/rules.d/70-persistent-net.rules file but now it seems that file is not being created anymore. Google seems to be totally clueless to to how to fix this, everyone has got some different trick they use to fix this and it seems to me that each one of them has managed to pull off a trick that works for their given situation but not mine. Also each trick only works for f14, f15, f16 or f17 and it seems to be a moving target in fedora right now. It seems to me that you guys may have fixed the biosdevname portion of this as far as nic renaming is concerned. I'm making that assumption here as ifconfig reports eth? for nics even though NetworkManager seems ready to name them something else. I guess what it boils down to is what is controlling the nic assignment now. In NST the naming convention seems fine but I can't control what nic becomes which virtual device (eth?).
Since f15 fedora introduced a new NIC naming convention. We have noticed on VMware that it does now apply. I typically disable NetworkManager on a system than has more than one NIC.
--RWH
Yes I disable it to. I first go in to NetworkManager and name and configure the nics in NM using eth?, I do this there so it writes out the ifcfg-eth? files. After naming I disable NM and enable network and reboot. In f15 I could go to /etc/udev/rules.d/70-persistent-net.rules and match the MAC to the eth? but now /etc/udev/rules.d/70-persistent-net.rules no longer exists so I can't setup the nics in proper order. Thing that seems ood is there was no problem till the fourth nic, could be luck or magic. Magic seems to be the current state of this issue because nobody seems to understand whats going on with it.
If you Google this issue most of what you find out there is folks trying to figure out how to rename their nics back to eth? .
thats not the situation here, here its more about assignment. Now I could shuffle the nics in vmware and achieve what I need but thats not a fix. The whole big change with systemd and NetworkManager has been a pain that I have tried to avoid but its now become something that needs to "get handled".
Did you try setting the HWADDR var for each interface definition "/etc/sysconfig/network-scripts/ifcfg-eth?"
From: http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-networkscripts-interfaces.html
HWADDR=<MAC-address>, where <MAC-address> is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive is useful for machines with multiple NICs to ensure that the interfaces are assigned the correct device names regardless of the configured load order for each NIC's module. This directive should not be used in conjunction with MACADDR.
--RWH
Wish it was that easy and it should and use to be done that way but I'm not sure what they are doing now. To be clear whats happening is I usually setup with three nics, the first one is assigned to LAN the second DMZ and the third is NET. If I install with this setup luckily it all seems to line up right. eth0=LAN eth1=DMZ and NET=eth2. The problem comes when the fourth nic is added it becomes eth0 and everything slides down a position. I said earlier that I could control this in f15 with /etc/udev/rules.d/70-persistent-net.rules but that was incorrect it must have been RH 5 or 6 that I could do that in maybe even Debian. If I disable NM and use network and modify the ifcfg-eth files and put in DEVICE= and the HWADDR= it just fails and says it was expecting a different hardware address when I start network. I've tried creating my own /etc/udev/rules.d/70-persistent-net.rules but that has no effect. I have tried this on a vmware 3.5 and 4.1 hosts and same issue.
fwiw, ymm
On a NST 15 install from DVD to hard disk on real hardware:
Not sure exactly why, but we had success using the newer interface names instead of ethx
We were / are able to reliably reboot and get the same nic matched to the same interface by using:
ifcfg-em1
ifcfg-em2
ifcfg-p2p1
ifcfg-p2p2
with each interface having entries for
DEVICE=
HW=
NM_CONTROLLED=no
We use ONBOOT=no for the sniffer interfaces and then use ifup in rc.local
we had no success using any /etc/dev configurations or "in theory" turning off NM.
and i think we ran across some strangeness that
NM_CONTROLLED=no is not the same as
NM_CONTROLLED=NO
But it's been quite a while since we solved this pickle.
I'm not sure it is a "solution" but it works as a band-aid.
V