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