No subject

RB-Rate-Limit-Rate = 450
RB-Rate-Limit-Burst = 10000
#################
#VENDORATTR 2352 RB-Rate-Limit-Rate 10 integer
#VENDORATTR 2352 RB-Rate-Limit-Burst 11 integer
#################
Now, from the SW release 6 (I think) is available such a administrative
command like:
[context]SMSDEVICE#reauthorize ?
  acct-session-id  Reauthorize by account id
  subscriber       Reauthorize by subscriber name
Which basically means that you can initialize "reauthorization" proccess by
yourself. Durning that proccess SMS sends Access-Request to radius, receives
reply, applies any attributes received to subscriber "on filght". So, if it
receives now that Rate has to be 2000 (Rate limit rate (Kb/s)) then it will
start rateing by 2000.
Fist they had some "problems" - Reauthorization Access-Request didn't
include all attribuest that were present in initial Access-Request but that
got fixed. I have tested Release 6.0.3.0 and it works fine.
And even better, you can initialize reauth by sending SNMP set. It is
basically possible to get the status of a session (Acct-Session-Id), kill it
and set it to reauth by just reading, seting to 1 or 2 with the same OID and
instance calculated from Acct-Session-Id.
So, to make it all work you just have to build a portal that authenticates
portal login against your userdatabase and against session database (to
verify http source ip), edit user record in userdatabase in desired way,
then get session-id (I'd prefer that to a username) from session-db,
snmp-set SMS device for that session reauth. PS. if this authentication
fails - nothing happens and user will not get disconnected, just no
attributes will be applied, so it is quite safe to try even with online SMS.
I even built db that contained sessions that had their attributes different
than per-product. In there I keep also user-desired timeouts (up to what
time they desired such parameters). Then it is easy to build a piece of SW
that looks up the table, finds "expired" sessions/users, sets their
user-record back to original in user-db and snmp-set's SMS for reauth of
their session.
I didn't send any code because they are all very old and bad and most of it
is rubbish. If I clean it up one day, maybe I'll send it then. Meanwhile, if
somebody is interested in launching something like it will have to ask
directly over mail (tomkar at estpak.ee).
(There's lot more that you can find out in 3,5 years in dsl buisness :).)

Rgds.
Toomas Kärner

----- Original Message -----
From: "Hugh Irvine" <hugh at open.com.au>
To: "Toomas Kärner" <tomkar at estpak.ee>
Cc: "Guðbjörn S. Hreinsson" <gsh at centrum.is>; <radiator at open.com.au>
Sent: Thursday, June 26, 2003 2:33 AM
Subject: Re: (RADIATOR) How to restrict the Dial Up on Bandwith.



Hello Toomas -

Not really a Radiator issue, but very interesting none the less.

And I am sure that there are many subscribers to the list who enjoy
this level of discussion as much as I do.

Please feel free to continue posting such interesting material.

regards

Hugh


On Wednesday, Jun 25, 2003, at 18:27 Australia/Melbourne, Toomas Kärner
wrote:

> Hi,
>
> I have successfully built and tested sord of portal for users where
> they can
> SET their desired bandwith for desired ammount of time and it applies
> to
> whole connection (not just to certain direction) with RedBack SMS. It
> uses
> SNMP set to initialize user "reauthentication" and then SMS applies new
> parameters "on flight" without droping any sessions. Juniper ERX
> family is
> capable of doing such things even based on access-lists (you can just
> order
> 2Mbps to sertain site) but it uses COPS/LDAP and so on and is much more
> harder to set up. I haven't spent much time with it also. This is how
> we
> will address users problem to spend extra money and get more.
> Anyway .. not more a radiator list issue ...
>
> Rgds.
> Toomas Kärner
> ----- Original Message -----
> From: "Guðbjörn S. Hreinsson" <gsh at centrum.is>
> To: "Toomas Kärner" <tomkar at estpak.ee>; <radiator at open.com.au>
> Sent: Wednesday, June 25, 2003 11:10 AM
> Subject: Re: (RADIATOR) How to restrict the Dial Up on Bandwith.
>
>
>> Cheers,
>>
>> We perform matching 10 min. after the hour every hour. This will
>> analyze
>> the logs, import it into an sql server and it is then compared to the
> radius
>> logs which are also in an sql server.
>>
>> I think it should scale pretty good, if you have performance problems
>> use
>> standard techniques, like breaking up the logging in the Collector
>> etc.
>>
>> The problem is tracking live sessions and configuring your whole
>> access
>> system so that as little as possible is lost about sessions. Radius
>> is not
>> the best protocol to insure no session information is lost.
>>
>> Not really very heavy...
>>
>> Flat fee and traffic shaping sounds good, do you think your customers
>> would be willing to pay for keeping the extra bandwidth after they
>> have
>> consumed the included bandwidth?
>>
>>
>> Rgds,
>> -GSH
>>
>> ----- Original Message -----
>> From: "Toomas Kärner" <tomkar at estpak.ee>
>> To: <radiator at open.com.au>
>> Sent: Wednesday, June 25, 2003 5:30 AM
>> Subject: Re: (RADIATOR) How to restrict the Dial Up on Bandwith.
>>
>>
>>> Hi,
>>>
>>> I wonder up to what point you are able to deal with such a log's? We
> have
>> at
>>> the moment around 5.5M records per month in our DSL customers log
>>> and to
>>> match that to a NetFlow log about 114TB (that's their generated
>> traffic)...
>>> huhh .... How far this kind a solution scales? Anyway, we give (test
>> period
>>> at the moment) to one certian site 2Mbps but to any else accoring to
>>> the
>>> original bandwith (256kbps to 512kbps) but we don't account for
>>> ammount
> of
>>> data - everything is flat fee. This feature is basically traffic
>>> shaping
>>> based on access-lists. Hardware used is Unisphere/Siemens/(and now
>>> already)Juniper ERX family. RedBack's will also have that feature for
>> their
>>> SMS series by the end of summer and SE (SmartEdge) is already
>>> capable of
>> it
>>> (I think - haven't tested jet the latest software).
>>>
>>> Rgds.
>>> Toomas Kärner
>>>
>>> ----- Original Message -----
>>> From: "Guðbjörn S. Hreinsson" <gsh at centrum.is>
>>> To: <mick at tsn.cc>; <radiator at open.com.au>
>>> Sent: Sunday, June 22, 2003 1:25 PM
>>> Subject: Re: (RADIATOR) How to restrict the Dial Up on Bandwith.
>>>
>>>
>>>>
>>>> We use Cisco Netflow to measure traffic, we exclude certain sites
>>>> so that traffic does not appear in the logs. We then match radius
>>>> accounting packets and netflow logs to generate rating data for
>>>> billing.
>>>>
>>>> We don't speed limit customers when they pass their limits, but
>>>> bill them for the extra download.
>>>>
>>>>
>>>> Rgds,
>>>> -GSH
>>>>
>>>>> I am not sure if this soultion is done with Radiator or not. I have
>>> noticed
>>>>> many ISP's offering
>>>>> ADSL connections with free traffic to certain web sites. They are
> also
>>> speed
>>>>> limiting customers when
>>>>> they run passed their download limit but not counting the traffic
>>>>> to
>> the
>>>>> free websites.
>>>>>
>>>>> Anyone know how the radius accounting is done. Or does anyone know
>> what
>>>>> product they are using to do this.
>>>> -
>>>> ===
>>>> Archive at http://www.open.com.au/archives/radiator/
>>>> Announcements on radiator-announce at open.com.au
>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>> 'unsubscribe radiator' in the body of the message.
>>>
>>> ===
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.


===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.