On Thu, Apr 12, 2012 at 2:28 AM, Saku Ytti <s...@ytti.fi> wrote: > On (2012-04-12 11:12 +0200), Emmanuel Halbwachs wrote: > >> Juniper fellows subscribed to this list, please bring us useful, >> complete and sane SNMP MIBs. We badly need it! Thank you very >> much. > > And maybe basic trap support, like ISIS up/down, BGP max-prefix, BGP trap > which reports previous state (so you don't need to keep track of states).
Nor poll too often. Since 10.x, I get the sense that Juniper has been chasing so many other bugs that good SNMP support has slipped somewhat. It's probably a lot of extra work, especially for things that mutate state. I can imagine it involving managing MIB contents and naming, finding every place in which a hook or function needs to be defined to support representing things into SNMP-compatible types. What if I do a write to shut an interface? Should a whole commit happen? It's too bad that netconf and op scripts are so hard to use (and utilize relatively-obscure XML-based languages). They hold the full power to read and manipulate states of just about everything in JunOS. However, I think this can sometimes be too big of a hammer. When you just want to pull out some counter data, routing protocol states, route next-hops, etc., who wants to have to haul out XML and XML-centric editing tools? The netconf Perl library seems like a step in the right direction, but seems like just a thinly veiled higher-layer API to build XML documents. I'll cherish the day when I can just curl http://r00ter/protocols/bgp/neighbors.json?key=d756d378f8e7bf506bf1c7d3aac2f8d480c84776 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp