[RADIATOR] F5 and Radius - Load Balancing Not Working

[Ullfig, Roberto Alfredo]

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 - rullfig at uic.edu
ACCC Research Programmer

From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Ullfig, Roberto Alfredo
Sent: Monday, July 27, 2015 7:33 AM
To: Ernst Oudhof; radiator at 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 - rullfig at uic.edu<mailto:rullfig at uic.edu>
ACCC Research Programmer

From: Ernst Oudhof [mailto:e.oudhof at mailfrom.nl]
Sent: Friday, July 24, 2015 2:54 PM
To: Ullfig, Roberto Alfredo; radiator at open.com.au<mailto:radiator at 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-bounces at open.com.au<mailto:radiator-bounces at open.com.au> [mailto:radiator-bounces at open.com.au] On Behalf Of Ullfig, Roberto Alfredo
Sent: vrijdag 24 juli 2015 14:54
To: radiator at open.com.au<mailto:radiator at 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-bounces at open.com.au<mailto:radiator-bounces at open.com.au> [mailto:radiator-bounces at open.com.au] On Behalf Of Ullfig, Roberto Alfredo
Sent: Thursday, July 23, 2015 1:41 PM
To: radiator at open.com.au<mailto:radiator at 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 - rullfig at uic.edu<mailto:rullfig at uic.edu>
ACCC Research Programmer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150729/50e67b92/attachment-0001.html