Forum Discussion

kend's avatar
kend
Icon for Altostratus rankAltostratus
Jan 28, 2016

iRule to Load Balance using Source IP

We have a application that we allow our customers to access from their location to our data center. The customers connect using a client, that we provide, for their local desktop. This client is similar to a RDP client, but does not contain any user unique information in the connection packet. The users connect through our LTM's to the servers on our internal network. The user's source IP is used for persistence on the LTM. The problem we have is the following.

 

If users connect from different source IP's, the sessions get load balanced correctly using least connections (member). But, if we have say 200 users connecting that are using the same source IP, they all go to the same server in the pool because of the source IP persistence. So, no matter how many servers are in the pool, all users go to the same server because of the same source IP used for persistence. Is there a way, using an iRule, to some how load balance these sessions even if they come from the same source IP but still maintain persistence?

 

application delivery
iRules

5 Replies

  • Lee_Payne_53457's avatar
    Lee_Payne_53457
    Icon for Cirrostratus rankCirrostratus
    Jan 28, 2016

    To do this you need to use universal persistence (UIE) and apply something like the following iRule.

     

    when CLIENT_ACCEPTED { persist uie "[IP::client_addr]:[TCP::remote_port]" }

     

    here's the SOL on how to configure UIE.

     

    https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7392.html

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 28, 2016

    Hi Ken,

     

    unfortunately no, since both requirements are absolutely mutual exclusive.

     

    Note1: Microsoft has a RD Session Broker, that would keep an eye on disconnected/reconnected TS sessions. By using this feature you wouldn't need persistence on your load balancer anymore.

     

    Note2: You may also have a chance to add additional information to the persistence table, if every user would use a slightly different FQDN to access the TS Farm (via TLS SNI Infomation). But even then it would require some very deep iRule codings to extract the used FQDN and use them for persistens records.

     

    Cheers, Kai

     

  • kend's avatar
    kend
    Icon for Altostratus rankAltostratus
    Jan 28, 2016

    Lee, In reference to your answer, and sorry I am not familiar with all the iRule parameters, is the [IP::client_addr] the source IP and [TCP::remote_port] the port the user's workstation used?

     

    Kai, This is not a standard RDP client. This client was written in-house and connects differently. So, RD Session Broker is not usable here.

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 28, 2016

    Good to know its your homegrown client. In this case you may ask your developers to integrate the old 

    Cookie: mstshash=username
    option into the client. By doing so you would be able to read the username and perform a username based persistent check on the very first TCP datagram...

    Note: It seems that Microsoft has discontinued the support the option for their RDP clients. Or at least made it very unrealiable...

    Cheers, Kai

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 29, 2016

    Hi Ken,

     

    you could actually check, if your homegrown RDP clients already sends a cookie, using the code below...

     

    when CLIENT_ACCEPTED {
    TCP::collect
}
when CLIENT_DATA {
    if { [TCP::payload] contains "Cookie" } then {
        log -noname local0.debug "RDP Session provides the Cookie = [findstr [TCP::payload] "Cookie: " 8 "\n"]"
    } else {
        log -noname local0.debug "RDP Session does not provide the Cookie"
    }
    TCP::release
}

    Cheers, Kai