Intemittent ping timout

pts.
Tags:
DHCP
DNS
Ethernet
Microsoft Exchange
Networking
Networking services
Security
We are getting intermittent ping timeouts (Request Timed Out / Destination host unreacheable) from most of the client workstations that are connecting to an exchange server 5.5 running on W2K server. There are about sixty users on the LAN and 20 others that are coming through the VPN link via a cisco PIX firewall.

We have tried putting different LAN cards into the exchange server but to no avail.

We have swopped out the switches many times and to no avail.

We have put in gigabyte 3com switch 3300TM and gigabyte LAN card in the server but to no avail.

We have run Trend antivirus on server and workstations and nothing shows up as a problem.

We have run Spybot and MS antispyware but nothing.

We have tested the entire LAN using subcontractor and termination problems solved but still prob elm exists.

Still Outlook gives error " Network problems are preventing connection to the MS Exchange server"

Our brief network configurations is as follows :

The central switch is the 3Com 3300TM. and it cascades to SIX different areas as follows :-

- to 12 port 3Com PSHUB 40 via 10MB fibre - which further fibre cascades to 12 pt Hub - to 12 port 3c hub 40 via 10M fibre - which further cascades 12 pt 3C baseline via cat5 - to 4 port hub via 10mb fibre - to 4 port hub via 10mb fibre - to 4 port hub via 10mb fibre - to 16 pt Trendnet nonmanaged switch via cat5 patch cable ( in same cabinet - thats where I am)

The client OS are combination of win98 and XP all running Outlook 2000.

I am running on my laptop, 3Com network supervisor to monitor each port on the 3300TM especially the giga and bandwidth utilization never goes beyond 5% even at time of timeouts.

This problem can sometimes get very bad on the weekends when I am the only one on the LAN.

This is the ping stats for the morning 28/07/05 at around 08:22 a.m

Pinging 192.168.0.3 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 This is ping stats for 27/07/05 at about 19.00 hrs Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Reply from 192.168.0.3: bytes=32 time=60ms TTL=128 Request timed out. Request timed out. Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 Reply from 192.168.0.3: bytes=32 time<1ms TTL=128 WHAT COULD BE THE SOURCE OF THIS PROBLEM

Answer Wiki

Thanks. We'll let you know when a new response is added.

Are any other servers having this problem? If they are check the DNS servers. Sounds like you have ruled out hardware.

Discuss This Question: 32  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • HumbleNetAdmin
    You have a number of fiber connections; check your fiber for kinks, bad spots and their connections to their devices. Also check cat5 cables and their connectors, make sure cat5 connections to switches and hubs, servers are seated well. Fiber connector ends are fragile, someone could accidentally bump the connector while messing with other items near them and mess up the fiber connector, had that happen to me a few times at another employer. Are you running CAT5 or CAT5e between the GigE connections, if CAT5 you may try CAT5E, When I first implemented GigE I tried on CAT5 and it would not cooperate until I used CAT5e and that could have just been the particular Ethernet card I was using also. Is there another server or PC near the Exchange server on the network, say, a server that is on the same switch/hub as the exchange server? If so, how does ping to the exchange work from there? Also how about pinging other servers, devices from the Exchange, can you produce the same problem from the Exchange server?
    0 pointsBadges:
    report
  • HumbleNetAdmin
    Dont think DNS is an issue since the problem is timeouts pinging an IP.
    0 pointsBadges:
    report
  • Dechamp
    Thanks guys for the suggestions. We subcontracted a Molex registered and accredited installer who came to test all CAT5 cables, flyleads, patch cords etc and corrected all terminations but still the problem exists. The only thing we did not test is the fibre links. Will do this and see what happens. We are mostly using CAT5 cables. Yes there are some other servers that are connected to the same switch that the exchange server is connected to, but they do not have this problem. Infact at the time when the server is timing out, I usually do pings to the other servers and clients including servers on the other side of the VPN link and all reply normally. By the way the gigabit switch was introduced a week ago when we thought that probably we were experiencing bottlenecks in the 10/100MB card in the exchange server. The problem started when we still had the 100MB card in the server and thats when we moved to 1000 gigabit card but as I said this did not change anything. Conicidentally, we only started noticing this problem after implementing VPN where we now connect on 128MB VPN link to two other sites. One of these sites is the one that is running an exchange server as well that talks to our exchange server and our server is the one that handles all outside mail and thus runs the Internet Mail Service within exchange.
    0 pointsBadges:
    report
  • Netserver
    Have you let any short patch leads sneak in your setup between active components. We had a similar problem when using a 1mtr patch lead between hubs, you should never use a lead shorter than 2Mtrs.
    0 pointsBadges:
    report
  • Cptrelentless
    I know I give this as an answer to every network problem, but have you tried using a device with ethereal installed? Plug it into each point on your network (the server switch, before and after the fibre connections etc) and you should be able to find where the packets are being eaten. You'll need to split the connections onto a hub to use it effectively as it's a passive listening program. Is there anything that might be stealing the IP address of the server? Like a slightly iffy routing device.
    0 pointsBadges:
    report
  • Helpdata
    Just a few questions and thoughts. No "magic bullet"... If the Exchange server at your site is the only device (server or workstation) which responds intermittantly, then I would think the general health of the network infrastructure is sound. This does not rule out a conflicting device and/or routing boggle. Was there communication between this Exchange server and the one connecting thru VPN, prior to puting the VPN in place? Did you have a problem with the connection to your Excange server immediately after bringing the VPN online, or after the Exchange servers were configured to talk to each other (if not already setup prior to VPN activation)? I have seen servers fail to respond to ping on an intermittant basis because it is "too busy" to do so. This does not necessarily mean that the CPU utilization is at 100% -- communications could be locked up by Exchange either waiting for a response (presumably from the other Exchange server) or stuck in a processing loop.
    0 pointsBadges:
    report
  • Dechamp
    Thanks ! Yes we are using 0.5m and 1m patch leads between switches and Hubs. Will move to 2/3 metres and see if that helps. Will try the Ethereal option to see what stats we get. I have spent the whole day on this problem and this is what I have also come up with. There are stations which I CANNOT ping successfully from my laptop in my office or from any other station BUT they are able to ping me or any other station. Now I wonder what the cable tester were testing. These same stations(ip addresses) that I CANNOT ping are also NOT being picked up by network discovery tools. Could this be the source of my problem???. What does it mean when you have such a scenerio????
    0 pointsBadges:
    report
  • Jaysea
    The stations that you can not ping, are they laptops running VPN software ? I have a few running the Cisco VPN application and the built in firewall completly hides the laptops from everything including management consoles.
    0 pointsBadges:
    report
  • Cptrelentless
    These machines that can ping you but you can't ping them - are there any inbound filters or software firewalls on them?
    0 pointsBadges:
    report
  • Amigus
    Sounds like you have a routing and or route metric problem. Are you running RIP on the servers or workstations? Whats the routing table look like on those boxes? Do you by chance have more than one route showing up in the routing table for 192.168.0.0/24 on boxes that are directed connected to that network?
    0 pointsBadges:
    report
  • Dechamp
    Many thanks guys for helping me think through this. The ping issue is sorted. Problem was the winXP firewall. Thanks for the pointers. Still have the main problem of ping timeouts to the exchange server. I can now confidently confirm that while the exchange server is Timing Out, all other pings to other servers and stations work well. Therefore it would seem like the exchange server has a problem. Helpdata has reminded me of the fact that when we switched on the VPN link we then had this problem. Unfortunately the two exchange server were configured to immediately start talking through the x400 connector. I have just tried something where, as the time outs were registering, I disconnected the VPN connection and immediately the pings were restored. What then does this mean??? Are the exchange servers over-chatting??? Is there something coming down the VPN link to cause a problem ?? If so why is this not exhibiting itself in the bandwith stats on the port which I am currently monitoring with 3Com network supervisor. Infact the network monitoring software as I stated earlier seems to indicate that very little would be happening on the server port during timeouts. Is it that the server goes quiet and stops responding??? By the way, who actually responds to ping commands??? Is it the LAN card of the server or is it some process that runs on the server to which we could say it sometimes decides to go quiet and goes to sleep for a while??? I know these are too many questions but I am trying to understand why I have timeouts when bandwith monitors shows no flood nor CPU stats 100%.
    0 pointsBadges:
    report
  • Bobkberg
    I'll start out with something a bit off-topic. I'm addressing other folks out there who are reading these posts and who might pose a question. This thread is an EXCELLENT example of the way this forum is supposed to work. The poster posed a question, and provided as much relevant info as possible. When other members responded with questions and suggestions, he (I'm assuming) responded with a number of relevant followups, which enabled everyone else to further think out the issue. I applaud everyone involved with this thread - this went the way it ought to - and I learned a thing or two as well. That's what makes this forum really worthwhile! On to the key topic... You should follow up cprelentless' suggestion to look at every troublesome connection with Ethereal (or other sniffer). I can't count the number of sticky problems that were solved after looking at the traffic on the wire. The other thing that you should look at is the port statistics for all manageable devices for any traffic anomalies - collisions, late collisions,errors, runts, giant packets - the whole gamut. Since the development of manageable hubs, switches, routers, etc., and the fact that the NDIS driver is not capable of passing up most low level errors on the wire/fiber, the only options for learning about such things is either statistic info at the device command line, SNMP variables, or use of a hardware sniffer (Network General/McAfee, Shomiti, and a few others. And thanks all for another educational thread. Bob
    1,070 pointsBadges:
    report
  • HumbleNetAdmin
    It sounds like that traffic is just having trouble getting to the server when the VPN link is up, routing issues. When the VPN is up computers on the network just cant get to the exchange server. Sorry, I dont have any answers as to why.
    0 pointsBadges:
    report
  • jimorus
    We have run into similar issues when people attempt to use the Cisco VPN Client when they are on the WAN. Have you tried a tracert to see where the connection is dying?
    0 pointsBadges:
    report
  • Dechamp
    Thanks guys. You've got my mind working overtime. I'll try trace route and see what stats I get. A point that confusses me is the fact that at the time that the server is timing out( as you saw this is only for a few minutes or seconds) I am able to ping everyone else INCLUDING the machines on the other end of the VPN link. So once again whats up with the link to the Exchange server? We do not use VPN clients. Seeing that its evening now, I'll try out the tests suggested tomorrow and see what stats we get.
    0 pointsBadges:
    report
  • Helpdata
    Pings --- pings are not just the network card; I don't have the exact layer in the model which responds to a ping, but you have already seen that the XP firewall can prevent a workstation from responding to a ping request. In "Secure" sites, ping response is supressed on purpose. To test the very good question of "over chatting" (or another Exchange based issue)... can you arrange for the other Exchange server to be taken off line (perhaps just have it's network cable disconnected temporarily) while the VPN is live? That would at least tell us if it is VPN or Exchange related.
    0 pointsBadges:
    report
  • Dechamp
    Bobkberg, you are quite right as this is really helping and at this rate I am sure we will crack this one.I only wish that this were not an intermittent problem. I will arange for the other site to be taken offline for the whole day so that my test can be conclussive.I had an interesting one about TEN minutes ago where my laptop suddenly lost contact with the server and I ran to the server room to disconnect the VPN and to my amazement the time outs continued for a very long time after that and infact the other laptop I have which I am using as a second test machine also lost contact. Now I am not so sure whether this has anything to do with the VPN BUT yes Helpdata, disconnecting the otrher side should answer this conclusively. During the time out, tracert also recorded Time Out for a maximum of 30 hops without any luck.
    0 pointsBadges:
    report
  • Bobkberg
    The reply to a ping (ICMP Echo Request / ICMP Echo Reply) is done by the TCP/IP Stack itself. If there is a network aware application listening (NetBIOS, IIS, whatever), then the IP stack will forward TCP and UDP traffic to it - as appropriate. But simple IP connectivity (Ping) involves only the IP stack. Bob
    1,070 pointsBadges:
    report
  • Dechamp
    I think I have narrowed down the problem. Its not the VPN link per se that is causing the problem BUT the CISCO PIX 501 firewall we are using. How I found this out is that once I got a successful ping, I ran it continuosly for 1 hour on 10 PCs and 2 laptops. After one hour I Ctrl-C and looked at the stats of ping on each machine and they registered 0% loss. I then switched some of the machines off and for the others I simply clossed the Dos screen. After ten minutes I powered up the ones that were switched off and then ran ping on all of them again. I got ONLY Two successful pings, out of twelve machines. Then I figured that this has to do with first time attempts of ping but once running, ping goes on forever without timeouts. Still did not answer my problem. Next I disconnected the VPN via switching off the radio/wireless unit. Got the same results. Next I disconnected the PIX from my LAN and problem went away. I repeated this test and everytime I get the same results ( Ping timeout when PIX connected to LAN and no problem when PIX disconnected)PIX dosn't have to be connected to VPN. The PIX is connected to the central switch and I notice that it seems to be frequently communicating with the switch (No VPN connected)as the Packet lights on the 3c switch seem to indicate. When the PIX talks to the switch ALL ports respond. Hope someone has experience with the PIX 501 out there. Why is it causing the intermittent ping timeouts to ONLY the exchange server and not other servers. Could this have anything to do with the Rules setup?? Do rules exhibit themselves intermittently??? My knowledge here is very limitted.
    0 pointsBadges:
    report
  • EngineerIT
    There may be a possiblity of conflict in IP addresses leased from the PIX to the remote site and remote clients. Make sure leased IP addresses from PIX are not used in your LAN. When there is request timeout for Exchange server, what is the status on vpn remote site and clients? Are you able to ping remote site exchange server and those clients? Can you check the routing on the exchange server "print route"? Are there TWO cards on exchange server in anyway? I faced the problem with Citrix having two cards, one for Lan and other for wan(DMZ). Sometime Server was not available for LAN, Problem was due to routing and metric of the routes. It was solved. You can check for the same. Moreover, When there is timeout for the server, try to ping from the server to local machines and see if it is pinging or not? Ping loopback address as well to check TCP/IP stack. Its good to try Traceroute that will help you to find out which way your packets are travelling. BEST OF LUCK
    0 pointsBadges:
    report
  • Bobkberg
    Something that occurs to me - Is it possible that, as EngineerIT points out there might be an address conflict with either addresses leased to the Pix, OR that the Pix might have an address pool of one sort or another (NAT, Static, vpn, etc.) for which it might be doing a Proxy ARP, thereby 'poisoning' the local arp cache with respect to the other addresses locally? I've seen some funny things with respect to PIXs and ARPing. Bob
    1,070 pointsBadges:
    report
  • Petroleumman
    Hello, Where does your Exchange server live....on the trusted (internal) network or is it external (DMZ)? If it is external then your problem is most likely with your PIX firewall configuration. There is something either in your interface settings (interface bridging the trusted w/ external)or a misconfigured policy (possibly your SMTP policy) which is blocking packets or from the intermittent ping responses your receiving, forcing them to use another path. You didn't say, but I'm assuming your users are not able to send or receive mail either? I know you've used PING to test your connectivity, but have you tried running TRACERT? If not, try this as it will trace the path your packets are using to get to your Exchange server as well as ID where they are failing. Good Luck!
    0 pointsBadges:
    report
  • Dfng2002
    As previously stated, it could be the vpn being active. Ping and tracert are ICMP and have low priority in networking, check to see if the ping loss time frames are when the servers are talking to each other, they might be getting deprioritized while servers talk. You may not even have a problem. Good luck.
    15 pointsBadges:
    report
  • Snapper70
    What I find odd is the replies to the continuous pings - some of the responses are 1 ms, and others are 60. Also, SOME requests are simply timing out, and others are Destination Unreachable. Is the PIX the only router in your environment? What was the source address of the original ping in the first post - from the same site? If so, you shouldn't see the Unreachable message...
    920 pointsBadges:
    report
  • Nephi1
    Thought of one thing... What is the IP address range being used on the VPN? And is the exchange server doing the VPN connection. As my line of thought is that you have the VPN and LAN using the same IP range (192.168.0.x range) and the ping packets are getting to the server but are being transmitted through the VPN and not back to the LAN. I would also check to see if both sides of the VPN have different IP ranges, as the exchange server (if its connecting) is getting a route to the other network (the one on the other side of the VPN). So basically LAN1 = your lan LAN2 = other lan != = does not equal LAN1 IP range != LAN2 IP range LAN1/LAN2 IP range != VPN IP range
    0 pointsBadges:
    report
  • SteveOK
    Are any of the network devices auto-negotiating the connection speed? If so, try setting the speed manually. Sometimes auto-negotiating doesn?t, especially between devices from different manufacturers. I?ve seen this on my network between 3com NICs and Cisco switches, and ended up with symptoms like you described.
    0 pointsBadges:
    report
  • Mtburke
    I would go with Bob'a answer and check the Proxy arp on the PIX. From the IOS you can enter "sysopt noproxyarp inside" to stop the proxy arp. Thanks Mike
    0 pointsBadges:
    report
  • Basavapa
    You can anticipate these kind of problems in the wireless infrastructure. The problem which you propogated is more or less n/w connectivity issues. This may occure if 1. Ether Net cables have not properly connected. meaning if there is any loose connection in any of eth switch then ICMP request fails intermittently 2. WLAN is not properly designed i.e chances of packet loss if bandwidth goes below desired one. 3. You simply said WS2k without specifying its firmware version. Please upgrade to new FW if it is running with an older one. By doing this, latest fw is smart enough to handle data transfer more securely. 4. There could be Power fluctuations to any of n/w elements. It might influences low bandwidth in turn ping fails Request: Please use open source ethreal for debugging purpose
    0 pointsBadges:
    report
  • CiscoNetguy
    four thoughts come to mind... 1)run a sniffer - mirror the exchange server and monitor traffic. 2)could be duplex mismatch between card and switch. 3)duplicate IP ? 4)server utilization or CPU queue length.. backup jobs could be running on server ..etc... what else is running on the server.
    0 pointsBadges:
    report
  • Dechamp
    Hie all. I am back on line. Thank you to all of you who contributed to this my dilema. The sum total of your contributions led to my finally coming up with the solution. To resolve the problem, I removed from the PIX, all reference to the Exchange server BUT rather pointed the PIX to talk to another server (Antispam) which I setup to accept mail relaying from the exchange server. This amounted to setup the mail server behind the atnispam server ( so to speak) and setup the mail server to relay all its internet mail via the Antispam server. Now the PIX firewall can talk to Antispam server as much as it likes and this will not affect the users as they connect to the mail server NOW without any hindrance or timeouts. They is probably a sound technical explanation to this solution but I put it down to "Never Connect your mail server directly to the PIX firewall" Dechamp
    0 pointsBadges:
    report
  • Genderhayes
    Check all switches in the network, replaced CAT5 cables leading to my server room, replaced the NIC card in the server and went as far as removing the hard drives in the MS Server 2003 and placed it into another backup server to see if the problem was related to my server?s hardware
    7,565 pointsBadges:
    report
  • Genderhayes
     DNS Check in Pingdom Tools will check your DNS health and help you find errors, and verify that you domain name has been set up correctly automatically find out which DNS servers are used by the domain name you specify, then perform a number of tests on them to make sure that the domain name is properly set up and that those DNS servers are responding in a consistent and correct manner
    7,565 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following