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