Parallel running RADIUS servers

Sallee, Stephen (Jake) Jake.Sallee at umhb.edu
Thu Feb 17 16:05:29 CET 2011


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 at lists.freeradius.org [mailto:freeradius-users-bounces+jake.sallee=umhb.edu at lists.freeradius.org] On Behalf Of Brian Candler
Sent: Thursday, February 17, 2011 8:38 AM
To: freeradius-users at 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




More information about the Freeradius-Users mailing list