FreeRADIUS 2.0.0-pre2 has been released

Jakob Hirsch jh at plonk.de
Fri Sep 14 17:53:52 CEST 2007


Quoting Alan DeKok:

>> As I understand the virtual servers, it is possible to have all vservers
>> listen to the same ip/port socket, but have different client
>> configurations. Is that right?
>   Hmm... hadn't thought of doing it that way.  It could be possible.

Meaning "try it and get back to list when you have the results"? :)

>> And would that be a sensible thing to do in a high traffic environment
>> (many million requests per day)? I'd think that every request would have
>> to be processed by all the vserser instances only to decide that the
>> request has to be discarded by most of them.
>   No.  The idea would be do tie a client to a virtual server.  Then, all
> requests from that client would be sent to one, and only one virtual server.

That's what I want.

Allow me to elaborate on that:

a global listen section:

listen {
   ipaddr = 10.0.0.1
   type = auth
}

two virtual servers:

server foo {
   client 10.1.0.1 {
     secret = secret1
  }
   autz...
   auth...
}

server bar {
   client 10.2.0.1 {
     secret = secret2
   }
   autz...
   auth...
}

So 10.1.0.1 and 10.2.0.1 will both send their requests to the server's 
address 10.0.0.1, and freeradius will determine by itself (with little 
performance penalty) the proper virtual server for the requests?

>   And no matter what, a request is handled by *one* virtual server.  You
> seem to be saying that a request will be handled by many in parallel.
> That will never happen, for the reasons you point out.

Ok, that's what I wanted to read :)

But what happens with requests that could be processed by more than one 
virtual server? Like, in the example above, if they had both the same 
client definition (same ip-address, same secret). Random, sequentially 
selected (e.g. first match wins), config error, doomsday?


(Hm, it's really time to set up a test installation... )






More information about the Freeradius-Users mailing list