Show Link State when viewing links on the Enlinkd topology maps

Description

When viewing the topology map, a user would like to be able to view the status of an Edge (Link) between two Vertices (Nodes) by styling the Link.  In theory, this state could be represented by a color or line styles of the Link and the state could be determined by any API call supported by the Link State Provider.

Environment

PoweredBy OpenNMS

Acceptance / Success Criteria

The very basic requirement here is that the Link should be colored Red when either port associated with the Link is reporting "Down".  Down will be determined by the value of the SNMP object: ifOperStatus.  More advanced state setting capabilities should be considered, i.e. LinkStatusProvider in GraphML Topology, but this is the minimum requirement.  RFC provided below.

 
McCloghrie & Kastenholz Standards Track [Page 31]


RFC 2863 The Interfaces Group MIB June 2000ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), – ready to pass packets
down(2),
testing(3), – in some test mode
unknown(4), – status can not be determined
– for some reason.
dormant(5),
notPresent(6), – some component is missing
lowerLayerDown(7) – down due to state of
– lower-layer interface(s)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets can
be passed. If ifAdminStatus is down(2) then ifOperStatus
should be down(2). If ifAdminStatus is changed to up(1)
then ifOperStatus should change to up(1) if the interface is
ready to transmit and receive network traffic; it should
change to dormant(5) if the interface is waiting for
external actions (such as a serial line waiting for an
incoming connection); it should remain in the down(2) state
if and only if there is a fault that prevents it from going
to the up(1) state; it should remain in the notPresent(6)
state if the interface has missing (typically, hardware)
components."
::= { ifEntry 8 }

Attachments

3

Lucidchart Diagrams

Activity

Show:

Arun Varadharajan December 24, 2021 at 5:13 AM

Please check ticket #713, we have identified more places of exception cause. The fix is incomplete. 

Please review the topology load flow and add check where ever possible. 

Jesse White October 8, 2021 at 5:08 PM

Documented existing behaviour as part of: https://github.com/OpenNMS/opennms/pull/3723

Jesse White October 7, 2021 at 6:44 PM

We'll address this by documentation the behaviour and the use of the "uei.opennms.org/internal/topology/linkDown" alarms to drive the link status.

David Hustace October 6, 2021 at 3:47 PM

Cool!

Jesse White October 6, 2021 at 3:28 PM

Tested with a build from the foundation-2019 branch:

Generate two nodes and a link between them via the Karaf shell:

Determine the node id and ifIndex for one of these using the WebUI:

View the the link in the topology app:

Set the uei.opennms.org/internal/topology/linkDown and uei.opennms.org/internal/topology/linkUp events in etc/events/opennms.linkd.events.xml from *donotpersist* to *logndisplay* and restart.

Trigger a linkDown event for the associated node and ifIndex:

Verify the link in the topology app:

This confirms the current logic and behavior works as expected.

The desired functionality can be achieved via event translator rules or Drools without making code changes to the topology application.

Fixed

Details

Assignee

Reporter

Labels

Internal Priority

High Medium

Estimated Days

Components

Affects versions

Priority

PagerDuty

Created October 5, 2021 at 7:06 PM
Updated April 27, 2022 at 4:38 PM
Resolved October 14, 2021 at 5:25 PM