Hi all, adding some clarifications on the proposed design I would like to propose:
The use case should cover two cases. Each case is exclusive of the other. a- stick one MIB to one connection. use case with multiple connections. b- stick several MIB in one connection. use case with single connection. The following is proposed: - extend agentx subagent code to multiple sessions a linked list of config sessions is created indexed by agentxsocket path the sub agent code is modified accordingly. at registration/unregistration of the session, a reference is done between netsnmp_session and config_netsnmp_session. at shutdown, the config session can be flushed based on the agentxsocket path too. example of config file: agentxsocket unix:/var/run/netns/test/agentx_snmpd [..] agentxsocket unix:/var/run/netns/test2/agentx_snmpd - add a linked list to the config sessions. that contains the list of mib contexts names. example of config file that could be applied for a) case: agentxsocket unix:/var/run/netns/test/agentx_snmpd name1 example of config file that could be applied for b) case: agentxsocket unix:/var/run/netns/test/agentx_snmpd name1,name2,name3 The advantage of using the config session list, is that there is no need to modify netsnmp_session. MIB (un)registration would be filtered by comparing the MIB registration name with the list of MIB names configured. The same would be done to check if a trap is eligible or not to a netsnmp_session or not. Thanks for letting me know if that approach should be considered or not, Thanks & Regards, Philippe On Fri, Nov 6, 2020 at 11:52 AM Philippe Guibert <philippe.guib...@6wind.com> wrote: > Hi all, > > I am in progress of implementing more than one parent agent for one agentX. > The problem I try to solve is that I have multiple MIB with same OID but > different vrfs. > > Do you have any proposals on how to stick MIBs to one dedicated parent > connection ? > From the sub agent trap code, I can see that a trap is supposed to be sent > to all pending connections, but I think this is not what should be done by > default ? > Thanks, > > Regards, > Philippe > > > On Tue, Oct 13, 2020 at 5:49 PM Wes Hardaker < > harda...@users.sourceforge.net> wrote: > >> Philippe Guibert <philippe.guib...@6wind.com> writes: >> >> > Instead of using agentX, I wonder if it could be possible to link the >> > application with a master agent library Somehow, the agent would be >> > configured as a proxy, and session would convey information over an >> > unixSocket to the real snmpAgent. Could it be possible ? >> >> Yes, certainly you can have multiple "real" snmp daemons query to a >> sub-process via a proxy like mechanism. There is no reason that >> shouldn't work to allow multiple upstreams query to your internal agent. >> >> The net-snmp package's snmpd actually supports that through the use of >> the "proxy" directive ; see the snmpd.conf manual page in the "Proxy >> Support" section. >> >> -- >> Wes Hardaker >> Please mail all replies to net-snmp-coders@lists.sourceforge.net >> >
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
