はじめに
このドキュメントでは、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のinput dropsカウンタが増加します。この場合、機能が設定されていないため、これらのフレームをドロップすることは正しいことであるため、心配する必要はありません。
- ASR 9000には、バグが原因で誤ってプログラムされたCisco Express Forwarding(CEF)エントリがあるため、有効な隣接関係をポイントしていません。この場合、ASR 9000ラインカード(LC)のネットワークプロセッサ(NP)は、ルータがロード情報を失ったことを認識し、インターフェイスの入力ドロップカウンタにアップロードされるネットワークプロセッサ(NP)ドロップカウンタを増分します。
入力廃棄が報告された場合、問題は、これらが例1のような正当な廃棄なのか、または例2のような問題の結果なのかを判断することです。
問題：入力ドロップの増加
このドキュメントでは、インプットドロップが増加する理由とその理由を確認する方法を次のように列挙します。
コントローラドロップ
ラント、Frame Check Sequence（FCS；フレームチェックシーケンス）、打ち切り、First Input First Output（FIFO；最初の入力先出力）のオーバーフロー、Giants Packet Over SDH/SONET（POS；ジャイアントPacket Over SDH/SONET）ドロップ。
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の入力ドロップカウンタと同じ速度で増加するカウンタが1つあるかどうかを確認します。これらのエラーカウンタの一部は、show interfaceでも出力される必要があります。
不明な宛先Medium Access Control Address(DMAC)またはdot1q VLAN
宛先MACアドレスがインターフェイスのMACアドレスではないパケット、または仮想ローカルエリアネットワーク(VLAN)がサブインターフェイスに一致しないパケット。これらは、不明なユニキャストMACアドレスのL2ドメインでフラッディングが発生した場合に発生する可能性があり、そのL2ドメインに接続されているXRルータは、コントローラの1つではない宛先MACアドレスが設定されたフレームを受信します。 Cisco IOSルータがGigeインターフェイスでイーサネットキープアライブを送信している場合にも、XRルータの宛先MACアドレスを持たないため、これらのキープアライブによってXRルータでの入力ドロップが増加する可能性があります。また、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ポートtengige固定PLIMでは、Input drop invalid DMACの代わりにinput drop otherが増分されます。
共有ポートアダプタ(SPA)(CRS、XR 12000)の場合、無効なMACを持つパケットはSPA l2-tcamによってドロップされるため、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 in the controller statsは増分されません。したがって、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#
インターフェイスギガ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インターフェイス上で、インターフェイスの1つではない宛先MACアドレスを持つフレームを受信したことを意味します。ルータは想定どおりにパケットをドロップし、これはshow interfaceで入力廃棄として報告されます。
ASR 9000のサブインターフェイスにdot1q VLANが設定されていない状態で受信されたパケットのASR 9000では、show controllers gigabitEthernet 0/0/0/30 statsのInput drop unknown 802.1Qカウンタが増加しません。手順は不明なDMACに関する上記と同じです。どのNPがインターフェイスを処理するかを特定し、このNPカウンタを確認します。この場合、NPカウンタUIDB_TCAM_MISS_AGG_DROPが増加していることがわかります。
認識されない上位プロトコルが原因でドロップされたパケット
この廃棄に対するカウンタはshow interfaceの入力廃棄の1行より下にあるため、このカウンタの検出は簡単です。
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
ここでは、すべての入力ドロップが認識されていない上位レベルのプロトコルが原因であることが分かります。
これは、ルータが対象としないイーサネットプロトコルでパケットが受信されたことを意味します。つまり、XRルータで設定されていないプロトコルを使用してフレームを送信するように、機能がネイバー（またはそのインターフェイスに接続されたレイヤ2ドメインに接続されたホスト）で設定されます。
例：BPDU、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)....
これらの機能がXRインターフェイスで設定されていない場合、XRボックスは期待どおりにドロップします。このカウンタが増加しているフレームの種類を調べるには、XRルータで有効になっている機能（ルータまたはスイッチの場合があります）と、ネイバーで有効になっている機能（ルータまたはスイッチの場合があります）を比較するか、そのインターフェイスに接続されているレイヤ2ドメインに接続されているすべてのデバイスで有効になっている機能（はるかに簡単ではありません）を比較する必要があります。XRルータがスイッチに接続されている場合は、入力ドロップが発生しているインターフェイス上のXRルータに送信するパケットのスパンをそのスイッチで試行できます。
ASR9000/XR:Drops for Unrecognized Upper-Level Protocolエラー
ASR 9000でのNPドロップ
ASR 9000のネットワークプロセス(NP)のドロップカウンタは、インターフェイスで受信されたパケットに適用されてドロップされた場合、入力ドロップとして報告されます。これは、CRSおよびXR 12000でのPacket Switch Engine(PSE)ドロップでは発生しません。これらは入力ドロップとしてカウントされません。
そのため、ASR 9000に入力廃棄があり、これらが上記の理由のいずれにも一致しない場合は、show controllers np ports all location 0/<x>/CPU0を実行して入力廃棄を伴うインターフェイスを処理しているNPを見つけ、show contr np counters np<y> location 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のパイプを使用できます。
clear controller np counters np<y> location 0/<x>/CPU0を使用して、インターフェイスカウンタとNPカウンタをほぼ同時にクリアし、入力のドロップと同じレートでどのNPカウンタが増加するかを調べることができます。
たとえば、NPカウンタにIPV4_PLU_DROP_PKTが表示される場合、これはCEF/PLUエントリがパケットを廃棄する必要があることを示していることを意味します。 デフォルトルートがなく、到達不能がディセーブルになっているため、デフォルトのCEFハンドラに到達するより具体的なルートに一致しないパケットは廃棄エントリになります。
NPでドロップカウンタが見つかった場合、そのカウンタは同じレートで増加するにつれて入力ドロップを説明しますが、NPドロップカウンタは説明の必要があまりない場合は、このページに移動してカウンタの意味を理解できます。
ASR9000/XR：パケットドロップのトラブルシューティングとNPドロップカウンタの理解
注：サポートフォーラムのXanderのページには、第1世代のラインカード(Trident)のドロップの理由が記載されており、新しい世代(Typhoon)のラインカードには新しいカウンタ名があります。名前に基づいて、Tridentと同様のカウンタ名を見つけることができる必要があります。
Netio
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>
この場合のMulti-Protocol Label Switching（MPLS；マルチプロトコルラベルスイッチング）ノードでの廃棄は、MPLSのTime To Live（TTL；存続可能時間）の期限切れ（ループの場合、またはお客様がtracerouteを実行する場合）、または、たとえば断片化が必要でDo Not Fragment（DF；フラグメントなし）ビットが設定されていることが原因で発生します。インターフェイスの場所を指定してdebug mpls packet dropおよびdebug mpls errorを実行すると、このカウンタで増加しているパケットの種類を調べることができます。
パントされたマルチキャストパケット。netio IN drop pktsが表示されるが、IN drop pktsを説明できるいくつかのドロップを含むnetioノードが下にない場合は、これはmcastパントされたパケットである可能性があり、deb mfib netio dropを有効にしてどのようなパケットを扱うかを判断できます
フィードバック