Forum Discussion

teknet7_237497's avatar
teknet7_237497
Icon for Nimbostratus rankNimbostratus
Dec 09, 2015

irule: HTTP traffic to the same real server as Radius session

Hello Team,   LTM should loadbalance both Radius (Authentication/Accounting) and also HTTP traffic to the same real server. Radius traffic should be balanced based on Calling Station id attribute....
application delivery
iRules
LTM
teknet7_237497's avatar
teknet7_237497
Icon for Nimbostratus rankNimbostratus

Hi Ed,

 

Thank you for the link.

 

I have read multiple documents but still not sure if that is possible. I would use multiple VIPs with the same address and match across services. Services: radius authentication, radius accounting, http.

 

I would need to:

 

  1. After receiving Radius Access-Request (no Framed-IP-Address yet at that stage) i would need to balance based on Calling-Station-ID (persistent profile universal with irule extracting Calling-Station-ID).

     

  2. Then i am receiving Radius Accounting-Request with Framed-IP-Address i would still do the same balancing based on Calling-Station-ID - and land on the same real server. But this time since i do have Framed-IP-Address attribute i would like to extract it and create a persistence entry (irule for Framed-IP-Address)

     

  3. Then i am receiving HTTP traffic from IP address which is the same as mentioned Framed-IP-Address. What would be the configuration for that VIP ? What kind of persistence rule and irule ?

     

Could you clarify what config would you recommend for all 3 VIPs - what persistence profile and irule ? What would be the content of persistence table ? Both via Calling-Station-ID and IP address ? I need to be sure that once i do receive subsequent accounting messages they are gonna land on the same real server as original access-request. But also all subsequent HTTP request from the same ip as framed-ip-address should land on the same real server.

 

Thanks, Michal

 

Red_19's avatar
Red_19
Icon for Nimbostratus rankNimbostratus
Dec 25, 2018

Michal did you find a solution for this problem ? I have the same situation with 2 VIPS(same IP different ports) one has MSRDP and the other has Source IP, the requirement is the same as yours. Traffic first comes on the VIP with SourceIP persistence and which ever node the traffic goes to that should be the same node it should go when the client connects to the VIP that has MSRDP persistence. Both the VIPs have the same pool members(same IP different ports)