Ugh, not confusing … just reading comprehension = 0. Glad I didn’t go too far.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong
Sent: Wednesday, November 29, 2017 11:39 AM
To: observium@observium.org
Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
We already have support for CDP and LLDP.
You're confusing LDP with LLDP.
adam.
Adam Armstro ng
Managing Director & Lead Architect
Observium Limited
On 2017-11-29 16:37:13, Sean Pedersen <spedersen.lists@gmail.com> wrote:
Before I go further, is any of this useful? CDP and LLDP captured from several P2P connections. I made some assumptions. If there are specific OIDs desired, I can run queries against the same connections and devices.
We have a decent assortment of Cisco and Brocade gear in production I can pull data from if it’s helpful.
CONNECTION 1 (CDP) – Cisco to Cisco:
Device A (Cisco 6509-E, IOS 12.x):
ifIndex
1.3.6.1.2.1.2.2.1.1.8 = INTEGER: 8
ifName
1.3.6.1.2.1.31.1.1.1.1.8 = STRING: "Te1/8"
ciscoCdpMIB (CISCO-CDP-MIB)
1.3.6.1.4.1.9.9.23.1.1.1.1.2.8 = INTEGER: 1
1.3.6.1.4.1.9.9.23.1.1.1.1.3.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.4.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.5.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.6.8 = STRING: "TenGigabitEthernet1/8"
1.3.6.1.4.1.9.9.23.1.1.2.1.1.8 = INTEGER: 2
1.3.6.1.4.1.9.9.23.1.1.2.1.2.8 = Gauge32: 0
1.3.6.1.4.1.9.9.23.1.2.1.1.3.8.1 = INTEGER: 1
1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.1 = Hex-STRING: 4A CE 6F 62
1.3.6.1.4.1.9.9.23.1.2.1.1.5.8.1 = STRING: "Cisco IOS Software, … <version info removed for sake of brevity>"
1.3.6.1.4.1.9.9.23.1.2.1.1.6.8.1 = STRING: "<remote_device_hostname>"
1.3.6.1.4.1.9.9.23.1.2.1.1.7.8.1 = STRING: "TenGigabitEthernet1/8"
1.3.6.1.4.1.9.9.23.1.2.1.1.8.8.1 = STRING: "cisco WS-C6509-E"
1.3.6.1.4.1.9.9.23.1.2.1.1.9.8.1 = Hex-STRING: 00 00 00 29
1.3.6.1.4.1.9.9.23.1.2.1.1.10.8.1 = STRING: "<vtp_domain>"
1.3.6.1.4.1.9.9.23.1.2.1.1.11.8.1 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.2.1.1.12.8.1 = INTEGER: 3
Device B (Cisco 6509-E, IOS 12.x):
ifIndex
1.3.6.1.2.1.2.2.1.1.8 = INTEGER: 8
ifName
1.3.6.1.2.1.31.1.1.1.1.8 = STRING: "Te1/8"
ciscoCdpMIB
1.3.6.1.4.1.9.9.23.1.1.1.1.2.8 = INTEGER: 1
1.3.6.1.4.1.9.9.23.1.1.1.1.3.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.4.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.5.8 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.1.1.1.6.8 = STRING: "TenGigabitEthernet1/8"
1.3.6.1.4.1.9.9.23.1.1.2.1.1.8 = INTEGER: 2
1.3.6.1.4.1.9.9.23.1.1.2.1.2.8 = Gauge32: 0
1.3.6.1.4.1.9.9.23.1.2.1.1.3.8.1 = INTEGER: 1
1.3.6.1.4.1.9.9.23.1.2.1.1.4.8.1 = Hex-STRING: 4A CE 6F 62
1.3.6.1.4.1.9.9.23.1.2.1.1.5.8.1 = STRING: "Cisco IOS Software, … <version info removed for sake of brevity>"
1.3.6.1.4.1.9.9.23.1.2.1.1.6.8.1 = STRING: "<remote_device_hostname>"
1.3.6.1.4.1.9.9.23.1.2.1.1.7.8.1 = STRING: "TenGigabitEthernet1/8"
1.3.6.1.4.1.9.9.23.1.2.1.1.8.8.1 = STRING: "cisco WS-C6509-E"
1.3.6.1.4.1.9.9.23.1.2.1.1.9.8.1 = Hex-STRING: 00 00 00 29
1.3.6.1.4.1.9.9.23.1.2.1.1.10.8.1 = STRING: "<vtp_domain>"
1.3.6.1.4.1.9.9.23.1.2.1.1.11.8.1 = INTEGER: 0
1.3.6.1.4.1.9.9.23.1.2.1.1.12.8.1 = INTEGER: 3
CONNECTION 2 (LLDP) – Cisco to Cisco:
Doesn't look like LLDP-MIB (1.0.8802.1.1.2) is supported on 12.x, but it's supported on 15.x. Had to switch devices.
Device A (Cisco 6509-E, IOS 15.x):
ifIndex
iso.3.6.1.2.1.2.2.1.1.7 = INTEGER: 7
ifName
iso.3.6.1.2.1.31.1.1.1.1.7 = STRING: "Gi2/1"
lldpMIB (LLDP-MIB)
iso.0.8802.1.1.2.1.3.7.1.2.7 = INTEGER: 5
iso.0.8802.1.1.2.1.3.7.1.3.7 = STRING: "Gi2/1"
iso.0.8802.1.1.2.1.3.7.1.4.7 = STRING: "GigabitEthernet2/1"
iso.0.8802.1.1.2.1.4.1.1.4.0.7.11 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.0.7.11 = Hex-STRING: 00 24 51 AC 10 00
iso.0.8802.1.1.2.1.4.1.1.6.0.7.11 = INTEGER: 5
iso.0.8802.1.1.2.1.4.1.1.7.0.7.11 = STRING: "Gi2/1"
iso.0.8802.1.1.2.1.4.1.1.8.0.7.11 = STRING: "GigabitEthernet2/1"
iso.0.8802.1.1.2.1.4.1.1.9.0.7.11 = STRING: "<remote_device_hostname>"
iso.0.8802.1.1.2.1.4.1.1.10.0.7.11 = STRING: "Cisco IOS Software, … <version info removed for sake of brevity>"
iso.0.8802.1.1.2.1.4.1.1.11.0.7.11 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.1.1.12.0.7.11 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.2.1.3.0.7.11.1.4.<remote_device_ip> = INTEGER: 2
iso.0.8802.1.1.2.1.4.2.1.4.0.7.11.1.4.<remote_device_ip> = INTEGER: 728
iso.0.8802.1.1.2.1.4.2.1.5.0.7.11.1.4.<remote_device_ip> = OID: ccitt.0
Device B (Cisco 6509-E, IOS 15.x):
ifIndex
iso.3.6.1.2.1.2.2.1.1.7 = INTEGER: 7
ifName
iso.3.6.1.2.1.31.1.1.1.1.7 = STRING: "Gi2/1"
lldpMIB
iso.0.8802.1.1.2.1.3.7.1.2.7 = INTEGER: 5
iso.0.8802.1.1.2.1.3.7.1.3.7 = STRING: "Gi2/1"
iso.0.8802.1.1.2.1.3.7.1.4.7 = STRING: "GigabitEthernet2/1"
iso.0.8802.1.1.2.1.4.1.1.4.0.7.2 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.0.7.2 = Hex-STRING: 00 24 51 5F 50 00
iso.0.8802.1.1.2.1.4.1.1.6.0.7.2 = INTEGER: 5
iso.0.8802.1.1.2.1.4.1.1.7.0.7.2 = STRING: "Gi2/1"
iso.0.8802.1.1.2.1.4.1.1.8.0.7.2 = STRING: "GigabitEthernet2/1"
iso.0.8802.1.1.2.1.4.1.1.9.0.7.2 = STRING: "<remote_device_hostname>"
iso.0.8802.1.1.2.1.4.1.1.10.0.7.2 = STRING: "Cisco IOS Software, … <version info removed for sake of brevity>"
iso.0.8802.1.1.2.1.4.1.1.11.0.7.2 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.1.1.12.0.7.2 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.2.1.3.0.7.2.1.4.<remote_device_ip> = INTEGER: 2
iso.0.8802.1.1.2.1.4.2.1.4.0.7.2.1.4.<remote_device_ip> = INTEGER: 717
iso.0.8802.1.1.2.1.4.2.1.5.0.7.2.1.4.<remote_device_ip> = OID: ccitt.0
CONNECTION 3 (LLDP) – Cisco to Brocade:
Device A (Cisco 6509-E, IOS 15.x):
ifIndex
iso.3.6.1.2.1.2.2.1.1.725 = INTEGER: 725
ifName
iso.3.6.1.2.1.31.1.1.1.1.725 = STRING: "Te8/1"
lldpMIB
iso.0.8802.1.1.2.1.3.7.1.2.725 = INTEGER: 5
iso.0.8802.1.1.2.1.3.7.1.3.725 = STRING: "Te8/1"
iso.0.8802.1.1.2.1.3.7.1.4.725 = STRING: "TenGigabitEthernet8/1"
iso.0.8802.1.1.2.1.4.1.1.4.0.725.16 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.0.725.16 = Hex-STRING: 74 8E F8 FE 8E 42
iso.0.8802.1.1.2.1.4.1.1.6.0.725.16 = INTEGER: 3
iso.0.8802.1.1.2.1.4.1.1.7.0.725.16 = Hex-STRING: 74 8E F8 FE 8E 54
iso.0.8802.1.1.2.1.4.1.1.8.0.725.16 = STRING: "10GigabitEthernet1/1/19"
iso.0.8802.1.1.2.1.4.1.1.9.0.725.16 = STRING: "<remote_device_hostname>"
iso.0.8802.1.1.2.1.4.1.1.10.0.725.16 = ""
iso.0.8802.1.1.2.1.4.1.1.11.0.725.16 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.1.1.12.0.725.16 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.2.1.3.0.725.16.1.4.174.128.10.172 = INTEGER: 2
iso.0.8802.1.1.2.1.4.2.1.4.0.725.16.1.4.174.128.10.172 = INTEGER: 2049
iso.0.8802.1.1.2.1.4.2.1.5.0.725.16.1.4.174.128.10.172 = OID: ccitt.0
Device B (Brocade ICX6650, 7.5):
ifIndex
iso.3.6.1.2.1.2.2.1.1.19 = INTEGER: 19
ifName
iso.3.6.1.2.1.31.1.1.1.1.19 = STRING: "ethernet1/1/19"
lldpMIB
iso.0.8802.1.1.2.1.3.7.1.2.19 = INTEGER: 3
iso.0.8802.1.1.2.1.3.7.1.3.19 = Hex-STRING: 74 8E F8 FE 8E 54
iso.0.8802.1.1.2.1.3.7.1.4.19 = STRING: "10GigabitEthernet1/1/19"
iso.0.8802.1.1.2.1.4.1.1.4.0.19.22 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.0.19.22 = Hex-STRING: 00 24 51 5F 50 00
iso.0.8802.1.1.2.1.4.1.1.6.0.19.22 = INTEGER: 5
iso.0.8802.1.1.2.1.4.1.1.7.0.19.22 = STRING: "Te8/1"
iso.0.8802.1.1.2.1.4.1.1.8.0.19.22 = STRING: "TenGigabitEthernet8/1"
iso.0.8802.1.1.2.1.4.1.1.9.0.19.22 = STRING: "<remote_device_hostname>"
iso.0.8802.1.1.2.1.4.1.1.10.0.19.22 = STRING: "Cisco IOS Software, … <version info removed for sake of brevity>"
iso.0.8802.1.1.2.1.4.1.1.11.0.19.22 = STRING: "("
iso.0.8802.1.1.2.1.4.1.1.12.0.19.22 = STRING: "("
iso.0.8802.1.1.2.1.4.2.1.3.0.19.22.1.4.174.128.10.70 = INTEGER: 2
iso.0.8802.1.1.2.1.4.2.1.4.0.19.22.1.4.174.128.10.70 = INTEGER: 735
iso.0.8802.1.1.2.1.4.2.1.5.0.19.22.1.4.174.128.10.70 = OID: ccitt.0
From: Sean Pedersen [mailto:spedersen.lists@gmail.com]
Sent: Tuesday, November 28, 2017 9:36 AM
To: 'Observium' <observium@observium.org>
Subject: RE: [Observium] Grouping both ends of Core P2P links into single Graph
I can provide the CDP and LLDP data from both Cisco and Brocade if that’s helpful.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Andrew Lemin
Sent: Tuesday, November 28, 2017 9:26 AM
To: 'Observium' <observium@observium.org>
Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
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
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium