The previous ifIndex based port mapping schema did detect deleted ports
by checking ports in the DB against the ports currently polled via SNMP
which breaks when using another port mapping schema. This commit fixes
problem by checking known and found ports by their port_id.
Signed-off-by: Maximilian Wilhelm <[email protected]>
$this_port already gets defined within include/polling/ports.inc.php
so there's no need to redefine it again in each submodule.
Signed-off-by: Maximilian Wilhelm <[email protected]>
In 2c9df26bbf I broke the association of
ports in the DB and ports just polled via SNMP for the adsl, etherlike
and poe submodules and no one noticed. This fixes this issue. Sorry.
Signed-off-by: Maximilian Wilhelm <[email protected]>
When using the ifName or ifDescr as means to map discovered ports to
known ports in the DB (think of port association mode) it's possible
that we're facing the problem that the ifName or ifDescr polled from
the device is unset or an empty string (like when querying some ubnt
devices...). If this happends we have no way to map this port to any
port found in the database. As reported this situation may occur for
the time of one poll and might resolve automagically before the next
poller run happens. Without this special case this would lead to new
ports added to the database each time this situation occurs. To give
the user the choice between »a lot of new ports« and »some poll runs
are missed but ports stay stable« the 'ignore_unmapable_port' option
has been added to configure this behaviour. To skip the port in this
loop is sufficient as the next loop is looping only over ports found
in the database and "maps back". As we did not add a new port to the
DB here, there's no port to be mapped to.
I'm using the in_array() check here, as I'm not sure if an "ifIndex"
can be legally set to 0, which would yield True when checking if the
value is empty().
Signed-off-by: Maximilian Wilhelm <[email protected]>
By default libreNMS used the ifIndex to associate ports just found via SNMP
with ports discoverd/polled before and stored in the database. On Linux boxes
this is a problem as ifIndexes are rather likely to be unstable between reboots
or (re)configuration of tunnel interfaces (think: GRE/OpenVPN/Tinc/...), bridges,
Vlan interfaces, Bonding interfaces, etc.
This patch adds a »port association mode« configuration option per device which
allows to map discovered and known ports by their ifIndex, ifName, ifDescr, or
maybe other means in the future.
The default port association mode still is ifIndex for compatibility reasons.
As port RRD files were stored by their ifIndex before, they are now identified
by their unique and stable port_id to ensure a stable and unique mapping and
allow future port association modes to be added without requireing any further
internal changes. Existing RRD files are renamend accordingly in discovery and
poller tools to ensure stability of port associations in both modules as we
don't know which might run first after an update.
Signed-off-by: Maximilian Wilhelm <[email protected]>
This makes the following changes:
- Record per-module performance data in the same measurement as overall poller-perf
- Add tags to distinguish modules
- Update rrd filenames
- Use stacked graph for poller modules
Implements the CISCO-OTV-MIB to retrieve OTV counters from Cisco devices.
This collects information on the configured Overlays and Adjacencies
Statistics are collected for the amount of VLAN's on each overlay and the amount of MAC addresses available over each OTV endpoint.
OTV alerts are collected and generated if the appropriate alerting rules exist.
Data is displayed under routing at both the global and device level.
Includes function snmpwalk_array_num, which performs a numeric SNMPWalk and returns an array containing $count indexes
One Index:
From: 1.3.6.1.4.1.9.9.166.1.15.1.1.27.18.655360 = 0
To: $array['1.3.6.1.4.1.9.9.166.1.15.1.1.27.18']['655360'] = 0
Two Indexes:
From: 1.3.6.1.4.1.9.9.166.1.15.1.1.27.18.655360 = 0
To: $array['1.3.6.1.4.1.9.9.166.1.15.1.1.27']['18']['655360'] = 0
And so on...
Implements the CISCO-CLASS-BASED-QOS-MIB to retrieve QOS counters from Cisco devices.
Policy and Class-map details are collected and stored in the database.
Details are presented on a new "CBQoS" tab of the interface that the policy is applied to.
Includes a policy selector that allows you to select which policy-map to show graphs for.
Each class-map has its own rrd file, in which 3 metrics are stored: Bytes, QoS Drops, Buffer Drops.
This can produce a LOT of rrd files.
As an example:
A Cisco 4500 series switch, running MQC on 200 ports. Each port has a common 5 class queueing policy applied, this creates 1000 (5 x 200) RRD's.
Because of this I have currently set:
```
$config['discovery_modules']['cisco-cbqos'] = 0;
```
Includes function snmpwalk_array_num, which performs a numeric SNMPWalk and returns an array containing $count indexes
One Index:
From: 1.3.6.1.4.1.9.9.166.1.15.1.1.27.18.655360 = 0
To: $array['1.3.6.1.4.1.9.9.166.1.15.1.1.27.18']['655360'] = 0
Two Indexes:
From: 1.3.6.1.4.1.9.9.166.1.15.1.1.27.18.655360 = 0
To: $array['1.3.6.1.4.1.9.9.166.1.15.1.1.27']['18']['655360'] = 0
And so on...
laf
Søren Rosiak
Tony Murray
Daniel Preussker
arrmo
f0o
pblasquez
Maximilian Wilhelm
Aaron Daniels
Paul Gear
vitalisator
Mike Rostermund