Hello, On Thu, 16.03.2006 at 09:21:18 -0700, Theo de Raadt <[EMAIL PROTECTED]> wrote: > > > [ "better" logging on interfaces, for whatever that means ]
> Claudio: > > Link state changes are generally not logged by the kernel. > > Only lmc(4) and sppp(4) tend to fill the syslog with "useless" status > > messages. The other interfaces I use seem to "behave". well, in general I agree with you, but I think that the special nature of WAN lines warrants special treatment, too. > > If link state changes need to be logged than it should be done in an > > interface independent way so that all interface will profit from it. I already try to log it using ifstated, but that doesn't work too well, and also doesn't give sufficient detail about the cause of the problem. Not useful enough to hold the resulting logs under the nose of a carrier's tech supporter. > I agree with Claudio that network interfaces should be as silent as > possible. They are network interfaces, not chatter boxes. Ummm... when you are most "always up" like in a LAN, that's probably right, but when you're in a more-or-less (un-)reliable WAN situation, with WAN lines also having other problems as well, you might think otherwise. And it's not only the question about getting packets in and out in the face of network failure, but also the question of whom to blame, and how/where to look to fix the real problem. ifstated is too coarse, or I'm still not using it correctly. > > It should be no issue to track the interface state in userland by > > listening on the routing socket. > > man route, and read up on 'show' I could also track bgpd's "lost connection to peer" messages, but that doesn't help me too much either - was it line failure, remote end's reboot, network overload, misconfiguration on either (which?) end, etc. pp ? Best, --Toni++
