変更要約: 初版
6.2構成要素とトポロジ（スイッチ・ルータ・ファイアウォール・LBと3つのプレーン）
スイッチ・ルータ・ファイアウォール・ロードバランサ（LB）の役割、トポロジ図とインタフェース/ポート値の読み方、そしてデバイスを管理プレーン・制御プレーン・データプレーンの3つに分ける見方を、「自動化はどのプレーンに触れ、経路上のどの機器がAPI呼び出しを止めうるか」という判断として学びます。
トポロジ図は自動化にとって「地図」です。スクリプトが叩くAPIエンドポイントまでの経路にどんな機器（スイッチ/ルータ/ファイアウォール/LB）が並び、どのポートを通るかを読めなければ、失敗したときにどこを疑うか決められません。さらに、Ciscoデバイスを管理プレーン・制御プレーン・データプレーンの3つに分けて捉えると、「自動化（NETCONF/RESTCONF/SNMP）が触るのは管理プレーンであり、それが遮断されても実トラフィック（データプレーン）は流れ続ける」といった切り分けができます。この節では機器の役割・トポロジとポートの読み方・3プレーンを、診断の枠組みとして整理します。
6.2.1機器の役割
- スイッチ（L2、L3スイッチはL2+L3）は同一セグメントのフレーム転送とVLANを担い、ルータ（L3）はサブネット/WAN間のパケット転送とルーティングを担う。自動化の管理接続（SSH/NETCONF/RESTCONF）は多くがこれらデバイスの管理インタフェースに対して張られる。
- ファイアウォールは境界でポリシに基づき通信を許可/拒否する。自動化から見るとAPI/管理ポート（443/830/22等）をファイアウォールが遮断していないかが最重要の関門になる。ロードバランサ（LB）は複数サーバへリクエストを分散し可用性/スケールを高めるが、単一のVIP宛でも実際の応答元が毎回変わりうるため、状態を持つAPIやヘルスチェック設計に注意が要る。
- トポロジ図では、各インタフェース（
GigabitEthernet0/1等）とその両端の機器、通すIPサブネットやVLAN、そしてポート値（後述のL4ポート）を読み取る。図から「自ホスト→GW→ファイアウォール→LB→APIサーバ」という経路を復元できると、失敗時にどの区間かを問える。
6.2.2管理・制御・データの3プレーン
- 管理プレーン＝デバイスを設定/監視するための面。SSH・SNMP・NETCONF・RESTCONF・Syslogなどが該当し、自動化が主に触れるのはここ。ここが遮断/過負荷でも、既存の転送は止まらないことが多い。
- 制御プレーン＝経路や転送表を作る面。ルーティングプロトコル（OSPF/BGP）・STP・ARP/MAC学習などが動き、データプレーンが使う転送情報を決める。データプレーン＝実ユーザトラフィックを実際に転送する面で、制御プレーンが用意した表に従いパケット/フレームを高速転送する。
- 3プレーンの分離は診断で効く：「
NETCONFで設定できないが通信は流れている」なら管理プレーンの問題、「ルートが消えて到達不能」なら制御プレーンの問題、「経路はあるのに特定フローだけ落ちる」ならデータプレーン/ACLの問題、という具合に原因面を切り分けられる。
「自動化(SSH/NETCONF/RESTCONF/SNMP)が触るのは管理プレーン」「制御プレーンは経路/転送表を作る(OSPF/BGP/STP/ARP)」「データプレーンは実トラフィックを転送」「LBは1つのVIP裏で応答元が変わりうる」「経路上のファイアウォールが管理/APIポートを遮断しうる」が要点。トポロジ図はインタフェース名・サブネット・VLAN・ポート値を読み取る訓練を。
あなたの監視自動化が、あるルータへ SNMP（UDP/161）でポーリングして No response を返し続けています。同時に、そのルータを経由する業務トラフィックは正常に流れ、ユーザからの障害報告はゼロです。ここでトポロジ図と3プレーンの見方が効きます。まず「実トラフィックは正常＝データプレーンは健全」「設定変更や経路には異常なし＝制御プレーンも動いている」と切り分けられ、問題は自動化が触る管理プレーンに限局していると判断できます。トポロジ図を辿ると、監視サーバとルータの間には境界ファイアウォールがあり、最近のポリシ変更でUDP/161（SNMP）が管理セグメント宛に許可されていないことが分かりました。つまり業務（データプレーン）は別経路/別ポリシで通るが、監視の管理プレーン通信だけがファイアウォールで落とされていたのです。ここで「ルータが落ちたのでは」と現場に急行するのは過剰反応で、症状（データプレーン正常・管理プレーンのみ不通）が原因面を教えてくれています。仮にファイアウォールが原因でなくても、次に疑うのはルータ側の管理プレーン保護（CoPP：Control Plane Policing）やACLでSNMPを絞っていないか、snmp-server のコミュニティ/バージョン設定不一致か、といった管理プレーン内の要素で、いずれもデータプレーンとは独立です。トポロジ図で「どの機器・どのポートを管理通信が通るか」を復元し、3プレーンで「どの面の問題か」を絞る——この二段構えが、自動化の到達性トラブルを最短で切り分ける方法です。
| プレーン | 主な機能/プロトコル | 自動化との関係 | この面の障害の見え方 |
|---|---|---|---|
| 管理プレーン | SSH/SNMP/NETCONF/RESTCONF/Syslog | 自動化が主に触れる面 | 設定/監視は不可だが通信は流れる |
| 制御プレーン | OSPF/BGP・STP・ARP/MAC学習 | 転送表を作る（自動化の設定結果が反映） | 経路が消える/収束が乱れ到達不能 |
| データプレーン | パケット/フレームの実転送・ACL | 実ユーザ/アプリのトラフィック | 経路はあるが特定フローだけ落ちる |
ひっかけ： 「SNMP/NETCONF が応答しない＝デバイスがダウンし全通信断」は誤りです——自動化が触るのは管理プレーンで、これが遮断/過負荷でもデータプレーンの実トラフィックは流れ続けることが多いです。また「LBのVIPにpingが通ればどのバックエンドも健全」も誤り＝LBは1つのVIPの裏で応答サーバを振り分けるため、一部のバックエンドだけ不調でも間欠的に失敗しうります。
6.2.3この節のまとめ
- 経路の機器（スイッチ/ルータ/ファイアウォール/LB）と、通すインタフェース/サブネット/VLAN/ポートをトポロジ図から読み、失敗時にどの区間かを問う
- デバイスは管理プレーン（自動化が触るSSH/NETCONF/SNMP）・制御プレーン（経路/転送表）・データプレーン（実トラフィック）に分けて考える
- 「管理は不通だがトラフィックは正常」なら管理プレーン、「経路が消えた」なら制御プレーン、「特定フローのみ落ちる」ならデータプレーン/ACLと、症状から原因面を絞る
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 監視自動化がルータへ `SNMP`（UDP/161）ポーリングし `No response` が続く。一方、そのルータを経由する業務トラフィックは正常でユーザ障害報告はゼロ。この症状から最初に絞り込める原因面と次の確認として最も適切なものはどれか。
Q2. あるAPIサービスはロードバランサ（LB）の単一VIP `203.0.113.10:443` で公開され、裏に3台のバックエンドがある。自動化クライアントから同じリクエストを繰り返すと、成功と `502 Bad Gateway` が不規則に混ざる。原因調査の方針として最も適切なものはどれか。
Q3. ネットワーク自動化で `NETCONF` によりルータのルーティング設定を変更したい。この操作が主に作用するプレーンと、その結果が反映される先の組み合わせとして最も適切なものはどれか。