本文へ移動

インフラ転職コンパスわからないところから、ひとつずつ。

メニュー

CiscoのミラーポートとWiresharkで通信障害を切り分ける方法

動画と記事で学ぶ / 試験・障害対応

Cisco Local SPANのsource・destinationとrx・tx・bothを構成図で解説。設定例、WiresharkのNICとフィルター、要求だけ見える時の判断、取得欠落と終了手順を整理します。

ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。

Wiresharkを起動したのに、調べたい通信が出てこない。スイッチにつないだ解析PCは、ほかのPCの通信を自動的にすべて受け取れるわけではありません。

SPANは、指定したポートなどの通信を、解析用ポートへコピーする機能です。通常の通信の線と、コピーを運ぶ線を分けて図で見ます。取得できたパケットから何を判断できるかまで、設定と読み方をつなげて説明します。

PC-AとWebサーバーの通常通信をSW1で接続し、Gi1/0/10の両方向をGi1/0/24の解析PCへ複製するSPAN構成図
構成図:上の実線が通常通信、下の解析PCへ向かう線がSPANのコピーです。解析PCは元の通信の中継点ではありません。 タップで拡大できます。数値と構成は説明用です。

sourceは監視する場所、destinationはコピー先

図ではPC-AがGi1/0/10、サーバーがGi1/0/11へ接続しています。Gi1/0/10をSPANのsourceにして、その通信をGi1/0/24の解析PCへコピーします。

ここでのsourceは送信元IPという意味ではありません。rxは対象ポートからSW1へ入る通信、txはSW1から対象ポートへ出る通信です。bothはその両方を取得します。

言葉 この例 意味
source port SW1 Gi1/0/10 監視する元のポート
rx Gi1/0/10からSW1へ入る方向 PC-Aが送る要求など
tx SW1からGi1/0/10へ出る方向 PC-Aへ返る応答など
both rxとtx 元ポートの両方向
destination port SW1 Gi1/0/24 解析PCへコピーを出すポート

rx/txをPC視点で読まないようにします。取得方向を間違えると、要求だけ・返信だけしか見えず、片方向障害のように見えることがあります。

設定前に、既存セッションと専用ポートを確認する

show monitor sessionで、使用中のセッションを確認します。同じ番号へ追加すると既存条件と混ざる場合があるため、例のsession1が未使用という前提を確かめます。

SPANのdestinationポートは、通常のスイッチポートとして使えなくなるのが基本です。解析PCの管理接続が必要なら、別のNICや経路を用意します。

  • 取得したい通信と区間を構成図で固定する。
  • 対象機種・OSのSPAN仕様と使用可能なセッションを確認する。
  • 解析PC用のGi1/0/24が業務用途で使われていないことを確認する。
  • 解析PCの監視用NICと、管理用の接続を分ける。
  • 送信元の通信量、コピー先の帯域、取得時間と保存容量を決める。
Cisco IOS XE系の説明例。session 1が未使用のラボで実施します。

configure terminal
 monitor session 1 source interface GigabitEthernet1/0/10 both
 monitor session 1 destination interface GigabitEthernet1/0/24
end
show monitor session 1

説明用の出力抜粋
Session 1
Type              : Local Session
Source Ports
  Both            : Gi1/0/10
Destination Ports : Gi1/0/24

設定後はsource、方向、destinationを表示で確認します。例はCatalyst 9300/IOS XE系のLocal SPANです。セッション数やタグ、制御フレームの扱いは対象機種・版へ合わせます。

初めてなら、ラボで一つのポートのbothから始めると、要求と返信を同じ場所で比べやすくなります。

正しいNICで取得し、そのあと表示を絞る

WiresharkではGi1/0/24につながる監視用NICを選びます。Wi-Fiや管理用NICを選ぶと、SPANのコピーは見えません。開始時刻を残し、試験通信を発生させて短時間で止めます。

キャプチャフィルターは保存する範囲、表示フィルターは保存済みのパケットの見せ方を選びます。二つは文法も役割も違います。

種類 例 使うタイミング
キャプチャフィルター host 172.27.81.15 and tcp port 443 取得前。合わないパケットは保存されない
表示フィルター ip.addr == 172.27.81.15 && tcp.port == 443 取得後。表示対象を絞る
表示フィルター arp ARPの要求・応答を見る
表示フィルター tcp.flags.syn == 1 TCPの開始付近を見る

最初からTCP443だけを保存すると、先に失敗したARPやDNSを後から調べられません。対象と容量を考え、何を除外したかも記録します。

まず保存したパケットをIP、ポート、時刻で絞り、要求と返信を同じ試験へ対応させます。フィルターで消えたことと、通信が存在しないことを分けてください。

要求だけ見えても、サーバー障害とは限らない

要求が見えた場所までは、そのパケットが来たと確認できます。その先のサーバーまで届いたか、相手が返信したか、途中でどのルールが評価されたかは別の確認です。

パケットがゼロなら、NIC、source、方向、リンク、フィルターを確認します。返信がなければ、反対側の取得点やサーバー・FWのログと比較します。

見えた結果 候補 次の確認
パケットがゼロ NIC・source・方向・リンク・フィルターの違い show monitor session、各ポートの状態
SYNだけ 応答なし、戻りが別経路、取得方向の漏れ サーバー側の取得、待受、経路、FW
SYN/ACKは見えるが接続失敗 後続のACK、端末側の状態 同じ接続のseq/ack、端末ログ
TCPは成立、HTTPSは失敗 TLS・認証・アプリの条件 TLSのアラート、サーバーと端末ログ
再送が多い 実際の損失、遅延、または取得側の欠落 両端取得、通信量、キャプチャdrop

SPANのコピー先が混雑すると、コピーだけが欠ける場合があります。たとえば1Gbpsの両方向を1Gbpsへまとめると、合計量が収まらないことがあります。解析PCの処理や保存も確認します。

端末自身での取得ではNICオフロードでチェックサム異常が見える場合もあります。取得の限界と線上の損失を分けて判断します。

終了後は、取得条件と設定の復旧を残す

保存ファイルへ対象ポート、方向、NIC、時刻、フィルター、試験操作を対応させます。pcapngだけを渡しても、どこで何を取ったかが分からない場合があります。

終了時は今回作ったセッションだけを外し、表示で確認します。対象ポートの元の用途と設定も、作業計画に従って戻します。

今回作成したsession 1だけを終了する例
configure terminal
 no monitor session 1
end
show monitor session 1

SPANは見たい場所の通信を観測する道具です。正常な通信をすべて漏れなく保存する保証ではないため、カウンターや装置ログも合わせます。

最初は要求と返信の二つを、取得点と方向を添えて追ってみてください。Wiresharkの画面と構成図がつながるようになります。

動画・筆者の投稿で補足する

文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。

確認に使った公式資料

このテーマを続けて学ぶ

最近の記事
ピックアップ