[Xorp-hackers] Does anybody have some suggesstion about SNMP?

[Bruce Simpson]

On 06/01/2010 10:20, cheng wan wrote:
> Xorp removes SNMP after version 1.6.
> I went through the SNMP part code and found it was not easy to read/write.
> How about this:
> Add agent++ as agent process to Xorp system.
> Modify agent++ to support xrl IPC.
> Agent++ is written in C++ and more lightwight than NET-SNMP.
>

We reviewed Agent++ in-house around 15 months ago, and found it wasn't a 
very good fit for XORP's needs. AgentX is the right approach, but 
Agent++'s API was lacking in any clean way to integrate its I/O into the 
existing XORP processes.

I would suggest that Net-SNMP is still a better place to start. It has 
AgentX support out of the box. The key is to be able to deal with 
composite OID keys in a way which doesn't block out XRL, Net-SNMP or 
other callbacs from running.out of the main event loop.

Bridging XRL to an SNMP API looks deceptively simple on the surface. The 
problem with that approach is that SNMP MIBs often need to use composite 
keys for access to internal data within each routing process, which 
isn't available upfront, unless SNMP is running in the same address space.

This is especially true for BGP, which has had scalability problems. 
Doing a mass copy of BGP's state into the address space of the SNMP 
daemon is not an acceptable solution, this is what the legacy XORP SNMP 
support did.

Table iterators are also another problem. Net-SNMP has an abstraction 
for this, but my research quickly uncovered the issue that proxying 
these to XRL requests isn't easy. State has to be saved for the iterator 
in a way which doesn't block out other parts of Net-SNMP from running, 
whilst the table index fetch is running. You quickly find that XRL is 
introducing unacceptable latency in the SNMP fetch just for the indexes 
themselves.

So the regular Net-SNMP programming idioms can't be used as-is; some 
custom handlers are needed, and a clean way of exporting data 
structures, e.g. via shared memory.

One alternative is to add SNMP instrumentation to each process as a 
loadable plugin DLL, and export each protocol's OID tree via AgentX, to 
an appropriate master agent.

This is breaking the process boundaries in a way in which the original 
architects of XORP had hoped to avoid, but unfortunately, the nature of 
the problem means taking this kind of approach.