Sleepy network interfaces on some 10.20 machines

[Alan Malek]

Hello, everybody. I am helping some folks remotely with 7 otherwise identical HPs. A uname -a gives this:
HP-UX hpetst4 B.10.20 A 9000/745. Three of the machines seem to act very consistently. They are always alive and kicking on the network. The other 4, however, suffer from what I call sleepy interfaces. If they are not sending network traffic of any sort they fall off the network completely. They are not pingable or anything. If someone hops on the console, though, and pings a machine that is alive then the interface wakes up and it acts perfectly normally. At that point I can log into it start a ping back to machine and work on it without problems. Should I happen to stop the ping it shuts back down immediately. All the HPs are essentially identical. I have looked at all sorts of conf files and most if not all are identical across machines. Clearly, I am missing something. Does anyone have any clue as to what this might be? It is causing a work stoppage for these folks. Oh, apparently, this has been the case since these machines were installed years ago, but it never really mattered until now. Any help would be greatly appreciated. Thanks.

[Chris Wilshaw]

It sounds like it could be network, rather than system related.

It is possible that the keepalive status of the router at the remote ends is not set up, in which case you could get the problem that you're seeing here (link drops after a pre-set time). Depending on how the link is set up, it is possible that it can only be re-activated by traffic from a specfic side of the link.

I'd suggest you get your network support guys to check out the routers.

[A. Clay Stephenson]

I suspect that you need to adjust two values on these boxes via nettune.

tcp_keepstart
and
tcp_keepstop

Do this on these boxes to see the the current value.
nettune -l tcp_keepstart.

Man nettune for details; the equivalent (more or less) command for 11x is ndd.

[A. Clay Stephenson]

In addition to routers, if you are going through a firewall - there are timers associated with them as well. It would help to know if the problems are associated with a particular subnet or will one box on the same subnet show problems while others will not.

[John Palmer · Accepted solution]

If the servers have been cloned then it's possible that someone may have configured specific MAC addresses for the interfaces.

Check /etc/rc.config.d/hpetherconf.

Regards,
John

[Alan Malek]

Hpetherconf looks to be the culprit. So, far I have identified 4 of the machines as having the exact same ether station addr. Thanks!

So, the question now is how do I fix it? Specifically, is there a way to tell it to use its default address or must I just hardcode something in there that's different from the others? That option seems a little less elegant. If I do have to just pick a new random address what is the convention here? Thanks!

[A. Clay Stephenson]

Just leave a null entry in the field and it will the get the MAC address from the hardware itself.

[James R. Ferguson]

Hi Alan:

Leave the address portion empty. It's not necessary to specify it.

Regards!

...JRF...

[Alan Malek]

Great! Then just take lan0 down and bring it back up and it should be fine, I assume? I just want to be sure because I'm walking someone through this over the phone who knows nothing about HP/UX.

[James R. Ferguson]

Hi Alan:

Taking the appropriate lan down should work. You should be able to use 'lanadmin'. My choice has always been to reboot when changing network parameters, though.

Regards!

...JRF...

[A. Clay Stephenson]

You bet. Edit the file on all four of these guys; blank the string; do a normal shutdown and reboot and you are done.

I can think of one reason someone hardset the address. It's possible that some license is tied to that MAC address; I would check that out before I called this puppy whipped.

[Alan Malek]

Thank you everyone for your extrememly helpful insight. It was an address problem and blanking out the station address in hpetherconf and rebooting resolves it. Many thanks.

FWIW, I couldn't get lanadmin to flush the old address for me. Seems like a reboot is the only way to get back to the machine's default hardware addr.

Thanks again!

Alan