> Thanks Mathias, > > You pretty much nailed what I'm seeing early on. I've been playing with 4 > IBM Datapower devices and V3 for about a week or so. That Admin is on my > team, and we've had the luxury of having him fiddle with things for us as we > explore how things are going to work. > > The first thing I did was change the default settings in $SPECROOT/SS/.vnmrc > for the following: > > snmpv3_default_auth_protocol=md5 > snmpv3_default_priv_protocol=des > > To: > > snmpv3_default_auth_protocol=SHA > snmpv3_default_priv_protocol=AES > > Since we felt those were more secure than the defaults. > > The Datapower's modeled fine initially, but like 12 hours later we got a > Duplicate Engine ID alarm on only one of the devices and traps stopped > working. Interestingly I could still walk the Agent MIB with MIBTOOLS on that > device. > > Then last night the network team started rolling out their V3 scheme to 325 > devices (without telling me, SIGH) and the SNMP NOT... Alarms started rolling > in. > > So I got the Creds the Network Team chose (SHA and AES as well) and started > modifying what they changed last night. Two 6509's modeled green initially, > but then one went "SNMP NOT RESPONDING" and the other gave me a "Duplicate > Engine ID". I'll have to doublecheck, but I believe we are letting the > device autoconfigure the Engine ID. > > I called support and they confirmed for me what I was seeing was a known > issue and informed me of the fix in H07 (Due next week?) I'm told there is > a PTR which I'll be testing this afternoon. > > I read that if you have the above .vnmrc defaults set as I do, and need to > support a device with say md5/des you need to preface those values before the > credentials in the Profile editor. I have not tried that yet, hope that > works OK. > > What is your feel for the added load that using AES puts on each side and the > potential latency? My feel is for marginal (CPU loaded) devices will need to > be tweaked for Timeout/Retries whereby V2 it might not have had to. You > seeing this?
If you've got Duplicate Engine ID alarms, it could be the cause of some of your snmp not responding alarms. Actual duplicates (rather that two address on the same device) will result in one of the devices responding correctly and the responses from the other device being dropped as invalid responses. You should check all of the snmp engine IDs for problem devices, it may be that some of your snmp not responding devices are using the same engine IDs as the devices with the Duplicate Engine ID alarms. A handy shortcut - poll .1.3.6.1.6.3.10.2.1.1.0 (snmpEngineID) on every suspect device. In terms of load, I'm sure that v3 has added some load to our Spectrum server, but it's been so long since we weren't fully snmp v3 that I really don't have a sense of how much capacity we are sacrificing on this server by using v3. We do have some models where we tweaked timeout and retries, but those are heavily loaded devices where we may have had to tweak timeout and retries regardless. For most things, we are using defaults. Mathias Wegner ISC N&T University of Pennsylvania --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
