I have a two MPS4 server farm on Win 2K server with Web interface and CAG 4. Users connect through the CAG to access a published IE window. The IE connects over a site-to-site VPN to a server in another state to run a .NET application. There is only a single T1 WAN connection provided for the farm environment. Users have long complained about delays, sluggishness issues when using the app. I've looked at Perf graphs and can't really see a bottleneck on the physical server machines themselves (although I do sometimes see spikes in the CPU and Disk queues of the primary server but they go down afterwards). I'm wondering if the lag users are see is due to running every bit of traffic over a single T1? Would it make sense to upgrade to a T3 instead or perhaps dedicate another private T1 for the VPN traffic itself thereby keeping it separate from the ISP's T1?
Are your internal users also running via the CAG? If so then you are creating a "lollypop" effect in your DMZ which may slow up your traffic due to additional packet scans and routing. Firstly if this is the case, remove this unless there is a business reason for it. Remember you are already running a IPSec tunnell site-to-site so encapsulating your traffic in SSL also is redundant to me anyway.
Secondly get some WAN statistics and see if your WAN is in fact saturated or maybe you are experiencing another issue with your WAN. Look at implementing QoS on that link or maybe WAN Acceleration.
Cheers
Jase
No internal users, these are all external remote users coming in through the CAG in the DMZ.
The WAN isn't saturated but I do see some periods of certain spikes around peak time. The highest I've seen the charts for the T1 hit in terms of incoming traffic is 935Kbps
Hi Jackson,
I am confused. The usual setup would consist of your CAG in the DMZ and then your Presentation Servers sitting behind it in the same Data Center.
Is there something I am missing?
How are you measuring your bandwidth usage?
Most methods (eg SNMP polling) give AVERAGE figures, and inevitably the short-term peak figures will be noticibly higher... this is very true when you have interactive users.
So of you are using 60% of link ON AVERAGE, then I'll pretty well guarantee that, for regular short periods (maybe 30 seconds at a time) the link is over-full. Typical causes are printing & file transfers.
How many external users are we talking about here, and how "busy" are they? (power-users? typing docs?)
Paul
Jason, yes the CAG is in the DMZ of the firewall and the Presentation Servers are sitting in the private zone behind the firewall.
Paul, the ISP I am hosting with provides a daily, weekly, monthly and yearly graph that shows all max and min traffic, bandwidth usage etc. You can definitely see the trends by that. Users are not doing much, just opening a published IE app that connects over a VPN to an web application in another remote location (out of state).
Yes, those ISP provided graphs will be "average graphs", probably based on 1 minute or 5 minute periods, which, in terms of playing "spot the peaks" doesn't REALLY help that much!
Yes, you'll see average usage trends, but that doesn't telly you that, for a 15 second period, the link was clogged, and everyone just sat there waiting.....
(The M25 motorway around London is very busy, and at peak time can grind to a halt. But "on average", taken over 24 hours, it shows no traffic problems :-) )
Paul,
Yes I see what you mean. Even though the graphs on the T1 are broken down Daily, Weekly, Monthly and Yearly I sometimes find it a little daunting to keep track of what is what. Based on the setup I described, with a single T1 that is responsible for funneling Citrix traffic, site to site VPN traffic from Checkpoint to other firewalls and from Nortel appliance to another Nortel appliance (about 3 IPSec VPNs total right now)...would you say it could possibly be a WAN problem? Upgrading the WAN to high bandwidth isn't a problem but I don't know what that would do for the latency of having a VPN connection as opposed to a dedicated circuit.
Well, of course, if you go to a faster pipe, the latency will usually drop, simply because the serialisation delays are lower.
Or are you implying that a fatter pipe would need to use a different "technology"?
paul