I have an interesting issue that I am struggling to get my head around
I have an EMC Array that has 4 Management ports that are connected to a 7K - we need to upgrade the Array's firmware but one of the pre upgrade checks is for a check on errors on the Nics. We are seeing RX errors - which we have narrowed down to rx_long_length_errors - they are continually increasing (by the same amount on all 4 Nics. Below is a sample of 3 runs 15 seconds apart - while the totals are different you can see the increments are the same on all 4 Nics.
Run 1 X1-SC1 rx_errors: 40333939 Run 2 (run 1 + 2) X1-SC1 rx_errors: 40333941 Run 3 (run 2 + 5) X1-SC1 rx_errors: 40333946 X1-SC2 rx_errors: 20669588 X1-SC2 rx_errors: 20669590 X1-SC2 rx_errors: 20669595 X2-SC1 rx_errors: 20554720 X2-SC1 rx_errors: 20554722 X2-SC1 rx_errors: 20554727 X2-SC2 rx_errors: 40718384 X2-SC2 rx_errors: 40718386 X2-SC2 rx_errors: 40718391
A breakdown of the errors on one Nic shows below but all 4 are similar.
rx_crc_errors: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_window_errors: 0 rx_long_length_errors: 40329872 rx_short_length_errors: 0 rx_align_errors: 0 rx_errors: 40329872 tx_errors: 0 rx_length_errors: 40329872 rx_over_errors: 0 rx_frame_errors: 0 rx_fifo_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0
My understanding is that rx_long_length_errors relates to MTU generally - so checked the MTU on both sides - on both sides its 1500.
I am seeing no tx or rx errors on the 7k - but there is a count of historical Jumbo Frames sent - this seems weird and I need to double check but it is possible maybe they are historical - are these stats reset on link up/down or when would they be reset?
Ethernet3/13 is up
admin state is up, Dedicated Interface
Hardware: 10/100/1000 Ethernet, address: 0026.0b3c.a694 (bia 0026.0b3c.a694)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec <<<<<<<<<<<<<<<<<
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is access
full-duplex, 1000 Mb/s
Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is off
Auto-mdix is turned on
Switchport monitor is off
EtherType is 0x8100
EEE (efficient-ethernet) : n/a
Last link flapped 02:38:38
Last clearing of "show interface" counters 01:16:59
0 interface resets
30 seconds input rate 173120 bits/sec, 118 packets/sec
30 seconds output rate 1446712 bits/sec, 180 packets/sec
Load-Interval #2: 5 minute (300 seconds)
input rate 114.74 Kbps, 17 pps; output rate 1.00 Mbps, 45 pps
470117 unicast packets 0 multicast packets 190 broadcast packets
470307 input packets 76575515 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
617354 unicast packets 14717 multicast packets 59151 broadcast packets
691222 output packets 670388018 bytes
2304 jumbo packets <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
My background is virtualization so apologies if any of the answers here are obvious. My main questions would be.
1) Am I correct in saying rx_long_length_errors are generally MTU - is there anything else that can cause these - has anyone seen similar errors before where MTU was 1500 on both sides.
2) On the show int of the 7k side I see mention of 2304 Jumbo Packets transmitted - the below is in the show int but am unsure if I an equating the time correct
Last link flapped 02:38:38 <- this is likely when we connected the array to this switch (2 hours 38 minutes would be about right)
Last clearing of "show interface" counters 01:16:59 <- is this when the counters are reset (1 hour 16 mins ago - would this include the Jumbo Counter)
3) I assume there is no scenario where a frame of larger than 1500 can be transmitted when mtu is 1500 on both sides - is this assumption correct?
4) Any other general thoughts
... View more