Optimize SMB on server to accomodate slow WAN link

[Guest]

Good morning,
I have a central office and two remote offices connected via Frame Relay.
The port speed at the central office is 512k and at the remotes, 256k. The
CIR is 32k at the remotes with bursting to 384k. Our remote offices do not
seem to get anywhere near the burst speed and queries to the Exchange and SQL
servers at the central office often timeout. Effective bandwith appears to
hover near the CIR with occational bursts to 120k. It has been suggested
that I reconfigure the Win2k servers to run SMB in raw versus block mode.
All I've been able to uncover in the KB are references to WindowsNT regarding
this issue.
Any pointers to KB articles describing how to configure Windows 2000 servers
for optimal WAN traffic communication would be greatly appreciated.
The carrier, ATT, analyzed sniffer traces and determined that the PVCs
appear configured correctly.
If you look at this scenario and have another idea of what might be going
on, I'd certainly like to hear what you have to say.
Thanks in advance for any ideas!
Jon : )

 

[Guest]

The lack of bursting is really a function of the carrier, and how over/under
subscribed their network is. I'd look at a few other things first but if at
the end of the day you thing you have it all sorted and it is still slow then
you'll just have to go for a higher CIR.

I'd get a protocol analyser (public domain version may be okay for starters)
and load it on a workstation that can be plugged into a hub (not a switch)
along side the router and then capture samples of traffic that are destined
for the far end subnet. I wouldn't be suprised if you see a lot of
Microsft-ds traffic humming away, especially if you have servers in the
remote offices. Advertising of shares/printers by workstations and servers
can really add to the background hum. This will then let you target "noisy"
computers. Make sure the routers are only passing IP traffic.

Make sure workstataions are not mapping drives or connecting to printers in
the central office that they do not need to be connecting to.

Think seriously about using Terminal Services or Citrix to deliver the SQL
applications.

Look at traffic prioritisation on the routers if they are capable. If you
can't do it on the routers (or if the carrier wants to charge a bomb for it)
consider a packet shaper (or similar device). SQL, Citrix (ICA), terminal
serices (RDP) all like a steady stream of responses from the server, if they
get held up you get timeouts etc. With prioritisation you can choose the
types of traffic that will get precedence over other stuff and that will stop
traffic such as SMTP and HTTP from swamping the sessions.

Packet shapers and Citrix servers can be pricey but a higher CIR will also
cost you. If your running HTTP and email over the links then you'll probably
need to look at the packet shaper first to get the traffic under control, you
would then consider the Citrix/TS solution to make better use of small
bandwidth rather than going to higher CIR.

An examples (case study if you like):

I look after a client that runs the full desktop via Citrix. They have no
servers on the remote sites whatsoever. A 20 workstation site runs fine with
512/128 (link/CIR). The bandwidth per workstation comes down to about 16K for
bigger sites, small sites, 5 workstations or less need a bit more, say 32K
each. Single user sites need a proper 64K (we use ISDN) connection. We are
currently moving the small/medium - less mission critical sites to VPN over
ADSL starting at 256K. They have a packetshaper in the central office and
this allows us to set ICA traffic to a priority 5, everything else get three
meaning that ICA packes will jump ahead in the queue to get out on the WAN.
It also lets us partition the link up so that no site can suck all the
capacity out of the central link unless there is nothing else needing it.
Workstations are all Win2K. We find a few workstations (usually ones that
were upgraded) that seem to be chatty using Microsoft-DS, they always seem to
be the ones that had a print share installed once upon a time in a different
life. We blow them away and reinstall them and they come good.
They use Telstra as their carrier (Australia). I've got to say they have no
problem bursting up to link speed at any time of day. That said, Telstra
wanted to charge an arm&leg to put prioritisation on the routers and hence
they lashed out $AUD20K+ for the PacketShaper, but I've got to say it has
been worth it. They run a 160 user network over 10 remote sites with three IT
staff.

Svend.