On Fri, 11 Feb 2000, Mike Andrews wrote:
Something *completely* different to look at...
Some older NMC revs would lose IP connectivity if you sent an SNMP request that was too large. If the response packet was bigger than 1500 bytes, the IP stack on the card would crash, and you'd have to reboot the card to get it to wake up again. Apparently it didn't deal with IP fragmentation very well...
I think they finally did fix that bug somewhere in the 6.x.x NMC code.
If you want to check, start a continuous ping up, then do a snmpget for several large string variables at once. Or maybe just the same integer variable repeated a bunch of times... but have it try to snmpget about 50 or 60 variables at once. If the card stops responding to pings, you need newer NMC code. If pings keep working, but the SNMP query just times out, then you're OK.
I found this when writing a bulk chassis config tool (which I'm in the middle of rewriting from scratch today)... it essentially snmpwalks the whole box and compares the values to a list in a config file. I had to cut back the number of simultaneous snmpget requests it did at a time to about 10 to keep it from killing the boxes as I was programming them... :)
That's mostly how I configure mine, except I only check and change the values that vary from the default, no snmpwalk. Single threaded, one chassis at a time, takes about 10 mins to do a chassis w/6 DSP's. I've never bothered speeding it up since I use it so infrequently. Certainly much less error-prone than using TCM. -- Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.