Hi, An SNMP engine won't truncate an octet string to fit within 484 bytes to my knowledge.
If the limitng factor is the sender, the sending engine probably just won't send it; it might tell the requesting application it cannot handle that size message, but that would be an implementation-specific detail that is not part of SNMP. If you want to have the syslog engine trim the data before sending it to the SNMP engine, you'll need to write that into the syslog standard or recommendations; the syslog engine would need to determine the max message size that the sending SNMP and receiving SNMP engines can handle. SNMP does not provide an API for the syslog application to use to get this info, although SNMPv3 messages contain a max message size field to advise other snmp engines with which it communicates about an engine's limits. If the limiting factor is the snmp receiver, the snmp receiver will simply refuse it with an error code of tooBig (and in snmpv3 will report its maxmessagesize in the response message). dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 11:55 AM > To: Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: syslog message size and fragmentation > > Hi Anton, > > thanks for this very helpful post. > > > > I have to admit I am not 100% sure what the UDP spec says: If > > > a UDP packet becomes fragmented (due to MTU), is it > > > guaranteed that the packet will be re-assembled by the > > > receivers IP stack before it is passed up to the app layer? > > > What if a fragment is missing? Will the whole packet be > > > discarded by the stack (UDP is best effort, after all...)? > > > > Postel's UDP RFC768 from 1980 is 3 pages long with > references. Ah, the > > good old times! :) > > indeed ;) > > > It talks about very few things. Besides, > > fragmentation is an IP layer issue and not UDP. IP layer must > > reassemble the whole packet before providing it to the next > layer - be > > it UDP or TCP. So, yes, if one fragment is lost, the whole > > datagram is > > discarded. > > That's fine with me. If don't receive a partial message and everything > is lost, I think this is consistent. If you use UDP, you have accepted > packet loss ;) > > [snip useful info for brevity] > > > So, I > > guess 64Kb limit is problematic for reasons other than > > fragmentation. > > > > But if we impose 1024 byte limit, let's at least make it > > something that > > is closer to using the whole Ethernet 1500 frame or at > least close to > > IPv6 minimum MTU, which I think is 1280 bytes. This would still be > > consistent with SNMP requirements, which seems to stem from the same > > limitation of 1500 byte frame minus IP/UDP header of 28 > bytes = 1472. > > That sounds like a good compromise from my point of view. I'd agree on > solving this issue as follows (just a sum-up of your points > to show if I > have correctly understood): > > #1 we allow up to 1280 bytes inside the syslog message > #2 we recommend to place important data early in the message > #3 we warn that a transport mapping may truncate the message > after 484 bytes (SNMP lowest limit as of David's post) > > Every transport mapping is allowed to use #3 at liberty (but > should try > to avoid it). It is NOT required to ensure that the whole > syslog message > will be transmitted. > > This will cause potential interop issues in rare cases, but I > think they > can be addressed, esepcially if > > #4 we recommend / demand (?) that an implementation must > provide an operator-configurable max message size > (configurable between 484 and 1280 bytes) > > So a proper implementation would look at the operator configured value > (default of 1280). So the operator can fine-tune is he has > actually one > of the rare cases where the size limitation is very low. > > That all sounds fine to me and I would edit -protcol-03 to > include this > if nobody objects or has a better solution. > > I would appreciate if somebody who eventually knows quickly could > confirm the 1280 byte IPv6 minimum MTU. > > Thanks, > Rainer > > >
