FreeRADIUS 2.X.X small functionality extensions

[Peter Lambrechtsen]

We are an ISP with around 800k subs and are running 2.1.12 since that's
what comes with RHEL 6.5 and use perl for the slightly more complex things
you can't easily do with unlang.

I was running performance testing against our ldap database last week using
a custom JMeter sampler I built to make the radius calls using tinyradius
as the client. Managed to get up to 760tps where a transaction was one
access request and two accounting starts (so 2280rps). I suspect that the
performance hit was coming from jmeter as those numbers smashed anything
the bngs could throw at us and the cpu never went above 8% so I am happy
enough.

So it's really a matter of how important testing the solution is. For us it
is very important so now I have a full functional and non functional test
script in jmeter... it's ugly but gives me what I wanted.

Cheers

Peter
On 5/06/2014 5:42 AM, "Arran Cudbard-Bell" <a.cudbardb at freeradius.org>
wrote:

>
> On 4 Jun 2014, at 17:08, Kostas Zorbadelos <kzorba at otenet.gr> wrote:
>
> >
> > Hello,
> >
> > let me be more specific to display the need.
> > We operate DSLAMs of various vendors (we have at least 3 now and noone
> > knows if that number will grow in the future).
> > The BRAS/BNG terminating devices send a NAS-Port-Id as in the following
> > examples:
> >
> > NAS-Port-Id -> Physical access ID (parsed form)
> > ------------------------------------------------
> > (HUAWEI)
> > <#VOIOT_LEFKTRA_D_HUA_10261 atm 0/1/0/40:8.35%Up:975kbps Down:1582#> ->
> > 10261:0/1/0/40
> > <#KYKLA_EMPORIO_D_HUA_9440 atm 0/12/0/54:8.35%Up:947kbps Down:4846#> ->
> > 9440:0/2/0/54
> > <#THESS_KALAM_D_HUA_13115_ONU_9502 atm 0/2/0/7:8.35#> -> 13115:0/2/0/7
> > <#THESS_FINIK_D_HUA_9732_ONU_9543 atm 0/1/0/57:8.35%Up:1023kbps Do#> ->
> > 9732:0/1/0/57
> > <#LAKON_ELAIA_D_HUA_10157_ONU atm 0/0/0/59:8.35%Up:1023kbps Down:1#> ->
> > 10157:0/0/0/59
> > <#LASIT_MOCHLOS_D_HUA_14154_KV atm 0/0/0/37:8.35%Up:1023kbps Down:#> ->
> > 14154:0/0/0/37
> > <#CHALK_PSAKOUDIA_D_HUA_14214_DLC atm 0/1/0/1:8.35%Up:511kbps Down#> ->
> > 14214:0/1/0/1
> > <#KERKY_POTAM_D_HUA_9857_DLC_7073 atm 0/9/0/9:8.35%Up:1023kbps Dow#> ->
> > 9857:0/9/0/9
> >
> > (ALCATEL)
> > <#KEFAL_ARGOSTOLI_D_ALU_13748_KV atm 1/1/01/47:8.35#2671024780> ->
> > 13748:1/1/1/47
> > <#ACHAI_EGLYKADA_D_ALU_14296 eth 1/1/01/42:835#2610621234> ->
> > 14296:1/1/1/42
> > <#ATTIC_PENTELI_D_ALU_13822_KV eth 1/1/01/12:835#> -> 13822:1/1/1/12
> > <#THESS_COSMO_D_ALU_14419_ONU_8523 atm 1/1/01/03:8.35#2310476377> ->
> > 14419:1/1/1/3
> >
> > The parsed form is the string we want to extract and use it later
> > against an LDAP repository containing ports to verify the port status
> > and make decisions based on that. We have reached in a regex containing
> > more than 8 groups. Also, as you can see, some DSLAMs send initial zeroes
> > in front of numbers describing DSLAM port/slot.
>
> You can strip those out trivially in a regex...
>
> Say you had /1/01/01/12
>
> Your regex would be
>
> /0?([0-9]+)/0?([0-9]+)/0?([0-9]+)/0?([0-9]+)
>
> https://www.debuggex.com/r/sgPccw67Z_fviF9u
>
> The optional 0s are consumed before the capture group data starts.
>
> In the examples above there still only appears to be 5 bits of data being
> pulled out.
>
> For v2.x.x the 0 stripping stuff can be done in a bunch of ways without
> requiring extra code, so that's definitely not going to be added.
>
> Alan has final on the number of capture groups and whether they'll be
> increased for v2.x.x. I suspect they won't be as it's in feature freeze.
>
> It's the sort of thing that would be quite nice to define at build time
> TBH. Instead of increasing it for everyone, as there is a performance
> penalty.
>
> > Given the fact that our LDAP repo will contain the parsed forms I
> > describe could you provide an alternative config to express the desired
> > functionality?
> > I know I can develop a specific module for the port parsing (have it
> > parse and store the value in a specific attribute of my choice) but I
> > found it more elegant to have a simple extension in the already provided
> > functionality of the core server. This will also allow me to have it in
> > config files (changing the expression as needed in the future). I also
> > think others can find it useful.
> > Finally, I would rather not use rlm_perl or rlm_python (which would be my
> > choice). Performance in our environment is critical, we host more than
> > one million subscribers.
>
> That's pretty small for an ISP TBH, but sure, throwing rlm_perl into the
> mix is probably a bad idea, and the GIL hurts rlm_python's performance in
> a multithreaded environment.
>
> > As I said I would not like to maintain seperate patches. I understand
> > the feature freeze of 2.x.x branch but we will not run 3.x in our
> > environment for now, we focus on stability.
>
> Sure. I'm assuming that's because you don't have the facilities to properly
> test your RADIUS service, and don't want to introduce changes where you
> can't fully determine what the impact will be.
>
> > In my opinion, I do not find
> > it a "big" change or feature but of course I am not the "owner" or even
> > master of the sources so I cannot provide an authoritative judgement on
> > the matter.
>
> Well the LDAP code doesn't suck, you'd probably get a marked performance
> improvement just from using the new rlm_ldap module.
>
> In general the policy language is more efficient, and there's a greater
> number of validation checks on startup. It's generally a lot more
> consistent with v2.x.x.
>
> But i'm not here to sell it to you. Upgrade when you want... or don't.
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS Development Team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140605/1d002f94/attachment-0001.html>