Nvidia/Mellanox製品 こんな時どうする トラブルシューティング（切り分け手法）
弊社にて開催しておりますトラブルシューティングウェビナーの内容を掲載します。
本内容は私が長年サポートして体験した、こんな時にこのようなツールを使ってこのようなことが確認できる、こんなことがあって、実はこんな原因だったなど、
長年のサポートの経験から得た情報を紹介します。
実際のウェビナーは、1時間2回のコースで開催してますが本サイトでは、それをの7項目に分類して紹介させていただきます。
ここで紹介する内容が、皆様がNVIDIA/Mellanox製品をお使いの際、不具合に遭遇した場合の切り分けや調査にに役に立つことをサポートスタッフ一同
心より願っております。
■こんな時どうする？ パート1（1日目）
1 はじめの一歩 まずはログを見ましょう
1.1 お願い 時間を正確に合わせておいてください
1.2 NIC/HCAのログ
1.3 スイッチのログ
2 ハードウェアの状態確認
2.1 NIC/HCA ハードウェア/ドライバの状態確認
2.2 スイッチ ハードウェア/ドライバの状態確認
3 便利なコマンド、ツールの紹介
3.1 Linkアップしない！ 突然Linkがダウンした！
3.1.1 アダプタ サーバから認識されているか？ MFTでの確認
3.1.2 アダプタ Link状態の確認 MFT
3.1.3 おまけ アダプタ パラメータの確認/変更方法 MFT
3.1.4 スイッチ ポート状況の確認 スイッチのコマンドでの確認
3.1.5 スイッチ MFTでのポート状況の確認
3.1.6 アダプタ（NIC/HCA）、スイッチでのケーブルの確認 MFT
3.2 SNMPサーバでスイッチのパケットロスを検知！ なんかパフォーマンスが悪いぞ？
3.2.1 スイッチ パケットカウンター Ethernet（ONYX)
3.2.2 WJH（What Just Happened） Ethernet（ONYX）
3.2.3 Discardパケットカウンター確認 Ethernet（ONYX）
3.2.4 ポートのトラフィックの確認 Ethernet（ONYX）
■こんな時どうする？ パート2（2日目）
4 sysinfo-snapshot/sysdump
4.1 アダプタ（NIC/HCA） sysinfo/system-sysinfo-snapshotの取得方法
4.1.1 Linuxでのsysinfo-snapshot取得方法
4.1.2 Windowsでのsystem-sysinfo-snapshot取得方法
4.2 アダプタ（NIC/HCA） sysinfo/system-sysinfo-snapshotの見方
4.3 スイッチ sysdumpの取得方法
4.3.1 CLIでのsysdumpの生成と取得方法
4.3.2 WebUIでのsysdumpの生成と取得方法
4.3.3 sysdumpの見方
5 あると便利！ What Just Happened
5.1 WebUIでWhat Just Happenedを見てみよう
5.2 CLIでWhat Just Happenedを見てみよう！
5.3 What Just HappenedでPCAPファイルを自動生成、そのPCAPファイルを見る方法
5.3.1 PCAPファイルファイルの自動生成の設定方法法
5.3.2 WJHの生成したPCAPファイルファイルを見る方法
6 事例から学ぶ！ 本当にあったこんな話！
6.1 やはり多いのは、ケーブルやトランシーバ
6.1.1 互換DACケーブル（異種ベンダー接続用）
6.1.2 ケーブルが抜けない！
6.1.3 SFPが抜けない！
6.1.4 光ケーブルの接続の不具合！
6.1.5 ケーブルが抜けているのにスイッチのLEDが点灯している
6.1.6 スイッチのポートLEDはグリーンでLinkUpしているが通信できない！
6.1.7 WinOF-2ドライバのTeaming機能でアダプタやチームがゾンビになった
6.2 スイッチOSのアップデート/ダウングレードでのトラブル
6.2.1 アップデートでErrorが出てアップデートが始まらない
6.2.2 ダウングレードしたら、スイッチが初期化した！
6.2.3 コンフィグのバックアップをしていない テキストからのリストア方法について
6.2.4 バイナリでバックアップしたコンフィグの内容を確認したい
6.3 アダプタ関連のトラブルのご紹介
6.3.1 sysinfo-snapshotを取得しようとしたら、いつまで経っても終了しない
6.3.2 Windowsのドライバアップデートでの注意点
7. 弊社へのお問い合わせ（障害発生時）に提供していただきたい情報について
1 はじめの一歩 まずはログを見ましょう！
1.1 お願い!! 時間は正確に合わせておいてください
トラブルを調査したり解析したりする場合、時系列が重要になります。サーバ、スイッチの時間は常日頃から必ず正確に合わせてください
NIC/HCA ：搭載しているシステムの時間を正確に設定してください（NTPなど）
スイッチ ：初期設定（工場出荷状態）でウィザードで設定してください。
SETP11:Update Time?
手動で設定する場合
CLIの場合: clockコマンドで設定します。
＃show clock
現在の状態を確認できます
＃clock timezone XXXXX で、タイムゾーンを設定します。
例: switch (config) # clock timezone Asia Eastern Tokyo
＃clock set <hh>:<MM>:<SS> <YYYY>/mm/ddで設定してください。
例: switch (config) # clock set 23:23:23 2010/08/19
WebUIの場合：「Setup」→「Date and Time」で設定できます。
1.2 NIC/HCAのログ
NIC/HCAを搭載しているサーバ/ワークステーションのログを確認してください。
Windows：EventViewer
Linux：/var/log/message や dmesgなど
Mellanoxやmlnxなどで検索することにより、WarningやErrorなどヒントを得ることが出来ます。
1.₃ スイッチのログ
スイッチのログはCLI、WebUIでもどちらでも確認出来ます。ただしどちらも操作や表示面で使いづらいので、私の場合はWebUIで接続して、接続したPCのローカルにテキストとしてログをダウンロードして、自身のエディタで見てます。こちらの方法の方がオススメです。
Logレベル７つあります、初期状態はNoticeです
下に行くほどログの粒度が細かくなりファイルサイズもより多く消費します。
emerg —system is unusable (emergency)
alert —alert notification
crit —critical condition
err —error condition
warning —warning condition
notice —normal, but significant condition
info —informational condition
debug —debug level messages
Notice →info に変更することにより、より詳細なLogを記録できますが、その分、Logの保存期間は短くなりますので注意が必要です。詳細はマニュアルの「Logging」を参照ください。
CLI： #show log でログを見ることが出来ます。
コマンドに続けて以下のオプションを付け加えられます。
– Continuous Logを継続して出力する Linuxでいう tail -f
– debug View event debug-logs
– files ファイル番号（1-10）を指定して表示 ログは20MB単位で10ファイル保存します。11ファイル目からは古い順に上書きとなります。
– matching 特定の合致した文字のある行を抽出 いわゆる grepです。
not 特定の文字に合致しない行を抽出
例 # show log files 1 matching “down”
Show log を実行すると、ログの参照モードになり、つづけて「h」キーを入力するとHelp画面になります。
動画デモはこちら 1-Switch-show logの見方
WebUI: 「Status」→「logs」で確認できます
しかしながらWebUI画面の表示数がすくないため、1つのログでも膨大なページ数となります。 画面上部の「Filter」で特定の文字列などでソートすることはできますが、いかんせん表 が 少ないため見づらいです。
■WebUIで接続しているPCにログをダウンロードする方法
「Status」→「logs」の中にあるDump Log Files」で、スイッチのWebUIに接続しているPCにテキストしてダウンロードできます。
デモ動画はこちらからご覧になれます 2-WebUIからLogの取り方
■CLIではコマンドでSCPサーバにログを送信することも出来ますが、実際の現地でSCPを受けるサーバ等が必要になります。
switch (config) # logging files upload 1 scp://admin@scpserver
2 ハードウェアの状態確認
ログの次は、実際のハードウェア（NIC/HCA、スイッチ）のハードウェアの状態を確認してください。
2.1 NIC/HCA ハードウェア/ドライバの状態確認
アダプタ（NIC/HCA）が正しくOSから認識されて、ドライバがロードされているか確認します。
■Windowsの場合：デバイスマネージャで確認します。
■Linuxの場合：
#lspci |grep Mellanox ハードウェアの認識の確認
PCIeバスの03:00にデュアルポートのNIC（ConnectX-5）が0，1で認識されてます。
#lsmod |grep mlx* ドライバがロードされているか確認
mlx5ドライバがロードされていることがわかります。
動画デモはこちら 3-アダプタ OSでの確認
2.2 スイッチ ハードウェア/ドライバの状態確認
機器正面パネルにあるLEDを参照してください。
以下はSN2xxxシリーズのLEDの例ですが並びが違ってもLEDは同じです。
3 便利なコマンド、ツールの紹介
Nvidia/MellanoxのNIC/HCAには、MFT（Mellanox Firmware Tool）というハードウェアの状態を確認、設定変更、自己診断、分析ができるツールがドライバに付属しております。
これを使うことにより、アダプタの情報だけでなく、Linkの状態確認、自己診断、トランシーバモジュールの状態確認、 自己診断、ケーブル（DACのみ可）の情報取得など、障害や不具合発生時に役立つ情報を取得することができます。マニュアルは以下からダウンロード出来ます。
https://network.nvidia.com/products/adapter-software/firmware-tools/
また、Nvidia/Mellanoxのスイッチ（Ethernet/IB）にも同様なツールはありますが、これは特別なモードを使って実行することになりますので、今回ご紹介しているコマンド（Nvidia/Mellanoxサポートから許可されている）以外のコマンドやオプションは実行しないでください。
3.1 Linkアップしない！ 突然Linkがダウンした！
このような場合、以下の流れて状況を確認、情報を取得します。
アダプタ/スイッチポートの設定確認
SFP/QSFP（トランシーバ）の確認
ケーブルの確認
3.1.1 アダプタ サーバから認識されているか？ MFTでの確認
- デバイスネームを確認
“mst status“コマンドの実行
上の例で表示されている /dev/mst/mt4119_pciconf0 mt4115_pciconf0 がMFTコマンドでデバイスを指定するデバイス名になります。
デモ動画はこちら 4-アダプタ mst status
- IB特有のコマンド InfiniBandの場合、特有の情報を取得するコマンドがあります。
・ibv_devinfo –v 搭載されているHCAの情報の表示
・ibdev2netdev ｰv PCIバスアドレスの表示
・ibstatus 認識されているIBデバイスの表示
・ibswitches IBスイッチの情報の表示
・sm_status サブネットマネージャの状態の表示
デモ動画はこちら 5-IB特有のコマンド
3.1.2 アダプタ Link状態の確認 MFT
MFTコマンドにて、Linkの状態を確認出来ます
#mlxlink –d <ｍst statusでのデバイスパス>
※DualPortの場合 /mt4115_pciconf0で、Port1、 0.1と入力することでPort２になります。
【ポイント】Troubleshooting info の部分を確認してください
正常時はグリーンの文字で No issue was observed と表示されます。
ここが赤文字で以下のように表示されている場合、何かしらの不具合があります。
・Auto-negotiation no partner detected オートネゴで失敗してます。
・Compliance code mismatch between the module and the port configuration
ポートの設定とモジュール（トランシーバ）が合致してません、もしくは故障してます。
・Peer is sending remote faults 対向側からの信号が不良です。
mlxlinkコマンドのオプション
※弊社Tech-supportへお問い合わせの際に是非とも取得してください。
＃mlxlink –d < device> -c –m –e
-c エラーのカウンター
-m トランシーバ（モジュール）の状態
-e Eyeの情報
“mlxlink –d < device> -c –m –e ” の表示例
【ポイント】 Troubleshooting info に問題が無くても、コネクタ不具合（接続不良、老朽化）、モジュールの不具合、ケーブル汚れ、破損（極端な曲がり、折れ）などがあると、BER（Bit Error Rate)が悪くなります。この場合、間欠的な症状（Linkが不安的、抜き差しで復旧）になることがありますので注意してください。
Nvidia/MellanoxのモジュールのBERの正常値は 15E-255 です。
デモ動画はこちら 6-アダプタ-mlxlinkの使い方
3.1.3 おまけ アダプタ パラメータの確認/変更方法 MFT
mlxconfig –d デバイスネーム q で、アダプタの設定を確認できます。
設定の変更は、mlxconfigで、set=xxxxにて変更できます。
（例）ポート1をIBから、Ethernetに変更
|
3.1.4 スイッチ ポート状況の確認 スイッチのコマンドでの確認
Nvidia/Mellanoxのスイッチには、ポートの確認、トランシーバの確認、Linkの確認のコマンドがあります。
この情報を確認することによって不具合の切り分けに役立つ情報が取得出来ます。
（1）ポート状態の確認
# show interfaces ethernet status スイッチの全ポートの状態一覧
（2）リンク状態の確認
＃show interfaces ethernet/ib link-diagnostics スイッチの全ポートのリンク状態一覧
リンクの状態は、Codeで区分されます。「Status」に説明はありますが、UsersManualにコードの一覧があります。（例：Onyx3.10.4100 P384 ）
0—No issue observed
1—Port is close by command (see PAOS)
2—AN no partner detected
3—AN ack not received
4—AN next-page exchange failed
5—KR frame lock not acquired
6—KR link inhibit timeout
7—KR Link partner didn’t set receiver ready
8—KR tuning didn’t completed
9—PCS didn’t acquire block lock
10—PCS didn’t acquire AM lock (NO FEC)
11—PCS didn’t get align_status
12—FC FEC is not locked
13—RS FEC is not locked
14—Remote fault received
15—Bad Signal integrity
16—Compliance code mismatch (protocol mismatch between cable and port)
17—Large number of physical errors (high BER)
18—Port is disabled by Ekey
19—Phase EO failure
20—Stamping of non-NVIDIA Cables/Modules
21—Down by PortInfo MAD
22—Disabled by Verification
23—Calibration failure
24—EDR speed is not allowed due to cable stamping: EDR stamping
25—FDR10 speed is not allowed due to cable stamping: FDR10 stamping
26—Port is closed due to cable stamping: Ethernet_compliace_code_zero
27—Port is closed due to cable stamping: 56GE stamping
28—Port is closed due to cable stamping: non-NVIDIA QSFP28
29—Port is closed due to cable stamping: non-NVIDIA SFP28
30—Port is closed, no backplane enabled speed over backplane channel
31—Port is closed, no passive protocol enabled over passive copper channel
32—Port is closed, no active protocol enabled over active channel
33—Port width is does not match the port speed enabled
34—Local speed degradation
35—Remote speed degradation
36—No Partner detected during force mode.
37—Partial link indication during force mode.
38—AN Failure—FEC mismatch during override
39—AN Failure—No HCD
40—VPI protocol don’t match
41—Port is closed, module can’t be set to the enabled rate
42—Bad SI, cable is configured to non optimal rate
1023—Info not available
MNG FW issues (1024—2047):
1024—Cable is unplugged/powered off
1025—Long Range for non MLNX cable/module .
1026—Bus stuck (I2C Data or clock shorted)
1027—bad/unsupported EEPROM
1028—part number list
1029—unsupported cable.
1030—module temperature shutdown
1031—Shorted cable
1032—Power Budget Exceeded
1033—Management force down the port
1034—Module is disabled by command
（3）各ポートの状態の詳細な確認
＃show interfaces ethernet 1/X / show interfaces ib 1/X
例：ポート1/7の状態
ポートの状態
パケット送受信のカウンター
(4)トランシーバ（モジュール）の確認
トランシーバの情報と自己診断コマンド
※弊社へ問い合わせの際は、以下の2つのコマンドで得られる情報が違いますのでセットで実行してください。
＃show interfaces ethernet 1/X transceiver
指定したポートに接続されているトランシーバの情報を取得できます。
＃show interfaces ethernet(ib) X/7 transceiver diagnostics
指定したポートに接続されているトランシーバの診断情報を取得できます。
トランシーバの自己診断で不具合を検知すると、赤枠の部分に赤文字でアラートが表示されます。
デモ動画はこちらから 7-スイッチコマンドでのトランシーバの情報取得
3.1.5 スイッチ MFTでのポート状況の確認
スイッチにもNICやHCAにあるMFTと同様のコマンドがあります。
【注意】このコマンドは開発者向けモードで実施することになり、一般公開されておらずマニュアルには記載されていません。Nvidia/Mellanoxサポートからの許可を得たコマンドのみご紹介させていただきますので、不測の事態を避けるためにも、今回ご紹介しているコマンド以外は実施しないでください。
＃fae mst status コマンド形態はNIC/HCAと同じですが、先頭に“fae”を付けてください。これによりスイッチがfaeモードでコマンドを実行します。
NIC/HCAの場合、ポートはデバイスネームの末尾で区別してましたが、スイッチの場合は同じデバイスに多数のポートが存在することになりますので、デバイスネームの後に、-p X でポート番号を指定してください。
＃fae mlxlink –d <Device> -pX X : ポート番号 eth1/XのX部分
【ポイント】Troubleshooting info の部分を確認してください
正常時はグリーンの文字で No issue was observed と表示されます。
ここが赤文字で以下のように表示されている場合、何かしらの不具合があります。
・Auto-negotiation no partner detected
オートネゴで失敗してます。
・Compliance code mismatch between the module and the port configuration
ポートの設定とモジュール（トランシーバ）が合致してません、もしくは故障してます。
・Peer is sending remote faults
対抗側の信号が不良です。Nvidia/MellanoxのNIC/HCAが対抗側の場合、MFTコマンドにて状況を確認してください。
NIC/HCAと同様にmlxlinkコマンドでは、-c -m -e オプションにて詳細な情報を取得出来ます。
＃fae mlxlink –d <Device> -pX -c –m –e NIC/HCAより詳細な情報が出力されます。
【注意】RJ45 1GBase-T/10GBase-TのSFPにはケーブルとの結線をモニタリングしていないモデルがあります。その場合、SFPがスイッチから問題なく認識された場合には、スイッチのLEDは点灯し、スイッチとしてはステータスを“UP”としてしまいます。これは異常ではありませんのでご注意ください。
【お願い】弊社へお問い合わせの際には、このコマンドでの出力結果を提供お願いいたします。
デモ動画はこちら 8-スイッチ fae mlxlinkコマンド
3.1.6 アダプタ（NIC/HCA）、スイッチでのケーブルの確認 MFT
MFTにはケーブルの情報を取得することができるコマンドもあります。※DACのみ
(1)アダプタ（NIC/HCA）のケーブル確認
ケーブルのデバイスネームを確認するために、mst statusにケーブルを追加します。
＃mst cable add を実行すると接続されているケーブルのでバイスネームが追加されます。
デュアルポートアダプタの場合、同じPCIバスのアドレスで末尾が0，1となります。
＃mlxcables -d デバイスネーム でケーブルを指定して確認出来ます。
デモ動画はこちら 9-アダプタ-mlxcablesコマンド
(2)スイッチでのケーブル確認
スイッチでのケーブルの確認もMFTを使用します。
＃fae mst cable add
＃mlxcables –d <Device+cable> cable番号はポート番号から“-1”
【注意】 追加されたケーブルを指定する際、スイッチの場合はケーブルが0から始まりますが、ポートはeth1/1から始まります。従いましてケーブルを指定する際には実際のポート番号から1つ少ないケーブルのデバイスネームを指定することになります。
上の例では、eth1/7のケーブルを指定している事になります。
デモ動画はこちら 10-スイッチ-fae mlxcablesコマンド
3.2 SNMPサーバでスイッチのパケットロスを検知！ なんかパフォーマンスが悪いぞ？
このような状況の場合に、スイッチのパケットの状態、ポートのトラフィックの状態を確認します。
エラーパケットの確認
Discardパケットの確認
スイッチ内のトラフィック状況の確認
3.2.1 スイッチ パケットカウンター Ethernet（ONYX）
＃show interfaces ethernet 1/x counters でポートのパケットの状況を確認できます
【注意】パケットカウンターは累積になりますので、症状が再現している場合には一端カウンターをリセットしてから状況を確認することをお薦めします。
＃switch (config interface ethernet 1/1) # clear counters もしくは
＃switch (config）#clear counters interface ethernet 1/1
【注意】必ずリセットするインターフェースを指定してください。何も指定しないで clear counters を実行するとスイッチの全てのカウンタがリセットされてしまいます。
#show interface vlan XX counters VLAごとのカウンター確認
3.2.2 WJH（What Just Happened） Ethernet（ONYX）
Nvidia/MellanoxのEthernetスイッチにはWJHという特有の機能があります。スイッチのポートの不具合を検出したリ、パケットを正しく受信したが、何らかの原因で送り先に送られず、パケットが捨てられた原因および対策を提示、記録します、これによってトラブルが発生した際に今、どのような状況なのか？確認することができるという優れた機能になります。
CLI,WebUIどちらでもこの機能を使って解析することができます。
詳細は、別章5．あると便利！What Just Happenedにて説明します。
3.2.3 Discardパケットカウンター確認 Ethernet（ONYX）
＃show interface ethernet 1/x counters discard
指定したポートでのパケット破棄の状態を確認できます
例：No buffer discard mc packets はマルチキャストパケットがバッファを使い切っている状態
＃ show what-just-happened buffer でバッファの状態を確認できます。
【参考】DiscardパケットやErrorパケットなどの詳細を確認することも出来ます。
エラーやDiscardの詳細な状況は、“sysdump”を生成すると、その中にある “sdkdump”
をテキストで表示することにより確認することができます。
sysdumpの中にあるsdkdumpフォルダの中にあるdkdumpをテキストエディタで確認することによりパケットの状況をより詳しく解析することができます。
sdkdumpでは、ポートを通常使っているeth1/xでは無くport IDで表現しております。従いまして希望するポートの情報を探すためには、ポート番号（1/x）のport IDを確認する必要があります。
sdkdumpをテキストエディタで開いたら、「panel」で検索して、port IDのテーブルを表示します。eth1/xのxはPanelの番号になりますので、テーブルから該当のポート番号のport IDを確認してください。
例：eth1/1 Port ID 0x16100の場合
0ｘ16100で検索して、Discardのカウンターグループ表を見つけます
ここでは、Discardされたパケットを特定のグループ別にカウントしておりますので、Discardされたパケットの状況を確認することができます
デモ動画はこちら 11-スイッチ-カウンターの確認方法
3.2.4 ポートのトラフィックの確認 Ethernet（ONYX）
# show interfaces ethernet rates
各ポートのIN（Ingress)/OUT(egress）のレートの状況を確認できます。
4 sysinfo-snapshot/sysdump
不具合/障害が発生した際、Nvidia/Mellanoxの製品には、アダプタ（NIC/HCA）には system-snapshot/sysinfo-snapshot、スイッチにはsysdumpというデバッグのための情報を取得する方法があります。
【お願い】弊社にお問い合わせ頂いた場合にはこの2つをご提供いただくようにお願いします。また、1.1で紹介しているとおり時間が正確にあっていることを確認お願いします。
4.1 アダプタ（NIC/HCA） sysinfo/system-snapshotの取得方法
ドライバをインストールすると、システムにはsysinfo-snapshot/system-snapshot（snapshotと表記）を取得するためのツールが配置されます。
- Linux
- CLIレベルでのサポート
- /tmpディレクトリに下記の様なファイルを作成
”sysinfo-snapshot-version-hosname-yyyymmdd-hhmmss.tgz “
- Windows
- WebUIレベルでのサポート
- デスクトップ上に下記の様なファイルを作成
”system-snapshotversion-DESKTOP-hosname-yyyymmdd-hhmmss.tgz“
注意： 必ず管理者権限（Windows=Administrator、Linux＝root）で実行してください
4.1.1 Linuxでのsysinfo-snapshot取得方法
# /usr/sbin/sysinfo-snapshot.py –ibdiagnet（IBのみ） を実行する
以下の表示の後、/tmp配下にsysinfo-snapshotが作成されます
sysinfo-snapshot is still in process…please wait till completed successfully
Gathering the information may take a while, especially in large networks
Your patience is appreciated
————————————————————
Running sysinfo-snapshot has ended successfully!
Temporary destination directory is /tmp/ ← /tmp配下にsysinfo-snapshotが作成されます
Out file name is /tmp/sysinfo-snapshot-v3.5.0-sw2-52-20210114-024634.tgz
・・・・
sysinfo-snapshot-v3.5.0-sw2-52-20210114-024634.html が/tmp配下に生成されました。
4.1.2 Windowsでのsystem-snapshot取得方法
Windowsの場合、Program Files➡Mellanox➡ MLNX_WinOF2➡Diagnostic Tools
の中にある、MLNX_System_snapshotを実行してください。
ポップアップが出現したら、Generates System-Snapshotボタンをクリックしてsystem-snapshotを生成します。
数分後、スナップショットファイルが生成されたことを示すウィンドウが表示されます
OKボタンをクリックしてください
デスクトップ上に、system-snapshotファイルが生成されます。
4.2 アダプタ（NIC/HCA）sysinfo/system-snapshotの見方
取得したsysinfo-snapshotを解凍すると数々のファイルが出現します。沢山あるので何が有効な情報なのか判断するのは難しいのですが、解凍したファイル群の中にあるhtmlファイルをブラウザで表示することにより、メニュー画面が表示されます。これによりsysinfo-snapshotにより実行されたコマンドやファイル名が一覧で表示されますので分かり易くなります。
■Windowsのメニュー画面
■Linuxのメニュー画面
WindowsとLinuxでは取得出来るファイル数に違いがありますが、MFTでのコマンドも実行してくれますのでその出力結果も確認することができます。
以下はファイルを開いた例になります。
デモ画像がこちらから 12-NIC-HCA-sysinfo-snapshot
4.3 スイッチ sysdumpの取得方法
Nvidia/Mellanoxのスイッチには、不具合/障害発生時にデバッグに有効な各種の情報を集めファイルとして生成する機能があります。この機能で取得するdumpファイルをsysdumpといいます。
生成したファイルはスイッチ内に保存されます。生成は、CLIでもWebUIでも可能です。CLIの場合、スイッチ内に生成したファイルを、scpコマンドにて別のデバイスと送受信ができるようにする必要があります。WebUIでは、生成したファイルをWebUIを接続しているPCのローカルにダウンロードすることが出来ます。実際の現場で不具合/障害発生時にscpの受け側を用意することが実際問題難しい場合がありますので弊社（私）の場合、お客様にはWebUIでの実行をお薦めしております。
4.3.1 CLIでのsysdumpの生成と取得方法
CLIの場合 scpでの受け側を構築する必要があります。
# debug generate dump sysdumpを生成します
# show file debug-dump スイッチ内のsysdumpファイルの一覧
SN2010-105 [standalone: master] (config) # show file debug-dump
sysdump-SN2010-105-20230201-091230.tgz
sysdump-SN2010-105-20230126-150155.tgz
sysdump-SN2010-105-20230201-144927.tgz
sysdump-SN2010-105-20230202-093713.tgz
sysdump-SN2010-105-20230202-105514.tgz
file debug-dump upload コマンドでSCPを受けられるデバイへ送信する
例：sysdump-SN2010-105-20230202-105514.tgzを送る場合
＃file debug-dump upload sysdump-SN2010-105-20230202-105514.tgz
scp://username:password@サーバ名もしくはIPアドレス/デバイスの保管場所のパス/sysdump-SN2010-105-20230202-105514.tgz
上記コマンドは改行せずに、1列で入力すること
4.3.2 WebUIでのsysdumpの生成と取得方法
WebUIの場合
①Status -> Maintenance -> Generate Sysdump Fileをクリック
dumpファイルが生成されます。
②生成されたsysdumpをプルダウンから選択 ※日付がファイル名になります
③ 「Download Sysdump File」をクリックすると接続している端末にダウンロードされます。
取得したsysdumpファイルを解凍すると大量のファイルが展開されます。
その中にある“START_HERE.html”をWebブラウザで表示すると、ファイル名とそのファイルの役割、リンクを示したメニュー画面が表示されます。
※NIC/HCAのようにMFTコマンドでの出力結果はありません。
NIC/HCAと比べてかなり多いファイルが含まれております。
■”START HERE”（メニュー画面）を開くと以下の様にファイル名、ファイルの役割、リンクが表示されます。
メニュー画面（START_HERE）からクリックして別画面で各種のファイルの中を確認出来ます。
◇sysinfo.txt ハードウェアの状態確認 スイッチの構成パーツの状態(アラート状況）記録
◇running-conf.txt 設定ファイル コンフィグ（スイッチの設定状態）
◇Messages いわゆるsyslogになります。
初期設定では20MBのファイルを10個まで保存します。
ActiveなMessage（Log）以外は圧縮して保持されます。
※1つのlogサイズを変更することもできますが推奨はしてません
デモ動画はこちらから 13-スイッチ-sysdumpの見方
5． あると便利！ What Just Happened
Nvidia/MellanoxのEthernetスイッチには、スイッチで不具合が発生しパケットドロップが起きた際、その詳細な状況を記録するWhat Just Happened（以下WJH）という機能があります。これにより不具合/障害が発生した際の切り分け、解析に役立つ情報を取得することが可能な非常に便利なツールです。
5.1 WebUIでWhat Just Happenedを見てみよう！
WebUIでは、「Status」→「What Just Happened」で確認出来ます。
機能が有効/無効は画面最上段で確認/設定が出来ます。
以下の様に、パケットドロップの状態をグループ分けして、グラフ、表で確認することが出来ます。
5.2 CLIでWhat Just Happenedを見てみよう！
CLIでもWJHを確認することができます。
#show what-just-happened status 現在のWJHの設定状態の確認
# what-just-happened <all | acl | forwarding | layer-1 | buffer> enable で有効にする
＃show what-just-happened WJHの記録を見る
詳細な見方の例：上記の結果でlayer-1（グループ）でのパケットドロップの状況を見る
＃show what-just-happened aggregated layer-1
【ポイント】出力結果の「Down Reason- Recommend Action」を確認する
例：Eth1/2 Cable/transceiver is unplugged – Plug cable/transceiver
ケーブル、トランシーバが装着されていないので、Recommand Actionとして「ケーブル、トランシーバを装着」と表示されてます。
詳細は、UsersManual P315（Onyx3.10.4100）をご参照下さい
デモ動画はこちら 14-WJH-CLIでの見方
5.3 What Just HappenedでPCAPファイルを自動生成、そのPCAPファイルを見る方法
WJHは不具合を検知した際、自動的にPCAPファイルファイルを生成できます。
5.3.1 PCAPファイルファイルの自動生成の設定方法法
■CLI
switch (config) # what-just-happened auto-export all enable
switch (config) # logging events what-just-happened-packets enable
switch (config) # logging events what-just-happened-packets interval <sec>
※最大300秒
■WebUI WJHのグラフの下にある「Create PCAPファイル File」にチェックを入れる
5.3.2 WJHの生成したPCAPファイルファイルを見る方法
WJHが生成したPCAPファイルファイルは、WinreShark等で展開しても、そのままでは訳せないので詳細を確認することは出来ません。これにはスイッチからWJH用のPlugin(Mellanox_WJH_dissector.lua)をダウンロードして、WireSharkをインストールしたPCのWireShasrkフォルダ配下以下の\plugin\x.x フォルダ内に配置もしくは、Windows10の場合:
\Users\Username\AppData\Roaming\Wiresharkの配下に配置すると、WJHが作成したPCAPファイルファイルを確認できるようになります
（1）スイッチからプラグインをダウンロードする WJH画面の中段にある「Download Wireshark Plugin」をクリックしてWebUIを接続しているPCのローカルにプラグインファイルをダウンロードします。
（2）ダウンロードしたプラグインをWireSharkプログラム配下へ配置
（₃）これで、WireSharkにて、WJHが取得したPCAPファイルファイルを開けば、詳細が確認できるようになります。
WJHが取得したPCAPファイルファイルはsyusdumpに含まれております。
デモ動画はこちら 15-WJH-PCAPファイルファイルの見方
6. 事例から学ぶ！ 本当にあったこんな話！
私達が長年、サポートをしていて経験した「あれ？」っと言うようなお話をまとめました。メーカのトラブルシューティングマニュアルなどには書かれていないような事例を紹介します。
6.1 やはり多いのは、ケーブルやトランシーバ
6.1.1 互換DACケーブル（異種ベンダー接続用）
ベンダーロックが有効となっている異種ベンダースイッチ間を接続するための互換ケーブルには
それぞれのベンダーに対応したトランシーバが搭載されているため、向きがあります。逆にすると接続できません。
6.2.1 ケーブルが抜けない！
LCケーブルのロックを解除するためのレバー(ラッチを解除するもの)が、ラッチ（ロック）ピンの下に潜り込んでしまい、ロックが解除できない。LCコネクタは比較的柔らかい樹脂製なので、熱や老朽化によってへなへなになったりしていると、ロック解除レバーとラッチ（ロック）ピンとのかかり（接触面）が空振りしてレバーがラッチピンの下に潜り込むことがあるので注意
・・・これがラックに入っているサーバのNICやHBAで起こると、見えないし指が入らないので困る！
→この場合、折るか、無理矢理もう一度回り込ませて潜り込みを解除しました！
このようにラッチの下にリリースレバーが潜り込んじゃうと、↓ 直接ラッチを下げてリリースしようとしてもリリースレバーの厚みでラッチが下がりきらずロックがリリースしない！
6.1.3 SFPが抜けない！
SFPも、それを格納するケージも、MSA: multi-source agreement という規格でサイズが規定されているが、若干幅があるので、ギリギリ同士が当たるとキツくなる。このときに外的な力が加わったりするとケージが微妙に歪んでしまい、抜けなくなったことがあった。
また、SFPをスイッチやNIC/HCAに装着する際にリリースレバーを解除の状態（リリース用のスライダーが吐出した状態）で、勢いよく装着するとケージ側にあるロックタブに当たってロックタブが変形してしまう危険性もあります。（※スライダーの形状にもよりますが・・）ロックタブが以下の写真にように歪んでしますとSFPのロックをリリースできなくなりますのでSFPを装着する際には無理な力をかけず、ゆっくり”カチッ”ということを確認するのが良いと思います。
SFPの抜け防止機能
6.1.4 光ケーブルの接続の不具合！
光ケーブルであった接続不良のお話
光ケーブルの場合、カッパーケーブルのように電気的な接続ではなく、光信号のため微妙に緩んでいても通信ができてしまうので、コネクタの緩みには気をつけてください。
6.1.5 ケーブルが抜けているのにスイッチのリンクLEDが点灯している
RJ45のSFPからケーブルを抜いてあるのに、スイッチのリンクLEDはグリーン、スイッチのポートステータスもUPの状態になっている。
RJ45のSFPはモデルによって、ケーブルの接続状態をスイッチへ通知する機能（ミッシングリンク）を搭載していない物があります。スイッチはSFPが正常に接続され可動していればステータスはUPとします。これは異常ではありません。
6.1.6 スイッチのポートLEDはグリーンでLinkUpしているが通信できない！
VLANの設定が間違っていたり、LAG（Link Aggregation）を作成した際に、Port-channel（LAG）をEnableにしていないと通信は出来ません。でも物理的にケーブルは接続されているのでスイッチのLEDはLinkUp状態となります
6.1.7 WinOF-2ドライバのTeaming機能でアダプタやチームがゾンビになった
ConnectX-4以降に使用するWindows10用ドライバWinOF2には、ClientOSにはないTeamingを組むことがDriver付属のユーティリティツール「mlx5muxtool.exe」で実現できます。
お客様が、mlx5muxtool.exeで作成したTeamとNICを、Windows10のデバイスマネージャーから削除して、サーバを再起動しました。
このため、OS上(デバイスマネージャ)ではネットワークアダプタ（NIC）とTeamは一旦は削除されましたが、サーバを再起動したため、NIC、ドライバはそのままだったので再度NICが認識されて違うWebUIDを割り振られてしまい、mlx5muxtool.exe上に、NICとTeamがゾンビとなって残ってしまいました。（実WebUIDがない）
実害は無いが、 mlx5muxtool.exe のリストからNICもTeamも消すことができない。
→レジストリエディタにてTeamとNICのWebUIDの登録を消すことによりリストから消すことができました・・・・・
【注意】 WinOF2のツール「mlx5muxtool.exe」で作成したTeamがある場合、デバイスマネージャでの操作の前にmlx5muxtool.exeにてNICをTeamから抜いて、Teamを消してから、NICをデバイスマネージャから削除してください。
6.2 スイッチOSのアップデート/ダウングレードでのトラブル
Nvidia/MellanoxスイッチのOSはある周期でアップデートされます。Nvidia/Mellanoxとしては常に最新を使用していただくことを推奨しておりますので、お客様には定期的にアップデートをお願いしております。
またお客様によってはエンドのお客様が承認されたバージョンでないと使用できないという制限からNvidia/Mellanoxは推奨しておりませんが、ダウングレードをする事もあります。
そんな中で遭遇したトラブルをご紹介します。
6.2.1 アップデートでErrorが出てアップデートが始まらない
Nvidia/Mellanoxサイト、弊社FTPサイトからダウンロードしたファイルは必ずチェックサムの確認をお願いします。
6.2.2 ダウングレードしたら、スイッチが初期化した！
お客様によってはエンドユーザが承認したバージョンしか使えないため、納品したスイッチのバージョンが新しいと、ダウングレードする必要がある場合があり、以前はそんなこと無かったのにダウングレードしたらスイッチが初期化されてしまった。
Onyxの3.10.xxxxからダウングレードすると、工場出荷状態にリセットするなりました。これは異常では無く正常な動作になります。従いまして必ずコンフィグはバックアップしておいてください。バイナリでバックアップしたコンフィグは同じバージョンでないとリストア出来ません。
6.2.3 コンフィグのバックアップをしていない テキストからのリストア方法について
この場合、sysdumpなど取得してあれば、そこにあるrunning-config（テキスト）から、スイッチに設定を流し込むことが出来ます。ただし、入れ替えではなく、追記となりますので工場出荷状態のような最低限の設定しか入っていない状態で行うことが望ましいです。
（1)コンフィグのテキストでバックアップ/リストアする方法
WebUIでは、リストア（流し込む）ことはできても、バックアップをテキストで取ることは出来ません。Show running-configの出力をテキストにコピーして保存するか、sysdumpを取得して、その中のrunning-config.txtを使用してリストアします。
「Setup」→「Configuration」の“Upload Configuration”でWebUIに接続したPCのローカルからファイルを送ります。
CLIでは、以下の要領で現在のコンフィグをテキストに生成して、scpコマンドでscpを受けられるデバイス（サーバ、USB）に送ります
今現在のコンフィグ(running-config)をテキストで保存する
1．テキストコンフィグレーションファイル作成
#configuration text generate active running save fumi-1
2．作成したテキストの確認
#show configuration text files
3．テキストコンフィグレーションファイルの転送
（1）USBに転送 ※スイッチにUSBを差すと自動的に/var/mnt/usb1にマウントされます。
#configuration text file fumi-1 upload scp://admin:admin@SN3700-110/var/mnt/usb1/fumi-2
（2）サーバへ転送 #configuration text file fumi-1 upload scp://root:password@192.168.10.xxx/temp/fumi-2
※（1）と（3）を同時にスイッチ内に保存しない方法
#configuration text generate active running upload scp://root:password@192.168.10.xxx/tmp/fumi-2
4．取得したテキストをスイッチ内に戻す
（1）USBから取得
#configuration text fetch scp://admin:admin@SN3700-110/var/mnt/usb1/fumi-2
（2）サーバから転送
#configuration text fetch scp://root:password@192.168.10.xxx/temp/fumi-2
5．取得したテキストの確認
#show configuration text files
fumi-1 ←以前作成したものが残っている場合
fumi-2 ←今回取得したテキストconfig
６.取得したテキストコンフィグを反映
#configuration text file fumi-2 apply これで現在動作しているコンフィグへ追記します。
デモ動画はこちら 16-スイッチ-テキストでのコフィグの操作
6.2.4 バイナリでバックアップしたコンフィグの内容を確認したい
バックアップしたコンフィグは、WebUIでもCLIでも簡単に確認することができます。
6.3 アダプタ関連のトラブルのご紹介
6.3.1 sysinfo-snapshotを取得しようとしたら、いつまで経っても終了しない
sysinfo-snapshotのGenerateを実行したが、いつまで経っても終了しない。
【原因1】管理者で実行していなかった。管理者権限でないと実行出来ないコマンドがあるため、リトライを繰り返してしまう。
【原因2】ドライバ、MFTは最新を使っているが、アダプタのFWのアップデートを促されたが省略した。
sysinfo-snapshotで取得するMFTの機能は更新されている場合があり、古いFWでは対応していないためエラーとなりリトライを繰り返していた。
sysinfo-snapshotを取得する際には、管理者権限で実行してください。また、最新のドライバの場合、適したFWバージョンをお使いください。ドライバのリリースノート、マニュアルに対応FWの組み合わせが記載されてますのでご確認お願いします。
6.3.2 Windowsのドライバアップデートでの注意点
Nvidia/Mellanoxのドライバには必要なセキュリティパッチがあります。インストーラーはWindowsのシステムから必要なKBxxxxxがリストにあるか確認してドライバのインストールを続行します。
Windowsアップデートを定期的におこなっていないと、マイクロソフト側でいくつかのパッチを別のKBに集約してしまうことがあり、一気にアップデートしたりするとこの事象に遭遇します。
7. 弊社へのお問い合わせ（障害発生時）に
提供していただきたい情報について
本書では、弊社で開催しているトラブルシューティングのウェビナーでご紹介した内容をまとめました。ここまでの内容を参考に、弊社へお問い合わせいただく際には、お客様の問題の解決までの早道として、以下の情報をできる限り取得いただき、弊社へご提供いただくことをお願いいたします。
本書で記した内容がお客様が不具合に遭遇された際の現場での切り分けにお客に立てることを、サポートスタッフ 一同心より願っております。
1．障害が発生している環境を正確に把握させてください
システムの全体構成（接続図） ※不具合観測箇所のみならず、関連する広範な接続構成図希望
※被疑NICを搭載しているサーバーとスイッチの接続に用いているケーブルやトランシーバー、スイッチに接続されている他機器のホスト名やIPアドレスなどの情報
2．問題を正確に把握させてください
(a)不具合現象詳細
(1)操作中に発生の場合：作業目的、参照マニュアル箇所、実施作業手順、観測結果
(xxxxのように動作することを期待したが、実際にはyyyyのように動作する/しない)
(2)稼働中のシステムでの突発的な発生：不具合の前後で何か環境に変更があったか?
(3)不具合発生のきっかけと発生時間
(4)不具合は現在も継続しているか？間欠か？その場合の頻度や加速条件は？
(5)被疑品を他の良品（正しく動作していることが確認されているもの）と交換するとどうなるか？ 被疑品を他の正常環境で使用すると再現するか
(6)他のソフトウェアバージョンではどうなるか？
(b)採取・提供 ※システム、スイッチのクロックは正確であるか確認必須
Mellanoxのツールファイル
スイッチ： sysdumpファイル
ノード（サーバー/クライアント）： sysinfo/system-snapshot
※可能であれば EventViewer(Windows) /var/log/messages(Linux)”
ケーブル/モジュール： MFT: mlxlink, mlxcables の実行結果
スイッチの場合： # show interfaces ethernet 1/x transceiver
# show interfaces ethernet 1/x transceiver diagnostics
MFT: mlxlink, mlxcables の実行結果
本サイトの内容に関してご質問は、tech-support@servants.co.jp までお問合せください。