> ZMM> I suspect that the values of "msgAuthoritativeEngineBoots" and > ZMM> "msgAuthoritativeEngineTime" change drastically when the standby > ZMM> agent becomes active. As the newly active agent and the previous > ZMM> Active agent has the same EngineID, the manager does not do a new > ZMM> "Agent Discovery" and the snmpv3 fails due to a big change in the > ZMM> msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime. Am > ZMM> I correct ? Will this problem be resolved if the standby agent > ZMM> is configured with a different snmpEngineID ? > > That's almost certainly the problem. It's likely that the manager may > work switching one direction (from the engine with the older boots/time > to the one with the newer value), but it is against the V3/USM specs to > go the opposite direction (for good security reasons). > > Using two different engineIDs is definitely the right thing to do > *unless* the manager is one that caches information associated with the > IP address.
Another possibility would be to coordinate the engineBoots value used by the two agents. If the standby agent uses the same engineID and increments the engineBoot value from that used by the original agent, then things should work properly (I think!) It would appear to the client as if the original agent was simply restarted. Though you'd also need to ensure that the first agent picks up the engineBoot value from the standby agent (and increments it again) when it's brought back into service. Dave ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
