(RADIATOR) DSL Auth setup
Hugh Irvine
hugh at open.com.au
Wed Aug 15 18:55:43 CDT 2007
Hello Adam -
From what you describe, it sounds like you need to take the
difference between the amounts reported in the accounting updates.
Ie. when processing an accounting update, subtract the amounts
reported in the previous update to get the amount for the period
between the updates.
regards
Hugh
On 15 Aug 2007, at 21:21, Adam Armstrong wrote:
> Hi Hugh,
>
> Thanks for the examples, i spent quite a while last night looking
> at the things in goodies/. It's probably going to be quite a bit
> mroe involved than i had hoped getting this all setup correctly!
>
> I really wish i could spent the cash on paying someone else on
> setting it all up, but it's hard enough getting the cash to
> actually pay for radiator! ;)
>
> The last thing I'm struggling with is accounting. I know how to set
> everything up to account to files or sql, but what i cant' work out
> is how to do per-hour accounting.
>
> I'm guessing it's either something really obvious that i've missed,
> or just impossible due to the way radius works?
>
> For example, i want to be able to calculate the bandwidth usage for
> a client between the hours of 0800 - 0000, when it's entirely
> possible that their session will stay up for months at a time. I've
> currently got the server kicking out radius accounting updates
> every 15 minutes, but they seem to be rolling updates? is it
> possible to get a just the amount transferred in the last 15 minutes?
>
> Thanks,
> adam.
>>
>> Hello Adam -
>>
>> We have many customers who use MySQL very successfully, and all of
>> our SQL examples in the Radiator distrubution also use MySQL.
>>
>> There is script to set up the example MySQL schema in "goodies/
>> mysqlCreate.sql".
>>
>> In my consulting practice I generally tend to organise things
>> around functional groups based on Client clause(s) with Identifier
>> (s).
>>
>> Something like this:
>>
>> ......
>>
>> # define Client clauses with Identifiers
>>
>> <Client 1.1.1.1>
>> Identifier SomethingMeaningful
>> .....
>> </Client>
>>
>> <Client 2.2.2.2>
>> Identifier SomethingMeaningful
>> .....
>> </Client>
>>
>> <Client 3.3.3.3>
>> Identifier AnotherUsefulTag
>> .....
>> </Client>
>>
>> <Client 4.4.4.4>
>> Identifier AnotherUsefulTag
>> .....
>> </Client>
>>
>> ......
>>
>> # define AuthBy clause(s) with Identfier(s)
>>
>> <AuthBy SQL>
>> Identifier CheckDatabase
>> ......
>> AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \
>> from SUBSCRIBERS \
>> where USERNAME = %0
>> AuthColumnDef 0, Password, check
>> AuthColumnDef 1, GENERIC, check
>> AuthColumnDef 2, GENERIC, reply
>> ......
>> # add common reply attributes
>> AddToReply ......
>> ......
>> </AuthBy>
>>
>> ......
>>
>> # define Handlers
>>
>> <Handler Client-Identifier = SomethingMeaningful>
>>
>> <AuthBy GROUP>
>> AuthBy CheckDatabase
>>
>> AddToReply ......
>>
>> </AuthBy>
>>
>> </Handler>
>>
>> <Handler Client-Identifier = AnotherUsefulTag>
>>
>> <AuthBy GROUP>
>> AuthBy CheckDatabase
>>
>> AddToReply ......
>>
>> </AuthBy>
>>
>> </Handler>
>>
>> .......
>> Groups of reply attributes for a single user can all be
>> specified in the field called "REPLYATTR" in the database.
>>
>> All of the common reply attributes can be specified in the
>> AddToReply in the AuthBy SQL clause, and reply attributes that
>> depend on each Handler can be specified in the AddToReply in the
>> AuthBy GROUP.
>>
>> See section 5.29 in the Radiator 3.17.1 reference manual ("doc/
>> ref.html").
>>
>> BTW - we are available on a contract basis for design,
>> implementation and training as required.
>>
>> regards
>>
>> Hugh
>>
>>
>>
>> On 14 Aug 2007, at 21:00, Adam Armstrong wrote:
>>
>>> Hugh Irvine wrote:
>>>>
>>>> Hello Adam -
>>>>
>>>> Can you give us a bit more detail on your requirements?
>>>>
>>>> You mention a "flat file mess" - do you need to use flat files
>>>> or would you prefer to use SQL or LDAP or something else?
>>>>
>>>> There are many example configuration files in the "goodies"
>>>> directory of the Radiator 3.17.1 distribution.
>>>>
>>> I'd prefer to use MySQL, but it seemed like a nightmare with
>>> FreeRadius. A previous employer of mine used Radiator, so i
>>> thought it might be worth looking to see if Radiator could do
>>> what we want somewhat more sanely.
>>>
>>> I initially have 2 basic type of account, a standard internet
>>> account and an account which gives access to a VRF.
>>>
>>> First, the internet service has two types, static and dynamic,
>>> i'm sure this is nothing special :)
>>>
>>> Dynamic like :
>>>
>>> test at vostron.net User-Password == "testing"
>>> Tunnel-Type = L2TP,
>>> Tunnel-Medium-Type = IP,
>>> Tunnel-Password = BLAH,
>>> Tunnel-Server-Endpoint = x.x.x.x,
>>> Tunnel-Client-Auth-ID = BLAH,
>>> Service-Type = Framed-User,
>>> Framed-Protocol = PPP
>>>
>>> and static the same with the addition of IP details
>>>
>>> Framed-IP-Address = 89.21.240.0,
>>> Framed-IP-Netmask = 255.255.255.255,
>>>
>>> Is there a way radiator could generate these additions of a
>>> particular field in the database has a CIDR block in it or
>>> something?
>>>
>>> It's also possible that static customers could have one or more
>>> additional subnets routed to them, which would require cisco
>>> avpairs. Are there any best practices on handling that?
>>>
>>> VRF access accounts are a bit more complicated, and need two
>>> extra cisco-avpairs to put them in the right vrf and give them
>>> the correct ip unnumbered interface like this :
>>>
>>> blah at mpls.vostron.net User-Password == "blah"
>>> Tunnel-Type = L2TP,
>>> Tunnel-Medium-Type = IP,
>>> Tunnel-Password = blah,
>>> Tunnel-Server-Endpoint = x.x.x.x,
>>> Tunnel-Client-Auth-ID = BLAH,
>>> Service-Type = Framed-User,
>>> Framed-Protocol = PPP,
>>> Framed-IP-Address = 10.255.254.1,
>>> Framed-IP-Netmask = 255.255.255.255,
>>> Cisco-AVPair = "ip:dns-servers=10.10.0.1",
>>> Cisco-AVPair += "ip:route=10.255.254.1 255.255.255.255",
>>> Cisco-AVPair += "ip:route#1=10.1.0.0 255.255.0.0",
>>> Cisco-AVPair += "ip:route#2=10.0.0.0 255.0.0.0",
>>> Cisco-AVPair += "lcp:interface-config=ip vrf forwarding
>>> XXXXXXXX",
>>> Cisco-AVPair += "lcp:interface-config=ip unnumbered
>>> loopback 60001"
>>>
>>> These accounts can also have a bunch of extra routes, as they're
>>> often used to provide backup to a private leased line.
>>>
>>> The final thing i want to be able to do (that i can remember!) is
>>> to pool our LNSes. For example, static and dynamic customers
>>> could get assigned lns 1.1.1.1 1.1.1.2 or 1.1.1.3 in a round-
>>> robin fashion, but i need to be able to lock vrf accounts to one
>>> or maybe two LNSes (otherwise every VRF has to be present on
>>> every LNS, which is a pain!)
>>>
>>> I'm basically just looking for a sane database schema and
>>> radiator config setup to handle this. An existing management
>>> interface would be ace, but I doubt any exist, and i'll probably
>>> end up writing one anyways!
>>>
>>> Kind Regards,
>>> Adam Armstrong
>>> Vostron Limited
>>>
>>>> On 14 Aug 2007, at 10:05, Adam Armstrong wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to sort out an authentication for our L2TP ADSL
>>>>> delivery to replace the current FreeRadius + Flat Files mess.
>>>>>
>>>>> Are there any front-ends out there which handle this stuff
>>>>> nicely? I also need to pass the occasional extra Cisco-AVPair
>>>>> (for clients in other VRFs).
>>>>>
>>>>> Any example Radiator configs or pointers to some decent
>>>>> documentation would be great!
>>>>>
>>>>> Thanks,
>>>>> adam.
>>>>>
>>>>> --
>>>>> 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 read the reference manual ("doc/ref.html")?
>>>> Have you searched the mailing list archive (www.open.com.au/
>>>> archives/radiator)?
>>>> Have you had a quick look on Google (www.google.com)?
>>>> Have you included a copy of your configuration file (no secrets),
>>>> together with a trace 4 debug showing what is happening?
>>>> Have you checked the RadiusExpert wiki:
>>>> http://www.open.com.au/wiki/index.php/Main_Page
>>>>
>>>
>>> --
>>> 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 read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/
>> archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
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.
More information about the radiator
mailing list