Multiple Nic's Not Working

hi
My Dell m/c is running suse 9.2 pro (with latest updates) and has two
onboard intel gigabit nic's plus (for testing now) an additional 2 nic's on
a pci card (intel, similar to onboard - all using e1000 driver). All have
been statically configured. However only one of these is working and that
too intermittently. Ping using the other interfaces shows 100% loss or
(rarely) a single return ping even though ethtool shows that the link has
been detected. I've even manually configured all cards for 100Mbps(as my
n/w is 100 only), autonegotiation off.

what is weirder (at least to me) is that a packet capure on my sole working
nic using ethereal shows that at irregular intervals some TCP frames,
specifically parts of the ACK frame, are being lost or that duplicate
ACKframes from other packets are being recieved (hope this makes sense!).
Though connections (ssh, xdmcp) to this port do not get dropped.

I've shut down all the services i can think of that might remotely cause
such interference, maybe due to misconfiguration, incl NIS and NFS (and
firwall) but no change.

Is there anything in my configurations or the updates that could be causing
this esp as too why the other 3 nic's do not recieve any return ping ? I've
tried everything I can think of including messing with the routing
tables(something I'm not too familiar with). This problem was noticed
initially with only the onboard nic's i.e. one failed. The (tested) PCI
card was added to check if this was a h/w failure but now i'm almost about
to do a reinstallation which should hopefully solve any misconfiguration
that i may have done earlier.

I should add that this setup (with the onboard nic's) has been pretty
stable for over a year previously.

tia
Carlos

carlos_desa@yahoo.com adjusted his/her tinfoil beanie to post:

> hi
> My Dell m/c is running suse 9.2 pro (with latest updates) and has two

Do you happen to know which updates?

Was there a kernel upgrade in the updates?

> I should add that this setup (with the onboard nic's) has been pretty
> stable for over a year previously.

Have a look at your /var/lib/YaST2/you/youlog to see what was installed
and if the dates correlate to when the nics stopped working.

HTH

--
Mark
Twixt hill and high water
N. Wales, UK
Novell Support Forums SysOp

Furthur to my previous post-

Put all the nic's on a separate switch with a winPC running ethereal and
same problem was noticed. However some clarifications here - only a single
- ANY - nic works at a time i.e. if I disable one and enable another it
works OK (with some problems as mentioned previously).
Also if i enable all nic's (but still only one will work and can ping a m/c
or be pinged) "arp -a" on the winPC shows multiple IP's (all configured
interfaces) of the SuSE m/c but all mapped to the same MAC ID - the working
one !
From what i've found so far such packet loss could be due to kernel/driver
or problems. (Still to check the updates part Mark as writing this on a
weekend). However got a reply elsewhere that such problems may be due to a
bug in the routing table config ?
any suggestions?

tia
Carlos

> hi
> My Dell m/c is running suse 9.2 pro (with latest updates) and has two
> onboard intel gigabit nic's plus (for testing now) an additional 2 nic's on
> a pci card (intel, similar to onboard - all using e1000 driver). All have
> been statically configured. However only one of these is working and that
> too intermittently. Ping using the other interfaces shows 100% loss or
> (rarely) a single return ping even though ethtool shows that the link has
> been detected. I've even manually configured all cards for 100Mbps(as my
> n/w is 100 only), autonegotiation off.
>
> what is weirder (at least to me) is that a packet capure on my sole working
> nic using ethereal shows that at irregular intervals some TCP frames,
> specifically parts of the ACK frame, are being lost or that duplicate
> ACKframes from other packets are being recieved (hope this makes sense!).
> Though connections (ssh, xdmcp) to this port do not get dropped.
>
> I've shut down all the services i can think of that might remotely cause
> such interference, maybe due to misconfiguration, incl NIS and NFS (and
> firwall) but no change.
>
> Is there anything in my configurations or the updates that could be causing
> this esp as too why the other 3 nic's do not recieve any return ping ? I've
> tried everything I can think of including messing with the routing
> tables(something I'm not too familiar with). This problem was noticed
> initially with only the onboard nic's i.e. one failed. The (tested) PCI
> card was added to check if this was a h/w failure but now i'm almost about
> to do a reinstallation which should hopefully solve any misconfiguration
> that i may have done earlier.
>
> I should add that this setup (with the onboard nic's) has been pretty
> stable for over a year previously.
>
> tia
> Carlos

carlos_desa@yahoo.com wrote:
> Furthur to my previous post-
>
> Put all the nic's on a separate switch with a winPC running ethereal and
> same problem was noticed. However some clarifications here - only a single
> - ANY - nic works at a time i.e. if I disable one and enable another it
> works OK (with some problems as mentioned previously).
> Also if i enable all nic's (but still only one will work and can ping a m/c
> or be pinged) "arp -a" on the winPC shows multiple IP's (all configured
> interfaces) of the SuSE m/c but all mapped to the same MAC ID - the working
> one !
> From what i've found so far such packet loss could be due to kernel/driver
> or problems. (Still to check the updates part Mark as writing this on a
> weekend). However got a reply elsewhere that such problems may be due to a
> bug in the routing table config ?
> any suggestions?

Are you trying to configure multiple nics on the same subnet?

> Are you trying to configure multiple nics on the same subnet?

Yes. However (in anticipation) - all statically configured, and the 2
onboard nic's were working without a hitch for over a year previously

> Was there a kernel upgrade in the updates?

yes- plenty. as per the youlog ( closest to the time when i first started
facing problems) -
2005-09-05 17:01:25 (28573): Retrieving kernel: "The Linux Kernel" ...
2005-09-05 17:02:29 (28573): Ok
then on
2006-01-23 10:25:18 (6873): Retrieving kernel: "The Linux Kernel" ...
2006-01-23 10:26:11 (6873): Ok

The earlier ones applied were -
2005-03-18 13:02:45 (20685): Retrieving kernel: "The Linux Kernel" ...
2005-03-31 20:05:47 (1724): Retrieving kernel: "The Linux Kernel" ...
2005-04-08 12:04:29 (4988): Retrieving kernel: "The Linux Kernel" ...
2005-06-21 19:08:21 (17450): Retrieving kernel: "Der Linux Kernel" ...
2005-06-30 09:05:24 (18374): Retrieving kernel: "The Linux Kernel" ...
2005-08-13 12:16:21 (26499): Retrieving kernel: "The Linux Kernel" ...

If this is a problem with the kernel could i just reinstall the kernel from
the installation CD's ,assuming that they dont break any libs/apps? though
i suspect modules would be a problem.
Any suggestions in this regard would be great !
thanks
Carlos

carlos_desa@yahoo.com adjusted his/her tinfoil beanie to post:


> If this is a problem with the kernel could i just reinstall the kernel
> from the installation CD's ,assuming that they dont break any
> libs/apps? though i suspect modules would be a problem.
> Any suggestions in this regard would be great !
> thanks
> Carlos

Yes you can just re-install the default kernel from the install source,
just one thing though after the kernel has been installed and
SuSEconfig has run in Yast before you re-boot it is always best to run
as root:

depmod -a
mkinitrd


the -a does not need to be entered as it is default but it is good to
make sure when you are dealing with new kernels.

You should not theoretically need to do that but I always do as
sometimes the script can forget to incorporate the new modules and also
it makes sure that your initrd is updated as well. if you are using
grub then you do not need to do anything else, if you use lilo then you
will need to configure and save it again.

HTH


--
Mark
Twixt hill and high water
N. Wales, UK
Novell Support Forums SysOp

Hi
after some furthur investigations seems my problems are due to a routing
bug in the kernel (app its been noticed in 9.3 and 10.0 too).
However i did get the other nic'c working (atleast have been able to try
one) by doing the following -
- after starting the nic (ifup eth1) noticed in the routing tables that the
network IP was being specified for that particular nic but default gateway
was not. Hence added this manually " route add default gw 132.186.85.10 dev
eth1".
- also noticed that link-local IP's ( 169.254.0.0 - 255.255.0.0) were not
added for eth1 tough these were specified for existing( workking) nic eth0
... So added this too "route add -net link-local netmask 255.255.0.0 dev eth1".
- thereafter ping from this nic is going thru a bit better , say every 3rd
ping , rather than just none or only one. And more importantly this does
not affect the other working nic.
- however where i check the MAC ID on my windows m/c "arp -a" shows that
both IPs are mapped to the same MAC - the first working one eth0. This
even though ifconfig shows the IP's mapped to the correct mac id's. Same
too shows up on another linux m/c. Though i must add that ssh connections
to the second nic's IP do not get dropped.

Any suggestions?
a very confused Carlos