ACI Intra-Fabric Forwardingのトラブルシューティング：断続的なドロップ

はじめに

このドキュメントでは、ACIの断続的なドロップをトラブルシューティングする手順について説明します。

背景説明

このドキュメントの内容は、『Troubleshooting Cisco Application Centric Infrastructure, Second Edition』のマニュアル、特に「Intra-Fabric forwarding - Intermittent drops」の章から抜粋しています。

ACI Intra-Fabric Forwardingのトラブルシューティング：断続的なドロップ

トポロジの例

この例では、EP A(10.1.1.1)からEP B(10.1.2.1)へのpingで断続的なドロップが発生しています。

[EP-A ~]$ ping 10.1.2.1 -c 10
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_seq=1 ttl=231 time=142 ms
64 bytes from 10.1.2.1: icmp_seq=2 ttl=231 time=141 ms
                                   <-- missing icmp_seq=3

64 bytes from 10.1.2.1: icmp_seq=4 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=5 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=6 ttl=231 time=141 ms
                                    <-- missing icmp_seq=7

64 bytes from 10.1.2.1: icmp_seq=8 ttl=231 time=176 ms
64 bytes from 10.1.2.1: icmp_seq=9 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=10 ttl=231 time=141 ms

--- 10.1.2.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9012ms

トラブルシューティングワークフロー

1. 間欠的なドロップの原因になっている方向を特定します

宛先ホスト(EP B)でパケットキャプチャ（tcpdump、Wiresharkなど）を実行します。 ICMPの場合、シーケンス番号に注目して、断続的にドロップされるパケットがEP Bで観測されることを確認します。

[admin@EP-B ~]$ tcpdump -ni eth0 icmp
11:32:26.540957 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 1, length 64
11:32:26.681981 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 1, length 64
11:32:27.542175 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 2, length 64
11:32:27.683078 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 2, length 64
11:32:28.543173 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 3, length 64   <---
11:32:28.683851 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 3, length 64     <---
11:32:29.544931 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 4, length 64
11:32:29.685783 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 4, length 64
11:32:30.546860 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 5, length 64
...

• パターン1 – すべてのパケットがEP Bのパケットキャプチャで確認される

ドロップはICMPエコー応答（EP BからEP A）である必要があります。

• パターン2:EP Bのパケットキャプチャで断続的なドロップが観察される。

ドロップはICMPエコー（EP AからEP B）である必要があります。

2. 同じ送信元/宛先IPを持つ別のプロトコルに同じ問題があるかどうかを確認する

可能であれば、2つのエンドポイント間の契約で許可されている別のプロトコル（ssh、telnet、httpなど）を使用して、エンドポイント間の接続をテストします。

• パターン1：他のプロトコルでも同じ断続的な廃棄が発生しています。

この問題は、エンドポイントフラッピング、または次に示すキューイング/バッファリングにある可能性があります。

• パターン2：断続的なドロップがあるのはICMPだけです。

転送テーブル（エンドポイントテーブルなど）は、MACとIPに基づいているため、問題がない可能性があります。キューイング/バッファリングは他のプロトコルに影響を与えるため、その理由にもなりそうにありません。ACIがプロトコルに基づいて異なる転送の決定を行う唯一の理由は、PBRの使用例です。

可能性の1つは、スパインノードの1つに問題があることです。プロトコルが異なる場合、同じ送信元と宛先を持つパケットは、入力リーフによって別のアップリンク/ファブリックポート（つまり、別のスパイン）にロードバランスされる可能性があります。

アトミックカウンタを使用すると、パケットがスパインノードで廃棄されず、出力リーフに到達することを確認できます。パケットが出力リーフに到達しなかった場合は、入力リーフのELAMをチェックし、パケットがどのファブリックポートから送信されているかを確認します。問題を特定のスパインに切り分けるために、リーフアップリンクをシャットダウンして、トラフィックを別のスパインに向けることができます。

3. エンドポイントラーニングの問題に関連しているかどうかを確認する

ACIはエンドポイントテーブルを使用して、あるエンドポイントから別のエンドポイントにパケットを転送します。エンドポイント情報が不適切であると、パケットが誤った宛先に送信されたり、誤ったEPGに分類されてコントラクトがドロップされたりするため、エンドポイントのフラッピングが原因で、断続的な到達可能性の問題が発生する可能性があります。宛先がエンドポイントグループではなくL3Outであると想定される場合でも、リーフスイッチ全体で同じVRFのエンドポイントとしてIPが学習されていないことを確認します。

エンドポイントフラッピングのトラブルシューティングの詳細については、このセクションの「エンドポイントフラッピング」サブセクションを参照してください。

4. トラフィックの周波数を変更することで、バッファリングの問題に関係しているかどうかを確認します

pingの間隔を増減して、ドロップ率が変化するかどうかを確認します。間隔の差は十分に大きくなければなりません。

Linuxでは、'-i'オプションを使って間隔（秒）を変更できる。

[EP-A ~]$ ping 10.1.2.1 -c 10 -i 5     -- Increase it to 5 sec
[EP-A ~]$ ping 10.1.2.1 -c 10 -i 0.2   -- Decrease it to 0.2 msec

インターバルを短くするとドロップ率が増加する場合、エンドポイントまたはスイッチでのキューイングまたはバッファリングに関連している可能性があります。

考慮すべき廃棄率は、（ドロップ数/時間）ではなく（ドロップ数/送信パケットの総数）です。

このようなシナリオでは、次の条件を確認します。

1. pingとともにスイッチインターフェイスのドロップカウンタが増加しているかどうかを確認します。詳細は、「Intra-Fabric Forwarding」の章の「Interface drops」のセクションを参照してください。
2. 宛先エンドポイント上のパケットとともにRxカウンタが増加しているかどうかを確認します。送信されたパケットと同じ数だけRxカウンタを増やした場合、パケットはエンドポイント自体でドロップされている可能性があります。これは、TCP/IPスタックでのエンドポイントのバッファリングが原因である可能性があります。

たとえば、100000回のpingができるだけ短い間隔で送信された場合、エンドポイントのRxカウンタが100000ずつ増加するにつれて監視されます。

[EP-B ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 10.1.2.1  netmask 255.255.255.0  broadcast 10.1.2.255
       ether 00:00:10:01:01:02  txqueuelen 1000  (Ethernet)
       RX packets 101105  bytes 1829041
       RX errors 0  dropped 18926930  overruns 0  frame 0
       TX packets 2057  bytes 926192
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

5. ACIがパケットを送信しているか、または宛先がパケットを受信しているかを確認します

リーフスイッチの出力ポートでSPANキャプチャを実行し、ACIファブリックをトラブルシューティングパスから除外します。

宛先のRxカウンタも、前のバッファリングの手順で示したように、ネットワークスイッチ全体をトラブルシューティングパスから除外する場合に役立ちます。

エンドポイントフラッピング

このセクションでは、エンドポイントフラッピングを確認する方法について説明します。詳細については、次のドキュメントを参照してください。

• www.cisco.comの「ACIファブリックエンドポイントラーニングホワイトペーパー」
• www.ciscolive.comの「Cisco Live BRKACI-2641 ACI Troubleshooting: Endpoints」

ACIが複数の場所で同じMACアドレスまたはIPアドレスを学習すると、エンドポイントが移動したように見えます。また、スプーフィングデバイスや設定ミスが原因で発生することもあります。このような動作は、エンドポイントフラッピングと呼ばれます。このようなシナリオでは、移動/フラッピングエンドポイントへのトラフィック（ブリッジドトラフィックのMACアドレス、ルーテッドトラフィックのIPアドレス）が断続的に失敗します。

エンドポイントフラッピングを検出する最も効果的な方法は、Enhanced Endpoint Trackerを使用することです。このアプリは、ACI AppCenterアプリとして、またはより大規模なファブリックを管理する必要がある場合に備えて外部サーバー上のスタンドアロンアプリとして実行できます。

拡張エンドポイントトラッカー

廃止に関する警告このガイドは4.2で作成されましたが、それ以降、Nexus Dashboard Insightsの機能を優先してEnhanced Endpoint Trackerアプリは廃止されました。詳細については、Cisco Bug ID CSCvz59365を参照してください。 .

次の図は、AppCenterのEnhanced Endpoint Trackerを示しています。この例では、Enhanced Endpoint Trackerを使用してフラッピングエンドポイントを検出する方法を示します。

エンドポイントフラッピングの例

この例では、IP 10.1.2.1はMAC 0000.1001.0102のEP Bに属している可能性があります。ただし、MAC 0000.1001.9999を含むEP Xも、設定ミスまたはIPスプーフィングが原因で、IP 10.1.2.1を含むトラフィックを発信しています。

拡張エンドポイントトラッカー出力：移動

Enhanced Endpoint Tracker(ELT)は、IP 10.1.2.1が学習された時間と場所を示します。前のスクリーンショットに示されているように、MAC 0000.1001.0102（予定）と0000.1001.9999（予定なし）の2つのエンドポイント間で10.1.2.1がフラッピングしています。 これにより、IP 10.1.2.1に対する到達可能性の問題が発生します。これは、誤ったMACアドレスで学習されたパケットが誤ったインターフェイスを介して誤ったデバイスに送信されるためです。これを解決するには、予期しないVMが不適切なIPアドレスを持つトラフィックを送信しないようにするための手順を実行します。

次の例は、不適切な設定が原因でエンドポイントがフラッピングしていることを示しています。

エンドポイントフラッピングを引き起こす可能性があるトポロジの例

サーバまたはVMがVPCのない2つのインターフェイスを介してACIリーフノードに接続されている場合、サーバはアクティブ/スタンバイNICチーミングを使用する必要があります。そうしないと、パケットは両方のアップリンクにロードバランシングされ、ACIリーフスイッチから見ると、2つのインターフェイス間でエンドポイントがフラッピングしているように見えます。この場合、アクティブ/スタンバイまたは同等のNICチーミングモードが必要であるか、ACI側でVPCを使用します。

インターフェイスの廃棄

この章では、入力インターフェイスのドロップに関連する主なカウンタを確認する方法について説明します。

ハードウェア ドロップ カウンタのタイプ

ACIモードで動作するNexus 9000スイッチには、入力インターフェイスのドロップに関してACIの主要なハードウェアカウンタが3つあります。

[転送（Forward）]

ドロップの主な理由は次のとおりです。

• SECURITY_GROUP_DENY：通信を許可する契約が欠落しているため、ドロップされます。
• VLAN_XLATE_MISS：不適切なVLANによるドロップ。たとえば、802.1Q VLAN 10を使用してフレームがファブリックに入ったとします。スイッチのポートにVLAN 10が設定されている場合、スイッチは内容を検査し、宛先MACに基づいて転送の決定を行います。ただし、VLAN 10がポートで許可されていない場合は、ドロップされ、VLAN_XLATE_MISSに分類されます。
• ACL_DROP:SUP-TCAMによるドロップ。ACIスイッチのSUP-TCAMには、通常のL2/L3転送の判断に加えて適用される特別なルールが含まれています。sup-tcam ルールは組み込み型でユーザ設定はできません。SUP-TCAMルールの目的は主に一部の例外または一部のコントロールプレーントラフィックを処理することにあり、ユーザによるチェックやモニタは意図されていません。パケットがSUP-TCAMルールに抵触していて、パケットをドロップするルールである場合、ドロップされたパケットはACL_DROPとしてカウントされ、転送ドロップカウンタが増加します。

転送ドロップは基本的に、既知の有効な理由でドロップされたパケットです。実際のデータトラフィックのドロップとは異なり、通常は無視してパフォーマンスを低下させることはありません。

エラー

スイッチが無効なフレームを受信すると、エラーとしてドロップされます。この例として、FCS や CRC エラーのフレームなどがあります。詳細については、後述の「CRC — FCS – カットスルースイッチング」の項を参照してください。

バッファ

スイッチがフレームを受信し、入力または出力に使用できるバッファがない場合、フレームは「Buffer」でドロップされます。 これは、ネットワークのどこかで輻輳が発生していることを示唆しています。障害を示すリンクがいっぱいであるか、宛先を含むリンクが輻輳している可能性があります。

APIを使用したカウンタの収集

APIとオブジェクトモデルを活用することで、ユーザはファブリックに対して、これらのドロップのすべてのインスタンスを迅速に照会できます（これらはapicから実行します）。 

# FCS Errors (non-stomped CRC errors)
moquery -c rmonDot3Stats -f 'rmon.Dot3Stats.fCSErrors>="1"' | egrep "dn|fCSErrors"

# FCS + Stomped CRC Errors
moquery -c rmonEtherStats -f 'rmon.EtherStats.cRCAlignErrors>="1"' | egrep "dn|cRCAlignErrors"

# Output Buffer Drops
moquery -c rmonEgrCounters -f 'rmon.EgrCounters.bufferdroppkts>="1"' | egrep "dn|bufferdroppkts"

# Output Errors
moquery -c rmonIfOut -f 'rmon.IfOut.errors>="1"' | egrep "dn|errors"

CLI でのドロップ状態表示

障害が指摘された場合、またはCLIを使用してインターフェイスでのパケットドロップを確認する必要がある場合、最善の方法はハードウェアのプラットフォームカウンタを表示することです。すべてのカウンタが「show interface」を使用して表示されるわけではありません。 3つの主なドロップの原因は、プラットフォームカウンタを使用してのみ確認できます。これらを表示するには、次の手順を実行します。

リーフ

リーフに SSH 接続し、次のコマンドを実行します。この例は、イーサネット1/31用です。

ACI-LEAF# vsh_lc
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-1/31    31  Total          400719   286628225      2302918    463380330
                   Unicast     306610   269471065       453831     40294786
                   Multicast        0           0      1849091    423087288
                   Flood        56783     8427482            0            0
                Total Drops     37327                        0
                   Buffer           0                        0
                   Error            0                        0
                   Forward      37327
                   LB               0
                   AFD RED                                   0
...

スパイン

固定スパイン（N9K-C9332CおよびN9K-C9364C）は、リーフスイッチと同じ方法でチェックできます。

モジュラスパイン(N9K-C9504、...)の場合、プラットフォームカウンタを表示する前に、ラインカードを接続する必要があります。スパインにSSH接続し、次のコマンドを実行します。この例は、ethernet 2/1用です。

ACI-SPINE# vsh
ACI-SPINE# attach module 2
module-2# show platform internal counters port 1
Stats for port 1
(note: forward drops include sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-2/1      1  Total        85632884  32811563575     126611414   25868913406
                   Unicast   81449096  32273734109     104024872   23037696345
                   Multicast  3759719   487617769     22586542   2831217061
                   Flood            0           0            0            0
                Total Drops         0                        0
                   Buffer           0                        0
                   Error            0                        0
                   Forward          0
                   LB               0
                   AFD RED                                   0
...

キューイング統計情報カウンタは、「show queuing interface」を使用して表示されます。 この例は、イーサネット1/5用です。

ACI-LEAF# show queuing interface ethernet 1/5
================================================================================
                 Queuing stats for ethernet 1/5
================================================================================
================================================================================
                 Qos Class level1
================================================================================
Rx Admit Pkts :  0                      Tx Admit Pkts :  0                   
Rx Admit Bytes:  0                      Tx Admit Bytes:  0                   
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  0                   
Rx Drop Bytes :  0                      Tx Drop Bytes :  0                   

================================================================================
                 Qos Class level2
================================================================================
Rx Admit Pkts :  0                      Tx Admit Pkts :  0                   
Rx Admit Bytes:  0                      Tx Admit Bytes:  0                   
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  0                   
Rx Drop Bytes :  0                      Tx Drop Bytes :  0                   

================================================================================
                 Qos Class level3
================================================================================
Rx Admit Pkts :  1756121                Tx Admit Pkts :  904909              
Rx Admit Bytes:  186146554              Tx Admit Bytes:  80417455            
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  22                  
Rx Drop Bytes :  0                      Tx Drop Bytes :  3776   

...

GUIでの統計情報の表示

場所は、「Fabric」>「Inventory」>「Leaf/Spine」>「Physical interface」>「Stats」です。

GUIインターフェイスの統計情報

エラー統計も同じ場所で確認できます。

GUIインターフェイスエラー

最後に、GUIはインターフェイスごとのQoS統計情報を表示できます。

GUIインターフェイスのQoSカウンタ

CRC — FCS – カットスルースイッチング

巡回冗長検査(CRC)とは何ですか。

CRCはフレーム上の多項式関数で、イーサネットの4B値を返します。すべてのシングルビットエラーを捕捉し、ダブルビットエラーのかなりの割合を捕捉します。したがって、フレームが送信中に破損していないことを確認します。CRCエラーカウンタが増加している場合は、ハードウェアがフレームで多項式関数を実行したときに、結果として4Bの数がフレーム自体にある4Bの数と異なることを意味します。フレームは、デュプレックスのミスマッチ、ケーブル配線の欠陥、ハードウェアの破損など、いくつかの理由で破損する可能性があります。ただし、ある程度のCRCエラーが予想され、この規格ではイーサネットで最大10 ～ 12ビットのエラーレートが許容されます（1012ビットのうち1ビットが反転する可能性があります）。

ストアアンドフォワードスイッチングとカットスルースイッチング

ストアアンドフォワードとカットスルーのレイヤ2スイッチは、どちらもデータパケットの宛先MACアドレスに基づいて転送を決定します。また、ステーションがネットワーク上の他のノードと通信する際に、パケットの送信元MAC(SMAC)フィールドを調べることでMACアドレスを学習します。

ストアアンドフォワードスイッチは、フレーム全体を受信して整合性を確認した後で、データパケットの転送を決定します。カットスルースイッチは、着信フレームの宛先MAC(DMAC)アドレスを検査した直後に転送プロセスに入ります。ただし、カットスルースイッチは、CRCチェックを実行する前にパケット全体を確認するまで待つ必要があります。つまり、CRCが検証される時点で、パケットはすでに転送されており、チェックに失敗した場合はドロップできません。

従来、ほとんどのネットワークデバイスはストアアンドフォワードに基づいて動作していました。カットスルースイッチングテクノロジーは、低遅延の転送を必要とする高速ネットワークで使用される傾向があります。

具体的には、Generation 2以降のACIハードウェアでは、入力インターフェイスの速度が高く、出力インターフェイスの速度が同じかそれよりも低い場合に、カットスルースイッチングが行われます。ストアアンドフォワードスイッチングは、入力インターフェイスの速度が出力インターフェイスの速度よりも低い場合に実行されます。

ストンプ

CRCエラーのあるパケットは廃棄が必要です。フレームがカットスルーパスでスイッチングされる場合、パケットがすでに転送された後にCRC検証が発生します。そのため、イーサネットフレームチェックシーケンス(FCS)を停止することが唯一のオプションです。 フレームのストンプには、CRCチェックを通過しない既知の値へのFCSの設定が含まれます。このため、CRCに失敗した不正フレームが1つ、通過するすべてのインターフェイスでCRCとして表示され、これがストアアンドフォワードスイッチに到達して廃棄される可能性があります。

ACIおよびCRC：障害のあるインターフェイスを探す

• リーフでダウンリンクポートのCRCエラーが発生する場合、その原因は主にダウンリンクSFPの問題か、外部デバイス/ネットワークのコンポーネントの問題です。
• スパインでCRCエラーが発生する場合、そのローカルポート、SFP、ファイバ、またはネイバーSFPで問題が発生していることが多くなります。リーフダウンリンクからのCRC失敗パケットは、スパインにストンプされません。ヘッダーが読み取り可能であるかのように、VXLANでカプセル化され、新しいCRCが計算されます。ヘッダーがフレームの破損から読み取れないと、パケットはドロップされます。
• リーフでファブリックリンクのCRCエラーが発生する場合は、次のいずれかの状態になっている可能性があります。
  • ローカルファイバ/SFPペア、スパイン入力ファイバ、またはSFPペアの問題
  • 生地を通り抜けるストンプされたフレーム。

ストンプ：ストンプのトラブルシューティング

• ファブリック上でFCSエラーが発生しているインターフェイスを探します。FCSはポートに対してローカルで発生するため、両端のファイバまたはSFPに発生する可能性が高くなります。
• 「show interface」出力のCRCエラーは、合計FCS+Stomp値を反映します。\

次に例を示します。

次のコマンドを使用して、ポートを確認します

vsh_lc: 'show platform internal counter port <X>'

このコマンドでは、次の3つの値が重要です。

• RX_FCS_ERR:FCS障害。
• RX_CRCERR – 受信したストンプCRCエラーフレーム。
• TX_FRM_ERROR：送信ストンプCRCエラーフレーム。

module-1# show platform internal counters port 1 | egrep ERR
        RX_FCS_ERR           0     ---- Real error local between the devices and its direct neighbor
        RX_CRCERR            0     ---- Stomped frame --- so likely stomped by underlying devices and generated further down the network 
        TX_FRM_ERROR         0     ---- Packet received from another interface that was stomp on Tx direction

CRCストンプのトラブルシューティングシナリオ

破損したリンクが大量の破損フレームを生成した場合、これらのフレームは他のすべてのリーフノードにフラッディングされる可能性があり、ファブリック内のほとんどのリーフノードのファブリックアップリンクの入力側にCRCが存在する可能性があります。これらはすべて、1つの破損したリンクから発生する可能性があります。