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, 14:58, 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.. ☹
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.. ☺
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 abilityto alert on unprotected and failed sessions
VPLS Instances with VFI MAC address countersTraffic Engineering Tunnels and RSVP infoBFD NeighborsThanks for your time and work on this project ☺ 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 http://www.observium.org http://docs.observium.org http://jira.observium.org
On 2017-11-27 23:53:30, Nick Schmalenberger <nick@schmalenberger.usmailto: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.orgmailto: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