Forum Discussion

boudjel_189273's avatar
boudjel_189273
Icon for Nimbostratus rankNimbostratus
Feb 25, 2015

Session Broker and F5 Weird stuff

hi all,

 

we implemented on a pre-production environement this architecture :

 

8 x 2008R2 TSE , all VMs on ESXi 5.5, setup in a FARM 2 x 2008R2 Session Broker in cluster mode 1 x 2008R2 DC 1 x F5 big IP , pool with the 8 nodes

 

we ran few tests to check the load balancing to all TSE all worked well and we moved to production

 

we are now migrating our clients from an old TSE farm to this new one each clients can have between 10 to 30 users that connect with rdp client to the new farm they all use the virtual IP of the F5 to access the farm we migrated 3 clients so far (around 40 users)

 

the weird thing that is happening is that every day all users sessions are redirected to one TSE only of the farm and every day it is a different TSE for example : could be TSE5 today for all clients and all users sessions and tomorrow could be TSE8 for no reasons..... all the others TSE are not in use but available !!!

 

when i try to open 30 test users sessions in the new farm using the same way as our clients all test sessions are correctly balanced in the farm using the 8 TSE

 

i have no clue what is causing this behaviour to not balanced sometime and when i try it all is working well....

 

any idea will be much appreciated thanks

 

3 Replies

  • Hi boudjel,

    did you configure it according to the deployment guide (including least conn and msrdp based persistence)?

    You can run a trace on the F5 to filter the traffic from the client and look after the RDP header values. If the first 8 characters do not vary, it could happen all requests persist to the same pool member depending on the very first selection.
    tcpdump -i 0.0:nnnp -s 0 -w /var/tmp/capture_ts001.cap host   
    

    This can be validated as well by monitoring the persistence table.

    watch -d tmsh show ltm persist persist-records mode msrdp   
    

    There is a kown issue in case of using routing domains. Please see SOL15695 for details.

    Another possible reason could be the direct path between the client and the real servers. As the session broker indicates the real server IP (as far as I understand) the client connects directy.

    The virtual server is bypassed and does not increase the concurrent connection. So least conn load balancing method will pick the next best member in pool with least number of current connections (please see the pool statistics).

    It would be great to keep us posted on your findings.

    Thanks, Stephan

    PS: There is another related open thread on this subject here on DC.

  • Hi Stepan,

     

    much appreciated for you help...

     

    i tried to watch live the persistence table msrdp i think this is exactly where to look because i can see that the username can appear as: - the real username sometimes like : user001 - the domain name like : mydomain

     

    therefore i think all users are connected using the same domain name and of course are load balanced to the same Terminal server

     

    we are trying to use a diferent method : source_addr do you think it is a good way to go ?

     

    thanks

     

    • StephanManthey's avatar
      StephanManthey
      Icon for Nacreous rankNacreous
      Hi boudjel, perhaps I can give an advice next Wednesday - end of business day - after meeting a customer with a similar issue. By now I have no clue how to modify the mstsc client to insert the proper parameters. Thanks, Stephan