Interface Deleted with SNMP supported and no ipAddrTable

Description

I was adding a Raritan power device to OpenNMS using a newSuspect event. Capsd is turned off and provisiond is handling them.

It turns out that while it supports SNMP it does not support the ifTable or ipAddrTable:

[tarus@barbrady ~]$ snmpwalk -v2c -c public 24.38.102.49 system
SNMPv2-MIB::sysDescr.0 = STRING: Raritan Dominion PX - Firmware Version 010305-7832
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.13742.4
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12123972) 1 day, 9:40:39.72
SNMPv2-MIB::sysContact.0 = STRING: nobody@nowhere
SNMPv2-MIB::sysName.0 = STRING: Circuit_3
SNMPv2-MIB::sysLocation.0 = STRING: Raritan Somerset Rack 2
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (117) 0:00:01.17
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.5 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.2 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORDescr.3 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.5 = STRING: The management information definitions for the SNMP User-based Security Model.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (21) 0:00:00.21
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (21) 0:00:00.21
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (117) 0:00:01.17
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (117) 0:00:01.17
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (117) 0:00:01.17
[tarus@barbrady ~]$ snmpwalk -v2c -c public 24.38.102.49 iftable
IF-MIB::ifTable = No Such Object available on this agent at this OID
[tarus@barbrady ~]$ snmpwalk -v2c -c public 24.38.102.49 ipaddrtable
IP-MIB::ipAddrTable = No Such Object available on this agent at this OID

This causes bad things to happen. First, the services are discovered, then the interface is deleted along with the new services. This sounds like improper behavior, as we have to deal with lame SNMP agents all of the time. See attached screenshot and logs.

Environment

Operating System: All Platform: PC

Acceptance / Success Criteria

None

Attachments

3

Lucidchart Diagrams

Activity

Show:

Matt Brozowski July 28, 2011 at 2:07 PM

Ok... This is actually fixed now in 1.10

Now primary interfaces are not marked as obsolete and removed when agents have no ipaddr or interfaces tables

Matt Brozowski July 28, 2011 at 11:15 AM

I think I see what is happening...

Apparently this is NOT a provisioned node and that's the difference

Matt Brozowski July 27, 2011 at 3:53 PM

I took the mib included here and created a test for this..

and it seems to be working correctly.

Can you verify that this still happens in 1.10?

I am marking as resolved but feel free to reopen

Seth Leger (community account) October 22, 2010 at 5:27 PM

  •  

    •  

      • has been marked as a duplicate of this bug. ***

Austin Papp July 9, 2010 at 10:45 PM

(From update of attachment 1047)
getting multiple nodes for a single IP address.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created July 3, 2010 at 7:31 PM
Updated January 27, 2017 at 4:26 PM
Resolved July 28, 2011 at 2:07 PM