Cannot send files without a continous ping running.

Imaging 2 sites, one having 2 workstations running windows NT and Linux. The other site runs windows NT. The 2 workstation location and the one workstation are connected via Bellsouth NMLI. The 2 station location need to send image files to the single site location. The linux system can do it all day problem. The Win NT system cannot send unless a continous ping is running otherwise it will fail during the transfer. The route path from both the NT and the linus are the same. Additional info: If I ping from the single site with NT to the sending site running linux, the pings can go forever with skipping a beat. If I ping from the single site to the NT..the pings works for exactly 60 secs, then fail for 60 secs, then work for 60 secs like clockwork. Any Thoughts ?? I think I have room to add more data. The 2 site location has a cisco 2950 24 pt sw, and the single site has cisco 6500 series chasis with router module to pass on to the next data center where the single site NT station is located. They run HRSP. The IT techs at the remote site says they disables HRSP to eliminate it as a possible cause.

Answer Wiki

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

This is one of those situations that just BEGS for a packet sniffer analysis!

Get a copy of Ethereal (and the winpcap packet driver) and sniff the traffic.

Look for things like TCP RST, ICMP status messages, etc. especially from the NT system. Also check the window sizes.

Since you mention NMLI, I assume you mean Frame Relay. Get the current traffic and error statistics from SBC to see if they can shed any light on it. The 60 seconds off and on business smacks of forced limitations.

What are the respective port speeds, port rates, etc. for both sides of the connection? If you don’t have a copy of the current contract, get one from SBC, since this might be a contractual detail issue.

Are these two sites the only elements in your WAN? Or are there other things going on as well?

The more information you can get and provide will help to nail this one down.


Discuss This Question: 1  Reply

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.
  • JamesTPHP
    We just had a somewhat similar problem with some of our remote sites. Our sites were VPN across Cable Broadband, but had very similar symptoms. I agree that a sniffer is your best tool, and if possible one on each end of the problem time synced and traces compared between the working and non-working host pairs. One thing you might want to try as a quick fix is to try changing the MTU size on the NT station and see if it has any effect on the problem. What we were seeing was if we pinged between a remote site and our local site w/ a 1024byte packet size and tried to run apps, the pings worked, but apps failed. When we increased the packet size of the ping to 1420bytes, we would see the pings fail along with the apps. When we set the Max MTU size on the remote workstations to 1392bytes, all the apps worked fine. We believe our problem is related to fragmentation across the VPN tunnel or with MTU discovery using ICMP. We are working with our Broadband provider to resolve these issues, but at least today our users can get their work done until we get a more permanent fix in place. Hope some of this is helpful. If you go to there is both an Analyzer and Optimizer that will let you check and set the MTU speed of your NT device.
    0 pointsBadges:

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.

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


Share this item with your network: