FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 05-02-2011, 03:33 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/2/2011 10:14 AM, Lamar Owen wrote:
>
> Major networking gear does this; cisco, for instance, gives you things like FastEthernet4/47, or GigabitEthernet2/2, or TenGigabitEthernet1/0, or POS3/0, etc for networking interfaces. Having seen the PCI eth device flips before between update releases of EL4, to give one example, it's really nice to be able to really know what device you've plugged a particular cable into, and know it in an unequivocal, and unchanging way.

Yes, good comparison. Imagine if you had to guess which router
interface or managed switch port configuration/name is connected to
which wire. That's exactly the situation you have with a multi-nic
linux box - which may have an equally complex network setup. For things
that don't need the bandwidth of multiple interfaces I've found it
easier to use a single VLAN trunk connection and split the subnets out
with vlan interfaces.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 04:19 PM
Steve Clark
 
Default RHEL 6.1 beta

On 05/02/2011 11:07 AM, Les Mikesell wrote:

On 5/2/2011 9:58 AM, m.roth@5-cent.us wrote:







But, yes, a different way of looking at NICs is coming down the pipe.




It's about




time.


EGADS Why? After working with FreeBSD for ten years it so nice not to



have to worry



is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why



would you



want to go back to that?



The numbers chosen in the eth? scheme are more or less randomized even


on identical hardware, so it is pretty much impossible to prepare a disk
<snip>
Anybody know *why*? Is it based on the order of response of the NIC
firmware? Certainly, were I writing the code, I'd have based it on the bus
address.



I think the 2.4 kernel did it that way, and was single-threaded during
detection. At least I seldom had problems omitting the HWADDR= setting
from ifcfg-eth? files and moving disks to a different chassis. My
impression was that 2.6 tries to do device detection in parallel to
speed up booting and thus makes the order unpredictable. As I recall,
there was a bug in early RHEL/Centos 5.x versions where the HWADDR=
setting was ignored if it was wrong, fixed in an update that made the
interface not come up at all. That made for fun times after the
update/reboot on remote machines...



Trying to save a few seconds when rebooting
a server seems pointless to me. It is not as if this is something

that happens with a great deal of frequency.



My $.02



--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 04:25 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/2/2011 11:19 AM, Steve Clark wrote:
>
>>> Anybody know *why*? Is it based on the order of response of the NIC
>>> firmware? Certainly, were I writing the code, I'd have based it on the bus
>>> address.
>> I think the 2.4 kernel did it that way, and was single-threaded during
>> detection. At least I seldom had problems omitting the HWADDR= setting
>> from ifcfg-eth? files and moving disks to a different chassis. My
>> impression was that 2.6 tries to do device detection in parallel to
>> speed up booting and thus makes the order unpredictable. As I recall,
>> there was a bug in early RHEL/Centos 5.x versions where the HWADDR=
>> setting was ignored if it was wrong, fixed in an update that made the
>> interface not come up at all. That made for fun times after the
>> update/reboot on remote machines...
>>
> Trying to save a few seconds when rebooting a server seems pointless to
> me. It is not as if this is something
> that happens with a great deal of frequency.

The Linux kernel is also used in laptops/desktops and isn't great at
sleep/hibernate (or at least wasn't when this change was introduced), so
I can see the value in a fast boot but it would have been nice to have a
boot option to use the more predictable 2.4 approach when you need it.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-03-2011, 03:40 PM
Steve Clark
 
Default RHEL 6.1 beta

On 05/02/2011 10:47 AM, Les Mikesell wrote:

On 5/2/2011 8:57 AM, Steve Clark wrote:


On 05/02/2011 09:38 AM, Lamar Owen wrote:


On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:


biosdevname for nics...bye bye eth0!


Not by default, and according to the release notes only for certain Dell servers ATM.

But, yes, a different way of looking at NICs is coming down the pipe. It's about time.


EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,
etc in networking scripts. Why would you want to go back to that?



The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
to ship to a remote site and have it come up working unattended or clone
disk images for a large rollout. If this gives predictable names in
bios-detection order it will be very useful. Remote-site support is
expensive and typically not great at the quirks of Linux distributions
that you need to know to do IP assignments.



In my experience with Linux over the last 3 years using Centos and
RH I have never seen the ethn device

numbering change, and it always corresponds to the hardware vendor
marking on the units we use.



We create images and ghost them onto various hardware platforms. I
just make sure I remove the

net persistent rules and the ifcfg-ethn stuff and they are then
redetected in the correct order.





--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-03-2011, 04:07 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/3/2011 10:40 AM, Steve Clark wrote:
>
>> The numbers chosen in the eth? scheme are more or less randomized even
>> on identical hardware, so it is pretty much impossible to prepare a disk
>> to ship to a remote site and have it come up working unattended or clone
>> disk images for a large rollout. If this gives predictable names in
>> bios-detection order it will be very useful. Remote-site support is
>> expensive and typically not great at the quirks of Linux distributions
>> that you need to know to do IP assignments.
>>
> In my experience with Linux over the last 3 years using Centos and RH I
> have never seen the ethn device
> numbering change, and it always corresponds to the hardware vendor
> marking on the units we use.
>
> We create images and ghost them onto various hardware platforms. I just
> make sure I remove the
> net persistent rules and the ifcfg-ethn stuff and they are then
> redetected in the correct order.

I was able to do that with the 2.4 kernel, but it hasn't worked for me
across an assortment of hardware with Centos 5.x. Even if I try to
pre-set the HWADDR in the ifcfg-eth? files when I know them ahead of
time, there's a fair chance that moving the disk will trigger a kudzu
run that renames my prebuilt files and replaces them with a default dhcp
set. The numbers tend to flip in pairs, though, probably corresponding
to the grouping on the motherboard and cards, so if you only have 2 they
might stay fixed.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-04-2011, 03:43 PM
Blake Hudson
 
Default RHEL 6.1 beta

-------- Original Message* --------

Subject: Re: [CentOS] RHEL 6.1 beta

From: Steve Clark <sclark@netwolves.com>

To: CentOS mailing list <centos@centos.org>

Date: Tuesday, May 03, 2011 10:40:51 AM



On 05/02/2011 10:47 AM, Les Mikesell wrote:

On 5/2/2011 8:57 AM, Steve Clark wrote:


On 05/02/2011 09:38 AM, Lamar Owen wrote:


On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:


biosdevname for nics...bye bye eth0!


Not by default, and according to the release notes only for certain Dell servers ATM.

But, yes, a different way of looking at NICs is coming down the pipe. It's about time.


EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,
etc in networking scripts. Why would you want to go back to that?


The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
to ship to a remote site and have it come up working unattended or clone
disk images for a large rollout. If this gives predictable names in
bios-detection order it will be very useful. Remote-site support is
expensive and typically not great at the quirks of Linux distributions
that you need to know to do IP assignments.



In my experience with Linux over the last 3 years using Centos and
RH I have never seen the ethn device

numbering change, and it always corresponds to the hardware vendor
marking on the units we use.



We create images and ghost them onto various hardware platforms. I
just make sure I remove the

net persistent rules and the ifcfg-ethn stuff and they are then
redetected in the correct order.






Ditto, working with Dell hardware mostly, 2 or 4 NICs, never had an
issue with them flipping or rearranging or out of order with the
labels on CentOS5. We did have some problems with Fedora detecting
in the wrong order, though we did not experience a flip.

Images made with Clonezilla work fine, though the NICs come back up
as DHCP - unsure if this was clonezilla or kudzu. Either way it was
easy enough to configure an IP manually.



I can see ethX/Y, eth0/1, 0/2, etc where X is the bus and Y is the
port being acceptable, although most people probably won't
experience a benefit. The BSD method of fxp0, rl0, etc is a pain in
the rear. How exactly is the naming convention supposed to occur?





_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-04-2011, 04:08 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/4/2011 10:43 AM, Blake Hudson wrote:
>
>> We create images and ghost them onto various hardware platforms. I
>> just make sure I remove the
>> net persistent rules and the ifcfg-ethn stuff and they are then
>> redetected in the correct order.
>>
>
> Ditto, working with Dell hardware mostly, 2 or 4 NICs, never had an
> issue with them flipping or rearranging or out of order with the labels
> on CentOS5. We did have some problems with Fedora detecting in the wrong
> order, though we did not experience a flip.

Maybe if they all take the same driver they are probed in a fixed order.
Mine usually have a mix of at least broadcomm and intel. Also note
that once the NIC mac address is set as HWADDR= in the ifcfg-eth? file
the settings will stay fixed (with a weird scheme of renaming the device
after kernel detection...).

> Images made with Clonezilla work fine, though the NICs come back up as
> DHCP - unsure if this was clonezilla or kudzu.

Clonezilla just copies your source, so the same thing happens as would
happen if you moved the original disk to a different chassis - which is
also a likely scenario for me. Kudzu will rename your ifcfg-eth? files
with a .bak extension and create new ones that default to dhcp. If
kudzu doesn't run and you have the wrong HWADDR= setting in the file the
interface won't come up at all.

> Either way it was easy enough to configure an IP manually.

This gets a lot harder when you've shipped the disk elsewhere for
installation and the operators there only know windows.

> I can see ethX/Y, eth0/1, 0/2, etc where X is the bus and Y is the port
> being acceptable, although most people probably won't experience a
> benefit. The BSD method of fxp0, rl0, etc is a pain in the rear. How
> exactly is the naming convention supposed to occur?

I think the bsd's have a mapping between the driver needed and the
device name. I don't really care what the name is, as long as I know
the names that correspond to the physical jacks and they are consistent
across machines with the same bus/card layout.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-05-2011, 03:41 PM
Drew Weaver
 
Default RHEL 6.1 beta

-------- Original Message* --------
Subject: Re: [CentOS] RHEL 6.1 beta
From: Steve Clark <sclark@netwolves.com>
To: CentOS mailing list <centos@centos.org>
Date: Tuesday, May 03, 2011 10:40:51 AM


On 05/02/2011 10:47 AM, Les Mikesell wrote:
On 5/2/2011 8:57 AM, Steve Clark wrote:On 05/02/2011 09:38 AM, Lamar Owen wrote:On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:biosdevname for nics...bye bye eth0!Not by default, and according to the release notes only for certain Dell servers ATM.*But, yes, a different way of looking at NICs is coming down the pipe.* It's about time.EGADS Why? After working with FreeBSD for ten years it so nice not tohave to worry is this rl0, vr0, em0, fxp0, bge0, ed0,etc in networking scripts. Why would you want to go back to that?The numbers chosen in the eth? scheme are more or less randomized even on identical hardware, so it is pretty much impossible to prepare a disk to ship to a remote site and have it come up working unattended or clone disk images for a large rollout.* If this gives predictable names in bios-detection order it will be very useful.* Remote-site support is expensive and typically not great at the quirks of Linux distributions that you need to know to do IP assignments.*In my experience with Linux over the last 3 years using Centos and RH I have never seen the ethn device
numbering change, and it always corresponds to the hardware vendor marking on the units we use.

>>>
I'm doing platform validation on a SuperMicro X9SCL and on everything except for RHEL 6 the NIC I am connected to is seen as eth0, on RHEL only it is seen as eth1. These kinds of wacky inconsistencies drive people crazy =)
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-05-2011, 06:25 PM
Ljubomir Ljubojevic
 
Default RHEL 6.1 beta

Because they are the same model. Use several model of NIC's together and
see what happens.

I do not have personal experience with CentOS, but I have seen different
X86-PC MB's on embedded units/routers recognizing LAN and Wireless NIC's
differently ones from PCI1 to PCI5, others from PCI5 to PCI1, one MB
even without any order at all. I had now Monitor so I had to power the
unit, guess NIC to connect to, login and see what was recognized in what
order.

Ljubomir

Drew Weaver wrote:
> -------- Original Message --------
> Subject: Re: [CentOS] RHEL 6.1 beta
> From: Steve Clark <sclark@netwolves.com> <mailto:sclark@netwolves.com>
> To: CentOS mailing list <centos@centos.org> <mailto:centos@centos.org>
> Date: Tuesday, May 03, 2011 10:40:51 AM
>
> On 05/02/2011 10:47 AM, Les Mikesell wrote:
>
> On 5/2/2011 8:57 AM, Steve Clark wrote:
>
> On 05/02/2011 09:38 AM, Lamar Owen wrote:
>
> On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
>
> biosdevname for nics...bye bye eth0!
>
> Not by default, and according to the release notes only for certain Dell servers ATM.
>
>
>
> But, yes, a different way of looking at NICs is coming down the pipe. It's about time.
>
> EGADS Why? After working with FreeBSD for ten years it so nice not to
>
> have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,
>
> etc in networking scripts. Why would you want to go back to that?
>
> The numbers chosen in the eth? scheme are more or less randomized even
>
> on identical hardware, so it is pretty much impossible to prepare a disk
>
> to ship to a remote site and have it come up working unattended or clone
>
> disk images for a large rollout. If this gives predictable names in
>
> bios-detection order it will be very useful. Remote-site support is
>
> expensive and typically not great at the quirks of Linux distributions
>
> that you need to know to do IP assignments.
>
>
>
> In my experience with Linux over the last 3 years using Centos and RH I
> have never seen the ethn device
> numbering change, and it always corresponds to the hardware vendor
> marking on the units we use.
>
> >>>
>
> I'm doing platform validation on a SuperMicro X9SCL and on everything
> except for RHEL 6 the NIC I am connected to is seen as eth0, on RHEL
> only it is seen as eth1. These kinds of wacky inconsistencies drive
> people crazy =)
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-06-2011, 04:34 AM
R P Herrold
 
Default RHEL 6.1 beta

On Thu, 5 May 2011, Ljubomir Ljubojevic wrote:

> I do not have personal experience with CentOS, but I have seen different
> X86-PC MB's on embedded units/routers recognizing LAN and Wireless NIC's
> differently ones from PCI1 to PCI5, others from PCI5 to PCI1, one MB
> even without any order at all. I had now Monitor so I had to power the
> unit, guess NIC to connect to, login and see what was recognized in what
> order.

Built from the sources that will become a CentOS 6 series,
there is a more mature udev implementation, which tracks MAC
addresses, and assigns them 'durably' to persist at a given
device name. Debian testing supports a similar approach, but
with more manual intervention

I'll try to blog about it, but once one knows the 'secret' it
is not all that hard to predict -- This unit has three NICs
(two onboard of the same type and an addon) which do NOT
'wander around' through reboots

[root@hostname rules.d]# pwd
/etc/udev/rules.d
[root@hostname rules.d]# cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:90:27:a0:fe:bf", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth2"

# PCI device 0x14e4:0x1648 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:e0:81:31:23:8f", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1648 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:e0:81:31:23:8e", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"
[root@hostname rules.d]#

----------------------------------

[root@hostname network-scripts]# pwd
/etc/sysconfig/network-scripts
[root@hostname network-scripts]# cat ifcfg-eth0
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=198.49.bb.cc
DEVICE=eth0
BOOTPROTO=none
NETMASK=255.255.255.0
TYPE=Ethernet
HWADDR=00:e0:81:31:23:8e
IPADDR=198.49.bb.dd
[root@hostname network-scripts]#

[root@hostname network-scripts]# uname -a
Linux hostname_elided 2.6.32-71.24.1.el6.x86_64 #1 SMP Fri
Apr 8 21:14:02 CDT 2011 x86_64 x86_64 x86_64 GNU/Linux

-- Russ herrold
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 10:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org