目录

简介

先决条件

要求

使用的组件

背景信息

问题：输入丢弃中的增量

控制器丢弃

未知目标介质访问控制地址(DMAC)或dot1q VLAN

由于无法识别的上层协议而丢弃的数据包

ASR 9000上的NP丢弃

内蒂奥

简介

本文档介绍如何对XR路由器的接口上的输入丢弃进行故障排除。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文介绍ASR 9000系列路由器、CRS系列路由器和GSR 12000系列路由器。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

Cisco IOS XR中的输入丢弃与Cisco IOS中的输入丢弃具有完全不同的含义。当它将Cisco IOS迁移到Cisco IOS XR并开始在show interface中看到其输入丢弃计数器时，可能会让您感到困惑。

在Cisco IOS中，输入丢弃是由于接口输入队列已满引起的。这意味着有太多数据包被传送到CPU进行进程交换，而且处理速度不够快。输入队列将建立到已满并且出现一些丢包为止。

在Cisco IOS XR中，输入丢弃没有严格的定义。因此，基本上由组件的开发人员决定，当他们决定丢弃数据包时，他们是否要增加输入丢弃计数器。这里的关键点是，在代码中的某个时刻，路由器决定丢弃数据包，这意味着路由器很可能不应该转发该数据包，而路由器决定有意识地丢弃该数据包。 因此，这与Cisco IOS中的拥塞无关。但是，它实际上是一个由路由器接收且不应转发的数据包，因此路由器决定丢弃该数据包，因此很可能不会引起警报。不过，在完全了解了使输入丢弃计数器递增的数据包类型之前，您无法判断它是否值得担忧，但这不是那么简单。

示例：

- XR路由器连接到交换机，该交换机发送一些网桥协议数据单元(BPDU)和UDLD数据包。XR路由器的第3层接口上未配置生成树和UDLD，因此它只丢弃这些帧，并在show interface中增加输入丢弃计数器。在这种情况下，无需担心任何问题，因为在没有配置功能的情况下，丢弃这些帧是正确之举。

- 由于Bug，ASR 9000的思科快速转发(CEF)条目被错误编程，因此它不会指向有效的邻接关系。在这种情况下，ASR 9000线路卡(LC)的网络处理器会发现路由器遗漏了负载信息，并会增加网络处理器(NP)丢弃计数器，该计数器会上传到接口输入丢弃计数器。

当报告输入丢弃时，问题是要弄清楚它们是合法的丢弃（如示例1所示）还是问题的后果（如示例2中）。

问题：输入丢弃中的增量

本文档列出了导致输入丢弃增加的原因以及如何检查是否是原因：

控制器丢弃

残帧、帧校验序列(FCS)、中止、第一输入第一输出(FIFO)溢出、SDH/SONET上的超大型数据包(POS)丢弃。

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

Giants:         0

Drops:          0

RP/0/RP0/CPU0:equinox#

对于以太网(gige、tengige...)接口，请检查类似以下内容：

show controllers gigabitEthernet 0/0/0/18统计信息

查看控制器统计信息中是否有与show interface中的输入丢弃计数器以相同速率递增的计数器。其中某些错误计数器也必须位于show interface中。

未知目标介质访问控制地址(DMAC)或dot1q VLAN

具有目的MAC地址（不是接口地址）或具有子接口不匹配的虚拟局域网(VLAN)的数据包。当未知单播MAC地址的L2域中有一些泛洪时，就会发生这种情况，因此连接到该L2域的XR路由器收到包含目标MAC地址的帧，而目的MAC地址不是其控制器之一。 当Cisco IOS路由器在其gige接口上发送以太网keepalive时，也有可能发生，因此这些keepalive将增加XR路由器上的输入丢弃，因为它们没有XR路由器的目标mac地址。此外，当接口连接到在XR路由器上配置了更多dot1q vlan/子接口的另一台设备时，使XR路由器接收带有未知dot1q标记的帧。

在CRS固定物理层接口模块(PLIM)上，您可以在以下位置找到此类丢包：

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

Node: 0/1/CPU0

TenGigE0/1/0/3 Drop

-------------------------------------------------------------------------------

RxFiFO Drop       : 0                   PAR Tail Drop     : 0

PAR Err Drop      : 0                   Invalid MAC Drop  : 86

TxFIFO Drop       : 0                   Invalid VLAN Drop : 11

或者，在tengige或gige控制器统计信息中：

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):

Ingress:

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

注意：Cisco Bug ID CSCub74803存在。 至少在CRS的8端口固定的PLIM上，Input drop other会递增而不是输入丢弃无效DMAC。

对于共享端口适配器(SPA)(CRS、XR 12000),SPA l2-tcam将丢弃具有无效MAC的数据包，因此您可以在show controllers TenGigE a/b/c/d all中找到这些丢包：

Input drop other            = 107

l2-tcam Invalid DA Drops: 107

在ASR 9000上，控制器统计信息中的Input drop invalid DMAC和Input drop other counters不会增加。因此，在ASR 9000上识别这些丢弃的方法是找到使用输入丢弃处理接口的NP:

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

Node: 0/0/CPU0:

----------------------------------------------------------------

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

RP/0/RSP0/CPU0:obama#

您可以看到接口gig 0/0/0/30由0/0/CPU0上的NP 0处理。

让我们检查0/0/CPU0上NP0的NP计数器：

RP/0/RSP0/CPU0:obama#sh contr np counters np0 location 0/0/CPU0

Wed Aug 22 16:56:19.883 CEST

Node: 0/0/CPU0:

----------------------------------------------------------------

Show global stats counters for NP0, revision v3

Read 26 non-zero NP counters:

Offset  Counter                                         FrameValue   Rate (pps)

-------------------------------------------------------------------------------

22  PARSE_ENET_RECEIVE_CNT                                  1465           0

23  PARSE_FABRIC_RECEIVE_CNT                                2793           0

24  PARSE_LOOPBACK_RECEIVE_CNT                              2800           0

28  MODIFY_FABRIC_TRANSMIT_CNT                                80           0

29  MODIFY_ENET_TRANSMIT_CNT                                1792           0

32  RESOLVE_INGRESS_DROP_CNT                                1000           0

35  MODIFY_EGRESS_DROP_CNT                                  1400           0

36  MODIFY_MCAST_FLD_LOOPBACK_CNT                           1400           0

38  PARSE_INGRESS_PUNT_CNT                                   465           0

39  PARSE_EGRESS_PUNT_CNT                                    155           0

45  MODIFY_RPF_FAIL_DROP_CNT                                1400           0

53  PARSE_LC_INJECT_TO_FAB_CNT                                80           0

54  PARSE_LC_INJECT_TO_PORT_CNT                              864           0

57  PARSE_FAB_INJECT_UNKN_CNT                                155           0

67  RESOLVE_INGRESS_L3_PUNT_CNT                              465           0

69  RESOLVE_INGRESS_L2_PUNT_CNT                              464           0

70  RESOLVE_EGRESS_L3_PUNT_CNT                              1400           0

93  CDP                                                      464           0

95  ARP                                                        1           0

109  DIAGS                                                    154           0

221  PUNT_STATISTICS                                         9142           1

223  PUNT_DIAGS_RSP_ACT                                       155           0

225  PUNT_DIAGS_RSP_STBY                                      155           0

227  NETIO_RP_TO_LC_CPU_PUNT                                  155           0

373  L3_NOT_MYMAC                                            1000           0

565  INJECT_EGR_PARSE_PRRT_PIT                                928           0

RP/0/RSP0/CPU0:obama#

因此，NP计数器中的L3_NOT_MYMAC意味着路由器在第3层接口上收到一个帧，其目的MAC地址不是该接口之一。路由器按预期丢弃它，这在show interface中报告为输入丢弃。

在ASR 9000上，对于ASR 9000的子接口上未配置dot1q VLAN接收的数据包，Input drop unknown 802.1Q计数器不会在show controllers gigabitEthernet 0/0/0/30统计信息中递增。未知DMAC的步骤与上面相同：确定哪个NP处理接口，然后检查此NP计数器。在这种情况下，您会看到NP计数器UIDB_TCAM_MISS_AGG_DROP递增。

由于无法识别的上层协议而丢弃的数据包

该计数器很容易检测，因为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

您可以在这里看到，所有输入丢弃都是由于无法识别的上层协议造成的。

这意味着收到的数据包使用的是路由器不感兴趣的以太网协议。这意味着在邻居（或连接到该接口的第2层域的主机）上配置了一个功能，这样它就可以使用未在XR路由器上配置的协议发送帧。

示例：BPDU、中间系统到中间系统(ISIS)、无连接网络协议(CLNP)、IPv6、UDLD、思科发现协议(CDP)、VLAN中继协议(VTP)、动态中继协议(DTP)、链路层发现协议(LLDP)等....

如果未在XR接口上配置这些功能，则XR框会按预期丢弃它们。要了解哪种帧会增加此计数器，您必须将XR路由器上启用的功能与邻居上启用的功能（可以是路由器或交换机）进行比较，或者比较连接到与该接口相连的第2层域的所有设备上启用的功能（简单得多）。如果XR路由器连接到交换机，您可以在该交换机上尝试使用输入丢弃在接口上发送到XR路由器的数据包的跨度。

ASR9000/XR：因无法识别的上层协议错误而丢弃

ASR 9000上的NP丢弃

当ASR 9000的网络进程(NP)中的丢弃计数器应用于接口上收到并丢弃的数据包时，它们被报告为输入丢弃。在CRS和XR上数据包交换引擎(PSE)丢弃不会发生此情12000。它们不计为输入丢弃。

因此，如果您在ASR 9000上存在输入丢弃，并且它们不符合以下原因之一，则您将执行show controllers np ports all location 0/<x>/CPU0以查找处理输入丢弃接口的NP，然后使用show controllers np counters np<y> location 0/<x>/CPU0检查其NP计数器。

您可以使用命令(如sh contrr np counters np<y> location 0/<x>/CPU0)传输输出以仅保留DROP计数器 | i DROP，但有时由于丢弃计数器的名称中没有DROP，因此这种操作非常危险。您已经看到一个使用L3_NOT_MYMAC的很好示例。因此，可能为DROP|DISCARD|NOT|EXCD建立管道。

您可以使用几乎同时清除接口计数器和NP计数器和clear controller np counters np<y> location 0/<x>/CPU0，以找出哪个NP计数器以与输入丢弃相同的速率增加。

例如，您在NP计数器中收到IPV4_PLU_DROP_PKT，这意味着CEF/PLU条目表示必须丢弃数据包。 您没有默认路由并禁用了不可达，因此不匹配更具体的路由（点击默认CEF处理程序时）的数据包是丢弃条目。

如果您在NP中找到一个丢弃计数器，它可以解释以相同速率递增的输入丢弃，但NP丢弃计数器并不是非常容易解释的，您可以浏览此页面来尝试理解计数器的含义：

ASR9000/XR：数据包丢弃故障排除和了解NP丢弃计数器

注意：Xander在支持论坛上的页面包含第一代线卡(Trident)的丢弃原因，并且新一代(Typhoon)线卡有新的计数器名称。根据名称，您必须能够找到与Trident中类似的计数器名称。

内蒂奥

您可以收集show netio idb <int>，这会为您提供接口输入丢弃和netio节点丢弃计数器：

RP/0/RP0/CPU0:ipc-lsp690-r-ca-01#show netio idb gigabitEthernet 0/2/0/1

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

Chains

--------------------

Base decap chain:

ether                <30>  <0xfd018cd8, 0x482c736c>  <       0,        0>

Protocol chains:

---------------

<Protocol number> (name)  Stats

Type  Chain_node       <caps num>  <function, context> <drop pkts, drop bytes>

<snip>

<13> (mpls)   Stats IN: 204 pkts, 23256 bytes; OUT: 0 pkts, 0 bytes

Encap:

mpls                 <25>  <0xfcc7ddbc, 0x00000000>  <       0,        0>

ether                <30>  <0xfd0189b4, 0x482c736c>  <       0,        0>

l2_adj_rewrite       <86>  <0xfcaa997c, 0x4831a2e8>  <       0,        0>

pcn_output           <54>  <0xfd0561f0, 0x48319f04>  <       0,        0>

q_fq                 <43>  <0xfd05f4b8, 0x48320fec>  <       0,        0>

txm_nopull           <60>  <0xfcadba38, 0x4824c0fc>  <       0,        0>

Decap:

pcn_input            <55>  <0xfd0561f0, 0x4830ba8c>  <       0,        0>

q_fq_input           <96>  <0xfd05f330, 0x48312c7c>  <       0,        0>

mpls                 <25>  <0xfcc7b2b8, 0x00000000>  <     152,    17328>

Fixup:

l2_adj_rewrite       <86>  <0xfcaa945c, 0x00000000>  <       0,        0>

pcn_output           <54>  <0xfd0561f0, 0x48319f04>  <       0,        0>

q_fq                 <43>  <0xfd05f4b8, 0x48320fec>  <       0,        0>

txm_nopull           <60>  <0xfcadba38, 0x4824c0fc>  <       0,        0>

此处的多协议标签交换(MPLS)节点中的丢弃可能是由于MPLS生存时间(TTL)过期（在出现环路或客户执行traceroute时），或者需要分段并且设置了Do Not Fragment(DF)位。您可以对接口的位置运行debug mpls packet drop和debug mpls error，以尝试了解哪种数据包会增加此计数器。

传送组播数据包。当您看到netio IN丢弃数据包但下面没有netio节点以及一些可以解释IN丢弃数据包的丢弃时，这可以是组播转发数据包，并且您可以启用deb mfib netio drop以确定数据包的类型