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>