Instance discovery filtering script for adding only Interfarfaces with IPs

[blazarov]

Hi,
I am working on setting up instance discovery for our routers in order to have the DCIs automatically created for all interfaces that have IP addresses set.
I have almost made it working using this script:

snmp = CreateSNMPTransport($node);

if (snmp == null)
	return -1;

oid = ".1.3.6.1.2.1.4.20.1.2"; // ip-to-ifindex relationship
vars = SNMPWalk(snmp, oid);

if (vars == null)
	return -2; // SNMPWalk failed

foreach (v: vars) {
	trace(5, "SNMP WALK ".v->name."=".v->value);
	if (v->value == $1) {
		ifName = SNMPGetValue(snmp, ".1.3.6.1.2.1.2.2.1.2." . $1);
		trace(5, "interface index id ".$1." has IP and its name is ".ifName." so we return true");
		return %(true, $1, ifName);
		} else {
		trace(5, "interface index id ".$1." has no IP and its name is ".ifName." so we return false");
		return %(false, $1, ifName);
		}
}

The issue is that it seems that SNMPWalk function returns only the first row instead of array of all 6 rows. So when I initiate instance discovery it creates a DCI only for instance id 5 (the first row from snmpwalk).

Here are some tests with snmpwalk:

# snmpwalk -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.4.20.1.2
IP-MIB::ipAdEntIfIndex.10.10.2.110 = INTEGER: 5
IP-MIB::ipAdEntIfIndex.10.207.141.109 = INTEGER: 11
IP-MIB::ipAdEntIfIndex.172.16.1.110 = INTEGER: 8
IP-MIB::ipAdEntIfIndex.172.20.1.110 = INTEGER: 9
IP-MIB::ipAdEntIfIndex.172.20.5.110 = INTEGER: 10
IP-MIB::ipAdEntIfIndex.192.168.110.1 = INTEGER: 7

cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.5
IF-MIB::ifDescr.5 = STRING: FastEthernet4
cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.11
IF-MIB::ifDescr.11 = STRING: Vlan2
cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.8
IF-MIB::ifDescr.8 = STRING: Loopback0
cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.9
IF-MIB::ifDescr.9 = STRING: Tunnel11
cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.10
IF-MIB::ifDescr.10 = STRING: Tunnel13
cnr-srv-11:~ # snmpget -v 2c -c CyIraBpNx3JjBqUDExzM 172.16.1.110 .1.3.6.1.2.1.2.2.1.2.7
IF-MIB::ifDescr.7 = STRING: Vlan1

Please help - where am I wrong?

P.S. what happens when an interface gets deleted - does netxms delete the relevant DCIs?

[victor]

Hi,

how instance discovery is configured? Are you sure that you have correct ifIndex in $1 in filter? I just checked WNMP walk part of the script on my system (using execute server script option on node object) and it works fine - returns all IP addresses on my router.

Server will delete DCIs created by instance discovery if instance will gone.

Best regards,
Victor

[blazarov]

Hi Victor,
thanks for your input. Yes I've checked everything and everything is as expected, but still the "foreach" node of the filtering script seems like it execute only once - with the value of the first row of the snmpwalk.
Anyways, however I just had a great idea that I can achieve the same functionality with much simpler script, just by reversing the logic. I already made it and it works just as expected.
Here's what I did:

• Instance discovery method = SNMP Walk Values ; Base SNMP OID: .1.3.6.1.2.1.4.20.1.2

Then my filtering script:
snmp = CreateSNMPTransport($node);
ifName = SNMPGetValue(snmp, ".1.3.6.1.2.1.2.2.1.2." . $1);
if (ifName ~= "Loopback.*") {
    return %(false, $1, ifName);
} else {
    return %(true, $1, ifName);
}

Basically I am first SNMPwalking the ipAdEntIfIndex table which returns all IP addresses with a value if the corresponding ifIndex. So I don't need any further filtering - In the values I am getting only ifIndex of all interfaces with IP address set.
Then with the filtering script I am only polling the interface name, along with a quick check to filter out the Loopbacks, because I don't need to monitor them.

Thank you guys, I am getting to like the NetXMS more and more!

I just still don't understand what happens when some interface is deleted and instance discovery runs. Are the DCI with their history completely deleted? Is there a way to control that - for example leave - delete them one month after disappearing?

[victor]

@blazarov said in Instance discovery filtering script for adding only Interfarfaces with IPs:

I just still don't understand what happens when some interface is deleted and instance discovery runs. Are the DCI with their history completely deleted? Is there a way to control that - for example leave - delete them one month after disappearing?

currently no - DCIs deleted instantly when instance discovery poll founds that instance do not exist anymore. Feel free to register a feature request - it sounds reasonable and should be relatively easy to implement.

Best regards,
Victor

[user54119]

If you register a feature request for that. We also have problems like that:

We use instance discovery on VPN-appliances for site-2-site tunnels.
If one tunnel goes down for a short time and in this moment instance discovery runs, all DCIs for this tunnel are deleted. Then the tunnel goes up again. On the next instance discovery run new DCIs will be created for the same tunnel. Now there are different DCIs for the same tunnel, now without history.

At the moment I don't know what would be the best solution for that. Otherwise I would already register the feature request. The best behavior for us would be to have the same DCIs (same number) after that. But I don't know how you could do that.

thanks
Dani

[victor]

Grace period when DCIs won't be deleted immediately after instance disappear should solve your problem as well. When tunnel goes up again data collection will continue (assuming it is on same OID).

Best regards,
Victor

[blazarov]

Yes, dynamic tunnels, e.g. PPTP, OpenVPN are bitch to monitor. Mikrotik have nice feature to create a virtual interface statically bound to a specific client that helps.
My request is more related to statically configured interfaces such as GRE tunnels or dot1q subinterfaces which does not change that often, but when someone does it noone cares to go to the monitoring system to do the proper changes. So what Victor suggests with a new feature for grace period will work perfectly fine for my case. I need that mostly just in case if we need to check some historical stats for an interface that has been deleted lately.
Posting a feature request.