By Alexander Thuijs
Introduction
In this articile I will describe the issue of unrecognized protocol drops reported on an interface on the ASR9000. Some steps for remediation are provide and a few things to check before opening a tac case.
Core Issue
NMS stations looking at interface statistics may get confused or report unnecessary alarms when they are seeing "errors" on the interface. It is recognized that these protocol errors are not well documented and these are raising a larger then normal amount of support cases. In this article I am trying to describe when you see these errors reported and what you can do about it.
The following example shows what you might see:
RP/0/RSP0/CPU0:A9K-TOP#sh int te 0/3/0/0
Fri Mar 4 01:25:16.691 UTC
TenGigE0/3/0/0 is up, line protocol is up
Interface state transitions: 3
Hardware is TenGigE, address is 0026.9800.15b0 (bia 0026.9800.15b0)
Layer 1 Transport Mode is LAN
Internet address is Unknown
MTU 1514 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
reliability 255/255, txload 0/255, rxload 0/255
Encapsulation ARPA,
Full-duplex, 10000Mb/s, LR, link type is force-up
output flow control is off, input flow control is off
loopback not set,
ARP type ARPA, ARP timeout 04:00:00
Last input 00:00:00, output 00:00:00
Last clearing of "show interface" counters 2d06h
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 2000 bits/sec, 3 packets/sec
151224 packets input, 17290273 bytes, 0 total input drops
3247 drops for unrecognized upper-level protocol Received 1 broadcast packets, 136817 multicast packets
0 runts, 0 giants, 0 throttles, 0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
753409 packets output, 73257197 bytes, 0 total output drops
Output 34 broadcast packets, 750081 multicast packets
0 output errors, 0 underruns, 0 applique, 0 resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
Resolution
"Drops for unrecognized upper-level protocol" means that we've received packets of a type that you haven't configured and therefore don't have a handler for in the interface protocol handling chain.
That may be (and most likely is) expected and purely cosmetic.
Examples:
- other side (switch) has CDP configured but you don't have CDP configured on this end
- someone on the Ethernet is sending IS-IS hellos but you don't have IS-IS configured on this end
- someone on the Ethernet is sending IPv6 neigbor discovery packets but you don't have IPv6 configured on this end
It may be worth checking:
- do these packets increment periodically (i.e. one packet every 30 sec or so)?
- are there any obvious features (CDP is a good candidate) that you haven't configured but the far-end (switch, or if it's a crosslink, then the connected peer) has?
Otherwise capture & decode the packets, and perhaps reviewing the config will already give the answer in a couple of seconds.
If a 7600/ 6500 port is connected to the ASR9000 and input error increment due to 'unrecognized upper-level protocol', then to avoid various l2 packets reaching ASR9000, you can use:
switchport nonegotiate - disable Dynamic Trunk Protocol (DTP) on the port
no cdp enable - to disable running Cisco Discovery Protocol (CDP)
no vtp - to disable sending VLAN Trunking Protocol(VTP) frame
spanning-tree bpdfilter enable - To enable BPDU filtering on the interface
UDLD: If you are running CatOS try “set udld disable x/y” or “udld port disable” under the interface if you have IOS on the 6500.
LLDP: (new addition) switches by default have lldp enabled that could be, like CDP, be perceived as an unrecognized upper level protocol on the ASR9000.
Introduction
In this articile I will describe the issue of unrecognized protocol drops reported on an interface on the ASR9000. Some steps for remediation are provide and a few things to check before opening a tac case.
Core Issue
NMS stations looking at interface statistics may get confused or report unnecessary alarms when they are seeing "errors" on the interface. It is recognized that these protocol errors are not well documented and these are raising a larger then normal amount of support cases. In this article I am trying to describe when you see these errors reported and what you can do about it.
The following example shows what you might see:
RP/0/RSP0/CPU0:A9K-TOP#sh int te 0/3/0/0
Fri Mar 4 01:25:16.691 UTC
TenGigE0/3/0/0 is up, line protocol is up
Interface state transitions: 3
Hardware is TenGigE, address is 0026.9800.15b0 (bia 0026.9800.15b0)
Layer 1 Transport Mode is LAN
Internet address is Unknown
MTU 1514 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
reliability 255/255, txload 0/255, rxload 0/255
Encapsulation ARPA,
Full-duplex, 10000Mb/s, LR, link type is force-up
output flow control is off, input flow control is off
loopback not set,
ARP type ARPA, ARP timeout 04:00:00
Last input 00:00:00, output 00:00:00
Last clearing of "show interface" counters 2d06h
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 2000 bits/sec, 3 packets/sec
151224 packets input, 17290273 bytes, 0 total input drops
3247 drops for unrecognized upper-level protocol Received 1 broadcast packets, 136817 multicast packets
0 runts, 0 giants, 0 throttles, 0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
753409 packets output, 73257197 bytes, 0 total output drops
Output 34 broadcast packets, 750081 multicast packets
0 output errors, 0 underruns, 0 applique, 0 resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
Resolution
"Drops for unrecognized upper-level protocol" means that we've received packets of a type that you haven't configured and therefore don't have a handler for in the interface protocol handling chain.
That may be (and most likely is) expected and purely cosmetic.
Examples:
- other side (switch) has CDP configured but you don't have CDP configured on this end
- someone on the Ethernet is sending IS-IS hellos but you don't have IS-IS configured on this end
- someone on the Ethernet is sending IPv6 neigbor discovery packets but you don't have IPv6 configured on this end
It may be worth checking:
- do these packets increment periodically (i.e. one packet every 30 sec or so)?
- are there any obvious features (CDP is a good candidate) that you haven't configured but the far-end (switch, or if it's a crosslink, then the connected peer) has?
Otherwise capture & decode the packets, and perhaps reviewing the config will already give the answer in a couple of seconds.
If a 7600/ 6500 port is connected to the ASR9000 and input error increment due to 'unrecognized upper-level protocol', then to avoid various l2 packets reaching ASR9000, you can use:
switchport nonegotiate - disable Dynamic Trunk Protocol (DTP) on the port
no cdp enable - to disable running Cisco Discovery Protocol (CDP)
no vtp - to disable sending VLAN Trunking Protocol(VTP) frame
spanning-tree bpdfilter enable - To enable BPDU filtering on the interface
UDLD: If you are running CatOS try “set udld disable x/y” or “udld port disable” under the interface if you have IOS on the 6500.
LLDP: (new addition) switches by default have lldp enabled that could be, like CDP, be perceived as an unrecognized upper level protocol on the ASR9000.
No comments:
Post a Comment