簡介
本文說明如何對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中增加輸入捨棄計數器。在這種情況下，沒有什麼需要擔心的，因為如果沒有配置功能，最好丟棄這些幀。
- 由於錯誤，ASR 9000的Cisco Express Forwarding(CEF)條目被錯誤程式設計，因此它不指向有效的鄰接關係。在這種情況下，ASR 9000線路卡(LC)的網路處理器會意識到路由器遺漏負載資訊，並遞增一個網路處理器(NP)捨棄計數器，該計數器會上傳到介面輸入捨棄計數器。
當報告輸入丟棄時，問題是要弄清楚它們是合法的丟棄（如示例1所示），還是問題的後果（如示例2中）。
問題：輸入丟棄中的增量
本文列出輸入捨棄值遞增的原因以及如何檢查其原因：
控制器丟棄
Runts、Frame Check Sequence(FCS)、aborts、First Input First Output(FIFO)溢位、Giants Packet Over 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 stats
檢視控制器統計資訊中是否有與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
註：思科錯誤ID CSCub74803存在。 至少在CRS的8埠固定式PLIM上，輸入丟棄其他操作會遞增，而不是輸入丟棄無效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上，控制器狀態中的輸入丟棄無效DMAC和輸入丟棄其他計數器不會遞增。因此，在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路由器的span。
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 controller np counters np<y>位置0/<x>/CPU0檢查其NP計數器。
您可以對輸出進行管道處理，以便僅使用sh contr np counters np<y> location 0/<x>/CPU0等命令保留DROP計數器 | i DROP，但有時由於丟棄計數器的名稱中沒有DROP，因此這種操作會很危險。您已經看到一個使用L3_NOT_MYMAC的很好示例。因此，可能為DROP|DISCARD|NOT|EXCD建立管道。
您可以大致同時清除介面計數器和具有清除控制器np計數器np<y>位置0/<x>/CPU0的NP計數器，以找出哪個NP計數器以與輸入捨棄相同的速率增加。
例如，您在NP計數器中得到IPV4_PLU_DROP_PKT，這表示CEF/PLU條目表示必須丟棄資料包。 您沒有預設路由，並且禁用了不可達，因此不匹配更具體路由的資料包（其中點選預設CEF處理程式）是一個丟棄條目。
如果您在NP中找到一個丟棄計數器，它可以解釋以相同速率遞增的輸入丟包，但NP丟棄計數器並不是非常容易解釋的，您可以瀏覽此頁來嘗試理解計數器的含義：
ASR9000/XR：資料包丟棄故障排除和瞭解NP丟棄計數器
註:Xander的支援論壇頁面包含第一代線卡（三叉戟）的丟棄原因，並且新一代（颱風）線卡有新的計數器名稱。根據名稱，您必須能夠找到與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 drop pkts但是下面沒有包含一些可能解釋IN drop pkts的丟棄的netio節點時，可以廣播投擲的資料包，並且您可以啟用deb mfib netio drop以確定資料包的型別
意見