Hello, Is there any plans to implement rfc7499 in freeradius? -- wbr, Sergey
Hi,
Is there any plans to implement rfc7499 in freeradius?
is there an issue you are currently facing that it resolves? ;-) note one of the authors of the RFC....... 8-) but, according to http://networkradius.com/radius-standards-compliance/index.html , the answer is not yet - and given the requirements on the other servers.... you might not find it helps you... alan
Hi, Alan In our setup radius-reply (access-accept) is very long (>4096 bytes), because we need to send the information for each end customer device is subscriber's context. 21.04.2016, 11:35, "a.l.m.buxey@lboro.ac.uk" <a.l.m.buxey@lboro.ac.uk>:
Hi,
Is there any plans to implement rfc7499 in freeradius?
is there an issue you are currently facing that it resolves? ;-)
note one of the authors of the RFC....... 8-)
but, according to http://networkradius.com/radius-standards-compliance/index.html , the answer is not yet - and given the requirements on the other servers.... you might not find it helps you...
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- wbr, Sergey
On Apr 21, 2016 9:14 PM, "Sergey V. Lobanov" <sergey@lobanov.in> wrote:
Hi, Alan
In our setup radius-reply (access-accept) is very long (>4096 bytes),
because we need to send the information for each end customer device is subscriber's context. Sounds like a very inefficient NAS you are using or have configured it in a bizarre way. For our deployment which handles 500k+ broadband customers the Access Accept is 500 bytes. It could have been smaller if we had chosen shorter plan names as a number rather than something human readable that are configured on the NAS and customers are mapped to and shorter unique subscribe ids rather than the 20 digit one we use. The response packet size was all determined by how complicated we wanted to make it. I was recently asked by capacity planners when I thought we were going to need to move from a 1gb lan port to 10gb. My response was never as there juat simply isn't that much traffic generated by radius. 1500 bytes for the request, accept, two starts and the acks. A 4k Access Accepts sounds like you're doing something incredibly complex when I'm sure something simple will work more effectively.
21.04.2016, 11:35, "a.l.m.buxey@lboro.ac.uk" <a.l.m.buxey@lboro.ac.uk>:
Hi,
Is there any plans to implement rfc7499 in freeradius?
is there an issue you are currently facing that it resolves? ;-)
note one of the authors of the RFC....... 8-)
but, according to
http://networkradius.com/radius-standards-compliance/index.html , the answer
is not yet - and given the requirements on the other servers.... you might not find it helps you...
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- wbr, Sergey - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Apr 21, 2016, at 2:26 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Apr 21, 2016 9:14 PM, "Sergey V. Lobanov" <sergey@lobanov.in> wrote:
Hi, Alan
In our setup radius-reply (access-accept) is very long (>4096 bytes),
because we need to send the information for each end customer device is subscriber's context.
Sounds like a very inefficient NAS you are using or have configured it in a bizarre way. For our deployment which handles 500k+ broadband customers the Access Accept is 500 bytes. It could have been smaller if we had chosen shorter plan names as a number rather than something human readable that are configured on the NAS and customers are mapped to and shorter unique subscribe ids rather than the 20 digit one we use. The response packet size was all determined by how complicated we wanted to make it.
I was recently asked by capacity planners when I thought we were going to need to move from a 1gb lan port to 10gb. My response was never as there juat simply isn't that much traffic generated by radius. 1500 bytes for the request, accept, two starts and the acks.
A 4k Access Accepts sounds like you're doing something incredibly complex when I'm sure something simple will work more effectively.
SAML or PCRF maybe? A fair few NAS also support dynamic firewall rules. Much nicer to do this stuff at the edge where you can distribute the load between hundreds or thousands of devices, than have central firewall that can break or become overloaded. The obvious solution to the firewall issue without resorting to massive packets is a hybrid approach between collections of boilerplate rules that you can reference, and user specific rules. -Arran
On Apr 21, 2016, at 5:13 AM, Sergey V. Lobanov <sergey@lobanov.in> wrote:n
In our setup radius-reply (access-accept) is very long (>4096 bytes), because we need to send the information for each end customer device is subscriber's context.
Then you're doing something wrong. FreeRADIUS doesn't (yet) support RFC 7499. Even if it did, none of the NAS / switch / AP products support RFC 7499. So having support for it in FreeRADIUS doesn't help. The correct solution is to simplify your rules so they don't require 4K Access-Accept packets. Alan DeKok.
participants (5)
-
A.L.M.Buxey@lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Peter Lambrechtsen -
Sergey V. Lobanov