My MIB file collection has become bloated ... and I'd prefer to stay bloated, i.e. to keep them all, rather than to prune them. [The 'Netops-MIBs' collection at http://www.skendric.com/nmgmt/] This volume of MIBs blows past the memory limit imposed by MAXTC
So, I compile my own net-snmp, changing MAXTC in parse.c from 4096 to 16384.
../snmplib/parse.c
[...]
#define MAXTC 16384
struct tc { / textual conventions /
int type;
int modid;
char descriptor;
char hint;
struct enum_list enums;
struct range_list ranges;
char *description;
} tclist[MAXTC];
[...]
I propose changing MAXTC from 4096 to 16384.
I admit that I'm proposing this purely for my own convenience and without any understanding of the collateral damage this change might inflict. But I note that I've doing this for almost a decade now, in my own net-snmp installations, without apparent ill effect.
[You might recall that Robert Story increased MAXTC from 1024 to 4096 for me, back in 2004, for precisely this same reason:
https://sourceforge.net/p/net-snmp/mailman/net-snmp-users/?viewmonth=200402&viewday=17]
net-snmp-5.7.3
Linux {xxxx} 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
--sk
Stuart Kendrick
I agree. On most hosts that I use for SNMP stuff I'm now running a recompiled net-snmp, also with MAXTC set to 16k. I'd appreciate a higher default though so I can simply use stock net-snmp on common Linux distros.
Could anyone comment on possible downsides to having the default MAXTC increased? I can only think of slightly higher memory usage (order of tens of kilobytes?)... for servers and workstations that shouldn't be an issue IMHO, and for lower spec devices (like networking gear) I'd assume that the vendor will compile net-snmp to their own spec anyway.
I agree with Stuart and Jeroen's comments that this would be helpful unless there is some downside for which we are unaware.
Bloated MIB module collection now supported on 5.7-patches and master.