Re: Issues with SNMP monitoring over a GRE tunnel.

[Gregory Moberg <gmoberg () logmatrix com>]

This would be a good approach.  In SNMP the request initiator (the one
sending the SNMP 'Get' or 'GetNext' or 'GetBulk' ) can anticipate the size
of the outgoing request will be small(er) by asking for fewer variables at
a time.  (Each variable is a 'varbind' and each is specified in the
outgoing request packet as an OID.)  But it sometime impossible to know how
large the return size will be.  The SNMP Agent responding the to request
will load up the return UDP packet with the required data and this could be
quite large - depending on what is being requested.  Thus, it is good to
ask for fewer variables at a time thus hopefully keeping the SNMP Agent
from responding with something that will prove too large to the MTU barrier
that is being hit somewhere along the transitioned network path.

'GetBulk' would seem to be the worst enemy regarding this.

Of course some returns are very small per-variable.  'ifInOctets' is a
32bit integer.  'ifHCInOctets' is a 64bit integer. Etc.  These are not
likely the problem.  Issues will occur when fetching octet strings such as
'ifDescr' or 'sysLocation' - there can be times when these values have been
loaded up the remote SNMP Agent with quite a substantial response.

On Wed, Nov 5, 2014 at 1:36 PM, Jeff Walter <jwalter () weebly com> wrote:

> I think the simple solution here is to query for fewer OIDs to get the
> packet size (in both directions) down below the MTU. It'll take more
> requests and thus longer, but if that's what solves the problem... well,
> that's what solves the problem.
>
> On Wed, Nov 5, 2014 at 7:59 AM, Brian Christopher Raaen <
> mailing-lists () brianraaen com> wrote:
>
> > I have two different customers where I am unable to monitor their
> networks
> > due to GRE MTU issues.  This is monitoring cable modems so I can't change
> > the MTU of the end device.  The problem I am having is that the modems
> are
> > producing frames that appear to be larger than some kind of MTU limit in
> > the system (we do not control the customer routers in either case).  One
> > that I am looking at is dropping anything larger than 1472, and I have
> let
> > to tune down on the other one.  In one case the customer endpoint is a
> > Cisco ASR1K router and the other is a ASR9K.  because these are UDP
> packets
> > I can't use a mss to clamp things down.  Also I have been unable to
> > replicate the issue in my lab, so I can't send them a list of commands to
> > help fix the issue on their end.
> >
> > --
> > Brian Christopher Raaen
> > Network Architect
> > Zcorum



-- 
Greg Moberg, Director, NerveCenter Engineering
LogMatrix, Inc |  http://www.logmatrix.com/ | CommunityForum
<http://community.logmatrix.com/LogMatrix/> | Blog
<http://www.logmatrix.com/Blog>
Telephone: +1 (800)892-3646
<http://www.logmatrix.com> <http://www.twitter.com/NerveCenter>
<http://www.linkedin.com/company/logmatrix?trk=ppro_cprof>
<https://www.facebook.com/Logmatrix?sk=page_insights>
<http://www.youtube.com/user/logmatrixchannel>