Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have inherited a Microsoft network / environment with all of the usual culprits: Active Directory, Exchange, Terminal Server, 50 clients, File & Print Server - standard enough office essentials.

The clients are all in the 172.25.51.* range and their download speeds from the internet are a fraction of those which the servers experience. File transfers between machines in this range seem zippy enough. (See output from machine #1 - Client below.)

The servers are all in the 172.25.24.* range and their download speeds from the internet and file transfers between each other seem fine (see the output from machine #2 - Server below).

File transfers between the two ranges seem quite slow too. I guess my question will eventually lead to another but here's what I need to do first: how can I set about formally diagnosing why the clients in the 51.* range experience such terrible download speeds from the internet and the 24.* range?

I suppose the fact that the internet comes in via the 24.* range explains that slowness so my real problem which I need to diagnose and find a cause for is what is causing the slowdown between the servers (24.) and the clients (51.)?

I'm fairly certain that it's not the cabling although I would welcome suggestions as to how I can prove that it isn't the problem? It was done by a professional company so I am inclined to believe it is a configuration issue somewhere. Any suggestions would be most appreciated.

#1 - Client

ipconfig

V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:33:30--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9a.tar.bz2 
   => `vlc-0.9.9a.tar.bz2'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done.    ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)

100%[======================================>] 17,500,620  39.3K/s   in 7m 35s

ipconfig /all

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : domain.local
Description . . . . . . . . . . . : Intel(R) 82566DM-2 Gigabit Network Connection
Physical Address. . . . . . . . . : 00-1E-4D-F4-35-57
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 172.25.51.77
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.51.1
DHCP Server . . . . . . . . . . . : 172.25.24.10
DNS Servers . . . . . . . . . . . : 172.25.24.18
                                    172.25.24.12
Primary WINS Server . . . . . . . : 172.25.24.18

#2 - Server

wget

V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:41:15--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vl.9a.tar.bz2
   => `vlc-0.9.9a.tar.bz2.1'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done.    ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)

100%[======================================>] 17,500,620   510K/s   in 28s

ipconfig

Ethernet adapter NIC:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2
Physical Address. . . . . . . . . : 00-11-54-31-32-50
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 172.25.24.17
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.24.1
DNS Servers . . . . . . . . . . . : 172.25.24.18
                                    172.25.24.12
share|improve this question
    
What is the output of "netstat -e" ? DNS issues would only cause the initial part of the transfer to be slow, not the whole thing. –  chris Jun 30 '09 at 19:24
    
I have a hard time w/ a configuration involving a "server subnet" and a "client subnet" with only 50 client devices. That seems to be needlessly complicating things to me, not to mention putting the burden of, potentially, gigabit-per-second traffic on whatever layer 3 entity is routing between those subnets. I'm guessing that, with a network that small, the Customer couldn't afford, like, a Catalyst 6500 for that layer-3 functionality. –  Evan Anderson Jun 30 '09 at 19:29
    
@evan: Most mid-tier and better managed switches do static routes at near wire-speed. They won't do OSPF or other dynamic routing protocols but they're totally able to shovel traffic from one vlan to another at the same speed they shovel traffic from one L2 interface to another. No need for a fancy router if you're just doing static routes between subnets. –  chris Jun 30 '09 at 20:15
add comment

5 Answers

Are the switches managed, and available for you to log into? I'm wondering if someone's solution to bandwidth-abuse wasn't to QoS a certain percentage to the server subnet, and let the user subnet suffer with whatever's left over. (I'll admit there are days when the idea has appeal)

share|improve this answer
    
"(I'll admit there are days when the idea has appeal)" Yes, all those days ending in a "y". ;) –  John Gardeniers Jul 1 '09 at 1:00
    
Exactly so! I work hard to put a good-witch-Glenda demeanor atop my BOFH nature... ;) –  Kara Marfia Jul 1 '09 at 13:01
add comment

Is there a duplex mismatch?

Any time there are performance issues the first question is: Is this a dns problem or is it the network?

If it is slow to establish connections but then they work normally after the initial connection, it may be DNS related. Users typically complain that "the internet is slow."

If it is a duplex mismatch, look for the duplex setting on both sides of the link, look for collisions, and look for transmit/receive errors. Duplex mismatches are often caused by people who set a switch to not auto-negotiate the link -- they hard-code the switch to be 100/full, but then neglect to set the computer side of the link to be hard-coded as well. Often that side of the link comes up 100/half and will work until you try to push more than a trivial amount of traffic through it, at which point it will perform worse than a 10/half link due to all the dropped packets (that the other end just thinks are collisions).

share|improve this answer
    
It is also possible to leave both ends auto-negotiating, only for them to get it wrong and settle on a different duplex setting at each end. +1 for mentioning it, though; of all the answers so far, yours is the only one I've actually seen happen. The other tell-tale is transfers are fine in one direction, but glacial in the other. –  RainyRat Jun 30 '09 at 21:15
    
The parent needs to test performance from one subnet to the next and from hosts inside the each subnet to each-other. That will isolate if it is an L3 problem or an L2 / L1 problem. Swapping cables isolates an L1 problem and looking at the interface error counters on each side of the link (switch & host) to isolate L2. Even 10/half is way way faster than the speed one of the hosts observed, which leads me conclude L2 errors which will destroy TCP/IP throughput under load. –  chris Jun 30 '09 at 21:26
add comment

What is the device "172.25.51.1", specifically (some kind of router, obviously)?

It's routing between the .51 subnet and the .24 subnet, and it looks like it's bottlenecking for some reason.

I'm guessing it's not the same device as the "172.25.24.1" device, though it could be.

I'm feeling like either the "172.25.51.1" device is having a problem-- either with the one of the interfaces that connects it to the various physical broadcast domains, or with its configuration. It could be overloaded with local traffic moving between the subnets, as well.

I'd examine the interface error counters on the Ethernet interfaces of the "172.25.51.1" device, and the switch ports it plugs into. I'd also try and gauge how much traffic it's moving between the subnets on average and how heavily loaded its CPU is.

You'd really like having something like MRTG or Cacti in this kind of situation so that you can get some visiblity into traffic flows (and, if your devices support it, CPU usage, temperature, etc).

share|improve this answer
add comment

If the transfers between all clients on a subnet and between all servers on a subnet are ok but not between client subnets and server subnets it sounds to me like the router is the culprit. If it's a single device then there is a config issue. If each subnet has its own router then the 51 router has an issue.

share|improve this answer
add comment

There's something in between them acting as a bottleneck, and my guess is that it's Windows software routing. As a troubleshooting step, can I suggest that you take a problematic client, pop it onto the server subnet (change nothing else on it) and see what happens. You'll probably have to physically relocate it for this.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.