[j-nsp] DOM: SNMP polling of RX power for 1 GE SFP impossible?

Jonathan Lassoff jof at thejof.com
Thu Apr 12 05:41:17 EDT 2012


On Thu, Apr 12, 2012 at 2:28 AM, Saku Ytti <saku at 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



More information about the juniper-nsp mailing list