I'm not sure how that would work ... the AAA process is a conversation that both sides participate in, your production server would churn along happily but how would your test server talk back to the client to keep the process going? Jake Sallee Godfather Of Bandwidth Network Engineer Fone: 254-295-4658 Phax: 254-295-4221 -----Original Message----- From: freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org [mailto:freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org] On Behalf Of Brian Candler Sent: Thursday, February 17, 2011 8:38 AM To: freeradius-users@lists.freeradius.org Subject: Parallel running RADIUS servers I wonder if anyone has implemented anything like the following, and if so, if they can share their experiences of how they did it. When rolling out a new RADIUS config, I would like to be able to run both the current and new configs side by side, processing the same packets in real time in both servers, and highlight if and where the responses differ. This would give a very high confidence level that the new config didn't break things in unexpected ways. (I already have an off-line test suite, which uses radclient to send a number of test cases to the development RADIUS server, but there is a lot of legacy traffic and I can never be sure that it the suite completely captures all possible cases) I can think of a few ways of implementing this: * Using bpf (like radsniff) to capture the live requests and responses. Forward a copy of the request to a second process, which would somehow be jailed to a loopback interface, and then compare the responses. * Have some sort of forking proxy, which takes one input packet and sends it to two places, A and B. It would take either the A or B response and return it to the client. It could even vote on them (e.g. Access-Accept takes precedence over Access-Reject) Some of the existing logic I work with makes use of the source IP address of the packet (i.e. Client-IP-Address), so a simple proxy which resends the packet would be a problem. I suppose I could put Client-IP-Address into a real AV. Anybody doing anything like this today, or know of any projects which do this? Thanks, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On 17/02/11 14:37, Brian Candler wrote:

I can think of a few ways of implementing this:

* Using bpf (like radsniff) to capture the live requests and responses. Forward a copy of the request to a second process, which would somehow be jailed to a loopback interface, and then compare the responses.

* Have some sort of forking proxy, which takes one input packet and sends it to two places, A and B. It would take either the A or B response and return it to the client. It could even vote on them (e.g. Access-Accept takes precedence over Access-Reject)

This is only going to work for the simpler authentication mechanisms - PAP and so forth. It won't work for EAP, because the server challenge state incorporates random numbers. Honestly, I think you are better off relying on proper testing & change control.