Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Capsd Use Case: OpenNMS continues to show an ip address associated with node that was removed during maintenance

Description

One of our routers was properly discovered when I initially set OpenNMS up for evaluation. During a maintenance window, one of the interfaces was reconfigured with a new address. Since then, the Node page shows both the correct ip address (207.98.64.186) for the interface (FastEthernet0/0) and the incorrect ip address (207.98.64.195).

An interesting sidenote is that the Interfaces table on the page shows two interfaces with the same ifIndex. They are both named FastEthernet0/0 and have an ifIndex value of 9.

One other interesting sidenote is that if I go to the Admin page to configure data collections for SNMP interfaces on this device, it shows only one interface with an ifIndex of 9 and that interface has the correct ip address.

Below is the output when walking the ipAdEntIfIndex table against the device in question:

IP-MIB::ipAdEntIfIndex.140.211.0.129 = INTEGER: 38
IP-MIB::ipAdEntIfIndex.140.211.0.133 = INTEGER: 27
IP-MIB::ipAdEntIfIndex.140.211.0.137 = INTEGER: 39
IP-MIB::ipAdEntIfIndex.140.211.0.141 = INTEGER: 28
IP-MIB::ipAdEntIfIndex.140.211.0.145 = INTEGER: 31
IP-MIB::ipAdEntIfIndex.140.211.0.157 = INTEGER: 29
IP-MIB::ipAdEntIfIndex.140.211.0.161 = INTEGER: 19
IP-MIB::ipAdEntIfIndex.140.211.0.165 = INTEGER: 20
IP-MIB::ipAdEntIfIndex.140.211.0.169 = INTEGER: 34
IP-MIB::ipAdEntIfIndex.140.211.0.189 = INTEGER: 41
IP-MIB::ipAdEntIfIndex.140.211.2.1 = INTEGER: 40
IP-MIB::ipAdEntIfIndex.140.211.8.1 = INTEGER: 37
IP-MIB::ipAdEntIfIndex.140.211.14.254 = INTEGER: 42
IP-MIB::ipAdEntIfIndex.207.98.64.53 = INTEGER: 16
IP-MIB::ipAdEntIfIndex.207.98.64.178 = INTEGER: 35
IP-MIB::ipAdEntIfIndex.207.98.64.186 = INTEGER: 9
IP-MIB::ipAdEntIfIndex.207.98.64.248 = INTEGER: 15

Lastly, here is the entry from the table ipinterface in the database:

opennms=# SELECT ipinterface.nodeid, ipaddr, ifindex, ipstatus, iplastcapsdpoll, iphostname, nodesysname FROM node, ipinterface WHERE ipaddr = '207.98.64.195' AND node.nodeid = ipinterface.nodeid;
nodeid | ipaddr | ifindex | ipstatus | iplastcapsdpoll | iphostname | nodesysname
-------------------------------+--------+---------------------------------------------------------------------- 15 | 207.98.64.195 | 9 | 1 | 2008-01-20 12:05:55.066 | corv-car2-gw.nero.net | corv-car2-gw.nero.net

Please let me know what other information would be of assistance in diagnosing this.

Environment

Operating System: Linux Platform: PC

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jeff Gehlbach February 5, 2016 at 10:02 AM

Capsd is dead. Won't fix.

Cyrille Bollu February 5, 2016 at 3:48 AM

Hello jeff,

This issue shall be closed in my opinion (concerning capsd).

Would you mind closing it?

Cyr

Philippe Guillebert April 1, 2009 at 12:46 PM

Hey,

I just ran into this bug doing the following use case :

  • Added a temporary interface on a node (unreacheable from ONMS manager),

  • This interface got auto-discovered by SNMP interface table and associated with the node (neat)

  • Deleted this interface on the node

  • The interface is not deleted from ONMS. The ONMS web interface table is showing the temporary IP, eve if the SNMP data does not show this interface anymore.

This occured on 1.6.2.

I'm hoping the upcoming rewrite of capsd will consider this problem.

Former user March 20, 2008 at 10:55 AM

I am going to post pone this as a use case for the upcoming capsd rewrite

Stephen Fromm March 18, 2008 at 7:15 PM

(In reply to comment #7)
> I do accept the circumstances you present, but since it does cut both ways, the
> final decision on this sort of behavior has to be down to the OpenNMS
> administrator.

Yes, this basically comes down to a matter of workflow.

> A compromise position would have to cater for both alternatives. Maybe a top
> level switch buried deep in a configuration file that selects which mode the
> system uses.

Agreed. This has the benefit of supporting both approaches and lets the administrator choose what is best for his/her site.

> Regarding the visual clue, a comparison between SNMP interface information and
> network-discovered information could be used to flag addresses that are no
> longer present. One of the programmer types could suggest whether this is
> feasible or if I'm talking out of my bum.

I only mention the visual cue as an alternative in case treating the device as authoritative is not doable. My preference would be to allow the administrator to make that choice.

The visual cue may have its own benefits that are in addition to allowing the administrator to configure which source is authoritative.

Won't Fix

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

PagerDuty

Created January 25, 2008 at 3:15 PM
Updated June 23, 2016 at 3:49 PM
Resolved February 5, 2016 at 10:02 AM