Hi Adam,

Oh. I'm sorry and confused. We have deactivated pseudowire in the past (Didn't work in 2013/2014).
I have reactivate the discovery module and the l2circuit on my Juniper are detected :-)

Maybe we could just add "Incoming" and "Outgoing" label and "Description" directly in Obserivum and it's perfect !
I see pwInboundLabel and pwOutboundLabel in MySQL table, but seems not display on interface?
Also, I'm just perplexe because the Inbound and Outbound Label is same value of pwID value :-/

From  http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/mibs/mib-jnx-vpn.txt
- The name/description in JnxVpnEntry > jnxVpnDescription.
- The inbound/outbound label in JnxVpnPwEntry > jnxVpnPwReceiveDemux (Inbound/Incoming Label) and jnxVpnPwTransmitDemux (Outbound/Outgoing Label)

I have tested on my router, and seems return good value :
Incoming label: 300048, Outgoing label: 299824 - Description: name
iso.3.6.1.4.1.2636.3.26.1.2.1.5.5.10.103.101.45.49.47.48.47.49.46.48 = STRING: "name"
iso.3.6.1.4.1.2636.3.26.1.4.1.13.5.10.103.101.45.49.47.48.47.49.46.48.1038 = Gauge32: 300048
iso.3.6.1.4.1.2636.3.26.1.4.1.14.5.10.103.101.45.49.47.48.47.49.46.48.1038 = Gauge32: 299824

For the RSVP/LDP :
From http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/mibs/mib-jnx-mpls.txt
It would be great Observium handled each ingress MPLS LSP more-or-less the same way it does with IBGP sessions; e.g. for each mplsLspInfoEntry:

        mplsLspInfoName             DisplayString,
        mplsLspInfoState            INTEGER,
        mplsLspInfoOctets           Counter64,
        mplsLspInfoPackets          Counter64,
        mplsLspInfoAge              TimeStamp,
        mplsLspInfoTimeUp           TimeStamp,
        mplsLspInfoPrimaryTimeUp    TimeStamp,
        mplsLspInfoTransitions      Counter32,
        mplsLspInfoLastTransition   TimeStamp,
        mplsLspInfoPathChanges      Counter32,
        mplsLspInfoLastPathChange   TimeStamp,
        mplsLspInfoFrom             IpAddress,
        mplsLspInfoTo               IpAddress,

Monitoring of LSP is very big advantage for many big tier-2 and tier-1 network.
We have looked for tools Observium-like for monitor our LSP, but not found yet ;-)

> If I still had a network, ISIS would probably have already been done, because it would have been useful to me. Since these days all I have is Observium servers, it's a little harder!
If you think that RFC4444 will make implementing ISIS in Observium easier ?
Alors, if you want, we can provide a vSRX image for virtualize your Juniper Lab :-)

Have a good day,
Johann

2016-07-19 10:43 GMT+02:00 Adam Armstrong <adama@memetic.org>:
Hi Johann,

Doesn't Juniper Pseudowire already work?

I think IPv6 port counters are on the list somewhere. What do you mean by RSVP/LSP? What counters are there for those? Where are they kept?

If I still had a network, ISIS would probably have already been done, because it would have been useful to me. Since these days all I have is Observium servers, it's a little harder!

Thanks,
adam.

Sent from Mailbird

On 19/07/2016 10:41:04, Johann Mallet <johann.mallet@zayo.com> wrote:

Hi Adam,

I'm sad for ISIS, but I can understand!
What about pseudowire for Juniper, IPv6 counters or RSVP/LSP? :-)
Are there any roadmap for integration in Observium?

I like Observium and use it since more 2 years, If I can help for these integration :-)

Johann

2016-07-15 10:57 GMT+02:00 Adam Armstrong <adama@memetic.org>:
Hi Aaron,

ISIS support doesn't yet exist because whoever wrote the ISIS MIB was a fool who thought it a good idea to use indexing that requires far more effort to decypher than I've ever had the motivation to expend. It's been on the list practically as long as Observium as existed, but each time I look at it, it just doesn't go anywhere.

The others are no, no and no. :)

Aside from not actually knowing what most of those things are, the resource cost to us of trying to implement stuff like that is orders of magnitude higher than the usefulness of them. The fact that I've not even heard of any of them goes some way to suggesting how useful they'd be to the majority of the user base! :D

adam.

Sent from Mailbird

On 15/07/2016 10:39:14, Aaron Finney <aaron.finney@openx.com> wrote:

I know this has been asked/answered, but the whole archives thing...what's the history behind [the lack of] support for IS-IS data in Observium, are there any plans to add it at any point, and would it be of value to anyone else? Even basics like warning on adjacency changes, tracking neighbors over time, etc. would be great...I would personally find it of value for an additional sanity check during maintenances or outages - an ISIS health overview tab for a device with the ISO address/area, participating interfaces, and stats.

Generalizing the data pool: any current thoughts around creating an abstraction layer between Observium and its data source? Mysql as the sole backend presents some challenges for us in trying to scale Observium to production. OBQL? :)

Sort-of on the tails of that last question, has there been any discussion about adapting Observium to take advantage of network devices which emit metrics using thrift/protobuf? E.g. using some other data pipeline/collection system as a data source...or even doing the collection itself and doing the necessary quantization/processing to produce a useable view.

Last one in that train of thought, any thoughts around incorporating additional data collectors other than simple snmp polling (e.g. facebook's udppinger or fbtracert)?

Aaron


--
Aaron Finney
Network Engineer | OpenX
888 East Walnut Street, 2nd Floor | Pasadena, CA 91101
o: +1 (626) 466-1141 x6035 | aaron.finney@openx.com
Advertising Age Best Places to Work
Deloitte's Technology Fast 500™
www.openx.com  |  Twitter  |  Facebook  |  LinkedIn  |  YouTube

_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium

_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium


_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium

_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium