Hi Roger, no problem. I will add a corresponding constructor. I assume a protected one would be sufficient.
Best regards, Frank > On 19 Oct 2015, at 09:37, Roger Andersson J <[email protected]> > wrote: > > Hi Frank, > > Will it be possible for you to do some small changes in SNMPv2MIB > implementation. > We would like to have the possibility to set SysUpTime in constructor. > public SNMPv2MIBExtended(OctetString sysDescr, OID sysOID, Integer32 > sysServices, SysUpTime sysUpTime) > > Regards, > Roger > > -----Original Message----- > From: SNMP4J [mailto:[email protected]] On Behalf Of Frank Fock > Sent: Wednesday, October 07, 2015 11:35 PM > To: [email protected] > Subject: Re: [SNMP4J] SNMPv3 and virtual IP > > Hi Roger, > > If there is only a single logical node that is implemented on a single > virtual IP that is realized in a redundant (load balanced) layout of systems > including your SNMP agent, then I see no reason why keeping engine ID, boots > counter, and engine time of those agents in sync should be problematic. > Important is, that also the USM (and the VACM) are synchronized or read-only. > > Loadbalancing should ensure, that messages with the same request-ID will be > always delivered to the same physical agent. Otherwise, retries would be > processed by several agents simultaneously (which is not really harmful but > is a wast of resources). > > The agents will then act on SNMPv3 level as they would be a single > "multi-threaded" > agent. > > The sysUpTime could vary for each agent, although this would have an effect > on write access messages send to the agent(s) if load balancing is dipatching > a the SET message after a GET on a TestAndIncr object on a different agent. > For that reason, I also recommend to synchronize the sysUpTime. > > Other critical objects might be tables with log information (like the > SNMP-NOTIFICATION-LOG). > > Hope this helps. > > Best regards, > Frank > > Am 07.10.2015 um 12:43 schrieb Roger Andersson J: >> Hi, >> >> We have a system which spans over several nodes. We want to see the system >> as one entity, it is just distributed over several physical nodes. >> We are using a virtual IP between these nodes. Either as a load balancer or >> one active and the other standby if active goes down. >> The SNMP manager don't know if there are just one or several nodes in the >> system, it uses the virtual IP to contact the system. >> On all these nodes there is a SNMP agent using the virtual IP, i.e. >> listening for get/set requests on virtual IP and sending traps from virtual >> IP. Our MIB tables etc in subagents are synchronized between all the SNMP >> agents. >> >> Using SNMPv2c and the virtual IP it works fine. The manager sends the SNMP >> get request is sent to virtual IP and it is routed to the agent on the >> active node. The agent on the active node sends SNMP traps to manager. If >> active node changes the SNMP get is just routed to the new agent on the >> active node. >> >> But using SNMPv3 and virtual IP is not as easy. >> To be able to use SNMPv3 and virtual IP all agents must have the same >> engineID. I guess they also needs to have the same boot counter and >> sysUpTime. >> The engineID is simple to solve if we generate it using the virtual IP. But >> it is ok to have the same engineID on several agents? We have a system that >> is distributed over several physical nodes, but it is ok to have a SNMP >> agent that is distributed over several physical nodes? >> Boot counter can also be distributed in a quite simple way. >> But how to handle the sysUptime? >> >> Anyone who has solved a similar situation? >> >> Regards, >> Roger Andersson >> >> >> _______________________________________________ >> SNMP4J mailing list >> [email protected] >> https://oosnmp.net/mailman/listinfo/snmp4j > > -- > --- > AGENT++ > Maximilian-Kolbe-Str. 10 > 73257 Koengen, Germany > https://agentpp.com > Phone: +49 7024 8688230 > Fax: +49 7024 8688231 > > _______________________________________________ > SNMP4J mailing list > [email protected] > https://oosnmp.net/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] https://oosnmp.net/mailman/listinfo/snmp4j
