4000M Network Problems

[James Henry_3]

First problem.

We keep losing connection from a 4000m to servers.
After loss if you check Mac table address is missing ?
Reboot server all is well for about 12-18 hours and then it loses its connection again.

Second Problem

Connect RS6000 have link light.
Both fixed at 100Full.

Can ping from Switch to both Mac and IP address.

But not from anywhere else.

[Ron Kinner]

Problem 1 I think is a software problem. Make sure you have the latest version (C.09.16) from http://www.hp.com/rnd/software/switches.htm

If that doesn't work try setting the arp table timeout to a larger value or go to static arps.

Also make sure you do not have a duplex mismatch causing errors to build up. Some switches will take a port out of service if there are too many errors. Remember if you set the duplex on one end you have to do it on the other end. Full on one and auto on the other gives you full and half and a bad mismatch which shows up most under load.

Problem 2 appears to be a routing issue tho I suppose if you had it in a vlan all its own you could have the same problem.

Check that RS6000 has a default route and does not have any incorrect routes. I suppose it runs AIX which I don't speak but if it is a UNIX type system and not one of those menu driven things then
netstat -rn
should show you the routing table.

traceroute hostipaddress
should also be of some help.

Ron

[James Henry_3]

Thanks for the reply.
Second problem has gone away !

First problem persists.

We are on C.09.16 already.

I have also increased the timeout.

Any more ideas ?

[Arnaud_9 · Accepted solution]

Hello James, here are some ideas :
- Check the log of the 4000m
- Try to swap, on the 4000m, the RS6000's port with another a port of a working device, to see if the problem persist on the RS6000 or get on the other device
- Check also the RS6000 log : may the inetd service has troubles (Bug in a patch/udpate, Overload, Hacking/DOS, the cron service stop it every 12 or 16h, ...)
- Try to connect the RS6000 to a non HP 4000/8000/2400 series switch.
- If possible, try to put the RS6000 back to back with a working device and ping it all a night, to check the RS6000 hardware.
--> Was it working fine before ?
- Is the Cabling system between the 4000m and the RS6000 is Ok ? May someone unplug and replug a cable or patch pannel (Like a house-keeper :-)) : some old NIC can not be able to get up alone after.
- On last ressort, try to monitor the RS6000's port with a sniffer that you launch some hours before a predicted crash time (a big hard disk may be requiered)

[Ron Kinner]

I wonder if there is a duplicate IP address floating around in your network that causes problem 2? When the guy comes back from vacation and turns his PC on again it may come back.

As for problem 1, assuming HP has their arp problem fixed, you can look at the driver for the server's NIC. I know some of the Compaq Server NICs had similar problems. Something about running out of buffer space.

Does the switch show any errors on the port going to the server?

Ron

[James Henry_3]

What arp problem ?

[James Henry_3]

No errors reported on port

[Ron Kinner]

If you look at the release notes for the 4000M software you will see that they have had problems with their MAC table in the past. Go to
http://www.hp.com/rnd/software/switches.htm

and click on Summary next to the C.09.16 download for the 4000M. Then click on readc916.txt and read the section on C.09.14.

Ron

[James Henry_3]

Thanks Ron, It seems they still have a problem !

[Anton Pikhteryev_2]

I have tried all suggestions and workarounds from Kinner's most recent post to this thread: http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x4b4e28c64656d71190080090279cd0f9,00.html

and would like to say that it didn't help me a bit. I am still experiencing the same problem as described above on all my switches with:

HP J4121A ProCurve Switch 4000M
Firmware revision C.09.22

Event log:

I 10/25/05 19:50:31 ports: port I3 is now on-line
I 10/25/05 19:52:24 ports: port I4 is now off-line
I 10/25/05 19:52:27 ports: port I4 is now on-line
I 10/25/05 20:01:15 ports: port A5 is now off-line
I 10/25/05 20:01:23 ports: port A5 is now on-line
I 10/25/05 20:01:31 ports: port A5 is now off-line
I 10/25/05 20:01:33 ports: port A5 is now on-line
I 10/25/05 20:01:54 ports: port A5 is now off-line
I 10/25/05 20:01:56 ports: port A5 is now on-line
I 10/25/05 20:04:37 ports: port B2 is now off-line
I 10/25/05 20:04:46 ports: port B2 is now on-line
I 10/25/05 20:04:54 ports: port B2 is now off-line
I 10/25/05 20:04:56 ports: port B2 is now on-line
I 10/25/05 20:05:18 ports: port B2 is now off-line

Uptime on devices connected to these ports didn't changed, cables are perfect.

Any other ideas?