Proxy to two RADIUS Servers

[Stefan A.]

Alan,

maybe there are some more information needed to understand my 'millisecond'
accounting thing and my anxiety for missing Accounting packets:

Imagine a Mobile Operators network.
Mobile users are often online for only some seconds using 3G/3G networks, so
we face short term IP address assignments to subscribers.
These Users might be routed via network elements, which are optimizing
content for the particular mobile handset devices. Optimizing might involve
e.g. downsizing images or removing 'unneeded javascript comments' in html
documents, which speeds up the link because of less data to be send.
If the user does not want to be 'optimized' he/she might configure this on a
self service page.

Here comes the provisioning part:
At the beginning of an IP session, we will get the assignment "IP address to
Subscriber Number" including a Filter-ID, advising pointing to the correct
optimization. This will be done, using RADIUS Accounting
This is not odd and several vendors of such systems are using this
mechanism.


But what will happen, if the Accounting Packets are gone? Have a look at a
single Framed-IP-Address over the time:

- If the START does not reach the Optimizer, User will get a default profile
- If STOP does not reach the Optimizer, no problem
- If STOP and START does not reach the Optimizer, user will get the setting
of the predecessor (Not good!). This might happen, if the link to the
optimizer is broken for some minutes 

At some Operators, Access to Mailboxes is given, using this mechanisms,
which might lead to wrong Access to wrong eMails... not good again!


I know, that this is hard to process...

Therefore my former question, whether it is possible to send START and STOP
directly, but only buffer the STOP packets for later transmission. This will
prevent constantly changing Subscribers, using a particular IP address,
during the phase, where the link is back up. Only sending /old/ stop packets
will delete assignments at the optimizer, even if the user just came online,
but this is much better, than wrong assignments.


The milliseconds thing:

The signaling flow (2G/3G Network): SGSN -> GGSN -> FR -> Optimizer
Still looking for a single Framed-IP-Address:
1 PDP Context creation Request from SGSN to GGSN
2 Access Request to FR
3 Access Accept to GGSN
4 Acct Start to FR
5 write in detail file
6 Acct ACK to GGSN
7a1 Listener catches the Acct Start and sends it to Optimizer
7a2 Acct ACK from optimizer
7b1 GGSN sends PDP Context Creation Accept to SGSN 
7b2 SGSN allows IP Packets to pass the link
 
Depending on system load and number of concurrent accesses, the 7a' and 7b'
might change their sequence, because they are decoupled. This will possibly
start a TCP Session via the optimizer, which will most likely use the
default profile.
But back to the eMail disaster: dropping a STOP and delaying the next START
for the same IP, will give the user Access to the wrong mailbox.

I hope this describes a little bit, why I'm asking possibly odd questions.

Any ideas on how to solve this problem beside looking for an new job or
industry?


Regards
Stefan

> -----Original Message-----
> From: freeradius-users-
> bounces+a.freeradius=premit.de at lists.freeradius.org [mailto:freeradius-
> users-bounces+a.freeradius=premit.de at lists.freeradius.org] On Behalf Of
> Alan DeKok
> Sent: Tuesday, June 15, 2010 10:36 AM
> To: FreeRadius users mailing list
> Subject: Re: Proxy to two RADIUS Servers
> 
> 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