Wired Intelligent Edge

last person joined: 15 hours ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

S2500 - Excessive error octets/CRC frames on one stack port

This thread has been viewed 2 times
  • 1.  S2500 - Excessive error octets/CRC frames on one stack port

    Posted Aug 07, 2019 11:00 AM

    Hi all.  Hoping that you might be of some assistance.  Plan to open a TAC on this soon, but waiting for (badly timed) renewal of service contract to process before being able to do so, so I figured I'd reach out to the community to see if anyone had any ideas/fixes.

     

    I've got a stack of eight S2500s over three floors of our building (3/3/2) and one of the units on the floor with two switches (a 24T) is showing an extreme number of error octets and CRC frames on the downlink stack port (but the corresponding uplink stack port from the adjacent floor has 0 errors).  I have replaced the SFP transceiver at that port with a new unit and still am getting a similar number of error octets on the same port.  The only other port that shows any error octets is the switch that this particular switch downlinks to (a 24P), and only on the downlink side (none on the uplink side) and those are both numerous orders of magnitude less and not increasing over time.

     

    For behavior, I saw at least one instance where all 24 ethernet ports on both switches briefly shifted to yellow "stack ports" on the GUI.  I did review  this thread but was unable to solve my issue.  The main issues this is causing an excessive amount of rebootstrapping of our wireless APs, along with network "pauses" that cause applications like videconferencing to freeze up temporarily for as long as 60 seconds.

     

    Running 7.4.1.9 on all switches on the stack (know that 7.4.1.10 is available - can't get image until service contract is back in place).  Can provide whatever other information that might be helpful as well.  Thanks for any assistance you can provide in advance.



  • 2.  RE: S2500 - Excessive error octets/CRC frames on one stack port

    Posted Aug 07, 2019 12:35 PM

    For some additional information, here is the stacking interface information for the switch having the issues first (#6)

     

     

    (ArubaS2500-48T-1) #show stacking interface member 6

     

    (ArubaS2500-48T-1) #show stacking interface member 6
    
    Member-id: 6 
    ------------
    stack1/2
    --------
    stack1/2 is administratively Enabled, link is Up, line protocol is Up
    Speed: 10 Gbps, MTU: 9224 bytes, Link flaps: 11
    Last update of counters: 	0d 00:00:06 ago
    Last clearing of counters: 	1d 02:46:17 ago
    Link status last changed: 	0d 02:08:43 ago
    Statistics:
        Received 16793846 frames, 8947886195 octets
        110 pps, 372.316 Kbps
        2425855 broadcasts, 0 runts, 0 giants, 0 throttles
        1440258389 error octets, 1150308 CRC frames
        1976477 multicast, 12391514 unicast
        Transmitted 4126913 frames, 1055738067 octets
        38 pps, 47.992 Kbps
        53629 broadcasts, 0 throttles
        62818 multicast, 4010466 unicast
        0 errors octets, 0 deferred
        0 collisions, 0 late collisions
     
    stack1/3
    --------
    stack1/3 is administratively Enabled, link is Up, line protocol is Up
    Speed: 10 Gbps, MTU: 9224 bytes, Link flaps: 0
    Last update of counters: 	0d 00:00:06 ago
    Last clearing of counters: 	1d 02:46:17 ago
    Link status last changed: 	1d 02:46:06 ago
    Statistics:
        Received 1612300 frames, 551209269 octets
        7 pps, 16.282 Kbps
        42512 broadcasts, 0 runts, 0 giants, 0 throttles
        0 error octets, 0 CRC frames
        44586 multicast, 1525202 unicast
        Transmitted 13321788 frames, 6267769637 octets
        74 pps, 134.777 Kbps
        2413133 broadcasts, 0 throttles
        1713922 multicast, 9194733 unicast
        0 errors octets, 0 deferred
        0 collisions, 0 late collisions

    And the switch that is upstream from it (#0)

    (ArubaS2500-48T-1) #show stacking interface member 0
    
    Member-id: 0 
    ------------
    stack1/2
    --------
    stack1/2 is administratively Enabled, link is Up, line protocol is Up
    Speed: 10 Gbps, MTU: 9224 bytes, Link flaps: 0
    Last update of counters: 	0d 00:00:05 ago
    Last clearing of counters: 	1d 02:39:34 ago
    Link status last changed: 	1d 02:39:11 ago
    Statistics:
        Received 56947987 frames, 54699813651 octets
        127 pps, 192.406 Kbps
        2314117 broadcasts, 0 runts, 0 giants, 0 throttles
        0 error octets, 0 CRC frames
        2806303 multicast, 51827567 unicast
        Transmitted 50327620 frames, 58834986351 octets
        92 pps, 305.929 Kbps
        224151 broadcasts, 0 throttles
        257943 multicast, 49845526 unicast
        0 errors octets, 0 deferred
        0 collisions, 0 late collisions
     
    stack1/3
    --------
    stack1/3 is administratively Enabled, link is Up, line protocol is Up
    Speed: 10 Gbps, MTU: 9224 bytes, Link flaps: 9
    Last update of counters: 	0d 00:00:05 ago
    Last clearing of counters: 	1d 02:39:34 ago
    Link status last changed: 	0d 02:08:37 ago
    Statistics:
        Received 4126729 frames, 1055705275 octets
        38 pps, 139.896 Kbps
        53628 broadcasts, 0 runts, 0 giants, 0 throttles
        0 error octets, 0 CRC frames
        62817 multicast, 4010284 unicast
        Transmitted 18055012 frames, 10422960266 octets
        78 pps, 106.027 Kbps
        2462964 broadcasts, 0 throttles
        2037540 multicast, 13554508 unicast
        0 errors octets, 0 deferred
        0 collisions, 0 late collisions
     

    stack 1/3 on #0 is the upstream port to stack 1/2 on #6



  • 3.  RE: S2500 - Excessive error octets/CRC frames on one stack port
    Best Answer

    Posted Aug 15, 2019 09:02 AM

    For any that might have been following or find themselves in a similar situation, the issue ended up being the SFP on the upstream switch (port 1/3 on switch #0 in the message above) was failing and causing the errors after it left that switch and prior to arriving at the downstream switch (port 1/2 on switch #6).  After replacing that SFP, all error octets ceased.