Re: [Syslog] [OPSAWG] Syslog message to Remote Rerver

William Herrin <bill@herrin.us> Tue, 26 February 2013 21:28 UTC

Return-Path: <wherrin@gmail.com>
X-Original-To: syslog@ietfa.amsl.com
Delivered-To: syslog@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE6821F8586; Tue, 26 Feb 2013 13:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBuvakHKVm2Z; Tue, 26 Feb 2013 13:28:27 -0800 (PST)
Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5221F8578; Tue, 26 Feb 2013 13:28:27 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id pb11so4398475veb.33 for <multiple recipients>; Tue, 26 Feb 2013 13:28:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GZC7QG4J+OXNRvqSeLMLoz95zqCRLdIC6UrW1o0S/sY=; b=oanJNVgGWFFgfjSLBc6pZ7gt5/lUvhPSmI4cTP6m5w0byjrrdzc8sjEK2/gRmci4CW gDpvs8419gZfjyNac9vsYlWHrtwXwt2VYAW/QiSGKNuosu1KCfyPguSquK8J7DVeNxd7 TJrooaf4DYZdXKvgGUlDBdDjpqvEOwN23OBxPhhZSTMBBvqk/hDGYzpBVM9Dzrb+RTb5 YfjINbQuCcsoWu0cys2w6Lw1toIpAtIioeuD9ELQNyALiqIxAfaWnbJYrsV/fLp8A8Sj 1Fg40AZcUdCA1ttQiQRwuGL4B1uG6isQ93iHYALx4c2i5AmGoutpteGa7A+k9Zz0Z1cF UaZg==
X-Received: by 10.52.99.1 with SMTP id em1mr10913470vdb.48.1361914106536; Tue, 26 Feb 2013 13:28:26 -0800 (PST)
MIME-Version: 1.0
Sender: wherrin@gmail.com
Received: by 10.52.179.40 with HTTP; Tue, 26 Feb 2013 13:28:06 -0800 (PST)
In-Reply-To: <94383E83699D0F4D9040CEFAE204B4071A0238@xmb-aln-x11.cisco.com>
References: <94383E83699D0F4D9040CEFAE204B40719E2A5@xmb-aln-x11.cisco.com> <1A3C0CDF-552E-4C93-A38B-44EFCB3DA52F@gmail.com> <94383E83699D0F4D9040CEFAE204B4071A0238@xmb-aln-x11.cisco.com>
From: William Herrin <bill@herrin.us>
Date: Tue, 26 Feb 2013 16:28:06 -0500
X-Google-Sender-Auth: c_xcA49D0xYBV_S350uZWDTq7p0
Message-ID: <CAP-guGW7SVatK8LFd0L+Bx=0vuLGVM1ZJ833xUNcBDmUH82qLw@mail.gmail.com>
To: "Aditya Dogra (addogra)" <addogra@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailman-Approved-At: Wed, 27 Feb 2013 08:09:05 -0800
Cc: Christopher LILJENSTOLPE <liljenstolpe@gmail.com>, "syslog@ietf.org" <syslog@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [Syslog] [OPSAWG] Syslog message to Remote Rerver
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2013 21:28:28 -0000

On Sun, Feb 24, 2013 at 11:47 PM, Aditya Dogra (addogra)
<addogra@cisco.com> wrote:
> My point was since syslogs are tried up mostly with
> the base/OS layer , hence it comes pretty much earlier
> than the management plane comes up . And remote
> logging comes in picture when management plane
> comes up . Should syslog's be so reliable that we
> buffer them (in case of udp protocol) or maintain
> sessions (in case of tcp) (and maintain sessions
> during failover/switchovers) so that once management
> plane comes up , we send previous messages also.

Hi Aditya,

I have had servers fail with processes blocked on a syslogger stuck
trying to forward logs to a network syslog server that was no longer
available. Or trying to output logs to a serial console at 9600 bps.
The syslog blocks and then everything else blocks waiting for the
syslog.

The equipment's overall reliability comes _way_ before the reliable
transmission of any particular log line. I want the logger to quickly
dispose of the message and then accept the next one so that the
processes generating those logs don't

A colleague of mine has something he calls "reliable UDP". The idea
goes like this:

1. Transmit the message with a sequence number AND add it to a local
ring buffer.
2. If the receiver receives an out-of-sequence message, it requests
the retransmission of the missing sequence numbers.
3. If the sender receives a retransmission request, it examines the
ring buffer and retransmits if the message is still available.
4. The ring buffer overwrites its own tail as additional messages are
sent. If retransmission isn't requested before the message is
overwritten then the message is lost.


That sort of thing might be handy for syslog messages, but it the
logger is trying much harder than that, I think it risks getting in
the way of the much more important processes generating the logs.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004