Re: [snmpsim-users] Multiple engines with same context:. engineID discovering algorithm.
Brought to you by:
elie
Menu
▾
▴
Re: [snmpsim-users] Multiple engines with same context:. engineID discovering algorithm.
|
From: Ilya E. <il...@gl...> - 2014-12-27 15:58:40
|
Hi Mike, I’d advise you using the latest development versions of snmpsim, pysnmp and pyasn1: download latest CVS snapshot <http://snmpsim.cvs.sourceforge.net/viewvc/snmpsim/snmpsim/?view=tar> download latest CVS snapshot <http://pysnmp.cvs.sourceforge.net/viewvc/pysnmp/pysnmp/?view=tar> download CVS snapshot <http://pyasn1.cvs.sourceforge.net/viewvc/pyasn1/pyasn1/?view=tar> There are many fixes and improvements in the latest versions, in particular multiple ContextEngineIDs can be configured per each SNMP Engine. You can’t dispatch messages coming through a single port over multiple SNMPv3 engines or SNMPv3 Message Processing Modules. Although this is not explicitly forbidden by RFC3412, there are no provisions for it there. If you think otherwise, please, share your thoughts. However, SNMPv3 model allows you to serve multiple SNMP contexts at a single SNMP engine. Each such context is identified by ContextEngineID and ContextName pair. In terms of snmpsim, each .snmprec file can be addressed through these identifiers. I suspect it is a bug in your version of snmpsim that allows you to make it binding to the same transport endpoint twice - the latest version would explicitly fail that. So if what you are looking for is multiple ContextEngineIds at a single transport endpoint, then I’d advise trying something like this: snmpsimd.py —v3-context-engine-id=010203040506070809 \ —data-dir=./data_for_snmpsim/data1 \ —v3-context-engine-id=090807060504030201 \ —data-dir=./data_for_snmpsim/data2 \ —v3-auth-proto=NONE \ —v3-priv-proto=NONE \ —agent-udpv4-endpoint=10.0.1.1:1161 Please, let me know in case of further issues. -ilya > On 25 Dec 2014, at 19:12, Mike Turchenkov <mc...@gm...> wrote: > > It seems that first engine does not work at all (though there is no indication of that in output) > > > To check it's availability, I've prepared a separate data dir for each engine, and even separate context. > > snmpsimd.py > --v3-engine-id=010203040505060809 --agent-udpv4-endpoint=10.0.1.1:1161 <http://10.0.1.1:1161/> --data-dir=./data_for_snmpsim/data1 --v3-auth-proto=NONE --v3-priv-proto=NONE --v3-only > --v3-engine-id=090807060504030201 --agent-udpv4-endpoint=10.0.1.1:1161 <http://10.0.1.1:1161/> --data-dir=./data_for_snmpsim/data2 --v3-auth-proto=NONE --v3-priv-proto=NONE --v3-only > > > Result: > > Configuring ./data_for_snmpsim/data1/context1/1.3.6.1.6.1.1.0.snmprec controller > SNMPv1/2c community name: context1/1.3.6.1.6.1.1.0 > SNMPv3 context name: 32f3220b9bcda5259967aa4a514e0e36 > > SNMPv3 EngineID: 0x010203040505060809 > SNMPv3 USM SecurityName: simulator > Listening at UDP/IPv4 endpoint 10.0.1.1:1161 <http://10.0.1.1:1161/>, transport ID 1.3.6.1.6.1.1.0 > > ================================================================== > Configuring ./data_for_snmpsim/data2/context2/1.3.6.1.6.1.1.1.snmprec controller > SNMPv1/2c community name: context2/1.3.6.1.6.1.1.1 > SNMPv3 context name: 727b1bd3cdfb215d7e49360fb6a8ab10 > > SNMPv3 EngineID: 0x090807060504030201 > SNMPv3 USM SecurityName: simulator > Listening at UDP/IPv4 endpoint 10.0.1.1:1161 <http://10.0.1.1:1161/>, transport ID 1.3.6.1.6.1.1.1 > > > And when I'm trying to get: > > snmpget -v 3 -e 010203040505060809 -u simulator -l NoAuthNoPriv -n 32f3220b9bcda5259967aa4a514e0e36 10.0.1.1:1161 <http://10.0.1.1:1161/> 1.3.6.1.2.1.1.1.0 > > I have: > Timeout: No Response from 10.0.1.1:1161 <http://10.0.1.1:1161/>. > > And also a silence in wireshark. > > If I skip -e option to initiate discovering, then the second engine responds with its ID in Report message. > > But I tend to think that GETs for first machine are not swallowed by second, cause I see no increments in usmStatsUnknownEngineIDs in second machine after series of these GETs. > > So the first engine seems to be not active at all by itself, not due to "shadowing" by second engine. > > So I see problems in dispatch of messages for one transport endpoint for different engines. AFAIK RFCs do not forbid multiple engines per port. > > 2014-12-25 14:01 GMT+03:00 Mike Turchenkov <mc...@gm... <mailto:mc...@gm...>>: > Hello and thanks for nice software! > > I have two engines, both have the same context (and running on the same port) > > snmpsimd.py > --v3-engine-id=010203040505060809 --agent-udpv4-endpoint=10.0.1.1:1161 <http://10.0.1.1:1161/> > --v3-engine-id=090807060504030201 --agent-udpv4-endpoint=10.0.1.1:1161 <http://10.0.1.1:1161/> > --v3-auth-proto=NONE --v3-priv-proto=NONE > > It starts fine: > ... > SNMPv3 EngineID: 0x010203040505060809 > SNMPv3 USM SecurityName: simulator > ... > SNMPv3 context name: 157b7f0b3230bafba09ea2cf90d6671b > ... > SNMPv3 EngineID: 0x090807060504030201 > SNMPv3 USM SecurityName: simulator > ... > SNMPv3 context name: 157b7f0b3230bafba09ea2cf90d6671b > > > > When asking for that context, how does it choose the engine to respond me it's ID using Report message? > They both have the same context! But he reports me ID of the last one (according to wireshark). > > msgAuthoritativeEngineID: 090807060504030201 > > Thanks is advance for your attention. > > Mike. > > > > |
