The server has IPv6 support in terms of it can send and receive RADIUS packets with IPv6, but lacks support in some modules which assumed NAS-IP-Address and Framed-IP-Address would always be IPv4. Do people have a preference for the default SQL schemas whether fields like NAS-IP-Address are modified to take either an IPv4 or IPv6 or whether we use distinct fields? The same goes for Framed-IP-Address and Framed-IPv6-Prefix. -Arran
On 21/07/13 12:36, Arran Cudbard-Bell wrote:
The server has IPv6 support in terms of it can send and receive RADIUS packets with IPv6, but lacks support in some modules which assumed NAS-IP-Address and Framed-IP-Address would always be IPv4.
Do people have a preference for the default SQL schemas whether fields like NAS-IP-Address are modified to take either an IPv4 or IPv6 or whether we use distinct fields? The same goes for Framed-IP-Address and Framed-IPv6-Prefix.
Distinct, particularly the Framed-* attributes - dual-stack clients are going to be very common. There might also be cases where the IPv6 Framed-* attributes are multi-valued, but I think that's going to have to remain site-specific for the time being - it's unclear how that will pan out in common use-cases.
On 22 Jul 2013, at 14:15, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 21/07/13 12:36, Arran Cudbard-Bell wrote:
The server has IPv6 support in terms of it can send and receive RADIUS packets with IPv6, but lacks support in some modules which assumed NAS-IP-Address and Framed-IP-Address would always be IPv4.
Do people have a preference for the default SQL schemas whether fields like NAS-IP-Address are modified to take either an IPv4 or IPv6 or whether we use distinct fields? The same goes for Framed-IP-Address and Framed-IPv6-Prefix.
Distinct, particularly the Framed-* attributes - dual-stack clients are going to be very common.
Ok. So we'll use a combination of NAS-IP-Address/NAS-IPv6-Address and Framed-IP-Addredd/Framed-IPv6-Address to identify NAS and clients. If users have issues with this, they can always remove on the attributes in authorize.
There might also be cases where the IPv6 Framed-* attributes are multi-valued, but I think that's going to have to remain site-specific for the time being - it's unclear how that will pan out in common use-cases.
Ok. That would be difficult to implement. In SQL especially. So maybe we'll just stick with single values for now. It may be helpful to have control attribute which, when present, gets used in preference to attributes in the request. Then administrators could identify the instance of the Framed-IPv6-Prefix they wanted to use to identify the device and: update { control:Framed-IPv6-Prefix := %{Framed-IPv6-Prefix[x]} } Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 22/07/13 14:40, Arran Cudbard-Bell wrote:
Ok. That would be difficult to implement. In SQL especially. So maybe we'll just stick with single values for now.
Yeah, definitely. TBH I keep wondering if a better approach to accounting long-term wouldn't be to keep live sessions in something NoSQL e.g. redis, then move them to SQL on session close, when the sum total of the data is known.
Phil Mayers wrote:
Yeah, definitely. TBH I keep wondering if a better approach to accounting long-term wouldn't be to keep live sessions in something NoSQL e.g. redis, then move them to SQL on session close, when the sum total of the data is known.
Yes. That allows for MUCH more performance. Some ISPs, tho, want to log all accounting packets. Others want to query live sessions via SQL. So any redes-enabled speedup would have to be site-specific, and configurable. Alan DeKok.
On Jul 22, 2013, at 9:51 AM, Alan DeKok <aland@deployingradius.com> wrote:
Phil Mayers wrote:
Yeah, definitely. TBH I keep wondering if a better approach to accounting long-term wouldn't be to keep live sessions in something NoSQL e.g. redis, then move them to SQL on session close, when the sum total of the data is known.
Yes. That allows for MUCH more performance.
Some ISPs, tho, want to log all accounting packets. Others want to query live sessions via SQL.
So any redes-enabled speedup would have to be site-specific, and configurable.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
We're working on a project with huge accounting needs and did run into some issues using the current SQL module and decided to write our own module to store accounting data and user authentication data in a nosql document database as JSON. I think this will become increasingly common and nosql/json seems to be a very natural fit for value pair data. -- Aaron
On Jul 22, 2013, at 10:17 AM, Aaron Hurt <ahurt@ena.com> wrote:
On Jul 22, 2013, at 9:51 AM, Alan DeKok <aland@deployingradius.com> wrote:
Phil Mayers wrote:
Yeah, definitely. TBH I keep wondering if a better approach to accounting long-term wouldn't be to keep live sessions in something NoSQL e.g. redis, then move them to SQL on session close, when the sum total of the data is known.
Yes. That allows for MUCH more performance.
Some ISPs, tho, want to log all accounting packets. Others want to query live sessions via SQL.
So any redes-enabled speedup would have to be site-specific, and configurable.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
We're working on a project with huge accounting needs and did run into some issues using the current SQL module and decided to write our own module to store accounting data and user authentication data in a nosql document database as JSON. I think this will become increasingly common and nosql/json seems to be a very natural fit for value pair data.
-- Aaron
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Just to clarify … there wasn't anything wrong with the rlm_sql module it was just a matter of scaling hardware to support the load on our end to do this with a traditional database. -- Aaron
participants (4)
-
Aaron Hurt -
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers