jof at thejof
Apr 12, 2012, 2:41 AM
Post #7 of 9
On Thu, Apr 12, 2012 at 2:28 AM, Saku Ytti <saku [at] ytti> wrote:
Re: DOM: SNMP polling of RX power for 1 GE SFP impossible?
[In reply to]
> 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
> 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
juniper-nsp mailing list juniper-nsp [at] puck