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 jwal...@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-li...@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
