Cisco 3560 to A5c - "unknown protocol drops"

So this is a first for me. I have been digging into some communication issues between my client whose router keeps losing its connection to the our gateway.

Setup is as follows: Mikrotik RB (Gateway) <-> Cisco 3560 w PoE <-> A5c <-> C5x <-> Mikrotik RB (Customer)

Mikrotik port is under a bridge interface to take advantage of rstp. MTU 1500
Cisco 3560:
interface GigabitEthernet0/24
description -----
switchport trunk encapsulation dot1q
switchport mode trunk

MTU is 1500 on Cisco

When I run a show int gi0/24 i get:
show int gi0/24
GigabitEthernet0/24 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is a80c.0d9e.2398 (bia a80c.0d9e.2398)
Description: -------
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:11, output 00:00:00, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 463000 bits/sec, 115 packets/sec
5 minute output rate 5952000 bits/sec, 559 packets/sec
901755292 packets input, 739437279860 bytes, 0 no buffer
Received 747724 broadcasts (277675 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 277675 multicast, 0 pause input
0 input packets with dribble condition detected
1472633156 packets output, 1056581705260 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
11008 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

Upon researching, I see where the DTP tunking protocol can cause this, but this is my first time seeing this as we have multiple other A5c’s out there without this issue.

Has anyone else run across this error? I believe the switchport nonegotiate command will disable dtp and fix, but my nerdy packet analysis minded brain wants to investigate the root cause a little more.

@William5 I know you have a similar setup, ever see this on your Cisco’s before?

I have noticed that on a few of my other APs I have enabled the 2474 MTU, wonder if that would help?

Actually dude, I don’t have any Cisco’s in my network anymore. Mikrotik, Netonix, and Ignitenet for me.

That said, out of over 1 billion packets having 11k being goofy isn’t such a bad thing IMO, but I am glad you are hunting down the issue.

Could be Mimosa’s discovery protocol getting screwed by the switch, otherwise something to do with your customer’s traffic would be my next best guess. Would you happen to be running IPv6 on the network?

Ah, OK. Not running IPv6 yet. I was assigned an address pool some time back but have tabled the implementation.

Looking like its wireshark time!

The lacking of CRC or FCS errors indicates to me that the issue is something more along the lines of the A5c doing something weird with traffic or your customer sending out weird traffic.

But with the root issue being the customer unable to reach your router, I am kinda curious about how this pans out. Please do update this thread with more info!

Mikrotik devices support CDP, LLDP, and MNDP (Mikrotik Neighbor Discovery Protocol). The C3560 knows the first two, but not the last one. Is MNDP turned on in the Mikrotik device?

1 Like

Hey Guys, just an update. We replaced the A5c with a spare on the shelf after replacing everything else. Seems we just had a defective unit. RMA has been processed, new unit is on shelf. All is well in my little wireless world, for now!!