Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 418
  • Last Modified:

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.
0
james_axton
Asked:
james_axton
  • 3
  • 3
1 Solution
 
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
 
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
Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

 
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

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now