peter at crypt.nz
Thu Apr 21 20:26:18 CEST 2016
On Apr 21, 2016 9:14 PM, "Sergey V. Lobanov" <sergey at 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
Sounds like a very inefficient NAS you are using or have configured it in a
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 at lboro.ac.uk" <a.l.m.buxey at 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
> List info/subscribe/unsubscribe? See
More information about the Freeradius-Devel