Hi! We are using FreeRADIUS as service provider. For certain realms we need to forward the access request to customer specific radius servers while the rest is authenticated on our radius. This work in the following ways: 1) "user@example.net" wants access. 2) Our NAS tries to authenticate "example.net". 3) "example.net" is a realm that needs to be forwarded to a customer specific server so our radius sends a reply containing attributes (like the IP) that tells the NAS which specific radius server to use. This is implemented by a local radius user named "example.net" with the specific set of reply attributes. 4) The NAS authenticates the user using the customer radius. The other case is as follows: 1) "user@example.com" wants access. 2) Our NAS tries to authenticate "example.com". 3) "example.com" is a realm that should be authenticated locally so the radius server returns a reject. 4) The NAS then tries a second time using "user@example.com" and sucessfully authenticates the user. As you can imagine the second case leads to a notably number of access rejects in the statistics of the server. Monitoring the rate of rejects alone no longer is useful to monitor the health of the system as these rejects are expected by design. Now we are thinking about a solution and came up with the idea of preventing a statistics update for these rejects. A new internal attribute (e.g. FreeRADIUS-Inhibit-Stats-Update) would be added to the request and the statistics update function would ignore requests that have this attribute set. Setting that attribute in unlang would be easy as it happens in a dedicated virtual server in our case. Does this sound like a good solution for our problem? Could that be useful for others as well (say: a pull-request on Github)? Thanks! -- Stefan