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