Proxy to two RADIUS Servers

[Alan DeKok]

Stefan A. wrote:
> 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.

  It's odd.  Provisioning things via Accounting-Request packets is not
part of RADIUS.

> 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

  Well... the *NAS* is supposed to generate accounting packets.  When it
does, you can forward them.

> - 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!

  Sure...

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

  It's ugly, and not a nice solution.

> 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.

  As I said earlier, you can use "radclient" to send any packet you
want.  You can use a Perl script to wrap radclient, and filter the
attributes.

> 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

  No... that's not a *required* flow.  You *can* proxy packets directly.
 See raddb/sites-available/robust-proxy-accounting

  It's up to *you* to configure the packet flow you want.  And *none* of
the above description shows accounting packets going to *two* different
locations, like you originally asked.

  Please keep a *consistent* story in your messages.

> 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.

  So... configure the server to do what you want.  If you want
accounting packets to go quickly to the optimizer, proxy them directly.
 If you want them to be copied elsewhere, *that* isn't time critical,
and can use the "detail" file.

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

  Ask vendors to not design && ship broken products.  But I've given up
hope on that.

  Alan DeKok.