This document describes how to troubleshoot input drops on the interface on XR routers.
There are no specific requirements for this document.
This article covers ASR 9000 series routers, CRS series routers and GSR 12000 series routers.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Input drops in IOS XR have a completely different meaning than that of input drops in IOS. It can confuse you when it migrates IOS to IOS XR and starts to see its input drop counters in the show interface.
In IOS, an input drop was due to the interface input queue that gets full. This means that too many packets were punted to the CPU for process switching and it was not able to handle them fast enough. The input queue is built up until it gets full and there are some drops.
In IOS XR, there is no strict definition of an input drop. So it's basically up to the developers of a component to decide whether they want to increment the input drop counter when they decide to drop a packet. The key thing here is that at some point in the code, the router decides to drop the packet so that means that it's likely that router was not supposed to forward that packet and router decide consciously to drop it. Therefore, this is not related to congestion like in IOS. However, it's rather a packet which was received by the router and which was not supposed to be forwarded so router decided to drop it and it's very likely not a reason to be alarmed. Although, you can't tell whether it's something to worry about or not until you have completely understood the kind of packets that are incrementing the input drop counter and that's not that simple, unfortunately.
An XR router is connected to a switch which sends some bridge protocol data unit (BPDUs) andUDLD packets. The XR router does not have spanning-tree nor UDLD configured on its layer 3 interfaces so it just drops these frames and it increments the input drops counter in show interface. In this case, there's nothing to worry about as it's just the right thing to do drop these frames as the features are not configured.
An ASR 9000 has a Cisco Express Forwarding (CEF) entry wrongly programmed due to a bug so that it does not point at a valid adjacency. In this case, the Network Processor of the ASR 9000 Line Card (LC) realizes that router misses a loadinfo and increment a Network Processor (NP) drop counter which is uploaded to the interface input drop counter.
When the input drops are reported, the problem is to figure out whether these are legitimate drops like in example 1 or the consequence of a problem like in example 2.
Problem: Increment in the Input Drop
This document enlists the reasons for the input drops that are incremented and how to check if it's that reason:
Runts, Frame Check Sequence (FCS), aborts, First Input First Output (FIFO) overflows, giants Packet Over SDH/SONET (POS) drops.
RP/0/RP0/CPU0:equinox#show controllers poS 0/2/0/0 framer statistics
POS Driver Internal Cooked Stats Values for port 0
Rx Statistics Tx Statistics
Total Bytes: 71346296 Total Bytes: 67718333
Good Bytes: 71346296 Good Bytes: 67718333
Good Packets: 105385 Good Packets: 67281
Aborts: 0 Aborts: 0
FCS Errors: 0 Min-len errors: 0
Runts: 0 Max-len errors: 0
FIFO Overflows: 0 FIFO Underruns: 0
For an ethernet (gige, tengige...) interface, check something like:
show controllers gigabitEthernet 0/0/0/18 stats
See if there's one counter in the controller stats which increments at the same rate as the input drop counter in show interface. Some of these error counters must also be in show interface.
Unknown Destination Medium Access Control Address (DMAC) or dot1q VLAN
Packets with a destination MAC address not the one of the interface or with a Virtual Local Area Network (VLAN) not matched by a subinterface. These can happen when there is some flooding in an L2 domain of unknown unicast MAC addresses so the XR router connected to that L2 domain receives frames with a destination MAC address which is not one of its controllers. It is also possible when an IOS router is sending ethernet keepalives on its gige interface so these keepalives are incrementing the input drops on the XR router as they do not have the destination mac address of the XR router. Or when the interface is connected to another device which has more dot1q vlans/subinterfaces configured as on the XR router so that the XR router receives frames with an unknown dot1q tag.
On a CRS fixed Physical Layer Interface Modules (PLIM), you could find such drops in:
RP/0/RP0/CPU0:pixies-uk#sh contr plim asic statistics interface tenGigE 0/1/0/3 location 0/1/CPU0
Wed Aug 22 16:07:47.854 CEST
RxFiFO Drop : 0 PAR Tail Drop : 0
PAR Err Drop : 0 Invalid MAC Drop : 86TxFIFO Drop : 0 Invalid VLAN Drop : 11
Or in the tengige or gige controller stats:
RP/0/RP0/CPU0:pixies-uk#sh contr ten 0/1/0/3 stats
Wed Aug 22 16:22:42.059 CEST
Statistics for interface TenGigE0/1/0/3 (cached values):
Input drop overrun = 0
Input drop abort = 0
Input drop invalid VLAN = 11
Input drop invalid DMAC = 0
Input drop invalid encap = 0
Input drop other = 86
Note: Bug CSCub74803 exist, Input drop other is incremented instead of Input drop invalid DMAC at least on the 8-port tengige fixed PLIM of the CRS.
For Shared Port Adapters (SPAs) (CRS, XR 12000), the packets with invalid MAC would be dropped by the SPA l2-tcam so you can find these drops in show controllers TenGigE a/b/c/d all:
Input drop other = 107
l2-tcam Invalid DA Drops: 107
On an ASR 9000, the Input drop invalid DMAC and Input drop other counters in the controller stats are not incremented. So the way to recognize these drops on the ASR 9000 is to find the NP handling the interface with the input drops:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/30 | i "input drops"
Wed Aug 22 16:55:52.374 CEST
1155 packets input, 156256 bytes, 1000 total input drops
RP/0/RSP0/CPU0:obama#sh contr np ports all location 0/0/CPU0
Wed Aug 22 16:56:01.385 CEST
NP Bridge Fia Ports
-- ------ --- ---------------------------------------------------
0 0 0 GigabitEthernet0/0/0/30 - GigabitEthernet0/0/0/39
1 0 0 GigabitEthernet0/0/0/20 - GigabitEthernet0/0/0/29
2 1 0 GigabitEthernet0/0/0/10 - GigabitEthernet0/0/0/19
3 1 0 GigabitEthernet0/0/0/0 - GigabitEthernet0/0/0/9
So you can see that the interface gig 0/0/0/30 is handled by the NP 0 on 0/0/CPU0. Let's check the NP counters of NP0 on 0/0/CPU0:
So L3_NOT_MYMAC in the NP counter means that the router received a frame on a Layer 3 interface with a destination MAC address which is not one of the interfaces. And router drops it as expected and this is reported as input drops in show interface. On the ASR 9000 for packets received with a dot1q VLAN not configured on a subinterface of the ASR 9000, the Input drop unknown 802.1Q counter is not incremented in show controllers gigabitEthernet 0/0/0/30 stats. The procedure is the same as above for the unknown DMAC: identify which NP handles the interfaces and then check this NP counters. You see that the NP counter UIDB_TCAM_MISS_AGG_DROP incrementing in that case.
Packets Dropped due to Unrecognized Upper-Level Protocol
That one is straightforward to detect as there is a counter for these drops one line below the input drops in show interface:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/18
Wed Aug 22 17:14:35.232 CEST
GigabitEthernet0/0/0/18 is up, line protocol is up
5 minute input rate 4000 bits/sec, 0 packets/sec
5 minute output rate 5000 bits/sec, 0 packets/sec
7375 packets input, 6565506 bytes, 1481 total input drops
1481 drops for unrecognized upper-level protocol
You can see here that all input drops were due to unrecognized upper-level protocol. That means that packets were received with an Ethernet protocol that router is not interested in. So that means that a feature is configured on the neighbor (or on a host connected to the layer 2 domain connected to that interface) so that it sends us frames with a protocol not configured on the XR router. Examples: BPDUs, Intermediate System to Intermediate System (ISIS), Connection Less Network Protocol (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Dynamic Trunking Protocol (DTP), Link Layer Discovery Protocol (LLDP) etc....
When these features are not configured on the XR interface, then the XR box drops them as expected. To find out what kind of frames are incrementing this counter, you'll have to compare which features are enabled on the XR router with the features enabled on the neighbor (it can be a router or a switch), or the features enabled on all the devices connected to the layer 2 domains connected to that interface (much less easy). If the XR router is connected to a switch, you can try a span on that switch of the packets that it sends to the XR router on the interface with input drops. See: ASR9000/XR : Drops for unrecognized upper-level protocol error
NP Drops on the ASR 9000
Drops counters in the Network Process (NP) of the ASR 9000 are reported as input drops when they apply to a packet received on an interface and dropped. This does not happen for Packet Switch Engine (PSE) drops on the CRS and the XR 12000: they are not counted as input drops.
So if you have input drops on an ASR 9000 and they don't match one of these reasons, then you would do a show controllers np ports all location 0/<x>/CPU0 to find the NP handling the interface with input drops and then check its NP counters with show contr np counters np<y> location 0/<x>/CPU0.
You can pipe the output to only keep DROP counters with a command like sh contr np counters np<y> location 0/<x>/CPU0 | i DROP but this can be dangerous as sometimes a drop counter does not have DROP in its name. You have seen a good example with L3_NOT_MYMAC. So maybe pipe for DROP|DISCARD|NOT|EXCD.
You can clear the interface counters and the NP counters with clear controller np counters np<y> location 0/<x>/CPU0 at roughly the same time to find out which NP counter increments at the same rate as the input drops.
For example, you get IPV4_PLU_DROP_PKT in the NP counters which means that the CEF/PLU entry is saying that the packet has to be dropped. You do not have a default route and have unreachables disabled so packets not matching a more specific route where hitting the default CEF handler which is a drop entry.
Note: Xander's page on support forums contains the drop reasons for the first generation of linecards (Trident) and there are new counter names for the new generation (Typhoon) linecards... but based on the name, you must be able to find a similar counter name as on Trident.
You can collect a show netio idb <int> and this gives you the interface input drop and the netio node drop counters:
GigabitEthernet0/2/0/1 (handle: 0x01280040, nodeid:0x21) netio idb: --------------------------------- name: GigabitEthernet0_2_0_1 interface handle: 0x01280040 interface global index: 3 physical media type: 30 dchain ptr: <0x482e0700> echain ptr: <0x482e1024> fchain ptr: <0x482e13ec> driver cookie: <0x4829fc6c> driver func: <0x4829f040> number of subinterfaces: 4096 subblock array size: 7 DSNCNF: 0x00000000 interface stats info: IN unknown proto pkts: 0 IN unknown proto bytes: 0 IN multicast pkts: 0 OUT multicast pkts: 0 IN broadcast pkts: 0 OUT broadcast pkts: 0 IN drop pkts: 0 <=========== cleared when added to input drop counter !!! OUT drop pkts: 0 IN errors pkts: 0 OUT errors pkts: 0
The drops in the Multi-Protocol Label Switching (MPLS) node here could be due to MPLS Time To Live (TTL) expired (in case of a loop or when the customer does a traceroute) or fragmentation required and Do Not Fragment (DF) bit set for instance. You can run debug mpls packet drop and debug mpls error with the location of the interface to try to figure out what kind of packet is incrementing this counter.
Punted multicast packets. When you see netio IN drop pkts but no netio node below with some drops which could explain the IN drop pkts, then this might be mcast punted packets and you can enable deb mfib netio drop to figure out what kind of packets