Unknown protocol drops

Unanswered Question
Apr 1st, 2009

I'm receiving the following display on a 2811 fast ethernet connection and am not sure what it means:

FastEthernet0/0 is up, line protocol is up

20 unknown protocol drops

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
lamav Wed, 04/01/2009 - 06:25

I have researched this before and have never been able to get a definitive and authoritative answer, not even from Cisco TAC.

These oftentimes appear with absolutely no other indication that your network performance has been adversely effected.

If you cannot explain these errors, you can use a sniffer to indentify the unknown protocol.

HTH (It probably doesnt, but its the best I can do) :-)

Victor

Yudong Wu Wed, 04/01/2009 - 06:42

What device is port F0/0 connected to?

Can you do a sniffer to see what packet is received when this count increments?

By the way, you can check your IOS version to see if you hit this bug CSCsx18388.

fred.gardner Wed, 04/01/2009 - 06:55

It's connected to a 2924-XL switch with

c2900xl-c3h2s-mz.120-5.WC15.bin.

Unfortunately, we don't have a sniffer.

I'm trying to use nGenius to identify the protocol. Fortunately it doesn't appear to be affecting performance...

mark.cronin Wed, 04/01/2009 - 07:17

Some times you can get dropped packets

when one device is trying to negotiate ISL or dot1q trunks and the other device does not understand the trunking protocol.

Can you ensure that both the switch and router have the ports set to not trunk

thotsaphon Wed, 04/01/2009 - 08:00

Frederick,

Well, You're gonna love MIB. (grin)

#########

ifInUnknownProtos (.1.3.6.1.2.1.2.2.1.15)

: These are counted as unclassified errors.

The variables previously listed that do not say they appear in show interfaces are not available anywhere other than SNMP.

#########

Please don't hesitate to check out this link.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml#QQ1

HTH,

Toshi

mark.cronin Wed, 04/01/2009 - 08:13

and also

switchport mode access

You should also move your servers / hosts

off of VLAN 1 as this is not best practice

Yudong Wu Wed, 04/01/2009 - 08:14

Hi Fred, how fast that counter increments? If you see it increase by one everytime you type "show interface", it might be related to the bug I mentioned before.

mark.cronin Wed, 04/01/2009 - 11:36

Can you show us the output from a

show interface fa0/1 switchport

On the switchport that connect to the router

fred.gardner Wed, 04/01/2009 - 11:53

UMB208R0#sh int fa0/0

FastEthernet0/0 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0013.8084.ae18 (bia 0013.8084.ae18)

Description: LAN interface at 700 E Santa Fe St Olathe

Internet address is 10.110.81.1/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

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

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

Last clearing of "show interface" counters 05:58:49

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 2000 bits/sec, 3 packets/sec

5 minute output rate 2000 bits/sec, 2 packets/sec

108257 packets input, 22583077 bytes

Received 10522 broadcasts, 0 runts, 0 giants, 0 throttles

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

0 watchdog

0 input packets with dribble condition detected

94558 packets output, 38512505 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

6151 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Yudong Wu Wed, 04/01/2009 - 13:14

can you post the port configuration on 2900 switch and the output of "sh int fa x/y switchport"

fred.gardner Wed, 04/01/2009 - 13:22

I car pool, so I can't tonight, but I will tomorrow. Thanks for your input...!

Fred

fred.gardner Thu, 04/02/2009 - 05:58

Here's the router Fa0/0:

interface FastEthernet0/0

description LAN interface at 700 E Santa Fe St Olathe

ip address 192.168.231.1 255.255.255.0 secondary

ip address 10.10.46.1 255.255.255.0 secondary

ip address 10.110.81.1 255.255.255.0

ip helper-address 192.168.48.50

ip helper-address 172.17.48.50

no ip redirects

no ip unreachables

ip directed-broadcast 143

no ip proxy-arp

no ip mroute-cache

duplex full

speed 100

no mop enabled

and the switch:

interface FastEthernet0/1

description Connection to Branch Router

duplex full

speed 100

Yudong Wu Thu, 04/02/2009 - 06:18

By default, "Negotiation of Trunking" is in "ON" status. Please check the switch port to "access mode". "switch mode access".

mark.cronin Thu, 04/02/2009 - 06:24

I have not got a 2924 to test with but

I think it uses DISL rather than DTP

Yudong Wu Thu, 04/02/2009 - 06:31

Yes, you could be right.

I would like to turn off any trunk negociation.

fred.gardner Thu, 04/02/2009 - 06:35

UMB208SW11#show int fa 0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative mode: static access

Operational Mode: static access

Administrative Trunking Encapsulation: isl

Operational Trunking Encapsulation: isl

Negotiation of Trunking: Disabled

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Trunking VLANs Enabled: NONE

Pruning VLANs Enabled: NONE

Priority for untagged frames: 0

Override vlan tag priority: FALSE

Voice VLAN: none

Appliance trust: none

Self Loopback: No

mark.cronin Thu, 04/02/2009 - 07:08

"Negotiation of Trunking: Disabled"

Well thats put a stop to that idea.

Can you put the switchport in to portfast mode.

I think you are going to need to install wireshark on a laptop and SPAN that port to look for the unknown protocol or during out of hours over a weekend look at using debug commands (ip packet detail - be carefull" on the router.

Have you got a hosts / printers on that switch with protocols like IPX DLC/LLC running?

Yudong Wu Thu, 04/02/2009 - 07:12

Agree. we have to do a sniffer to find out what the packet causes the drop if you don't know what else traffic is on that link.

Actions

This Discussion