CentOS - Mar 2013 - network connectivity lost after reboot/upgrade

I upgraded one of my old machines running 5.x to the latest kernel (from 
308.24.1 to 348.1.1).
After rebooting network connectivity was gone. I rebooted with the old 
kernel, I also tried the one before it (308.20.1) still no luck. So I 
assume it's got nothing to do with the kernel or even CentOS. But a 
hardware failure seems also unlikely, see below.

ethtool shows the link as up and if I remove the cable as down.
I attached a laptop via crossover cable, it detects the link, but same 
problem.
I disabled iptables and set selinux to disabled. No change.
There's a Xen VM running on that machine and I can ping it from the 
hardware. So, internal networking seems to be ok. I'm using bridged 
networking for Xen connectivity, setup by normal Red Hat means, not via 
Xen. Never had a problem.
There are no errors in the logs, except for dhcpd telling network is down 
and named is also giving some weird errors. This is my only dhcpd, so I 
would like to have it up ASAP :-(

Is there anything else besides a weird hardware failure that I could 
check? I'm going to get a new card tomorrow and see if that changes the 
situation. This is mobo internal networking based on nforce-MCP61.

Has anyone seen such a hardware failure where the link goes up but no 
packets go over the wire? It seems a bit unlikely that this hardware 
failure (and nothing else) should happen on a reboot after an upgrade.

Thanks.



Kai

On Mon, Mar 4, 2013 at 1:15 PM, Kai Schaetzl <maillists at conactive.com>
wrote:
> I upgraded one of my old machines running 5.x to the latest kernel (from
> 308.24.1 to 348.1.1).
> After rebooting network connectivity was gone. I rebooted with the old
> kernel, I also tried the one before it (308.20.1) still no luck. So I
> assume it's got nothing to do with the kernel or even CentOS. But a
> hardware failure seems also unlikely, see below.
>
> ethtool shows the link as up and if I remove the cable as down.
> I attached a laptop via crossover cable, it detects the link, but same
> problem.
> I disabled iptables and set selinux to disabled. No change.
> There's a Xen VM running on that machine and I can ping it from the
> hardware. So, internal networking seems to be ok. I'm using bridged
> networking for Xen connectivity, setup by normal Red Hat means, not via
> Xen. Never had a problem.
> There are no errors in the logs, except for dhcpd telling network is down
> and named is also giving some weird errors. This is my only dhcpd, so I
> would like to have it up ASAP :-(
>
> Is there anything else besides a weird hardware failure that I could
> check? I'm going to get a new card tomorrow and see if that changes the
> situation. This is mobo internal networking based on nforce-MCP61.
>
> Has anyone seen such a hardware failure where the link goes up but no
> packets go over the wire? It seems a bit unlikely that this hardware
> failure (and nothing else) should happen on a reboot after an upgrade.
>

I've seen similarly weird things when running VMs on some smart
switches where (and I'm not a networking guy here, so my terminology
will get fuzzy) something was set to disable ports(port fast, maybe?)
if multiple MACs were seen on the port (on machine other than my
desktop, I can normally get that fixed by having a trunkport and
default VLAN assigned to my port(s)).    not sure if that could be
applied to your situation.




-- 
Even the Magic 8 ball has an opinion on email clients: Outlook not so good.

thanks for the tip, but, unfortunately, this cannot be the case here.
Networking of the host is also affected, even when Xen is shut off.
I have no smart switches in this office and I ruled out switches by using 
a direct connection to the laptop.

Kai

Kai Schaetzl wrote on Mon, 04 Mar 2013 19:15:46 +0100:
> Has anyone seen such a hardware failure where the link goes up but no 
> packets go over the wire? It seems a bit unlikely that this hardware 
> failure (and nothing else) should happen on a reboot after an upgrade.
It was indeed a weird hardware failure. All works fine with disabled 
inboard LAN and a cheap PCI network card.

Kai