Hi, Ok. I have been configuring SMS devices for 3,5 years now and from customer 0. to customer ~40'000. And here is what I know about SMS devices and bandwith management. (at the beginning there is some simple stuff). Fist you can set default parameters that will be applied to all subscribers and these are defined under: subscriber default dns primary 1.2.3.4 dns secondary 4.5.6.7 ip address pool rate-limit rate 450 burst 10000 This is context based (defined per each context (Virtual Router) separetly and applies only to subscribers bound to this context durning binding). It is also lower priority than radius, if SMS gets any attributes from radius - they are applied. >From radius you can send these parameters with attributes: 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 ([EMAIL PROTECTED]). (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" <[EMAIL PROTECTED]> To: "Toomas K�rner" <[EMAIL PROTECTED]> Cc: "Gu�bj�rn S. Hreinsson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: "Toomas K�rner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> 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" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >>> 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 [EMAIL PROTECTED] >>>> To unsubscribe, email '[EMAIL PROTECTED]' with >>>> 'unsubscribe radiator' in the body of the message. >>> >>> === >>> Archive at http://www.open.com.au/archives/radiator/ >>> Announcements on [EMAIL PROTECTED] >>> To unsubscribe, email '[EMAIL PROTECTED]' with >>> 'unsubscribe radiator' in the body of the message. >>> >> > > === > Archive at http://www.open.com.au/archives/radiator/ > Announcements on [EMAIL PROTECTED] > To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
