Multi Link PPP, plenty of bandwith, but slow file access across mapped drives

I've asked this here before and wanted to give it another shot to see if I could do a better job of explaining my problem.  We have two companies - one East coast, one West coast - that we wanted to join using a Multi Link PPP connection.  Analysis shows almost no traffic going across the line but when we attempt to map a drive from the East coast location to the West coast server - like this, \\WestCoastServer\SharedDrive - we get incredibly unacceptable wait times when browsing larger directories and opening files.  In some instances we might wait 7 minutes for a large directory to populate and than another 5 minutes for a small 500k file to open.  

The line has been tested and retested, and as I said there is almost no traffic running across it.  Experts Exchange has already helped me rule out any firewall issues.  

Is this issue a limitation of Windows File Sharing and if so what other options might be available to us so that we can use files located on the other server.  Terminal Services is not an option for our particular situation.

Thanks for any help you can offer.
james_axtonAsked:
Who is Participating?
 
blue-screenCommented:
Ah, you don't control the 2811, so you don't know the configuration?

Since I don't know what the "testing" entails, I can't say that anything was ruled out.

Does everything BUT file shares work well?  FTP?  HTTP?  

If all traffic but the file shares runs at a good speed, I'd think the network is OK.  

Another possibility is permissions management - Are the server and the client in the same domain?  How are the domain contollers and DNS set up?  If the firewall blocks connections to the appropriate domain controller providing share permissions, you can have a situation where the server asks DC1 for file permission a bunch of times before it gives up and asks DC2.  if the firewall blocks DC1 and not DC2, that would explain why it EVENTUALLY works but does totally slow.

In that case, directory listings would take forever, but file transfers should zip along once they start after a long delay.

Summary - if file transfer traffic outside of AD goes fast, the network is not the issue.  At least, the multilink PPP is not the issue.  Firewall access to AD controllers and DNS servers might be, though.
0
 
blue-screenCommented:
Multilink PPP over what kinds of link?  ISDN?  Dialup?  T1?  How many links?  2?  3?  What kind of routers?

This sounds like a case where there may be packet fragmentation or some crossed links in the bundle (example:  You have 3 links, but only 2 of the 3 are connected correctly).  The packets keep getting dropped until you are lucky enough that the packets traverse the two-of-3 correctly configured links.

More details, diagrams, router configs, etc... would be helpful
0
 
james_axtonAuthor Commented:
Blue-screen,

These are T1s, 3 total, handled by Cisco 2811 routers.

Wouldn't the scenario you described be noticed during testing by the provider?

The last thing a packet sees as it leaves one company is it's Cisco 2811 router and the first thing it sees when it hits "the other side" is the other company's Cisco 2811 router.  The only other thing in between the "main" 2811 and the network switches is the firewall, and both the switches and the firewall have been ruled out as being the issue.  Also, we don't control the 2811s, they are owned by the provider.

Is this enough information?  
0
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
james_axtonAuthor Commented:
blue-screen, I let this sit for too long and I apologize.

It's just file sharing that is slow.  And it's not a case of just waiting for a single population of a directory and then I'm able to work okay.  If I wait for let's say 3 minutes for a directory population, then accidentally close and re-open, I'm going to wait 3 minutes again.  Further, even if I don't accidentally close and instead try to open a file, I might wait an addition 2 minutes.    

I've had the firewall checked by another person on staff here and am comfortable that it's not the issue.  There are however several different subnets i.e. 172.17.x.x, 172.19.x.x.  Could something with the subnet configuration cause a problem like what we are seeing?
0
 
blue-screenCommented:
So, this is SAMBA (CIFS, windows sharing) only, and it is only the time it takes the directory to display?  

Once displayed, do downloads go quickly?

Is it possible that there is a problem accessing one of the AD servers by firewall, or if there is an issue with fragmentation?

A packet trace from a slow/failing machine could be illustrative.,
0
 
james_axtonAuthor Commented:
blue-screen we handled this issue another way.  I'm going to close this out and award points.  Thanks for sticking with it!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.