Port Stats not showing accurate count for Bytes Received (Bytes Rx)

[Ramzah_Rehman]

Hello. I have an Aruba 2930F switch. I have a 1 hop network containing 2 host machines connected to the switch. I send ~5GB of data from the sender to the receiver. ~5GB is received successfully on the receiver (I have counted the number of bytes on the receiver). However, the ingress port, port 25 in this case, (connected to the sender) only shows ~1GB of data on the "bytes Rx" field. Please let me why it's happening. Is it some kind of bug in the switch? I verified how much packets have been received from the sender through flow rule stats as well, the flow rule stats show a packet count of 3536747 (~5GB) as well.

I have attached the stats for port 25, flow rule, as well as the result of my client application that received ~5GB of data.

I need reliable stats for my research. Please reply as soon as possible. Early waiting for the response. Thanks!

[Emil_G · Accepted solution]

Hello

The Bytes Rx statistic is taken from the OID ifinOctets. This OID has a 32 bit counter. The maximum value of a 32 bit counter should be 4 294 967 295. 

So this simply means that the counter reached its maximal value and started counting from 0. If you add 1 075 672 819 to 4 294 967 29 you will get to expected amount of traffic.

COuld you please try the command "show interface 25 hc" if there will be any difference.

[Ramzah_Rehman]

All right. I get it. yes, there's no difference.

Can you please share any documentation where I can find the allocated bytes for each counter? That would help me with interpreting other counters as well.

[Emil_G]

Hello, 

The "hc" in the command show interface 25 hc means High Capacity. This command should use high capacity (64 bit) counters. For example for Bytes Rx it should use ifHCInOctets from rfc 2863

ifHCInOctets OBJECT-TYPE
    SYNTAX      Counter64
    MAX-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 }

However I am not sure if 2930F implements this for all interfaces or only for the uplinks. If you dont see a difference between show interface 25 and show interface 25 hc, you can try to use ifHCInOctets either from an SNMP management statation or from the CLI of the switch using the command walkmib ifHCInOctets adding the interface index.

Aruba-2930F# walkmib ifHCInOctets.25

The following command can help you to verify which port corresponds to which SNMP interface index.

Aruba-2930F# walkmib ifdescr

[Ramzah_Rehman]

oh Actually, hc is implemented for 2930F switch. with hc, I do see ~5GB of data to be sent. So, hc is working fine.

What I want to ask is, I know now that for Bytes Rx there are 32 (without hc) and 64 bit (with hc) counters, right. I want to know the size of counters for other stats shown in port stats, such as Discards Rx, Bytes Tx, Drops Tx, etc. Is there any documentation that you can refer me for this? 

[Emil_G]

Hi, 

I sent to you a little bit more information which SNMP OIDs are used in the show interface commands. You can find information if they are using 32 bit or 64 bit counters in the internet. For example you can find a lot of information in rfc2863.

For example Discards Rx is using ifInDiscards. In rfc2863 you can find that it is 32 bit counter. This should be sufficient for discards because they are not usuall network events and shouldnt happen so freuqently.

ifInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of inbound packets which were chosen to be
discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One
possible reason for discarding such a packet could be to
free up buffer space.

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 13 }