Proxy to two RADIUS Servers

[Alan DeKok]

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.

  Alan DeKok.