What is the purpose of the default accounting-on/off queries?

[Nathan Ward]

> On 12/10/2021, at 6:25 AM, Antônio Modesto <modesto at hubsoft.com.br> wrote:
> 
> 
> On 09/10/2021 23:28, Nathan Ward wrote:
>>> On 10/10/2021, at 6:11 AM, Terry Burton <terry.burton at gmail.com> wrote:
>>> 
>>> On Sat, 9 Oct 2021 at 16:03, Nathan Ward <lists+freeradius at daork.net> wrote:
>>>> Ah yep. It will be sending Accounting-On when a VRF (routing-instance) gets the first customer, or has its configuration changed in certain ways (depending on the version). I have this very problem.
>>> Another issue with the MX series that we've discovered the hard way is
>>> that they can continue to send Accounting-On requests without backoff
>>> *forever*, until the request is acknowledged. So if you are "ignoring"
>>> them you must still send an Accounting-Response.
>> That sounds what I would want to happen, so I don’t think that’s an MX issue. You want to be sure that Accounting-On/Off is being handled.
>> But yes good point - you want to make sure you respond to any requests that you “ignore”, rather than filter them out and *really* ignore them :-)
>> 
>>> As well as the VRF issue, you can experience this in global context if
>>> the database connection is configured with a query timeout and the
>>> bulk session update does not complete in time.
>> It seems very odd to me that you would have an Accounting-On/Off query taking anywhere near what a DB query timeout is. That doesn’t sound like an MX issue - that sounds like some index tuning is required, or perhaps the query is doing a large amount of work that could be handled another way?
>> 
>> --
>> Nathan Ward
>> 
>> 
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 
> 
> Can I just edit my sites-enabled/default accounting section to look like this?
> 
> if (Acct-Status-Type != Accounting-On) {
> 
>     -sql
> 
>     -sqlippool
> 
> }

Yeah you probably could - though I guess I think you’re better off solving the problem with the NAS (BNG) rather than working around it in RADIUS.
For example, if you do the above, you now need to:
- ensure that your sqlippool timers are appropriate so your IPs free up if your BNG crashes so you don’t run out of IPs
- ensure that you have some out of band process to close sessions if your BNG crashes - when will the stop time be?

As I say.. it technically functions, but you’re making a trade off. You’re proposing that to avoid changing the BNG which is misbehaving [1], you change the RADIUS system which is doing exactly as it’s supposed to. That’s just adding technical debt - but - your network :-)


[1] Juniper would say misconfigured, but really their RADIUS code is a bit wrong

--
Nathan Ward