> "What configuration problem on a host computer can disallow a router from > maintaining its entry in an arp cache - even though the host is active?" ***Strange problem. Two things come to mind. Duplicate IP of the router on the 100.100.100.x network. The server is arping for the router and gets a response from the duplicate, therefore has the wrong arp entry and won't be able to initiate traffic for remote networks. When the ping goes across, the router arps the server, causing the server to update its arp cache with the correct entry, and now it can work properly. I doubt that's the case becuase the 'net use' statements shouldn't have done anything different then the ping from that perspective.
Secondly, I saw a really strange problem with a wireless bridge (breezecom) one time. Layout was print server ---6509(L3)----bridge----jetdirect. For some reason, the bridge would lose the arp entry (or something) and stop forwarding requests to the jetdirect if it was inactive for more than about 10-15 minutes. Since the MSFC was caching the arp entries for 4 hours, it didn't arp the jetdirect 30 minutes later when a print job came through. You could not ping the jetdirect from the msfc. But, if you dropped a machine on the other side of the bridge (from the jetdirect) but inside the msfc, you could ping it (because it initiated an arp) and then everything else would start working since the bridge was 'woke' back up. I sniffed the connections and when we pinged it from the msfc, I could see the icmp echo go into the bridge, it just never came out the other side...until a fresh arp. I never did resolve the underlying problem, just lowered the msfc arp cache aging time to 10 minutes. Weird stuff. Good luck, Vance ""Daniel Cotts"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > When pinging to a device for the first time the first ping times out while > the last network device (router) arps for the hardware address of the host > (server). (I'm assuming that the server is at a remote location from you.) > The router should then maintain the ip to MAC translation in its arp table > for a specified time. The arp table timeout (due to inactivity) on Cisco > routers is four hours. I think that we can assume that the server is busy > enough that it should maintain its entry in the routers arp cache. The > router seems ok because it works fine with other servers - hopefully on the > same subnet. That points to the server. I believe that you posted this > question the other day and indicated then that the problem had just started > happening. The question then is "Who messed with the server recently?" and > "What did they do?" What configuration problem on a host computer can > disallow a router from maintaining its entry in an arp cache - even though > the host is active? I can't state a definitive answer for that -- but I'd > sure want to check the subnet mask and default gateway values on that > server. > Please post your solution to the list. > > > -----Original Message----- > > From: Sim, CT (Chee Tong) [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 19, 2002 12:46 AM > > To: [EMAIL PROTECTED] > > Subject: can't map before ping first? [7:53599] > > > > > > I have a server which always has problem mapping to other PC > > across the WAN > > (other branch network). But it works after I ping to > > overseas PC (as shown > > below). Do you know what might be the problem. My other > > server don't have > > this problem and it is still the same after I switch it to > > another switch > > port. > > > > > > > > C:\>net use * \\w2k01\c$ > > > > System error 53 has occurred. > > > > > > > > The network path was not found. > > > > > > > > > > > > C:\>net use * \\100.100.100.19\c$ > > > > System error 53 has occurred. > > > > > > > > The network path was not found. > > > > > > > > > > > > C:\>ping w2k01 > > > > > > > > Pinging w2k01 [100.100.100.19] with 32 bytes of data: > > > > > > > > Request timed out. > > > > Reply from 100.100.100.19: bytes=32 time=109ms TTL=124 > > > > Reply from 100.100.100.19: bytes=32 time=110ms TTL=124 > > > > Reply from 100.100.100.19: bytes=32 time=110ms TTL=124 > > > > > > > > C:\>net use * \\100.100.100.19\c$ > > > > Drive G: is now connected to \\100.100.100.19\c$. > > > > > > > > The command completed successfully. > > > > > > ================================================================== > > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en > > is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht > > onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en > > de afzender direct te informeren door het bericht te retourneren. > > ================================================================== > > The information contained in this message may be confidential > > and is intended to be exclusively for the addressee. Should you > > receive this message unintentionally, please do not use the contents > > herein and notify the sender immediately by return e-mail. > > > > > > ================================================================== Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53690&t=53599 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
