こんにちは、クレスコ・デジタルテクノロジーズのY.Kです。
私は、新卒で入社して以来、ネットワークエンジニアとして様々なネットワークの構築や保守、障害対応を担当してきました。
今回は、ネットワークの疎通が取れないときに確認すべきポイント、つまり不通の原因となりがちな箇所について、お話しします。

■あわせて読まれている資料：
対応事例やネットワークサービス一覧を掲載！
→ネットワークテクノロジーサービス

PC・NW機器・ケーブルの問題（物理層）

何年も前、私が右も左も分からない駆け出しのエンジニアだった頃、当時の上司は「（トラブル発生時は）まず物理から見るんだよ」とよく仰っていました。

 
この「物理」というのは、「OSI参照モデル」における第1層、物理層のことです。ネットワーク不通を含めた想定外の事象が発生した際、OSI参照モデルに沿って下層から順に原因を探っていく切り分け方法は、私にとっても非常に有効なものでした。
 
そのため、私もこの方法に従って、ネットワーク不通の原因となりがちなポイントや具体的な切り分け方法、そして対策について、経験を交えてお話ししていこうと思います。
 
ちなみに、OSI参照モデル（OSI reference model）とは、コンピュータネットワークで様々な種類のデータ通信を行うために機器やソフトウェア、通信規約（プロトコル）などが持つべき機能や仕様を複数の階層に分割・整理したモデルの1つのことで、第1層の物理層から第7層のアプリケーション層までの計7層が存在します。

さて、上記の切り分け方法において真っ先に疑うべき物理層（physical layer）は、データを通信回線に送出するための物理的な変換や機械的な作業を受け持つ層です。ピンの形状やケーブルの特性、電気信号や光信号、無線電波の形式などの仕様がここに含まれます。
 
物理層でネットワーク不通の原因を考えると、ネットワークを構成する物理的な要素、つまりPCやNW（ネットワーク）機器、ケーブルそのものに異常が発生していることが推測されます。
実例として、私がこれまでに経験してきた物理的な問題を以下に記載します。

1. PCの問題
   一時的な不調、LANポートの故障
2. NW機器の問題
   一時的な不調、故障
3. ケーブルの問題
   ケーブル種別の誤り（ストレート or クロス）、ケーブル内部の断線、接続不良、接続先の誤り

 このような問題を発見するためには、PCのコントロールパネルを見てケーブルがPCに認識されているかを確認したり、NW機器におけるLANポートの点灯状況や、インタフェースの接続状態に関する部分をconfigで確認（例えば、Cisco機器の場合 [show ip interface brief]の実行結果）することで、疑わしい箇所を一つ一つ地道に潰していくことが一番の近道です。

そして、PCやNW機器に問題があるようであれば再起動や機器交換を、ケーブルに問題があるようであればケーブル接続の修正やケーブル交換を行い、ネットワーク疎通が取れるようになっているか再度確認しましょう。
もちろん、対応後に状態が改善したとしても、障害の再現性があるかどうか、しばらくは注視が必須です。

VLAN設定の誤り（データリンク層）

PC・NW機器・ケーブルをすべて確認してもネットワーク不通の原因が見つからない、または対応したにもかかわらず状況が改善しないという場合は、第2層の「データリンク層」の確認に移りましょう。

データリンク層（data link layer）は、回線やネットワークで物理的に繋がれた二台の機器の間でデータの受け渡しを行う層です。通信相手の識別や認識、伝送路上の信号の衝突の検知や回避、データの送受信単位（フレーム）への分割や組み立て、伝送路上での誤り検知・訂正などの仕様がここに含まれます。
 
データリンク層でネットワーク不通の原因を考えると、L2SW（レイヤ2スイッチ）やL3SW（レイヤ3スイッチ）が、通信相手の認識に用いるMACアドレスを正しく認識していない、SW同士を相互接続したネットワークで、ループ経路を検知して対処するスパニングツリー機能がうまく働いていないなどが挙げられます。
 
特にL3SWでは、電源を落とさずに機器のリプレースを行う場合や、GARP（Gratuitous ARP）が無効になっている機器が接続されている場合に注意が必要です。
GARPとは、ARP（Address Resolution Protocol）で用いられる特殊なパケットの一つで、IPアドレスの重複を回避したり、IPアドレスとMACアドレスの対応関係が変わった際に、そのことを他のホストにいち早く知らせるために使用されます。GARPが無効の場合、IPアドレスとMACアドレスを紐付けるARPテーブルが更新されず、ネットワーク不通に繋がってしまう場合があります。
 
そのため、Cisco機器であればconfigの [show mac address-table]や[show arp]の実行結果を比較し、接続されている機器のMACアドレス情報が正しく認識されているか、ARPテーブルの内容が適切に更新されているかを確認することも重要なポイントと言えるでしょう。

しかし、個人的な経験では、これらの理由によるネットワーク不通よりも、物理ネットワークを複数の論理的なネットワークに分割するVLAN（仮想VLAN）機能に起因するネットワーク不通に多数遭遇してきました。代表的な例を以下に挙げます。

1.  VLAN IDの不一致
   機器間を接続するポート同士で、異なるVLAN IDを設定してしまっていた
2. ポート種別の不一致
   一方がアクセスポート、一方がトランクポートに設定されてしまっていた
3. ポートチャネルに対する不適切な設定
   チャネルグループに対してではなく、チャネルグループにバインドされた物理ポートに対してVLAN設定をしてしまっていた

このような問題を発見するためには、接続しているNW機器間でconfig [show running-config]や、vlan情報[show vlan]の実行結果（Cisco機器の場合）を比較し、物理ポートや仮想ポート、チャネルグループのVLAN設定が適切に行われているかをよく見てみましょう。
 
そして、問題のある箇所を見つけたら修正するのは勿論のことですが、キッティングや設定変更の段階で、機器に投入しようとしているコマンドの内容が適切かどうか、事前によく確認することも重要です。
 
接続される箇所の間で同一のVLAN IDやポート種別が投入されることになっているか、投入対象は合っているか、トランクポートに許可するVLAN IDを追加する作業であるならば、コマンドがきちんと[switchport trunk allowed vlan add xxxx]になっているか（この[add]の記載が漏れていると、[VLAN xxxx]のみが許可される設定に上書きされてしまい、それまで許可されていたVLAN IDの設定はすべて消えてしまいます！）など、気を付けるべきポイントはたくさんありますので、曖昧な記憶頼りで投入コンフィグを作成することはせず、資料をよく見て作成し、できればチームメンバーに再鑑を依頼するなどして万全を期すようにしてください。
 
また、既に設定が入っているNW機器を初期化して流用しようとしている場合、そのNW機器がCisco機器であるならば、startup-configの削除に加えて、フラッシュメモリ上にあるVLAN情報の入ったファイル、[vlan.dat]ファイルの削除も忘れずに実施するようにしてください。このファイルが存在している場合、初期化前に削除しておかなければ、初期化後も古いVLAN情報が新しいconfig上に残ってしまいます。

ルーティングの問題（ネットワーク層）

VLANを含めたデータリンク層に関係する箇所を確認してもネットワーク不通の原因が見つからない場合は、第３層の「ネットワーク層」の確認に移りましょう。

ネットワーク層（network layer）は、物理的な複数のネットワークを接続し、全体を一つのネットワークとして相互に通信可能な状態にする層です。ネットワーク内のアドレス（識別符号）の形式や割当の方式、ネットワークをまたいで相手方までデータを届けるための伝送経路の選択などの仕様がここに含まれます。
 
ネットワーク層でネットワーク不通の原因を考えると、経験上最もよく見かけたのは「単純にPCやNW機器に対するIPアドレスの割り振りが誤っている」というものでした。大抵の場合、その理由は些細な入力ミスだったりするのですが、もたらす結果と焦りは甚大ですので、こちらにも十分注意が必要です。
 
しかし、ネットワーク上のどのPC・NW機器にも設計通りのIPアドレスが割り振られている場合、原因はもっと複雑な、NW機器のルーティングに起因するものである可能性があります。
私の経験の中で、遭遇回数が多かったのは以下のようなケースでした。

1. ルートの不足
   ネットワーク疎通のためのルートが不足していたせいで、通信が宛先まで到達できなかった
2. 誤ったルート設定
   誤ったルートが設定されていたせいで、通信が行き詰まってしまった、あるいはネットワーク内でループしてしまった
3. ロンゲストマッチ
   経路通りに進むルートの他に、宛先IPアドレスが含まれる、かつネットワーク部がより長い別のルートが存在したせいで、ロンゲストマッチの法則に従って、通信が別の経路に渡ってしまった

​​​​​​

このような問題を発見するためには、送信元や、送信元に近いPCやNW機器から宛先IPアドレスに向かって[traceroute]コマンドを実行し、どの箇所で問題が発生しているかを突き止めましょう。

正常時に[traceroute]コマンドを実行すると、宛先IPアドレスに到達するまでに通過したNW機器のIPアドレスが次々に表示され、最後には宛先IPアドレスが表示されて終了しますが、ネットワーク不通時にも、通過できたNW機器のIPアドレスはしっかり表示されるようになっています。
ですので、そこから先のIPアドレスが表示されないNW機器、あるいはルーティングループの始点になってしまっている機器があれば、その機器の設定を洗い出すことで原因が見つかるかも知れません。
 
そして、こちらについては、原因発見後の修正は勿論、設計段階からの確認が大変重要です。
経路上のNW機器に、希望の通信を阻害するような設定が既に入っていないか、設定を追加することによって既存の他の通信を阻害することにならないか、不必要に広範囲なIPアドレスのルートを設定し、他の通信を巻き込む恐れはないかなど、留意すべきポイントはたくさんあります。
また、スタティックルートであれば比較的分かりやすいですが、BGPやEIGRPによるルートの再配信を行っている場合、どこに向かってどのルートを配信しているかについても気を配る必要が出てくるでしょう。
ですので、既存のNW機器のconfigを含む資料をよく見ながら設計し、どう設定すれば良いか迷う時にはチームメンバーやお客様に相談するなどして、設定投入後のトラブルを極力避けるようにしてください。
 
ちなみに、[traceroute]コマンドについて、windowsの場合は綴りが[tracert]となっていることや、LinuxやCisco機器では、デフォルトではICMPプロトコルではなくUDPプロトコルが使用されることなど、実行されるOSによって仕様が異なっているので、こちらも覚えておくと良いでしょう。（後述の、トランスポート層～アプリケーション層に沿ったネットワーク不通の原因にも少し関わってきますが、対応するネットワークプロトコルがNW機器で許可されていなければ、当然[traceroute]コマンドによる通信はそのNW機器を通過できません。）
 
また、ネットワークが大規模になってくると、機器の多さや、お客様側で管理している機器の存在などの理由で、前述の「物理層やデータリンク層に関するネットワーク不通の原因を探る方法」での調査が有効でない、あるいはそもそも難しい場合も出てきます。
そんな時にも、[ping]コマンドを用いた単純な疎通確認や、[traceroute]コマンドを用いた、経路上のどこまで疎通が取れているかの確認は、ネットワーク不通の原因と疑わしき箇所の特定に大変役立ちますので、是非どちらも積極的に使ってみてください。

フィルタリング設定（トランスポート層～アプリケーション層）

IPアドレスやルーティングなどの、ネットワーク層に関係する箇所を確認してもネットワーク不通の原因が見つからない場合は、残る第4層の「トランスポート層」から第7層の「アプリケーション層」までをまとめて確認してみましょう。

まず、各層に関する説明を以下に記載します。
トランスポート層（transport layer）は、データの送信元と送信先の間での制御や通知、交渉などを担う層です。相手方まで確実に効率よくデータを届けるためのコネクション（仮想的な専用伝送路）の確立や切断、データ圧縮、誤り検出・訂正、再送制御などの仕様がここに含まれます。
 
次に、セッション層（session layer）は、連続する対話的な通信の開始や終了、同一性の維持などを行う層です。アプリケーション間が連携して状態を共有し、一連の処理を一つのまとまり（セッション）として管理する機能を実現するもので、利用者の認証やログイン、ログアウトなどの状態管理を行います。
 
そして、プレゼンテーション層（presentation layer）は、アプリケーション間でやり取りされるデータの表現形式を定義する層です。通信に用いられるデータのファイル形式やデータ形式、暗号化や圧縮、文字コードの定義や形式間の変換などの仕様が含まれます。
 
最後に、アプリケーション層（application layer）は、具体的なシステムやサービスに必要な機能を実装する最上位の層です。利用者が操作するソフトウェアが提供する具体的な機能や通信手順、データ形式などの仕様がここに含まれます。
 
これらの層で考えられるネットワーク不通の原因として、httpやssh、snmpなどのネットワークプロトコルによる通信が、送信元から宛先までのPCや、NW機器の設定ミスや不足のために阻害されている可能性が高いです。
例としては、ACL（アクセスリスト）やACLと組み合わせて使う様々な機能（ポリシーベースルーティングなど）、FW（ファイアウォール）のフィルタリング設定、メーカー独自の機能などが挙げられます。
ネットワーク不通の原因が分かりやすいケースから少々複雑なケースまで、私が経験してきた中で印象に残っている（つまり、それだけ頻発している）実例は以下の通りです。

1. 穴開け設定の不足
   経路上のFWに、ネットワークプロトコルによる送信元から宛先までの通信を許可する設定（穴開け設定）が不足していたせいで、通信が遮断されてしまった
2. 戻り通信の考慮不足
   経路上のFWの穴開け設定はしていたものの、その先のNW機器で戻り通信を許可する設定が不足していたせいで、通信が遮断されてしまった
3. タイムアウト
   経路上のFWの穴開け設定はしていたが、タイムアウト値の短いデフォルトアプリケーションを使って設定していたために、独自要件の長い通信時間のせいで戻り通信がタイムアウトに間に合わず、通信が遮断されてしまった

このような問題を発見するためには、前述の「ネットワーク層に関するネットワーク不通の原因を探る方法」と同じように、[traceroute]コマンドの実行結果を見て、疑わしい箇所を絞っていくのも有効ではあります。
 
しかしながら、「２．戻り通信の考慮不足」や「３．タイムアウト」のケースのように、戻り通信が遮断されてしまっている場合、実際にはもっと先のNW機器までネットワーク疎通が取れているにもかかわらず、あたかも手前のNW機器で通信が止められているように見えてしまい、原因究明の妨げとなってしまう場合があります（あるいは、前述の通り、対応するネットワークプロトコルによる通信が経路上のNW機器で許可されていないために、[traceroute]コマンドによる疎通確認自体が難しい場合もあるでしょう）。
その場合は、経路上のNW機器で[show running-config]や[show log messages]を実行し、設定内容やログメッセージを確認することで、何が通信を阻害しているかの目星を付けていくことをお勧めします。
 
FWはネットワーク不通の原因になりがちですが、それにばかり固執していると他の原因を見逃してしまう可能性があるため、視野は広く持っておくようにしましょう。
 
そして、このようなネットワーク不通をそもそも発生させないための根本対策として、設計段階からの確認を丁寧に行っていくことも重要です。
経路上のすべてのNW機器にて、希望のネットワークプロトコルによる通信が通過できるように許可がされているか、ステートフルインスペクション機能（到達するパケットの情報を読み取り、あらかじめ設定されたルールに基づいて通過させるかどうかを動的に判断することで、不正なやり取りを排除する仕組み）がない機器であるならば、戻り通信についても考慮されているか、漏れのないようにしっかりチェックしましょう。
また、お客様から通信要件を連携していただく際にも、送信元や宛先のIPアドレス、ネットワークプロトコルに加えて、タイムアウト値に猶予を持たせたいなどの独自要件がないか、丁寧にヒアリングするようにしてください。
 
ちなみに、前述の「ステートフルインスペクション機能」は、主にFWに搭載されている便利な機能ではありますが、何らかの理由で、送信元から宛先に向かう行きの通信と、宛先から送信元に向かう戻りの通信の経路が異なっている、所謂「非対称ルーティング」の状態になっている時、この機能によって戻り通信が送信元偽装と見なされ、通信が遮断されてしまいますので、注意が必要です。
 
対策としては、そもそも非対称ルーティングとなるようなネットワーク設計をしないことが一番なのですが、お客様都合などの理由でどうしても構成を変えることができない場合、FWの設定で非対称ルーティングを許可することもできますので、最終手段として覚えておくと良いでしょう。
 
また、先ほど少々言及した通り、PCの設定がネットワークプロトコルによる通信を阻害するケースも存在します。
具体的には、「Windows Defender ファイアウォール」などのOS独自のセキュリティや、PCに導入したセキュリティ対策ソフトの働きにより通信が遮断されているケースが挙げられますが、NW機器ばかりに気を取られていると忘れてしまいがちですので、これらの設定もしっかり確認し、必要に応じて無効化しておきましょう。
勿論、社外のインターネットにPCを接続する必要が出てきた場合には、再度有効化することも忘れないようにしてください。

番外編（パケットキャプチャについて）

さて、これまで物理層からアプリケーション層までの、OSI参照モデルの全7層に沿ったネットワーク不通の原因についてお話してきましたが、トラブルシューティングを語るのであれば、やはり「パケットキャプチャ」の話題を避けて通ることはできないでしょう。
という訳で、本記事の最後は、ネットワーク不通の原因から少し離れて、パケットキャプチャについての解説や代表的なやり方を、簡単にですがお話しします。
 
パケットキャプチャ（packet capture）とは、通信ネットワークや回線を流れるデータを捕獲（capture）して、内容の表示や解析、集計などを行うことです。ネットワークの管理・運用やトラブル時の原因究明、ソフトウェアの通信機能の挙動の検証などのために行われます。
 
ネットワークにおけるトラブルシューティングとしてのパケットキャプチャの流れは、まずPCや専用の機器をネットワークに接続し、機器に到達ないし機器から発出するデータを取得、そしてその内容を蓄積・記録することから始まります。
 
取得したデータはパケットやフレームなどの送受信単位で管理され、各々について内容を表示することができます。ですので、解析ソフトを使うなどの方法により、制御データ部（ヘッダ）に記載された通信の種類や送信元・宛先のアドレスなどを割り出したり、伝送データ部（ペイロード）が何を運んでいるのかを調べたりすることができるのです。
 
つまり、単純な[ping]コマンドや[traceroute]コマンドの実行だけでは分からない、機器に到達しているパケットの詳細な情報（到達時刻やプロトコルの種類、パケットの長さや内容等）を可視化できるため、ネットワーク不通が何に起因しているか（そもそも通信自体が来ていないのか、特定のプロトコルの通信が遮断されているのか等々）を特定するのに大いに役立つ、ということです。

このパケットキャプチャを行うための方法として、最も手っ取り早いのは、エンドポイントとなるPCにパケットキャプチャ用のソフトをインストールして、どのようなパケットがPCに到達しているか、またどのようなパケットがPCから送出されているかを直接的に見るというものです。

この方法には、ネットワークの構成変更をすることなく手軽にパケットキャプチャを始められるというメリットがあるものの、解析できるパケットが「エンドポイントPCに発着するパケット」に必然的に限られてしまうため、ネットワーク全体の通信を把握するのには適していません。
 
また、パケットが常に発着し続けることで、経過時間に応じてキャプチャログの容量が膨れ上がっていくこと、そして、業務外の処理を常に走らせる必要があるというデメリットから、検証環境ならさておき、本番稼働しているネットワークのPCで実施することはあまり現実的とは言えないでしょう。
 
そのため、本番環境のネットワークでパケットキャプチャを行う場合、ミラーリング機能付きのL2SWやL3SWを利用して行うパケットキャプチャが代表的な方法として挙げられます。
ミラーリング機能とは、特定のポートで送受信されるパケットを指定のポート（ミラーポート）へコピーする機能です。ミラーポートにパケットキャプチャ用ソフトがインストールされたPCや専用の機器を接続することで、L2SWやL3SWの特定のポートを経由するパケットを間接的に収集することができます。
 
特にCisco製品であるCatalystスイッチにおいて、ミラーリング機能はSPAN（Switched Port Analyzer）と呼ばれているのですが、SPANであれば、キャプチャ対象として複数のポートを指定してパケットキャプチャをしたり、VLANベースでキャプチャしたりすることも可能であるため、ネットワークを流れるパケットを柔軟にキャプチャ・分析することができます。
 
また、キャプチャの処理を、パケットキャプチャ専門のPCや機器に担わせることができるため、エンドポイントPCでの直接的パケットキャプチャのデメリットである、キャプチャログの容量過多や業務外処理による負荷の問題にも対処しやすいメリットもあります。
 
ただし、キャプチャ対象の指定やミラーポートの設定など、設定変更の内容が少々煩雑である上、ミラーポート～パケットキャプチャ用のPCもしくは機器間の物理的な接続を設けたり、パケットキャプチャ用の機器を調達したりと、実施のためには様々な手間がかかります。
また、本番環境のネットワークで新たに間接的パケットキャプチャを採用するためには、こういった構成や設定を変更する必要性をお客様にご理解いただき、承認を得る必要もあるため、思い立ったタイミングですぐさま実施する、というのは難しいかもしれません。

今回、具体的なミラーポートの設定方法や、[Wireshark]の使い方などの詳細な内容については割愛しましたが、パケットキャプチャがなぜネットワーク不通の原因を探るトラブルシューティングに有用なのか、どのような方法やメリット・デメリットがあるかについてはしっかりお伝えできたかと思います。
 
OSI参照モデルに沿った、ネットワーク不通の原因を探るトラブルシューティングの考え方と同様に、パケットキャプチャの知識もきっと役に立つはずですので、ネットワークの不通で困った時、[ping]コマンドや[traceroute]コマンドの実行に並ぶ選択肢として、「パケットキャプチャの実行」という方法があることを覚えていただけたら嬉しいです。

まとめ

いかがでしたでしょうか。
今回お話しした、ネットワーク不通の原因となりがちなポイントはほんの一部ではありますが、
「私自身が、これまで経験してきたネットワーク不通時のトラブルシューティング事例」
をできる限り詰め込ませていただきました。
この記事の内容が、これを読んでくださった皆様にとって何らかのヒントとなり、
さらなるスキルアップの一助となれば、本当に嬉しく思います。
最後までお目通しをいただき、ありがとうございました。

■サービス資料一覧はこちら↓

引用元

【参考文献】
・（OSI階層モデル）とは - IT用語辞典 e-Words
https://e-words.jp/w/OSI%E5%8F%82%E7%85%A7%E3%83%A2%E3%83%87%E3%83%AB.html
【詳解・図解】OSI参照モデルと技術・ネットワーク機器について【YouTube解説動画あり】
https://shanai-neet.com/?p=3790#google_vignette
L2スイッチ（レイヤ2スイッチ）とは - IT用語辞典 e-Words
https://e-words.jp/w/L2%E3%82%B9%E3%82%A4%E3%83%83%E3%83%81.html
L3スイッチ（レイヤ3スイッチ）とは - IT用語辞典 e-Words
https://e-words.jp/w/L3%E3%82%B9%E3%82%A4%E3%83%83%E3%83%81.html
ARP（アドレス解決プロトコル）とは - IT用語辞典 e-Words
https://e-words.jp/w/ARP.html
GARP（Gratuitous ARP）とは - IT用語辞典 e-Words
https://e-words.jp/w/GARP.html
VLAN - アクセスポートのコンフィグ設定
https://www.infraexpert.com/study/vlanz3.html
VLAN - トランクポートのコンフィグ設定
https://www.infraexpert.com/study/vlanz10.html
Ciscoデバイスの操作 - Cisco IOS - 設定保存方法、初期化方法
https://www.infraexpert.com/study/ciscoios3.5.html
ロンゲストマッチとは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%AD%E3%83%B3%E3%82%B2%E3%82%B9%E3%83%88%E3%83%9E%E3%83%83%E3%83%81.html
スタティックルーティングとは
https://www.infraexpert.com/study/routing3.html
ICMPとは（tracerouteコマンド)
https://www.infraexpert.com/study/tcpip6.html
プロトコルとは？ネットワークプロトコルの定義 | Cloudflare
https://www.cloudflare.com/ja-jp/learning/network-layer/what-is-a-protocol/
JUNOS Software Security Configuration Guide
https://www.juniper.net/documentation/software/junos-security/junos-security10.1/junos-security-swconfig-security/index.html?topic-41683.html
ステートフルインスペクションとは？ファイアウォールの仕組みを理解しよう｜ITトレンド
https://it-trend.jp/firewall/article/60-0009
非対称ルーティングとは何か？非対称ルーティングで通信ができなくなる原因と対処法を解説 | Promapedia（プロマペディア）
https://ssaits.jp/promapedia/trouble/20230227.html
Windows Defender ファイアウォールが勝手にONになる件について #Windows10 - Qiita
https://qiita.com/coarat/items/77cab5fea7e5fc393370
パケットキャプチャとは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%91%E3%82%B1%E3%83%83%E3%83%88%E3%82%AD%E3%83%A3%E3%83%97%E3%83%81%E3%83%A3.html
パケットキャプチャツール「Wireshark」の使い方（前編）｜プラネックス
https://www.planex.co.jp/articles/lan/no9/
パケットキャプチャとは？方法やメリット・デメリットを解説
https://www.manageengine.jp/products/NetFlow_Analyzer/solution_packet-capture.html
パケットキャプチャーとは
https://www.infraexpert.com/study/span.htm
 
【図のアイコン】
・Network Topology Icons - Doing Business With Cisco - Cisco
https://www.cisco.com/c/en/us/about/brand-center/network-topology-icons.html