incomplete arp entry

[Ben Dehner]

I have two HP-UX 10.20 systems with tokenring interfaces; one is a D-class, the other a K580. Our tokenring environment is a single network, but with an ATM core backbone.

Occaisionally, we have tokenring client workstations that (over ATM) we cannot get an ARP resolution for. "arp -a" will show something like

? (172.16.131.128) at (incomplete)

and all communications with this address will fail. (There is no discernable pattern of address or systems that seems to fail consistently.) If I delete the entry from the arp cache, most of the time the same incomplete entry will return, but sometimes not, and things will work. If I manually add in the correct arp entry, everything works fine, until the arp entry ages out of the cache. I see this same problem on both HP boxes, but, oddly enough, a Windows 2000 server connected to the same switch as the Unix systems has no problems.

What does this "incomplete" entry mean? Is this telling me something useful, other than "arp isn't working right"?

I've tried troubleshooting the ATM environment as best I can, but I cannot see any problems. What is especially troubling is that that Windows box has no problems. If there is an issue with ATM, I would suspect there would see more connectivity issues than just these two Unix systems. Any hints would be appreciated. Thanks.

[Ron Kinner]

Incomplete just means that the ARP request was sent but no reply has yet been received. Probably lost a packet in one direction or the other or the other end was down.

Try doing a linkloop test (see man) between the two HPUX boxes to see if you have any layer 2 problems with the NICs, cables or switch.

If I remember correctly the HPUX likes to do arps periodically even if it has happily been talking to the device on the other end the whole time. The windows box just keeps using the old arp info unless it has not talked to it recently. IF that's true then that might explain why you see a difference between the two.

Ron

[Ben Dehner]

Thanks for the reply, but I'm still struggling here.

I tried linkloop, and got nothing but timeouts up to 20 seconds. This includes various combinations of the unix boxes to each other, and to windows boxes as well. I tried boxes on the same ring (RIF data is empty, no ATM), as well as including the RIF information from the arp cache, but the same result.

Also, the windows box for which everything work often does not have an arp entry for the client PC. It's not a heavily used server, and often does will not have connected to an arbitrary client PC. It has to do a dynamic arp request same as everyone else.

[Ron Kinner]

I expect linkloop defaults to the Ethernet driver. I'm not up on token ring enough to tell you what -f /dev/? to use but I think that is the problem. Perhaps lanscan or ioscan would tell you.

lanadmin
lan
display

if I remember correctly that should show you the status of the NIC. The second page has error statistics which might help.

Does
netstat -s
show any errors?

you might try

ndd -h |grep arp

and see if there are any tunable parameters which might help. Perhaps arp replies are slower in coming with token rings?

Ron

[Ron Kinner]

Now that I look at it more carefully you are really in the wrong forum for your problem. Why don't you post it over in http://forums1.itrc.hp.com/service/forums/categoryhome.do?categoryId=245

where the hpux heavy hitters hangout?

Ron

[Ben Dehner]

With linkloop you specify the net management ID of the interface from lanscan, which I've been doing. Also, unfortunately, there is no ndd command on HPUX 10.20.

I'll try on the HP-UX networking forum, thanks.

[Ron Kinner]

Sorry Ben,

I missed the fact is was a 10.20. The command is

nettune -l | grep arp

Ron