So why exactly is an irule needed? We see the WISM make an initial connection to the Radius server and that connection remains in place for a long time (according to the F5). I don't see a TCP socket between the WISM and the Radius server so I don't understand what's going on. UDP packets are supposed to be connectionless but with Radius there's some stickiness going on and I don't know how that is accomplished. I've read this here:
https://f5.com/zh/resources/white-papers/message-based-load-balancing but it doesn't really answer in detail. Even if we force the server offline on the F5 the WISM continues to send all the packets to the original Radius server. --- Roberto Ullfig - rull...@uic.edu ACCC Research Programmer From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Ullfig, Roberto Alfredo Sent: Monday, July 27, 2015 7:33 AM To: Ernst Oudhof; radiator@open.com.au Subject: Re: [RADIATOR] F5 and Radius - Load Balancing Not Working Thanks a lot for this info! I gathered we needed to create an iRule. We contacted F5 support and they weren't helpful afaik. --- Roberto Ullfig - rull...@uic.edu<mailto:rull...@uic.edu> ACCC Research Programmer From: Ernst Oudhof [mailto:e.oud...@mailfrom.nl] Sent: Friday, July 24, 2015 2:54 PM To: Ullfig, Roberto Alfredo; radiator@open.com.au<mailto:radiator@open.com.au> Subject: RE: [RADIATOR] F5 and Radius - Load Balancing Not Working Roberto, I wrote the following iRule some time ago to loadbalance based on calling-station-id. It loadbalances based on a hash of the calling-station-id so it doesn't require a state table on the F5. It works fine with wired and wireless auth since the calling-station-id is the mac-address of the client in these cases. when CLIENT_ACCEPTED { set calling_station_id [RADIUS::avp 31 "string"] #log local0. "Radius type: [RADIUS::code] Calling-station-id: $calling_station_id" if { $calling_station_id != "" } { set pool [LB::server pool] binary scan [md5 $calling_station_id] w1 hash set picked [lindex [active_members -list $pool] [expr $hash % [active_members $pool]]] pool $pool member [lindex $picked 0] #log local0. "pool $pool member [lindex $picked 0] selected" } else { log local0. "no calling-station-id in radius packet" } } Regards, Ernst From: radiator-boun...@open.com.au<mailto:radiator-boun...@open.com.au> [mailto:radiator-boun...@open.com.au] On Behalf Of Ullfig, Roberto Alfredo Sent: vrijdag 24 juli 2015 14:54 To: radiator@open.com.au<mailto:radiator@open.com.au> Subject: Re: [RADIATOR] F5 and Radius - Load Balancing Not Working It appears to be acting like this because we are using mschapv2. Has anyone gotten an F5 to properly load balance packets when using mschapv2? It would appear that we need to create special irules to split the packets. From: radiator-boun...@open.com.au<mailto:radiator-boun...@open.com.au> [mailto:radiator-boun...@open.com.au] On Behalf Of Ullfig, Roberto Alfredo Sent: Thursday, July 23, 2015 1:41 PM To: radiator@open.com.au<mailto:radiator@open.com.au> Subject: [RADIATOR] F5 and Radius - Load Balancing Not Working We've configured our F5 per their documentation. We are testing with one WISM and seeing all the connections go to one Radius server in the pool (10 servers). Rarely, a different server is chosen. The F5 shows "connections" being evenly distributed but I don't know what "connections" means because the number of Radius authentications is much greater (170 connections vs thousands of radius connections from over 1200 different users). It seems like the F5 is creating a tunnel and the WISM is just sending everything through it. We've contacted F5 support but were wondering if this could be an issue with the WISM. Has anyone seen this before? Thanks! --- Roberto Ullfig - rull...@uic.edu<mailto:rull...@uic.edu> ACCC Research Programmer
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
