On Thu, Aug 25, 2022 at 01:48:50PM +0100, Stuart Henderson wrote: > On 2022/08/25 14:38, Claudio Jeker wrote: > > On Thu, Aug 25, 2022 at 09:23:01AM +0100, Stuart Henderson wrote: > > > On 2022/08/24 18:47, Denis Fondras wrote: > > > > Le Tue, Aug 23, 2022 at 06:28:12PM +0200, Claudio Jeker a écrit : > > > > > I noticed that the "connection from non-peer" message can fill the > > > > > log and > > > > > be so chatty that it is hard to see the other messages. The system I > > > > > see > > > > > this on is a bit special since it gets hammered by incorrectly > > > > > configured > > > > > systems. Maybe other people find this message helpful. If so please > > > > > speak up now because I think the message does not add much info and > > > > > should > > > > > be skipped unless verbose logging is used. > > > > > > > > > > > > > I agree with this change (I also have a log full of this message). > > > > > > btw I like the log message, it shows me if I messed up and forgot to add a > > > session, or if someone else messed up and added a session without > > > arranging > > > it (or typoed the address, etc). But I only allow port 179 connections > > > from > > > possible candidates for peering (IXP peering lans etc) - I consider that > > > good practice anyway - and means it isn't too noisy. > > > > True but in my case of a route collector misconfigured neighbors try to > > connect more or less every other second. This results in a lot of log > > chatter that is very annoying. > > > > Maybe bgpd needs to keep some state so that the message is not shown over > > and > > over again. > > Looking at the actual log message I see -v isn't much more noisy for bgpd > anyway, so it's not a problem to use that.
-v enables a lot of LOG_DEBUG messages which syslog will drop by default. This is one of the few LOG_INFO that is based on -v. Now if you log with -v it will be more noisy (but since I run bgpd often with -v I try to keep the noise down). > I thought about keeping state, but there are a lot of potential non-peers > that might try to connect, which could result in a a lot of addresses > for bgpd to keep track of :) We could use a fixed upper limit and LRU to keep the number of connections small. -- :wq Claudio
