Ok cool J

 

I will spend some time gathering the OID’s for at least the LDP and BFD adjacencies as soon as I get a spare moment then. And can think about the MPLS service related ones later.

 

Completely agree that the db schema needs to be logical, so fingers crossed the OID mappings are reasonably consistent across the main vendors at least, to allow easy injection into a schema.

 

And in the mean time we will remain quietly hopeful that “circuit-id” groupings might be pondered over for the Core page ;)

 

Thanks again for your thoughts,

Andy.

 

 

From: Sean Pedersen [mailto:spedersen.lists@gmail.com]
Sent: Tuesday, November 28, 2017 3:25 PM
To: 'Observium' <observium@observium.org>
Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph

 

I think an LDP/BDF/CDP requirement for this to work is reasonable. Make use of data that’s already available per-device vs. trying to reinvent the wheel.

 

From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong
Sent: Tuesday, November 28, 2017 8:16 AM
To: 'Observium' <observium@observium.org>
Cc: 'Observium' <observium@observium.org>
Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph

 

This is actually all stuff I wanted to do too last time I worked for an SP/Telco. Most of it was "definitely going to add in the next 6 months", but since I stopped having a network, it's difficult to do.

All of these things are ok to add, but you need to build database schemas which can be used for multiple vendors, otherwise they end up being abandoned.

LDP and BFD seem the easiest, they're just another per-port thing. If you look at a bunch of vendor mibs for these things, you can work out what needs to be stored for all of them, and we can come up with a table schema.

Adam.

Sent from BlueMail

On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com> wrote:

Hi Adam,

 

A CDP/LLDP driven page sounds nice. How would you envision it?

 

Would it be a dedicated “Links” page that shows graphs like the existing “Core” page, but with only a single graph per logical link?

Or an enhancement to the existing Map where you could hover over the link and the Graph appears?

 

 

Naturally it’s your project and I’m sure you already have future plans in mind for how you want things to be, but I’m thinking that adding in some logic to the existing Core page to group/merge links which have the exact same ‘circuit-id’ string would give more control to the admins?

 

Many people (including ourselves) may not be able to run CDP or LLDP everywhere due filtering on pseudowires, EVPL circuits etc which do not support them, or just because of security policies etc.. L

 

I built an Observium system for my previous “Enterprise” employer, but I’m now working for a small Colo/Service Provider, and so I’m thinking about scaling with Observium. This is one of the first things that came up to be able to view links as links, and not just multiple ports.. J

 

 

Also if I was to go and spend a bunch of time working out all the OID’s and how they all map together, would you be receptive to adding some extra pages for things like displaying;

-          LDP Sessions (Protected and Targeted) – Ideally with ability to alert on unprotected and failed sessions

-          VPLS Instances with VFI MAC address counters

-          Traffic Engineering Tunnels and RSVP info

-          BFD Neighbors

 

Thanks for your time and work on this project J

Cheers, Andy.

 

 

 

Andy Lemin | Senior Network Engineer

---------------------------------------------------------------------------------------------------------------

4D – Cloud, Connectivity & Colocation

 

From: Adam Armstrong [mailto:adama@observium.org]
Sent: Tuesday, November 28, 2017 8:22 AM
To: observium@observium.org
Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph

 

This would be best done as a page which showed cdp/lldp/etc "links" as opposed to the core page, which his based on port descriptions. We already use this logic when drawing the map, so as not to draw links twice.

 

We don't have such a page yet, but it probably wouldn't be terribly difficult to create.

 

adam.

 

Adam Armstrong

Managing Director & Lead Architect

Observium Limited

On 2017-11-27 23:53:30, Nick Schmalenberger <nick@schmalenberger.us> wrote:

On Mon, Nov 27, 2017 at 01:43:31PM +0000, Andrew Lemin wrote:
> Hi,
>
> We are evaluating Observium at the moment, and we have many point-to-point links in our WAN as everyone should ;)
>
> Each end of the same p2p link is labeled to be identical;
> interface Te1/1/1
> description CORE:DeviceA=DeviceB
>
> This results in two graphs in Observium. One for DeviceA (labelled "CORE:DeviceA=DeviceB") and one for DeviceB (labelled "CORE:DeviceA=DeviceB").
>
> However as they are connected back-to-back to each other they show the exact same information (just "in" and "out" reversed obviously).
>
> Is it possible to merge these two ports/graphs into a single logical Core link?
>
>
>
> This would significantly save on screen real estate (halving the Core page at the least) and make tracing paths through the network much more logical.
>
> Similar to how the Customer graphs aggregate multiple ports with the same description together. But I guess throwing away one side of the link maybe?
>
> Details for each end could still be seen on the specific device's page to view locally significant things like port errors etc
> Thanks, Andy.
>
>
Maybe you could also include something about an A and Z side of
each link. This won't work directly with the port description
parsing, but you could easily make a group of A side links and
use the group for aggregation.
-Nick
_______________________________________________
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