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. _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
