Possible network problem?

[Katty Torla Puga]

Hello,

I have a Proliant ML370 G4 with RedHat ES 4
The network cards are:
PCI Embedded HP NC7781 Gigabit Server Adapter
PCI Slot 4 HP NC7771 Gigabit Server Adapter

All seems to work ok, but sometimes the two interfaces does'nt respond neither to a ping from a pc. I lost the connection with the server, but normally after few seconds I retrieve the connection.

I've tried to use the new driver bcm5700 from http://h18000.www1.hp.com/support/files/server/us/download/23666.html but the behaviour is the same.

I add the /proc/net/nicinfo/eth*.info

Any idea?

Another question, are normal the values of PCI amb Part_Number for the embedded nic? Is normal that the eth1 corresponds to the pci embedded nic?

Thank you for all,

[Sivakumar TS]

Dear Katty,

Are you sure that the NIC has got the problem ?

Sometimes a faulty network cable /switch also could cause this probelm.

Try some swaping between a know working SET OF CABLE & PORT to this and observe, we will be able to conclude.

With Regards,

Siva.

[Bill Thorsteinson]

Check the output of dmesg to see if the
kernel is noticing the network dropout.

The dropouts should also be logged in
/var/log/syslog or /var/log/messages.

[Bill Thorsteinson]

Also check the output of /sbin/ifconfig
for errors and events for the interfaces.
The number and type of errors and events
may give you a hint as to what is happening.

[Katty Torla Puga]

We have another servers in the same modul Gigabit of the Cisco 4507R. The other servers work ok. If I connect the Proliant in the port of another server or with another cable, the behaviour is the same ... so it seem's that it's not a problem of the network equipment.

I append a file with the outputs ...

Thank you

[Alan_152]

check the cabling, and make sure that the speed/duplexing is the same on both sides of the connection (sometimes, autonegotiate doesn't work right, so you'll have to set them manually).

[rick jones]

"Never" harcode a gigabit NIC - unless, and _perhaps_ if you are hardcoding it to 100 Megabit operation. Gigabit operation basically requires autonegotiation.

The suggestions to try other cables are good.

Also, you might consider installing and trying linkloop - it is a sourceforge project which is a port of the HP-UX linkloop command. This is a "link-level" "ping" command that you can use. If ping does not work, but linkloop does, it suggests some issues with IP addresses.

[Katty Torla Puga]

I've dowload linkloop from http://freshmeat.net/projects/linkloop/

When I try linkloop against a server RedHat9 in the same subnesk ... the results are:

linkloop -i eth0 -d 00:30:37:00:06:0E
interface=eth0 timeout=2 num=1 size=1500
Link connectivity to LAN station: 00:30:37:00:06:0E (HW addr 00:30:37:00:06:0E)
Getting MAC address of interface 'eth0'
Testing via eth0 (HW addr 00:12:79:D4:20:F8)
sent TEST packet to 00:30:37:00:06:0E
** TIMEOUT (2 seconds)
Retry 0...
-- NO RESPONSE --

A ping to this server works ok.


Another thing:

By default, the system assigns eth0 to the external network card and eth1 to the internal network cars. I've modified
/etc/sysconfig/network-scripts/ifcfg-eth?
to force the HWADDR parameter ... so, now eth0 is the internal ...

Since this change, it seems that the connectivity is ok ... but I would like to be more secure about this event ...

What do you think about it?

[Ivan Ferreira]

Check if you continue to receive packages when the problem occurs, you should always receive packages even when you are not using the network, because of broadcast. Check the RX Packets in the output of ifconfig, should always increment after an interval. That should be a good indicator of link.

Also, do you have any messages in the /var/log/messages file? like NETDEV WATCHDOG, etc.

Check your adapter at the time of the problem with ethtool.

Use tcpdump to monitor the interface to see if you can see any packages going to the interface.

[Katty Torla Puga]

RX ifconfig -> ok
No NETDEV nor WATCHDOG in messages
ethtool -> ok

I append a file with the other information

Thank you,

[rick jones]

Unless the remote system is HP-UX, he "linkloop" daemon needs to be running on it as the default linux NIC drivers do not automagically respond to the XID/TEST message that linkloop uses.

[Ivan Ferreira]

I think that you should run tcpdump in logging mode. And pay atention to the moment where you loss the connectivity. The moment that you ran tcpdump seems that everything was working. I would like to know what is happening when the network does not work.

[Katty Torla Puga]

Hello,

And the problem goes on ...

I append a file with the tcpdump. Near the end of the file you can see the moment where I lost the connectivity.

Thank you

[Ivan Ferreira]

Sorry, there are lots of unusefull packets on your capture, and you did not specify the hosts with problems.

Please run again with a filter, for example:

tcpdump -w tcpdump.out host faraday.upc.es and pc11290.euetib.upc.es

So, there will be less information and will be more usefull.

Also, when you have the problem, get the output from:

netstat -nr
netstat -ni

Ensure that you don't have installed a software like portsentry.

[Ivan Ferreira]

Also, you should run the tcpdump on both hosts, source and destination, to match the output. Also, record the output of netstat -n too see the state of the connections.

[Jorge Cocomess]

I had this same problem serveral months ago. What happened was at the port setting on the switch was set for 100 /aut_neg and I set my NIC to 100 full /NOAUTO_NEG - Older Cisco switches doesn't like auto too much as I learned from this. Pick your settings for both ends and implement.

Try that and let us know the result.

[paolo barila]

Hi,
check and/or post

# ethtool eth0
(or)
# mii-tool -v


Pablo