CSS not LB to available RDP services

[Carl King]

We have 20 term servers behind a 11500 with RDP connection limits set to 4 because of heavy resource utilization on the application running there. With max connections at 6 the CSS could potentially go over but we thought it would distribute them more evenly. Instead it is overloading one server and leaving the remaining servers untouched.

So far we have made a few changes to try to minimize the complexity of the config and still achievve our objective. We have dropped sticky sessions, changed LB to RoundRobin from least conn, and removed the flow-inactive timer and made it permanent.

In one troubleshooting scenario we had 5 people attempt connections to the VIP and each got a connection to service number 5 but the flows were not in the flow table and the CSS connection counters did not reflect 5 connections.

Has anyone seen this before?

[Carl King]

Here is the initial config.

All services active.

owner PMN-RS-term

content PMN-RS-RDP

add service PMN-RS-term01

add service PMN-RS-term02

add service PMN-RS-term03

add service PMN-RS-term04

add service PMN-RS-term05

add service PMN-RS-term06

add service PMN-RS-term07

add service PMN-RS-term08

protocol tcp

port 3389

add service PMN-RS-term09

add service PMN-RS-term10

add service PMN-RS-term11

add service PMN-RS-term12

add service PMN-RS-term13

add service PMN-RS-term14

add service PMN-RS-term15

add service PMN-RS-term16

add service PMN-RS-term17

add service PMN-RS-term18

add service PMN-RS-term19

add service PMN-RS-term20

advanced-balance sticky-srcip

sticky-inact-timeout 128

flow-inactive-timeout 8

balance leastconn

vip address 10.10.225.67

active

The recent config change has removed;

advanced-balance sticky-srcip

sticky-inact-timeout 128

flow-inactive-timeout 8

balance leastconn

in favor of;

flow permanent port1 3389

balance roundrobin

[Zach Seils]

How long ago did you make these changes? Did you clear the sticky-table after you made them?

Why did you make the RDP port (3389) permanent?

~Zach

[Carl King]

We didn't explicitly clear the sticky table. We suspended the content rule and found the sticky table was empty when we looked at it after activating the rule again. Is that effectly the same?

The connections are coming in from call center reps who load a flaky 16bit Foxpro app from the terminal server. If the RDP session gets disconnected prematurely, the user cannot get back into the Foxpro application and the DB admins have to go into the FP server and manually clear their hung session each time. Permanent prevents the "post disconnect maintenance" issue. When they are finished for the day, they log off. We are forced to clear the flow tables late at night or early in the AM.

A workaround for the stupid user syndrome.