On Thu, May 1, 2014 at 5:54 AM, Steve Clark sclark@netwolves.com wrote:
On 04/30/2014 02:41 PM, Les Mikesell wrote:
On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark sclark@netwolves.com wrote:
So, have you ever had to deal with a CentOS box and multiple NICs. Especially one where you've cloned it or moved a disk to a new chassis? Apparently there is just not a good way to identify interfaces.
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
So, now you've got 6 NICs connected to 6 different switches. Which name is which? This is a really fun exercise when the box is remote and you are trying to tell someone used to configuring windows systems how to get it to a point where you can ssh in.
I guess I am confused, you haven't ever worked with the hardware you are installing the cloned drive in? If that is true then I guess you have a problem.
"Working with it" doesn't matter. And network manager or not doesn't matter. Interfaces get named in a random order unless it is a Dell with the netbios naming scheme and probably then only for the motherboard NICs. Our servers generally have on-board Broadcomm and Intel cards and the names within a set may stay ordered, but the cards and motherboards will flip randomly if there are not already matching items with the correct MAC addresses in the udev rulss file (in 6.x, in 5.x having a matching MAC in the ifcfg-eth? file was enough to rename the device to match). This is just a response to your comment about windows names being difficult to know, (and a long-standing problem on its own) and doesn't relate much to the NetworkManager discussion. If you only have one (or maybe even a pair on the motherboard or a single card) you might always see the same ordering - if so consider yourself lucky because that is not the general case. We usually have to run through a drill like 'ip link ls' to get a list of interface names, then iterate through them with 'ifconfig up' and use ethtool to see which has link up, connecting one at a time. So, in my opinion, there are problems with the old system that need to be fixed, but they aren't the things that networkmanager does. A way to restore a backup to an identical machine and have the same NICs in the same positions get the old configurations would be nice. Or at least to know the names of the NICs in the same positions. (And if you go back to CentOS3 they did - detection was single threaded back then and would always probe in the same order).
On 05/01/2014 09:09 AM, Les Mikesell wrote:
On Thu, May 1, 2014 at 5:54 AM, Steve Clark sclark@netwolves.com wrote:
On 04/30/2014 02:41 PM, Les Mikesell wrote:
On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark sclark@netwolves.com wrote:
So, have you ever had to deal with a CentOS box and multiple NICs. Especially one where you've cloned it or moved a disk to a new chassis? Apparently there is just not a good way to identify interfaces.
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
So, now you've got 6 NICs connected to 6 different switches. Which name is which? This is a really fun exercise when the box is remote and you are trying to tell someone used to configuring windows systems how to get it to a point where you can ssh in.
I guess I am confused, you haven't ever worked with the hardware you are installing the cloned drive in? If that is true then I guess you have a problem.
"Working with it" doesn't matter. And network manager or not doesn't matter. Interfaces get named in a random order unless it is a Dell with the netbios naming scheme and probably then only for the motherboard NICs. Our servers generally have on-board Broadcomm and Intel cards and the names within a set may stay ordered, but the cards and motherboards will flip randomly if there are not already matching items with the correct MAC addresses in the udev rulss file (in 6.x, in 5.x having a matching MAC in the ifcfg-eth? file was enough to rename the device to match). This is just a response to your comment about windows names being difficult to know, (and a long-standing problem on its own) and doesn't relate much to the NetworkManager discussion. If you only have one (or maybe even a pair on the motherboard or a single card) you might always see the same ordering - if so consider yourself lucky because that is not the general case. We usually have to run through a drill like 'ip link ls' to get a list of interface names, then iterate through them with 'ifconfig up' and use ethtool to see which has link up, connecting one at a time. So, in my opinion, there are problems with the old system that need to be fixed, but they aren't the things that networkmanager does. A way to restore a backup to an identical machine and have the same NICs in the same positions get the old configurations would be nice. Or at least to know the names of the NICs in the same positions. (And if you go back to CentOS3 they did - detection was single threaded back then and would always probe in the same order).
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
On Thu, May 1, 2014 at 12:45 PM, Lamar Owen lowen@pari.edu wrote:
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
Yes, the names are nailed down after the first run creates the /etc/udev/rules.d/70-persistent-net.rules with the MAC addresses for that box. But the first detection is more or less random. If you pop that disk into a different chassis, if you don't remove that file you'll get all new names with higher numbers and if you do remove it you get the same names but random ordering again. And the ifcfg-eth? files that also have the MAC address entries will be ignored if the names and MACs don't match.
Les Mikesell wrote:
On Thu, May 1, 2014 at 12:45 PM, Lamar Owen lowen@pari.edu wrote:
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
Yes, the names are nailed down after the first run creates the /etc/udev/rules.d/70-persistent-net.rules with the MAC addresses for that box. But the first detection is more or less random. If you pop that disk into a different chassis, if you don't remove that file you'll get all new names with higher numbers and if you do remove it you get the same names but random ordering again. And the ifcfg-eth? files that also have the MAC address entries will be ignored if the names and MACs don't match.
What I do when I upgrade a box via rsync is either rm 70-persistant-net.rules, or look at the MAC addresses beforehand, and edit the rules so that they're correct for this box before the reboot.
mark
On Thu, May 1, 2014 at 1:42 PM, m.roth@5-cent.us wrote:
What I do when I upgrade a box via rsync is either rm 70-persistant-net.rules, or look at the MAC addresses beforehand, and edit the rules so that they're correct for this box before the reboot.
If it is a box we've used before, ocsinventory will have reported the last mac/ip pairing, but what normally happens is that new boxes are shipped to their install locations and racked up by people that know all about configuring windows but not so much about Centos.
On 05/01/2014 01:45 PM, Lamar Owen wrote:
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
Like I said in the part you snipped after we clone the drive I always do:
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
The above makes them be rediscovered on the reboot.
The lan ports are numbered on the back of the unit and I have never had them not come up in the correct order - In fact it would cause us untold grief it they did.
On 05/01/2014 01:45 PM, Lamar Owen wrote:
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
Like I said in the part you snipped after we clone the drive I always do:
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
The above makes them be rediscovered on the reboot.
The lan ports are numbered on the back of the unit and I have never had them not come up in the correct order - In fact it would cause us untold grief it they did.
I forgot to add this is over 750 systems.
On May 1, 2014, at 11:45 AM, Lamar Owen lowen@pari.edu wrote:
On 05/01/2014 10:56 AM, Steve Clark wrote:
I feel for you then. I guess we have been lucky in the 6 or 7 hardware platforms we have used that the nics ( minimum 3, usually 4 or more ) have always stayed the same names in the same order.
That's actually an illusion. If the detection pulls it up in a different order, then by MAC address it will get put in the old order, at least with EL6. Here's a 'grep' excerpt showing the fun: ++++++++++ Apr 21 14:39:25 www kernel: udev: renamed network interface eth0 to rename2 Apr 21 14:39:25 www kernel: udev: renamed network interface eth1 to rename3 Apr 21 14:39:25 www kernel: udev: renamed network interface eth2 to eth0 Apr 21 14:39:25 www kernel: udev: renamed network interface eth3 to eth1 Apr 21 14:39:25 www kernel: udev: renamed network interface rename3 to eth3 Apr 21 14:39:25 www kernel: udev: renamed network interface rename2 to eth2 ++++++++++
Been there, done that.
NM creates the opposite problem for places that have "lights out" data-centers without trusted (much) remote-hands support, however... when a vendor goes in and swaps a motherboard out of a flaky server... now it's looking for specific MAC addresses that don't exist anymore... and getting the average "on-site tech" from a vendor to give you MAC addresses prior to swapping the hardware that's 1000 miles away, is pretty hit-or-miss. IMHO.
Really isn't NM's fault, and swapping out Ethernet cards (back when they were actual cards... ha...) never has been safe remotely... but I like picking on NM. :-)
-- Nate Duehr denverpilot@me.com
-
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Nathan Duehr -
Steve Clark