cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

3279
Views
15
Helpful
29
Replies
Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

Cable is swapped.  Counters are cleared.  Here is the latest output.

SWITCH OUTPUT#sho int g2/0/38

GigabitEthernet2/0/38 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet, address is 7c95.f3a2.bea6 (bia 7c95.f3a2.bea6)

  Description: Zone1 Access Ports

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

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

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

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

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

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

  Last clearing of "show interface" counters 00:16:02

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

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 0 bits/sec, 0 packets/sec

  30 second output rate 2000 bits/sec, 4 packets/sec

     384 packets input, 106554 bytes, 0 no buffer

     Received 24 broadcasts (12 multicasts)

     0 runts, 0 giants, 0 throttles

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

     0 watchdog, 12 multicast, 0 pause input

     0 input packets with dribble condition detected

     1439 packets output, 169568 bytes, 0 underruns

     0 output errors, 0 collisions, 1 interface resets

     4 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

AP OUTPUT#sho int g0

GigabitEthernet0 is up, line protocol is up

  Hardware is PowerPC Ethernet, address is 7c69.f663.52d9 (bia 7c69.f663.52d9)

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

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

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full Duplex, 1Gbps, media type is T

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

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

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

  Last clearing of "show interface" counters never

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

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 1000 bits/sec, 3 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     1729 packets input, 171335 bytes, 0 no buffer

     Received 1388 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

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

     0 watchdog, 0 multicast, 0 pause input

     418 packets output, 109757 bytes, 0 underruns

     0 output errors, 0 collisions, 5 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

Hall of Fame Community Legend

Re: 3602i AP's w/ 802.11ac module input and crc errors connected

This means that for the last 16 minutes, you only received 5 CRC errors.

Are you still using Panduit cable or using a different cable?

Beginner

Re: 3602i AP's w/ 802.11ac module input and crc errors connected

After the AP is online and associated to the 5760 is when the Input and CRC errors start happening.  They happen every 30 seconds.

Hall of Fame Community Legend

3602i AP's w/ 802.11ac module input and crc errors connected to

Are you still using Panduit cable?

Do you have ANY OTHER switch models other than 3850?  Do you have, for example, a 2960G/S/X or 3750G/E/X?

Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

Any solution to this problem? we also see FCS and RCV errors on a 3850 stack with 2602i Access points connected.

Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

Nothing yet and I had to leave that customers site.  Out of curiosity, are your 3850's strictly switches or are they MA's/MC 's?  I checked on another customer and they have 3850 with 3602i's and the 802.11ac module but their switches are MA's and MC's and they are not seeing any errors.

Highlighted
Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

Frame check sequence (FCS) errors indicate that frames of data are being corrupted during transmission. FCS error count is the number of frames that were transmitted/received with a bad checksum (CRC value) in the Ethernet frame. These frames are dropped and not propagated onto other ports.


Could be caused by many different things..


Many performance issues with NICs can be related to data link errors. Excessive errors usually indicate a problem. When operating at half-duplex setting, some data link errors such as Frame Check Sequence (FCS), alignment, runts, and collisions are normal. Generally, a one percent ratio of errors to total traffic is acceptable for half-duplex connections. If the ratio of errors to input packets is greater than two or three percent, performance degradation may be noticed.


In half-duplex environments, it is possible for both the switch and the connected device to sense the wire and transmit at exactly the same time and result in a collision. Collisions can cause runts, FCS, and alignment errors due to the frame not being completely copied to the wire which results in fragmented frames.


When operating at full-duplex, FCS, Cyclic Redundancy Checks (CRC), alignment errors, and runt counters should be minimal. If the link is operating at full-duplex, the collision counter is not active. If the FCS, CRC, alignment, or runt counters are incrementing, check for a duplex mismatch. Duplex mismatch is a situation where the switch is operating at full-duplex and the connected device is operating at half-duplex, or vice versa. The result of a duplex mismatch will be extremely slow performance, intermittent connectivity, and loss of connection. Other possible causes of data link errors at full-duplex are bad cables, faulty switch port, or NIC software/hardware issues.

Regards

Rashid Asghar

Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

the customer has a 5760 controller where the access points terminate their capwap tunnel. the 3850 switches are deployed as just switches. It only happens on 3850 stacks and not on 3750x stacks. the strange thing i does not happen on all interfaces where there are access points connected. it seems not possible that there is a cabling issue as it happens at about 80 percent off the connected access points.

VIP Mentor

Re: 3602i AP's w/ 802.11ac module input and crc errors connected

Hi Arne,

You should log a TAC case against 3850 product & get TAC involved. There may be a defect/bug with 3850 with this respect.

Also I would suggest to upgrade IOS-XE of this platform to latest (3.3.2)

HTH

Rasika

**** Pls rate all useful resposnes *****

Beginner

3602i AP's w/ 802.11ac module input and crc errors connected to

Hello Rasika,

Thank you, i've not mentioned that i already opened a TAC case. When i have some more info i will post again.

Beginner

In my case the FCS errors was

In my case the FCS errors was related to bug CSCui80121.

After disabling jumbo-mtu on alle access points the FCS errors where gone.

you have to disable jumbo-mtu on the 5760 controller per access point even if the status with command "show ap name config general | inc Jumbo" says jumbo mtu is disabled. somehow it is still enabled on the access points:

ap name no jumbo-mtu

 

Beginner

This fixed my issue - have

This fixed my issue - have six 3702Is plugged directly into a 3850.  All interfaces showed FCS and RCV errors (tens of thousands after a few months), but stopped incrementing after using the "ap name no jumbo-mtu" command.

View solution in original post

Beginner

While working through this

While working through this issue with new 3702i's and 4506 switches I found the AP's to be configured with an mtu size of 1792 by default. Resetting this to 1500 on the gi0 & bvi1 interfaces cleared up the increment errors.

5508 WLC's / 7.6.100.0

4506 w/ SUP / 7-E 15.1(1)SG2

BVI1 is up, line protocol is up
  Hardware is BVI, address is 3c08.f689.d460 (bia 3c08.f689.d460)
  Internet address is 10.5.244.81/23
  MTU 1792 bytes, BW 1000000 Kbit/sec, DLY 5000 usec,
!
GigabitEthernet0 is up, line protocol is up

  Hardware is PowerPC Ethernet, address is 3c08.f689.d460 (bia 3c08.f689.d460)
  MTU 1792 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

 

 

VIP Mentor

Thanks for the update +5

Thanks for the update +5

Beginner

Just came across this bug

Just came across this bug from 5/30/2014.

https://tools.cisco.com/bugsearch/bug/CSCun12965

Symptom:
Lightweight AP may send CAPWAP packets whose size is larger than 1500 bytes for testing maximum Path MTU.
These large CAPWAP packets cause giant errors on a directly connected switch, if the switch does not enable jumbo frame support.
Because AireOS based Wireless LAN Controller does not support jumbo frame, this behavior should not be enabled by default.

CreatePlease to create content
Content for Community-Ad

August's Community Spotlight Awards