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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html