Greg Sarsons wrote:
>
> On Mon, 2001-12-10 at 09:23, Pierre Fortin wrote:
> > Greg Sarsons wrote:
> > >
> > > > > Is anyone using or has used mdk 8.1 as remote syslog? I'm trying to
> > > > > figure out why there seems to be gaps in the logs on the 8.1 machine.
> > >
> > > It logs all the packets I'm seeing which is good but it looks like the
> > > router is not logging properly :(
> >
> > The router must have a sequence number on each log entry for you to notice this,
> > or is there some other means...?
> >
> > Ways for a router to fail to log remotely include:
> > - the path over which to send the log data is temporarily down
> > - logging packets may be dropped by intermediate nodes
> >
> > Logging is done blindly AFAIK -- send and hope the logger got it... so if
> > another router is in the path next to the logging host, that local router can
> > time out its ARP cache which will cause an incoming log message to be converted
> > to an ARP request to repopulate the ARP cache... the problem being that the log
> > entry is not retried; hence lost... If logging from a particular router is
> > critical, then the logging host should be local to avoid this situation.
> >
> > HTH,
> > Pierre
> >
>
> Well I hope my firewall is not dropping any packets. It is one hop
> away, 15 feet of twisted pair, through the firewall to the syslog
> machine. Firewall has no indication that it is dropping packets.
>
> Actually, I'm thinking this am that the router depending on the load
> does not log to syslog right away.
>
> Greg
router-------firewall----------------sysloghost
log_msg->
ARPentry?
yes: forward-> log_msg_OK
no: convert_to_ARP->
(log_msg lost)
<-ARPreply
The firewall may be dropping the packets if it expires its ARP cache and
converts any new packets (syslog) to an ARP to repopulate the cache. If so, you
should see ARP request/reply exchanges with no other traffic immediately
following. Unfortunately, this "convert packet to an ARP and wait for the
sender to retransmit" was a [Cisco] implementation detail way back to avoid
maintaining any state for any traffic stream, and allowing the end-system to
recover; and there is no requirement to indicate the number of such packets lost
-- part of networking "overhead"...
Delayed logging by the router is possible; but that usually comes at the cost of
losing visibility during problem states... so not sure that would be a wise
thing to do.
Pierre
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
