Anomalia on graphic report.

[Miller Echagarreta]

Hi everyone.

 

I need your help for understand this.

 

I have a router-switch of type alcatel monitored with snmpcollector.

When generate a report, the day 30 Jun, 2 interfaces showing a peak of 27.40gb and 22.29gb in qos_bits_in. This device have a nominal speed of 10gb.

 

 

My questions are:

 

1- If the nominal speed is 10gb, Why the qos max and value are above the 10gb?.

2- Why the max indicate 21.16gb if on the graphic only the top is 16.79gb?. The graphic not achieves to 21.16gb

 

For this graphic, is normal that exist space whe select aggreggation to 5 minutos?

 

 

Best Regards.

 

ME.

[Kathy Maguire]

1.  Is the ifSpeed returned by the device for the ifSpeed OID correct?  Is the ifSpeed actually 10Gbps for this device?  If ifSpeed returned by the device for the ifSpeed OID is incorrect this will result in erroneous interface metric calculations. You need to first verify with the device administrator to determine if the ifSpeed is really 10Gbs for this interface.  If it is not, then you need to provide Speed In and Speed Out interface override values for the device in the snmpcollector Configure GUI to force the probe to use the correct ifSpeed in the interface metric calculations.  You will not see the speed overrides appear in the UMP USM portlet though.  I believe it will still report the ifSpeed returned by the device for the ifSpeed OID.

 

If the ifSpeed returned by the device for the ifSpeed OID is correct, then I would recommend that you open a support case to pursue this further.

 

2.  I am not sure why the 21.16gb max value reported in the table is not displayed on the chart for the time interval specified.  If you do not get an answer is this forum, I would recommend opening a support case to get your answer.

 

3.  I believe that the gaps you are seeing in the Performance chart are an indication that the snmpcollector probe failed to collect any QoS data during those intervals.  Either the device did not respond to the snmpget request in time or something else occurred.  The only way to track this would be to check the snmpcollector log files from the time the gaps appear to see if there is any indication as to why there is no data.

[Miller Echagarreta]

Thank you for your comments and your time. I will working with your suggestions.

[David Michel]

Device side, if it is using a 32bit counter for the interface it could have rolled over producing the one time spike.

[Miller Echagarreta]

DavidM, how can I validate if the interface it is using a 32bit counter?

[David Michel]

Miller,

 

You can't. It is necessary to have the network engineer responsible for the device to check it, since a login to the device itself is needed.

 

david

[Robert Kettles]

It comes down to the OIDs that are being used to collect your statistics.  If it's ifInOctets, it's 32 bit:

 

ifInOctets OBJECT-TYPE
    SYNTAX Counter32 (0 .. 4294967295)
    ACCESS read-only
    STATUS current

 

    DESCRIPTION
    "The total number of octets received on the interface,
            including framing characters.

 

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime."
     ::= { ifEntry 10 }

 

-- 1.3.6.1.2.1.2.2.1.10

 

You should probably use ifHCInOctets instead which are the 64 bit equivalent:

 

ifHCInOctets OBJECT-TYPE
    SYNTAX Counter64 (0 .. 9223372036854775807)
    ACCESS read-only
    STATUS current

 

    DESCRIPTION
    "The total number of octets received on the interface,
            including framing characters.  This object is a 64-bit
            version of ifInOctets.

 

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime."
     ::= { ifXEntry 6 }

 

-- 1.3.6.1.2.1.31.1.1.1.6

[Miller Echagarreta]

Thank you Robert.