Forum Discussion
Ok - done some deeper packet inspection and all seems to be in line with the RFC. One authentication dialogue below (afraid it doesn't format well):
Packet Type State ID 110 Request 162 113 Challenge AVP: l=18 t=State(24): 5d5772375d556b2f478e8a00b3c8166c162 117 Request AVP: l=18 t=State(24): 5d5772375d556b2f478e8a00b3c8166c12 119 Challenge AVP: l=18 t=State(24): 5d5772375d556b2f478e8a00b3c8166c12 126 Request AVP: l=18 t=State(24): 5d5772375c546b2f478e8a00b3c8166c52 128 Challenge AVP: l=18 t=State(24): 5d5772375c546b2f478e8a00b3c8166c52 130 Request AVP: l=18 t=State(24): 5d5772375f536b2f478e8a00b3c8166c50 131 Accept50
Just to be clear, there's nothing wrong with the workings of radius either through the F5 or not - people are being authenticated ok - about 4 million individual authentications per day across our two wireless controllers. We want to load balance so we can add more capacity easily. The controllers will only point to one IP address so using the F5 seemed to be a perfect solution. As I say, the authentication bit is working fine, it's just that all the traffic goes to one or other of the radius servers.
Clearly the state AVP is being used and I know if I turn on Datagram LB the requests seem to get distributed evenly so I may try the Radius profile with persist-avp. I wanted to test this before applying it to a live service but it seems that radtest does not work in the same way as the wireless controllers so I may have to just go for it (in a suitable 'quiet' time)