>> > also check to make sure their hardware addresses are not the same, > sometimes as an admin I see folks copy/paste network settings from one > card to another in the console via an editor or cp or mv command, and > the hardware address gets cat'd in by mistake. > > also just use the ifdown and ifup commands and tail -f > /var/log/messages as you do so. if that doesn't work you've already > seen the driver and other recommendations, -putting in a spare NIC for > a server is useful if the testing shows your onboard broadcomms are > being iffy. the dells I work on have two broadcomms and one intel > -any luck with the 10/100 intel nic on there? > > ifdown eth0 ifdown eth1 ifdown eth2 > ifup eth0 ifup eth1 > > you've also seen the mayhem with port#'s not matching actual hardware > #'s, so maybe skip to watching the reboot dmesg output by doing > > dmesg | less and scanning for the hardware > > also do: > > lspci > > that should show you those cards sitting on the board, if not, then > you have a firmware/bios/hardware driver issue. try updating to > another newer kernel see if that helps. get the dell tool johnny > hughes mentioned, or even go to broadcomm and see if there's a linux > driver -perhaps the broadcomm nic type your dell has only works with > wintel -my own vendors have slipped before when telling me a server is > linux ready -only to find out they didn't vet this info with their > hardware/assembly dept. > > if that turns out to be the case, you should catapult cows at them. > > -karlski > > Thanks for the reply Karlski. Steve had the issue nailed in his post with the NIC's being named wrong. That said there appears to be ongoing weirdness with RH and Broadcoms in general. Replacing seems to be the prudent measure.