Some interesting developments coming:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html
On Saturday, April 30, 2011 04:10 AM, Kenneth Porter wrote:
Some interesting developments coming:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html
biosdevname for nics...bye bye eth0!
FUSE!
control groups!
a linux 2.2 feature!
ipchains anyone?
On Monday, May 02, 2011 06:48 PM, Christopher Chan wrote:
On Saturday, April 30, 2011 04:10 AM, Kenneth Porter wrote:
Some interesting developments coming:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html
biosdevname for nics...bye bye eth0!
FUSE!
control groups!
a linux 2.2 feature!
ipchains anyone?
We're getting finger print authentication on our screen savers. Soon, we are going to have to show our ugly faces instead grubby silicon fingers.
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?
On Monday, May 02, 2011 09:57:19 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?
I couldn't agree more... One of the things in Solaris that was always a pain. Just write a monitoring script that enumerates all devices... On linux you simply write a loop, start with eth0 and go up. On Solaris, you parse path_to_inst, then go from there iterating over the devices and instances... Not real hard to do but makes a script go from 80 lines on Linux to about 250 lines on Solaris. Oh and then of course there is the lovely implementation in Oracle RAC (and many other clustered pieces of software) that wants the same interface name on all hosts. Good luck finding two identical systems for the demo tomorrow afternoon :)
Essentially, having names per driver sounds good - until you actually lived it. Then you realize you gain virtually nothing (how often have you really looked at the cabeling of a server after its initial install) and made it significanly more complex to script and maintain.
Peter.
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.
-- Les Mikesell lesmikesell@gmail.com
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.
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.
-------- 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?
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.
-------- Original Message -------- Subject: Re: [CentOS] RHEL 6.1 beta From: Steve Clark sclark@netwolves.commailto:sclark@netwolves.com To: CentOS mailing list centos@centos.orgmailto: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 =)
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
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
On 5/5/11 11:34 PM, R P Herrold wrote:
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
But can you swap the disk into a new chassis of identical hardware and have it come up with the right subnets on the NICs in the corresponding physical positions? Without knowing MAC addresses ahead of time?
On Fri, 6 May 2011, Les Mikesell wrote: herrold:
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
But can you swap the disk into a new chassis of identical hardware and have it come up with the right subnets on the NICs in the corresponding physical positions? Without knowing MAC addresses ahead of time?
Not without prior knowledge of the MAC addresses and edits, but it is still trivial to do. With DHCP fabric on a physical segment, however, the devices will come up and be assigned IPs, the MAC addresses discerned [hooray for 'arpwatch' to make this trivial], and then may be revised into permanent working assignments without the need to resort to ILO or such
Indeed the reason the udev rules segment quoted is in the the rather peculiar order: eth2, eth1, eth0 ... is that I had done just that kind of drive move, and prior to just such edits of that file, it enumerated MAC address and associated them to devices in order: eth0 eth1 eth2 eth3 eth4
I editted the file for the last two [not bothering to move specification stanzas, as udev is indifferent to ordering], and renamed the corresponding /etc/sysconfig/networking-scripts/ifcfg-eth3 and ifcfg-eth4 into eth1 and eth0 respectively. Then within those two files, I edited the DEVICE names to complete the move a disk from the host it was built on, to the host it is now running on
The process is stable and predictable enogh that these edits were done via just such a process, after a 'remote pair of hands' had physiclly installed the drive into a chassis at a datacenter that I cannot presently travel into and work at comfortable, due to an ankle injury some months ago. The 'cold' aisles are too narrow for a stool or chair, and trying to work standing one-legged like a stork is too tiring
-- Russ herrold
On 5/6/2011 7:53 AM, R P Herrold wrote:
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
But can you swap the disk into a new chassis of identical hardware and have it come up with the right subnets on the NICs in the corresponding physical positions? Without knowing MAC addresses ahead of time?
Not without prior knowledge of the MAC addresses and edits, but it is still trivial to do. With DHCP fabric on a physical segment, however, the devices will come up and be assigned IPs, the MAC addresses discerned [hooray for 'arpwatch' to make this trivial], and then may be revised into permanent working assignments without the need to resort to ILO or such
Supplying DHCP service with spare addresses on a bunch of remote subnets at a bunch of remote locations isn't really trivial just to be able to have a centos box work there.
The process is stable and predictable enogh that these edits were done via just such a process, after a 'remote pair of hands' had physiclly installed the drive into a chassis at a datacenter that I cannot presently travel into and work at comfortable, due to an ankle injury some months ago. The 'cold' aisles are too narrow for a stool or chair, and trying to work standing one-legged like a stork is too tiring
There are lots of reasons to want to be able to ship pre-loaded disks separately from the chassis or have remote support swap either one. You don't have to cast it as a rare circumstance. Consider the 'green' value of shipping drives instead of whole machines (which is what we usually end up doing for anything complicated). I just hope whatever they are doing in 6.1 for non-random naming works on our hardware. On a more practical note, I suppose I should have written something long ago that runs automatically after network startup that parses the ifcfg-ethx files, tries to ping the gateways through each interface and juggles things around until it works at least on the subnet we use for administration. I had something like that mostly working when I did a 'clonezilla image on dvd' rollout to upgrade a bunch of machines from a centos3 to 5 base, but in that case I had the previous mac/IP's to work with and was trying to match the old setup after the image came up on each one. But, it failed on a few and I didn't bother to track the bugs down because it would have been hard to reproduce the circumstances.
On Monday, May 02, 2011 09:57:19 AM Steve Clark wrote:
On 05/02/2011 09:38 AM, Lamar Owen 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?
I knew I'd get a reaction..... :-) And it's good to see Peter A around again.....
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.
I might, for instance, put the server's primary 'serving' port(s) on server-grade gig or tengig ethernet adapters, but do out-of-band ethernet management on the motherboard's built-in Realtek 8139. Ok, I have eth0, eth1, eth2, and eth3. I have a dual-port Intel e1000 on a 64-bit PCI-X slot (and the card is PCI-X 133 capable, and I have two motherboard ethernet ports.
Care to guess which eth's go to which ports with a recent kernel (F14's kernel)? You might cringe: eth0 is the first e1000 port; eth1 and eth2 are the first and second motherboard ports (and the linux enumeration order is opposite of the labeling on the botherboard!); eth3 is the second e1000 port. This is better than previous; I've used the same hardware for quite a while now for one of my development servers, and between CentOS 5, and Fedoras 11, 12, 13, and 14, I've not had consistent ethernet enumeration.
Likewise, I'm working on a packetfence box (based on C5); the capture devices are server grade gig-e devices, and the managment port is a run-of-the-mill RTL8139. I really want to be able, without having eyes on the box, to know for a fact what device I'm working with. I know about grepping dmesg, but even then it's not nearly as easy as with a cisco box (like our two 7609's or our 12008) where I just: configure terminal interface gigabitethernet1/2 ......
and I *know* exactly, with no magic, what port I'm working with.
I also know that my requirements aren't typical 'home' users' requirements; but this *is* the CentOS list, not the Fedora list, right?
I know the convenience of kickstarting to possibly heterogeneous hardware; but device aliases are available and reasonable setup of those aliases can eliminate most of the problems.
Now, I'm not sure I particularly care for the current biosdevname setup; but I also know that upstream is going to be rather careful about this particular change, especially given the flak that has happened in the past with devnames flipping between kernel releases.
But then I can pull out all the stops on my most beastly networking config on a Linux box: our Sun E6500 (for which I hope to do a from-source C6 rebuild): every I/O card in the box has an ethernet port; I have eight I/O cards in this box, two of which are SunGEM gigabit cards. I'd love to be able to get the devname in a slot-subslot format, like cisco..... but that's not currently the way it is. And it gets worse if I pull an I/O card, particularly given the E6500's slot numbered 'fun.'
When you get to the level of a box having half a dozen or more ethernet devices of various capabilities and speeds, you begin to really despise the single namespace that currently exists, especially when the devnames change between kernel releases.
HWADDR in the configs has helped fix some of that, but that's worse than the biosdevname setup when it comes to imaging/cloing between multiple boxes....
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.
-
Blake Hudson -
Christopher Chan -
Drew Weaver -
Kenneth Porter -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Peter A -
R P Herrold -
Steve Clark