No connectivity to specific hosts, flushing ARP cache helps temporarily

[ronanian]

One of the desktop PCs (running XP) on my network has a weird problem. It can reach some hosts but not others. If I delete an unreachable host from the arp cache, it can then reach that host for a few minutes. If I display the arp cache when it can't reach the host, the entry is correct.

 

A couple hundred other PCs have no problem.

 

In addition to the usual things, I tried "netsh int ip reset" and "netsh winsock reset catalog". I also tried hardware; I tried replacing the network card, and I tried a different port on the switch just in case.

 

Here's basically what I was doing that best demonstrates the weirdness:

 

ping 192.168.18.1 (one of the hosts it can always reach)

Reply from 192.168.18.1: bytes=32 time<1ms TTL=64

 

ping 192.168.18.9 (one of the hosts it can't always reach)

Request timed out.

 

arp -a

192.168.18.9 = 00-1e-0b-4e-44-ba (I checked, that IS the correct address)

 

arp -d 192.168.18.9

(no error)

 

arp -a

(192.168.18.9 not listed)

 

ping 192.168.18.9

Reply from 192.168.18.9: bytes=32 time<1ms TTL=64

 

arp -a

192.168.18.9 = 00-1e-0b-4e-44-ba

 

...leave it alone for a few minutes...

 

ping 192.168.18.9

Request timed out.

 

arp -a

192.168.18.9 = 00-1e-0b-4e-44-ba

 

(Rinse and repeat as necessary)

 

How can clearing the arp entry fix it when the arp entry isn't wrong?

[ronanian]

Okay, I found out what's happening and fixed it, but I don't know HOW it happened and I hope someone can help. The school library is attached to a regional library system. The regional system has their own pipe, their own switch, and their own network drops on our site. Their switch had a cable going to our network. I disconnected that cable and everything started working.

 

Here's the part I don't understand: Their switch was somehow messing up routing on PCs. I had started using a new IP range, 192.168.61.0/24, and any computer in that range had the problem described above with the weirdness from clearing the ARP entry. If I went to another computer and did a traceroute to it, I'd get the library system's router, which totally didn't make sense.

 

Here's a transcript that demonstrates it better than I can describe it, pasted from a command prompt window on a computer that does NOT have the problem:

C:\>route print

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x2 ...00 0a 5e 77 79 dc ...... 3Com EtherLink XL 10/100 PCI For Complete PC Management NIC (3C905C-TX) - Packet Scheduler Miniport

===========================================================================

===========================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.18.1 192.168.18.228 20

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

169.254.0.0 255.255.0.0 192.168.18.228 192.168.18.228 30

192.168.0.0 255.255.0.0 192.168.18.228 192.168.18.228 20

192.168.18.228 255.255.255.255 127.0.0.1 127.0.0.1 20

192.168.18.255 255.255.255.255 192.168.18.228 192.168.18.228 20

224.0.0.0 240.0.0.0 192.168.18.228 192.168.18.228 20

255.255.255.255 255.255.255.255 192.168.18.228 192.168.18.228 1

Default Gateway: 192.168.18.1

===========================================================================

Persistent Routes:

None

 

C:\>tracert 192.168.61.5

 

Tracing route to 192.168.61.5 over a maximum of 30 hops

 

1 <1 ms <1 ms <1 ms 192.168.18.2

2 5 ms 5 ms 5 ms 172.29.131.25

3 * * ^C

C:\>

 

Default gateway (our firewall) is 192.168.18.1. Their router had 192.168.18.2. My PC is 192.168.18.228. 192.168.61.5 is a comptuer with the problem described in the previous message.

 

The destination, 192.168.61.5, is on the same subnet as my PC, and both have 255.255.0.0 netmasks so should be able to directly ping eachother without routing through any gateways. There is NOTHING in my PC's routing table about 192.168.18.2.

 

How the heck can a PC use 192.168.18.2 as a gateway to something on its local subnet when it shouldn't use a gateway at all AND doesn't have 192.168.18.2 anywhere in its routing table? Severing the connection between their network and ours makes everything work.

 

I saved a wireshark packet capture of that traceroute to see if I could learn anything from it but I can't. 192.168.18.2 was responding with "Time-to-live exceeded in transit", but shouldn't have gotten involved at all.

 

Is there some kind of automated routing protocol going on there?

 

Edit: I'm pretty sure Linux systems weren't affected, only Windows; the PC with the new address could communicate properly with Linux servers but not Windows ones.

Edited August 29, 2008 by ronanian