Grouping both ends of Core P2P links into single Graph
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.
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
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.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
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 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 ☺ 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
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
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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Ok cool ☺
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.orgmailto:observium@observium.org> Cc: 'Observium' <observium@observium.orgmailto: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 BlueMailhttp://www.bluemail.me/r?b=11249 On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.commailto: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 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 ☺ 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.orgmailto: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.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
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 :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
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 mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
Ok cool :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
We already have support for CDP and LLDP.
You're confusing LDP with LLDP.
adam.
Adam Armstrong Managing Director & Lead Architect Observium Limited http://www.observium.org http://docs.observium.org http://jira.observium.org 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 [mailto:observium-bounces@observium.org]] On Behalf Of Andrew Lemin Sent: Tuesday, November 28, 2017 9:26 AM To: 'Observium' <observium@observium.org [mailto: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 [mailto:spedersen.lists@gmail.com]] Sent: Tuesday, November 28, 2017 3:25 PM To: 'Observium' <observium@observium.org [mailto: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 [mailto:observium-bounces@observium.org]] On Behalf Of Adam Armstrong Sent: Tuesday, November 28, 2017 8:16 AM To: 'Observium' <observium@observium.org [mailto:observium@observium.org]> Cc: 'Observium' <observium@observium.org [mailto: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 [http://www.bluemail.me/r?b=11249] On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com [mailto: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 [mailto:adama@observium.org]] Sent: Tuesday, November 28, 2017 8:22 AM To: observium@observium.org [mailto: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://www.observium.org] http://docs.observium.org [http://docs.observium.org] http://jira.observium.org [http://jira.observium.org] On 2017-11-27 23:53:30, Nick Schmalenberger <nick@schmalenberger.us [mailto: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 [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
observium mailing list observium@observium.org [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
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 Armstrong
Managing Director & Lead Architect
Observium Limited
On 2017-11-29 16:37:13, Sean Pedersen <spedersen.lists@gmail.com mailto: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 mailto: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 mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
Ok cool :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I saw you make the mistake yesterday, but I've been pretty busy these last few days and didn't get a chance to point it out :D
I think our xDP stuff is fairly complete but there might actually be more data returned that we could capture. Did you compare the data returned with what we keep in the neighbours table?
Adam.
Sent from BlueMail
On 29 Nov 2017, 20:32, at 20:32, Sean Pedersen spedersen.lists@gmail.com wrote:
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 Armstrong
Managing Director & Lead Architect
Observium Limited
On 2017-11-29 16:37:13, Sean Pedersen <spedersen.lists@gmail.com mailto: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 mailto: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 mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
Ok cool :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org mailto: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
Had a quick look at the devices used for connection 2 and 3 below.
Ports list info is fine under devices/ports and appears to be about all you can fit in there. It identifies the neighbor interface as well as the port-channel the interface is a member of. Both for Cisco and Brocade. I checked an Arista device and that’s working, too. I did notice that if the supplied device hostname via CDP or LLDP does not match the hostname in Observium, it can’t cross-reference the data, but that’s more my problem. It still shows the neighbor information, just no link to the device. I think that's all that can be captured there.
Went to neighbors and looked at the same interfaces. I don't think I've ever used this interface! Noticed here that it seems to prefer LLDP over CDP. Is that intentional? It looks like CDP may offer more detail, but not sure that's important. For example: I saw an OID for the chassis type with CDP but not LLDP, but with all the other data Observium collects it may not be necessary to pull that info through CDP vs. other sources. I see local device, local port, remote device, remote port, chassis types, interface descriptions, and protocol. I can't think of anything else I'd like to see. All the other data via LLDP or CDP detail commands show info that can be pulled or correlated from other sources.
You know what would be super-helpful, though? I thought of it while looking at the list of search results. If there was a means to hit a link similar to the "Show RRD Command" toggle for graphs that output the returned search data in a more export-friendly format it would save on manual MySQL queries and make it easier to export data. There have been a lot of cases where I've used Observium to pull large amounts of data, but have had to do it via SQL query because the GUI returns results that are not ideal for spreadsheets, etc.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Wednesday, November 29, 2017 1:59 PM To: 'Observium' observium@observium.org Cc: 'Observium' observium@observium.org Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
I saw you make the mistake yesterday, but I've been pretty busy these last few days and didn't get a chance to point it out :D
I think our xDP stuff is fairly complete but there might actually be more data returned that we could capture. Did you compare the data returned with what we keep in the neighbours table?
Adam.
Sent from BlueMail http://www.bluemail.me/r?b=11249
On 29 Nov 2017, at 20:32, Sean Pedersen <spedersen.lists@gmail.com mailto:spedersen.lists@gmail.com > wrote:
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 mailto: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 mailto: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 mailto: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 mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
Ok cool :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I'm not sure what you mean, what returned search data?
adam.
Adam Armstrong Managing Director & Lead Architect Observium Limited http://www.observium.org http://docs.observium.org http://jira.observium.org On 2017-11-29 21:32:29, Sean Pedersen spedersen.lists@gmail.com wrote: Had a quick look at the devices used for connection 2 and 3 below. Ports list info is fine under devices/ports and appears to be about all you can fit in there. It identifies the neighbor interface as well as the port-channel the interface is a member of. Both for Cisco and Brocade. I checked an Arista device and that’s working, too. I did notice that if the supplied device hostname via CDP or LLDP does not match the hostname in Observium, it can’t cross-reference the data, but that’s more my problem. It still shows the neighbor information, just no link to the device. I think that's all that can be captured there. Went to neighbors and looked at the same interfaces. I don't think I've ever used this interface! Noticed here that it seems to prefer LLDP over CDP. Is that intentional? It looks like CDP may offer more detail, but not sure that's important. For example: I saw an OID for the chassis type with CDP but not LLDP, but with all the other data Observium collects it may not be necessary to pull that info through CDP vs. other sources. I see local device, local port, remote device, remote port, chassis types, interface descriptions, and protocol. I can't think of anything else I'd like to see. All the other data via LLDP or CDP detail commands show info that can be pulled or correlated from other sources. You know what would be super-helpful, though? I thought of it while looking at the list of search results. If there was a means to hit a link similar to the "Show RRD Command" toggle for graphs that output the returned search data in a more export-friendly format it would save on manual MySQL queries and make it easier to export data. There have been a lot of cases where I've used Observium to pull large amounts of data, but have had to do it via SQL query because the GUI returns results that are not ideal for spreadsheets, etc. From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Wednesday, November 29, 2017 1:59 PM To: 'Observium' observium@observium.org Cc: 'Observium' observium@observium.org Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph I saw you make the mistake yesterday, but I've been pretty busy these last few days and didn't get a chance to point it out :D I think our xDP stuff is fairly complete but there might actually be more data returned that we could capture. Did you compare the data returned with what we keep in the neighbours table? Adam. Sent from BlueMail [http://www.bluemail.me/r?b=11249] On 29 Nov 2017, at 20:32, Sean Pedersen <spedersen.lists@gmail.com [mailto:spedersen.lists@gmail.com]> wrote: Ugh, not confusing … just reading comprehension = 0. Glad I didn’t go too far. From: observium [mailto:observium-bounces@observium.org [mailto:observium-bounces@observium.org]] On Behalf Of Adam Armstrong Sent: Wednesday, November 29, 2017 11:39 AM To: observium@observium.org [mailto: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 http://www.observium.org [http://www.observium.org] http://docs.observium.org [http://docs.observium.org] http://jira.observium.org [http://jira.observium.org] On 2017-11-29 16:37:13, Sean Pedersen <spedersen.lists@gmail.com [mailto: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 [mailto:spedersen.lists@gmail.com]] Sent: Tuesday, November 28, 2017 9:36 AM To: 'Observium' <observium@observium.org [mailto: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 [mailto:observium-bounces@observium.org]] On Behalf Of Andrew Lemin Sent: Tuesday, November 28, 2017 9:26 AM To: 'Observium' <observium@observium.org [mailto: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 [mailto:spedersen.lists@gmail.com]] Sent: Tuesday, November 28, 2017 3:25 PM To: 'Observium' <observium@observium.org [mailto: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 [mailto:observium-bounces@observium.org]] On Behalf Of Adam Armstrong Sent: Tuesday, November 28, 2017 8:16 AM To: 'Observium' <observium@observium.org [mailto:observium@observium.org]> Cc: 'Observium' <observium@observium.org [mailto: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 [http://www.bluemail.me/r?b=11249] On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com [mailto: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 [mailto:adama@observium.org]] Sent: Tuesday, November 28, 2017 8:22 AM To: observium@observium.org [mailto: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://www.observium.org] http://docs.observium.org [http://docs.observium.org] http://jira.observium.org [http://jira.observium.org] On 2017-11-27 23:53:30, Nick Schmalenberger <nick@schmalenberger.us [mailto: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 [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
observium mailing list observium@observium.org [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
observium mailing list observium@observium.org [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
Say I go to /ports and want to pull up a bunch of interfaces based on key word or status match for a report that I need to give to our team or management. Right now, I can run the query just fine via the built-in search functions in the GUI. However, if I want to export that same data, I don’t really have any options except to run a similar MySQL query against the database itself. I can’t copy and paste the output directly from the GUI without spending a ton of time reformatting it. One row copied from the search output looks like this in plain text:
edge6.phx1
GigabitEthernet2/18
0bps
0bps
0%
0%
0pps
0pps 1Gbps
1500 Ethernet
00:1c:0f:62:e4:00
If there was an option somewhere to basically get the same result data in plain text format in a fixed width font similar to a default SQL query output, that might be helpful to others. Like this:
edge6.phx1 GigabitEthernet2/18 0bps 0bps 0% 0% 0pps 0pps 1Gbps 1500 Ethernet 00:1c:0f:62:e4:00
Or even an option to export the data to XML, a CSV, etc.
I’m making some assumptions about how the data is treated once it’s pulled from the database. Not sure if this would be super-simple or a royal pain in the ass.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Wednesday, November 29, 2017 3:24 PM To: observium@observium.org Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
I'm not sure what you mean, what returned search data?
adam.
Adam Armstrong
Managing Director & Lead Architect
Observium Limited
On 2017-11-29 21:32:29, Sean Pedersen <spedersen.lists@gmail.com mailto:spedersen.lists@gmail.com > wrote:
Had a quick look at the devices used for connection 2 and 3 below.
Ports list info is fine under devices/ports and appears to be about all you can fit in there. It identifies the neighbor interface as well as the port-channel the interface is a member of. Both for Cisco and Brocade. I checked an Arista device and that’s working, too. I did notice that if the supplied device hostname via CDP or LLDP does not match the hostname in Observium, it can’t cross-reference the data, but that’s more my problem. It still shows the neighbor information, just no link to the device. I think that's all that can be captured there.
Went to neighbors and looked at the same interfaces. I don't think I've ever used this interface! Noticed here that it seems to prefer LLDP over CDP. Is that intentional? It looks like CDP may offer more detail, but not sure that's important. For example: I saw an OID for the chassis type with CDP but not LLDP, but with all the other data Observium collects it may not be necessary to pull that info through CDP vs. other sources. I see local device, local port, remote device, remote port, chassis types, interface descriptions, and protocol. I can't think of anything else I'd like to see. All the other data via LLDP or CDP detail commands show info that can be pulled or correlated from other sources.
You know what would be super-helpful, though? I thought of it while looking at the list of search results. If there was a means to hit a link similar to the "Show RRD Command" toggle for graphs that output the returned search data in a more export-friendly format it would save on manual MySQL queries and make it easier to export data. There have been a lot of cases where I've used Observium to pull large amounts of data, but have had to do it via SQL query because the GUI returns results that are not ideal for spreadsheets, etc.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Wednesday, November 29, 2017 1:59 PM To: 'Observium' <observium@observium.org mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
I saw you make the mistake yesterday, but I've been pretty busy these last few days and didn't get a chance to point it out :D
I think our xDP stuff is fairly complete but there might actually be more data returned that we could capture. Did you compare the data returned with what we keep in the neighbours table?
Adam.
Sent from BlueMail http://www.bluemail.me/r?b=11249
On 29 Nov 2017, at 20:32, Sean Pedersen <spedersen.lists@gmail.com mailto:spedersen.lists@gmail.com > wrote:
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 mailto: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 mailto: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 mailto: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 mailto:observium@observium.org > Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
Ok cool :)
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 mailto: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 mailto:observium@observium.org > Cc: 'Observium' <observium@observium.org mailto: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 http://www.bluemail.me/r?b=11249
On 28 Nov 2017, at 14:58, Andrew Lemin <AndrewL@4d-dc.com mailto: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 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 :)
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 mailto: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 mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_____
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
We solved this by only adding the "Core:" prefix to one end of the link... Seems awfully agricultural in this conversation now.
The aggregated core graphs was the only purpose for us adding the tag though. We aren't leveraging it for any extra functions like alerting/matching.
HTH
Michael
On 28 Nov 2017, at 12:43 am, Andrew Lemin AndrewL@4d-dc.com 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.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
What did you add to the other side? CoreB:?
Seems that humans could mess that system up. Humans are dumb.
adam.
Adam Armstrong Managing Director & Lead Architect Observium Limited http://www.observium.org http://docs.observium.org http://jira.observium.org On 2017-11-28 08:52:23, Michael obslist@smarsz.com wrote: We solved this by only adding the "Core:" prefix to one end of the link... Seems awfully agricultural in this conversation now.
The aggregated core graphs was the only purpose for us adding the tag though. We aren't leveraging it for any extra functions like alerting/matching.
HTH
Michael
On 28 Nov 2017, at 12:43 am, 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.
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
What did you add to the other side? CoreB:?
Our case is DCI, but still valid... More or less, something like this
DC1 interface Te1/1/1 description Core: to DC2 something something te1/1/4 {circuit_info} [rate]
DC2 interface Te1/1/4 description to DC1 something something te1/1/1 {circuit_info} [rate]
We have quite a number of dark fibre DCI and use this to show total cross-site throughput.
Seems that humans could mess that system up. Humans are dumb.
Don't worry. We've found/employed most of them. :o
Michael
I like the idea of creating logical representation of links on a map or page of some kind. Similar functionality in other platforms has been very helpful in the past in terms of information presentation, especially when showing things to executive management.
Also - being a logical representation of two ports that would presumably exist in the database somewhere, could logical link alarms be created and to reduce alert spam when a P2P circuit goes down?
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Tuesday, November 28, 2017 3:21 AM To: observium@observium.org Subject: Re: [Observium] Grouping both ends of Core P2P links into single Graph
What did you add to the other side? CoreB:?
Seems that humans could mess that system up. Humans are dumb.
adam.
Adam Armstrong
Managing Director & Lead Architect
Observium Limited
On 2017-11-28 08:52:23, Michael <obslist@smarsz.com mailto:obslist@smarsz.com > wrote:
We solved this by only adding the "Core:" prefix to one end of the link... Seems awfully agricultural in this conversation now.
The aggregated core graphs was the only purpose for us adding the tag though. We aren't leveraging it for any extra functions like alerting/matching.
HTH
Michael
On 28 Nov 2017, at 12:43 am, 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.
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (6)
-
Adam Armstrong -
Adam Armstrong -
Andrew Lemin -
Michael -
Nick Schmalenberger -
Sean Pedersen