Proxy to two RADIUS Servers
aland at deployingradius.com
Tue Jun 15 10:35:55 CEST 2010
Stefan A. wrote:
> I have to provision the DEST1 using live session information, and DEST1 only
> needs the information during the current IP, but if I set up:
> 1. manual Proxy from sites-enabled/default file: all ACK Packages are
> delayed to the NAS, if DEST1 is not there, and the NAS possibly retries...
> not good!?
That's why the other virtual servers exist.
> 2. if I use'copy-acct-to-home-server', I have to keep track of the packet,
> to not send too old information to the DEST1. In strange cases, where DEST1
> is down for hours, I will keep sending packets of old sessions, until I went
> through all left files...
Uh... the server keeps track of the packet. And the whole point of
accounting is to store data. i.e. to send *all* traffic, even after the
home server has been down for hours.
If you don't like this, you can change the proxying rules to *ignore*
accounting packets that are older than X hours. See Acct-Delay-Time.
> 3. I could possibly mix it: I might send START and STOP packets to DEST1. In
> case DEST1 is not available, I put all STOP Packets into the
> 'copy-acct-to-home-server' files. After DEST1 is back up, all previous ended
> sessions will be cleared and new sessions will overwrite the possibly old
> status in the DEST1 databases ..., but this might not work, as 'redundant'
> does not take updates on a attribute list.
That sounds complicated.
> also... 'copy-acct-to-home-server' seems to delay the forwarded packet at
> about 0.2 to 0.5 seconds...
> I checked to use a ramdisk for this, but it did not speed up the process...
> I sometimes see 0.05 but often 0.4
I don't understand why that's a problem. Do you really need
millisecond resolution on accounting packets?
> Again, nobody cares about start packets after the session has been
> terminated, but fast delivery is critical...
Why? No one else needs millisecond response time for accounting packets.
More information about the Freeradius-Users