RE: length of community strings

"Mike Ayers" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <83E753BE7B6A324ABB336245BAF1DAAC0B9A22BF@mailserver.metatv-ds.metatv.com>
> From: Dave Shield [mailto:[email protected]] 
> Sent: Wednesday, April 15, 2009 12:25 AM

> 2009/4/15 Richard Gipps <[email protected]>:
> > There does not seem to be anything in the RFCs on maximum community
> > string lengths.
> 
> Correct.
> The specs implicitly allow an arbitrary length string
> (although there may be some limit imposed by ASN.1
> or BER - I'm not sure offhand).

	Over a million octets, IIRC.

> > Is there some defacto standard for maximum length.
> 
> The main restriction will be from MIB objects that take
> a community string as their value.

	There's another aspect to take into account.  SNMP is run over UDP in the (vast) majority of cases, and therefore all information in a request or response must fit into a single UDP packet.  I'd have to consult references for the exact number, but there's about 1300+ bytes available for UDP packets over a standard ethernet link.  Since you need to put varbinds in the packet, too, the space fills up quickly.

	Soooo... the rule of thumb is that if you're asking how big a community string can get, you're probably thinking about doing something you'll regret later.


	HTH,

Mike

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.