For some interfaces of specific devices, you may often see the event: 0x10d80 that may affect the IN_LOAD and OUT_LOAD monitoring.
Problem detected with data in the Interface Performance Calculations
What are the possible causes of event? And how to prevent it from occurring?
DX NetOps Spectrum all currently supported releases
When checking the SOURCE DATA, we see:
Initial X_IN_OCTETS: 3690255947302006Final X_IN_OCTETS: 3690261998657745Initial X_OUT_OCTETS: 3936512669608771Final X_OUT_OCTETS: 3936532747070030Initial X_IN_ERROR_PKTS: 2Final X_IN_ERROR_PKTS: 2Initial X_OUT_ERROR_PKTS: 0Final X_OUT_ERROR_PKTS: 0Initial X_IN_NO_RESOURCE_PKTS: 0Final X_IN_NO_RESOURCE_PKTS: 0Initial X_OUT_NO_RESOURCE_PKTS: 0Final X_OUT_NO_RESOURCE_PKTS: 0Initial X_IN_NUCAST_PKTS: 41193845Final X_IN_NUCAST_PKTS: 41193872Initial X_OUT_NUCAST_PKTS: 3084851016Final X_OUT_NUCAST_PKTS: 3084851044Initial X_IN_MCAST_PKTS: 41193828Final X_IN_MCAST_PKTS: 41193855Initial X_OUT_MCAST_PKTS: 3084851004Final X_OUT_MCAST_PKTS: 3084851032Initial X_IN_BCAST_PKTS: 17Final X_IN_BCAST_PKTS: 17Initial X_OUT_BCAST_PKTS: 12Final X_OUT_BCAST_PKTS: 12Initial X_IN_UCAST_PKTS: 3409694604525Final X_IN_UCAST_PKTS: 3409701142611Initial X_OUT_UCAST_PKTS: 3745949816989Final X_OUT_UCAST_PKTS: 3745965376977Initial X_IN_UNKNOWN_PROTOS: 0Final X_IN_UNKNOWN_PROTOS: 0Initial X_SYSTEM_UP_TIME: 3542613419Final X_SYSTEM_UP_TIME: 3542614427Delta SYSTEM_UP_TIME: 1008PREVIOUS IFTYPE: 6CURRENT IFTYPE: 6PREVIOUS X_LOW_BANDWIDTH: 4294967295CURRENT X_LOW_BANDWIDTH: 4294967295PREVIOUS X_HIGH_BANDWIDTH: 10000CURRENT X_HIGH_BANDWIDTH: 10000
From this, the CALCULATED METRICS are:
PREVIOUS BIT_RATE_IN: 0PREVIOUS BIT_RATE_OUT: 0CURRENT BIT_RATE_IN: 4802663284CURRENT BIT_RATE_OUT: 15934493062PREVIOUS LOAD_TOTAL: 0PREVIOUS LOAD_IN: 0PREVIOUS LOAD_OUT: 0CURRENT LOAD_TOTAL: 207CURRENT LOAD_IN: 48CURRENT LOAD_OUT: 159PREVIOUS IN_THROUGHPUT_PKTS: 0PREVIOUS OUT_THROUGHPUT_PKTS: 0PREVIOUS TOTAL_THROUGHPUT_PKTS: 0CURRENT IN_THROUGHPUT_PKTS: 648622CURRENT OUT_THROUGHPUT_PKTS: 1543652CURRENT TOTAL_THROUGHPUT_PKTS: 2192274PREVIOUS PERCENT_ERROR_PKTS: 0CURRENT PERCENT_ERROR_PKTS: 0PREVIOUS PERCENT_IN_ERRORS: 0CURRENT PERCENT_IN_ERRORS: 0PREVIOUS PERCENT_OUT_ERRORS: 0CURRENT PERCENT_OUT_ERRORS: 0PREVIOUS PERCENT_DISCARDED_PKTS: 0CURRENT PERCENT_DISCARDED_PKTS: 0PREVIOUS PERCENT_IN_DISCARDS: 0CURRENT PERCENT_IN_DISCARDS: 0PREVIOUS PERCENT_OUT_DISCARDS: 0CURRENT PERCENT_OUT_DISCARDS: 0
One of the possible cause of 0x10d80 is that some X_IN value is > than the corresponding X_OUT value (see KB : Alarms in Spectrum for "IN/OUT LOAD THRESHOLD EXCEEDED” show values over 100%), but also if the data is consistent, per Spectrum design, the SpectroSERVER raises the 0x10d80 event when current LOAD_TOTAL(LOAD_IN + LOAD_OUT) value exceeds default threshold of 200.
Increasing the port_perf_valid_result_age may help to reduce the frequency of the 0x10d80 event. This parameter is set in the .vnmrc file located on the SpectroSERVER under:
$SPECROOT/SS
During port performance calculation two attributes read from .vnmrc file. The first attribute is port_perf_valid_result_age (Default 8 sec) and the second one is port_perf_node_ageout (Default 900 secs).
It you configure the port_perf_valid_result_age attribute value to 60 secs this means spectrum polls the interface only once every 60 secs.
If any request comes from oneClick during valid time age, spectrum simply returns already calculated metrics (cached results) instead of new polling on the interface.
The other attribute port_perf_node_ageout value is used for identifying the stale node of an interface in case polling fails.
INTERNAL SOURCES ATTRIBUTES
0x12daa0x12dab0x12dac0x12db60x12db20x12db40x12db80x12dad0x12db70x12db30x12db50x130d10x12dfa0x12db00x12dae0x12db10x12daf0x12bb50x12bb40x2201770x12df9
EXTERNAL SOURCES ATTRIBUTES:
0x11f650x11f690x11f660x113170x113180x113190x1131a0x11f6a0x1131e0x1131f0x113210x113480x1134c0x11f6c0x11f6d0x11f700x11f710x11f6b0x22001a0x22001a0x22005e