SG300 Port Counters via SNMP - do they work?

[Reuben Farrelly]

I've got an SG300-10 connected back to back (trunked) with a Cisco 3560X switch, across a fibre link and am seeing some big inconsistencies in terms of unicast data transferred across the ports between them.

During a night time window of 4am - 6am I run backups which involves a large copy of files, that almost saturates a GigE link - we can see from the 3560X end that the link is running at a bit over 800MBit/sec of throughput, sustained.  The duration of this transfer is consistent with the size of the files being transferred (ie just over an hour, and is what I'd expect for a data transfer of about that amount).  Back-of-the-envelope calculations indicate that the 3560X is measuring this data throughput correctly.

However on the SG300 end of the link, which is also being polled by the same application (Cacti), I'm observing spikey counts of only around 20MBit/sec during that window.  These counters are very obviously incorrect - there's a huge amount more data moving across the port than that.  The incorrect calculations are showing on both the trunk port out of the SG300 (uplink) as well as the interface where the NAS is connected in (which is an access port).

Cacti is polling the OID:  .1.3.6.1.2.1.2.2.1.16.57  which translates to IF-MIB::ifOutOctets.57 = Counter32

I'm running version 1.3.0.62 but this problem is not new to this release - previous releases and 1.2 based releases also had this problem.

It looks like multicast traffic may be being counted correctly (that's only a suspicion though), however what I am certain of is that there is a very large discrepancy with the unicast traffic counts.

Has anyone else experienced this?

Is this OID the correct one to be using for this switch?  I thought interface counter OIDs were all industry standard but....

Reuben

[jeffrrod]

Dear Reuben,

Thank you for reaching the Cisco Small Business Support Community.

I did not find any bug or failure related your particual issue on this latest firmware release v1.3.0.62 even though I passed this info over the development team for revision.

I am not aware of a Cisco recommended Object IDentifier for this Small Business devices so my suggestion is before you run your backup to check on GiE link status; you can go to "Status and Stadistics>Ethernet" and Status a Stadistics>Etherlike", clear the trunk interface counters and check on the results after your backup is over.

Something else would be to check on the optical module status:

Administration > Diagnostics > Optical Module Status

Just for your reference look under chapter 7 on the admin guide for further details on other diagnostics tools:

http://www.cisco.com/en/US/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/78-19308-01.pdf

If there is anything I may assist you with please let me know.

Kind regards,

Jeffrey Rodriguez S. .:|:.:|:.
Cisco Customer Support Engineer

*Please rate the Post so other will know when an answer has been found.

[Reuben Farrelly]

Hi Jeffrey

Thanks for your reply.

Further investigation shows that the web interface is also showing incorrect counts, as well as via SNMP.  However the counts in the CLI are correct.

To test this I copied a 246G file from server to storage (from a port on the Catalyst switch, to the storage port on the SB300 switch), and the counts show:

1. Catalyst Switch uplink:

GigabitEthernet1/4 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet, address is a493.4c1f.471c (bia a493.4c1f.471c)

  Description: Trunk Link to switch-4

  MTU 9198 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

     reliability 255/255, txload 185/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive not set

  Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP

  input flow-control is off, output flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:14, output 00:00:00, output hang never

  Last clearing of "show interface" counters 00:45:03

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 611

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 3083000 bits/sec, 4082 packets/sec

  5 minute output rate 727120000 bits/sec, 59728 packets/sec

     11156317 packets input, 1051020064 bytes, 0 no buffer

     Received 1927 broadcasts (1812 multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 1812 multicast, 0 pause input

     0 input packets with dribble condition detected

     173028780 packets output, 263286174429 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier, 0 pause output

     0 output buffer failures, 0 output buffers swapped out

2. Cisco SB switch uplink:

switch-4#show int counters GE 9

      Port       InUcastPkts  InMcastPkts  InBcastPkts    InOctets  

---------------- ------------ ------------ ------------ ------------

      gi9         173006502      22022         502      263286205400

      Port       OutUcastPkts OutMcastPkts OutBcastPkts  OutOctets  

---------------- ------------ ------------ ------------ ------------

      gi9          11154765       1816         115       1051355248 

Alignment Errors: 0

FCS Errors: 0

Single Collision Frames: 0

Multiple Collision Frames: 0

SQE Test Errors: 0

Deferred Transmissions: 0

Late Collisions: 0

Excessive Collisions: 0

Carrier Sense Errors: 0

Oversize Packets: 0

Internal MAC Rx Errors: 0

Symbol Errors: 0

Received Pause Frames: 0

Transmitted Pause Frames: 0                          

switch-4#

This matches what we're seeing on the Catalyst switch and also matches the expected size of the file.

3. Web Interface view in Status and Statistics -> Interface -> Ge9:

Receive Statistics

Total Bytes (Octets):     1293218418

Unicast Packets:     173006562

Multicast Packets:     22090

Broadcast Packets:     504

Packets with Errors:     0

Transmit Statistics

Total Bytes (Octets):     1051378320 

Unicast Packets:     11154823

Multicast Packets:     1827

Broadcast Packets:     115

Note that the Total Bytes transmitted is about right, but the total bytes received is NOT, by a significant amount.

4. SNMP graphs (attached).  This first graph is of Gi9 on switch-4, which is the port on the SB-300 connected to the Catalyst switch.  Supposedly peaking at somewhere between 80-100MBit/sec.

And here's the graph from Gi1/4 which is the port on the Catalyst connected to the SB switch, showing the actual and correct throughput of about 600-800 MBit/sec:

So, in summary: the problem appears to be in the counting of received bytes on ports, both within the Web interface as well as SNMP.  The underlying CLI is correctly counting but the SNMP and also the Web views are not.

Can you advise where to go next either in terms of what to test or how we go about getting this fixed?

Thanks,

Reuben

Message was edited by: Reuben Farrelly - updated highlighting of sent and receive counts