Arista一般的なトラブルシューティング

パケットロス等の一般的なトラブルシューティングを説明します。

トラフィックロスについて

目的）

ネットワーク接続の問題を診断または絞り込むために迅速に実行できる一般的なトラブルシューティング手順の一部を説明します。

停止の性質は、大まかに次のように分類できます。

• 完全なトラフィック損失
• 断続的なトラフィック損失

完全なトラフィック損失

次の手順は、2 つのホスト間の ping またはデータ トラフィックによって 100% のトラフィック損失が発生するシナリオに役立ちます。
まず、対象となる両方のホストのIPアドレスとMACアドレスを収集します。
ここで、次の 2 つの条件があります。

条件 1 ホストが同じサブネット内にある

次の手順は、問題が発生している可能性のあるホスト間のスイッチを切り分けるのに役立ちます。

STEP1
Host-AからHost-Bへ、またHost-BからHost-Aへ連続pingを開始します。ステップ2に進みます。
注:両方向で連続pingを実行すると、スイッチがMACアドレスを学習するのに役立ちます。

STEP2
STEP1の後、ホスト間のフォワーディングパスと予想されるリバースパスを特定する必要があります。これには、パス内のすべての中間スイッチで「show mac-address-table」コマンドを実行して、どのポートでホストAのmacアドレスが学習され、どのポートでホストBのmacアドレスが学習されるかを識別することが含まれます。
次のコマンドは、同じものを判断するのに役立ちます。

switch#show mac address-table

ステップ2では、Host-AとHost-BのMACアドレスが全ての中間スイッチの正しいポートで学習されていることを確認してください。学習していない場合は、Step3に進んでください。
全ての中間スイッチの正しいインターフェイスで MAC アドレスが学習された場合は、ステップ 5 に進みます。

STEP3
Step2から、MACアドレスが正しく学習されていないスイッチを特定できます。
エンド ホストが存在する VLAN が、スイッチの両方のポート(入力/出力)で許可されていることを確認します。

確認のため、以下のコマンドを実行してください。

Switch#show vlan vlan-number

ステップ3から、それぞれのVLANがホスト間のフォワードパスとリバースパスの両方で許可されているかどうかを判断できます。

VLANが正しく設定されている場合は、STEP4に進みます。

STEP4
スパニングツリーがパス内の特定のポートをブロックしていないことを確認します。

switch#show spanning-tree vlan vlan-number

上記のコマンドを数回繰り返し実行、前の出力から出力に変更があるかどうかを確認します。
ステップ4で、問題が特定されない場合は、ステップ5に進みます。

STEP 5
プラットフォームがCPUへの高度なミラーリングをサポートしている場合は、スイッチがパケットを送受信しているかどうかを判断するために使用できます。

以下はコマンドです。

Switch(config)#monitor session 1 source Ethernet Interface-number both
Switch(config)#monitor session 1 destination Cpu
Switch(config)#tcpdump session 1 file flash:FileName.pcap

スイッチのフラッシュからpcapファイルを収集、Wiresharkなどのツールで分析するか、次のコマンドを使用してコンソールでpcapファイルを展開します。

Switch#bash tcpdump -r /mnt/flash/FileName.pcap | less

STEP6
両方のホストが互いの有効なarpエントリを持っているかどうかを確認します。
ホストに有効な arp エントリがない場合は、ドキュメントの最後に進み、Arista TAC が必要とする必要な情報について説明してください。
両方のホストに有効な arp エントリがある場合はステップ7に進みます。

STEP 7
以下の方法は、問題を特定するための追加の手順であり、すべてのネットワーク環境に適しているとは限りません。

方法 1

ホップ バイ ホップ チェックでビンをカウンターする Host-A の観点から、パス内の最初のスイッチにログインします。
ステップ2から、入力ポートと出力ポートを決定しました。それに基づいて、次のコマンドを実行します。

Switch#show interfaces ethernet <ingress port> counters bins

Sample Flow

Traffic Flow is in this direction ————>
Interface Eth27/4 ——- |Switch| —— Interface Eth23/4
Switch#show interfaces ethernet 27/4 counters bins
Input
Port 512-1023 Byte 1024-1522 Byte 1523-MAX Byte
————————————————————-
Et27/4

カウンターがゼロであるか、一定期間にわたって増加していないビンを特定します。

ビンのバイト範囲をメモします。

ステップ 1 で開始した ping を停止し、ビンのサイズがゼロ/増分しない新しい ping を開始します。
入力/出力カウンタが増加しているかどうかを確認します。

Switch#show interfaces ethernet 27/4 counters bins
Input
Port 512-1023 Byte 1024-1522 Byte 1523-MAX Byte
————————————————————-
Et27/4 5 0 0
Switch#show interfaces ethernet 23/4 counters bins
Output
Port 512-1023 Byte 1024-1522 Byte 1523-MAX Byte
————————————————————-
Et23/4 5 0 0

パス内のの全ての L2 スイッチをホップごとにチェック、どのスイッチの入力/出力カウンタが一致していないかを特定します。

方法 2

エントリーごとの統計情報を持つ IP ACL:プラットフォームと EOS コードの互換性に応じて、次の方法を使用してホップバイホップ パケットの伝搬を確認できます。
前の手順から、入力ポートと出力ポートはすべての中間スイッチで識別されます。
転送パス内のすべての着信インターフェイスに入力ポート ACL を適用します。
ACL 設定の例は次のとおりです。

ip access-list test
statistics per-entry
10 permit ip host hostA_IP host hostB_IP
20 permit ip any any

interface Ethernet1
ip access-group test in

Host-A から Host-B への ping を say count として 5 で開始します。
ACL 統計情報が 5 パケット数と一致したかどうか、全ての中間ノードで確認します。

そうでない場合は、前のホップにジャンプしてログを確認します。

Switch#sh ip access-lists test
IP Access List test
statistics per-entry
10 permit ip host 1.1.1.12 host 1.1.1.13 [match 5 packets, 0:00:00 ago]
20 permit ip any any

条件 2 ホストが異なるサブネットにある場合

ホストがゲートウェイに ping できるかどうかを確認します。
ホストから traceroute を実行し、障害が発生したポイントを確認します。
障害のあるデバイスに宛先への有効なルートがあるかどうかを確認します。

Switch#show ip route <destination_IP>

問題が存在する可能性のあるネットワークのセクションを特定したら、条件 1 に記載されている手順に従って、問題をさらに切り分けることができます。

断続的なトラフィック損失

まず、対象となる両方のホストのIPアドレスとMACアドレスを収集します。
送信元と宛先の間のパスにインターフェイス フラップがあるかどうかを確認します。

その場合は、フラップが発生しているスイッチで次のログが繰り返し観察されます。

Leaf-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, changed state to down
Leaf-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, changed state to up

インターフェイスのフラップがランダムな間隔で発生している場合は、インターフェイスの稼働時間と状態変化の数を確認できます。

Switch#show interfaces ethernet 1
Ethernet1 is up, line protocol is up (connected)
Hardware is Ethernet, address is 5038.0002.0001 (bia 5038.0002.0001)
Member of Port-Channel1
Ethernet MTU 9214 bytes
Full-duplex, Unconfigured, auto negotiation: off, uni-link: n/a
Up 10 seconds
Loopback Mode: None
17 link status changes since last clea

スパニングツリーが不安定でないかどうかを確認します。

Switch#show logging | grep -i “Stp”
Stp: %SPANTREE-6-STABLE_CHANGE: Stp state is now not stable

次のコマンドを使用して、最新のタイムスタンプで発生したスパニングツリートポロジの変更の数を確認できます。

タイムスタンプと変更数の助けを借りて、STPがスイッチで安定しているかどうかを判断できます。

Switch#show spanning-tree detail
MST0 is executing the mstp Spanning Tree protocol
<snipped>
Root port is 100 (Port-Channel1), cost of root path is 0 (Ext) 1999 (Int)
Number of topology changes 3 last change occurred 4842 seconds ago from Port-Channel1

インターフェイスに出力廃棄があるかどうかを確認します。
次の出力を数回の反復で収集して、一定期間にわたってカウンターが増加しているかどうかを判断できます。

Switch#show interfaces counters discards | nz
Port InDiscards OutDiscards
————— —————- ———–
Et11 0 15
Et12 0 10092
Et13 0 31095
——— ——— ———
Totals 0 41202

ホスト間のパスのインターフェイスに CRC エラーと Rx エラーがあるかどうかを確認します。

————- show interfaces counters errors ————-
Port FCS Align Symbol Rx Runts Giants Tx
Et1 3245 0 0 3245 0 0 0
Et2 1939 0 0 1939 0 0 0
<snipped>

注:ここに記載されている手順は、エンジニアが問題が存在する可能性のある特定のスイッチまたはネットワークデバイスまで問題を追跡するのに役立ちます。ただし、問題の性質を確認して判断するために、弊社への問い合わせをお勧めします。

※本内容は、Arista社のドキュメント等より情報を抜粋し東京エレクトロンデバイスにて記事としてまとめたものとなります。