Incomplete arp entry

[Ben Dehner]

I tried posting this in the "networking" forum, but it was suggested I ask here.

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 using linkloop to test link status, but all it does is time out

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.

[Steven E. Protter]

Check the integrity of the network hardware. cstm,mstm,xstm. If its always the same NIC, maybe its just hardware.

Make sure there are no wiring issues.

You might be able to deal with this without finding the problem by having a cron job clear the arp cache.

SEP

[Ben Dehner]

Thanks for the reply.

I have two different HP-UX systems that are showing the same symptoms, and they are conncted to different TR hubs. xstm doesn't indicate any problems on either system with the NICs.

Flushing the arp cache usually doesn't help, because most of the time the incomplete entries just come back. The only common thing I can find is the ATM core. However, I can't confirm that because only these two systems seem to have ARP resolution issues. If it was a general ATM problem, I know a lot other systems and applications would have problems.

[rick jones]

Incomplete entry means that an ARP request was sent (broadcast) but as of yet no ARP reply has been forthcoming. It suggests that either the ARP request or the ARP reply was lost somewhere along the way.

I forget how long 10.20 will keep trying to complete an ARP entry before it gives-up. At that point it would require an another attempt to send to that destination before more ARP's would be sent.

[KapilRaj]

This entry ..

"? (172.16.131.128) at (incomplete)"

means 172.16.131.128's DNS name is changed and is no more responding . Did you move any of ur subnets ?.

I had this problem and the only thing worked to get rid of it was , bring up this IP on the local interface and then delete it.

Note "arp -d" did not work for me. I think this request could be from any of ur NFS mounts or any other process. When u bring up the same IP on one of the local interface , that process or NFS would time-out else it will be in an incomplete state.

What you can do is ,

ifconfig alias 172.16.131.128
sleep 10
ifconfig delete 172.16.131.128

I am not sure HP's ifconfig syntax is the same but should be something similier , I heard there is also a command callled ifalias for older versions...

Regds,

Kaps

[Ben Dehner]

Thanks to those who responsed, it looks like we found the problem.

Apparently, something in our network did not like source routing over tokenring. Our TR environment is a single IP network, but it is broken up into multiple segments or rings. When I disabled source routing with lanconfig -rif, the problem went away, or so it appears.

Rhetorical question of the day, these boxes have been like this since day one. What changed in our environment to break it?

[rick jones]

well, you are probably in a better position to find-out what changed recently in uour environment than the rest of us :)

some ideas:

*) some new kit was installed with restrictive defaults

*) some over-eager network admin, having learned by rote that "ip source routing" should be disabled, decided to (mis)apply that knowledge to the configuation of token-ring bridges too

[Ben Dehner]

We're shooting tokenring now anyway. 3 years later. I don't like to leave open threads dangling.