Page History

...

The "Reason" describes why NMIS has decided to not collect this interface; in this particular case the model for the device has specified that interfaces without Description are to be ignored.

Depending on your model and version of NMIS, the labels on the Interface Details page may be slightly different from the example:

• The "Name" generally refers to the SNMP properties ifDescr or ifName (availability of the latter depends on the hardware in question)
• "Description" almost universally refers to the SNMP property ifAlias.
• "Type" refers to ifType.
• "Hardware" (if present) refers to ifDescr. This is for cases where the interface "Name" is dynamically chosen from the 'best available' source (e.g. ifName or ifDescr if ifName isn't supported).

NMIS 8.6 and newer ship with models that have amended labels which include the relevant source, for example "Hardware (ifDescr)" and "Type (ifType)" for greater clarity.

Overriding NMIS' choices for one node

...

Here is an example:

'collect' => {
  'Description' => '(CNOC|Collection)',
  'ifDescr' => '(FastEthernet|ATM)',
},
'nocollect' => {
  'ifOperStatus' => 'null',
  'ifDescr' => 'sublayer|null|controller',
  'Description' => '^#',
  'noDescription' => 'true',
  'ifType' => 'other|softwareloopback|propVirtual|slip'
}

...

Like before, global_nocollect_noDescription is a true/false setting, whereas the others are all interpreted as regular expressions (if not missing or empty).  Keep in mind that these are regular expressions, therefore if we wanted to not collect ifType's propVirtual & l2vlan the syntax would look like this:

    'global_nocollect_ifType' => 'l2vlan|propVirtual',

Please note that the checkable properties aren't  necessarily labelled the same on the Interface Details page (e.g. setting global_collect_ifDescr compares the ifDescr value against the given regular expression, but the ifDescr data is likely labelled "Name" in the GUI).

The  sequence of checks is as follows:

...

Please note that changes to any of these globals also don't become effective until the next type=update operation is performed.

Interfaces which have been down for a long time

NMIS includes a feature which will disable collecting of interfaces which are down for a period of time, by default, this is 30 days, this is because if down for 1 month, it is likely the interface is not being used anymore.  This feature can be disabled by setting the value in the Config.nmis for global_nocollect_interface_down_days to a very high number, like 5000 or more.  Or the interface can be set in Node Config to always collect.

This feature is based in the ifLastChange MIB for each interface. By definition, ifLastChange is "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value.". Some Fortigate devices have been identified as not updating the ifLastChange when ifOperStatus is changed. That will set the interfaces with operational status down as no collect after sysUpTime days is greater than global_nocollect_interface_down_days (30 days by default). In this case, setting global_nocollect_interface_down_days to a really high value is recommended to disable the feature, to prevent the interfaces not being collecting were they should be.