On Tue, Jan 28, 2003 at 10:21:18AM -0800, Chris Lonvick wrote:
>We've talked about changing the TIMESTAMP and the HOSTNAME fields which
>will increase them. From that, we may be pushing the length of previously
>valid messages over the 1024 byte limit. Perhaps an explicit statement
>about the length of syslog messages would be appropriate in the
>syslog-sign ID?
As you stated in rfc3164 sec 6.1:
"Various behaviors have been seen on receivers that do
receive messages greater than 1024 bytes."
I'd prefer just specifying what a conformant sender/
receiver should do when it receives a message (or field)
larger than is expected.
Simply stating: "must not malfunction" may lead to
deployment/operational problems. When mpls/l2 vpns are introduced
to a network, l2 switches may see valid frames with size larger than
1500 bytes. A conformant switch (either older or misconfigured)
will exhibit the same behavior:
increment dot3StatsFrameTooLongs and discard.
>[snip] How about stating the the default maximum size
>is 1024 bytes but that may be increased to be the MTU between the device
>and the collector when using UDP? This would cover the expansion of the
>HOSTNAME and TIMESTAMP fields and allow all previously valid messages to
>be sent without having something truncate it or fragment it.
The message size might also be decreased by the discovered MTU
between the device and the collector as well.
I prefer that the minimum size a conformant
implementation must support be defined.
SNMP over UDP specifies a minimum message size of 484.
If one wants to support a larger msg size, just configure for it.
The same goes for switches these days too.
Otherwise why not just recommend a transport that has
path mtu discovery in cases where syslog msg length > 1024.
Regards,
Mike
