net.inet6.ip6.log_interval: use ppsratecheck(9) inernally

[melifaro]

Thank you for working on this!
I certainly agree that there should be a nice logging facility that allows to print the debug data while not having an impact on production and avoid polluting dmesg / the user.

With that in mind, I have a meta-question:

• does any of these messages actually bring any value to the user?

There's already a counter that we're incrementing which someone can monitor and build alers on. Is there a need to actually provide the details via printing it to the kernel buffer?

On the technical side for the generic debugging - I'd rather have a macro that can abstract all this ppsratecheck details, so the person adding the debug can simply use such macro.

[kaktus]

This review is a response for a comment made by mjg in D38644 in which I added a sysctl to completely disable such logging on per vnet basis.
The whole logging section appeared in 1999 in one of the KAME commits and since then wasn’t particularly maintained apart of adding vnet support some time ago.
ppsratecheck is used like this is other parts of the kernel, for example in linuxkpi, and apparently is a preferred way to limit certain actions on time basis.

As usual the answer to the meta question is complicated :-)
I believe that the messages has some value because they may suggest misconfiguration, they probably also have some value during debugging of network issues too. Ideally we should have a way to log such event once but it may get overly complicated, as the questions is once per what? Interface? Address? Packet relation?
The problem comes when a volume is too high and the source is outside of the control of the local admin, then it’s just a nuisance apart of additional cycles wasted on processing it later.
From the operations point ot view It may be beneficial to change it to log(9) as it’d be easier to distinguish in the logs.

OTOH, I don’t hold strong opinion on the internals of such logging, maybe the defaults should be bumped higher and it should be disabled by default.

[zarychtam_plan-b.pwste.edu.pl]

As the person from whose inspiration D38644 was created, I can only refer to the annoyance and usefulness of messages generated this way. Currently, setting the net.inet6.ip6.log_interval to a high value does the trick of preventing log spamming, but it is not intuitive and easy for the average user to find without searching the source code. There is only a mention of this sysctl in inet6(4). Perhaps digging the mailing list archives could bring more ideas on how to get rid of the irritating "cannot forward src ...." from dmesg(8).
These types of forwarding error messages can be still useful to some extent, especially when a FreeBSD-based IPv6 router is deployed for a small LAN, it is easy, for example, to detect errors in the RA configuration. On the other hand, in the case of an edge router, which cannot do much with packets with a link-local source address received on the link from upstream, disabling the logging of these extinguished packets is an optimal solution (Yes, such packets do circulate in the Internet!). In this case, it will be even better to ignore them instead of sending "ICMP6, destination unreachable, beyond scope...", but I am far from demanding it nor want to put any burden on committers who would struggle with the implementation.

[kaktus]

Make all virtualised variables static and only expose ip6_log_ratelimit() function.