変更要約: 初版
6.1L2/L3の基礎（MAC・VLAN・IP・サブネット・ゲートウェイ）
自動化スクリプトやAPIクライアントが「相手に届く」ための前提として、L2のMACアドレスとVLAN、L3のIPアドレス・サブネットマスク/プレフィックス・ルーティング・デフォルトゲートウェイを、「なぜこのホストからだけAPIが叩けないのか」という接続性の診断として学びます。
自動化を書く人にとってネットワークの基礎は暗記科目ではなく、「自分のスクリプトが叩くAPIエンドポイントに、パケットが本当に届くのか」を判断するための土台です。requests.get() がタイムアウトする、ssh が張れない、NETCONF セッションが確立しない——その原因は多くの場合、アプリのバグではなくL2/L3の到達性にあります。この節では、同一セグメント内の転送を担うMAC/VLAN（L2）と、セグメントをまたぐ到達性を担うIP/サブネット/ルーティング/デフォルトゲートウェイ（L3）を、「どこで止まっているか」を切り分ける道具として整理します。
6.1.1L2：MACアドレスとVLAN
- MACアドレス＝NICに焼かれた48ビットのL2識別子（例
00:1A:2B:3C:4D:5E）。同一セグメント（同一VLAN/サブネット）内では、スイッチが宛先MAC宛にフレームを転送する。異なるサブネットへはMACでは届かず、L3のルーティングが必要になる——ここを混同すると「同じスイッチに挿さっているのに通信できない」診断を誤る。 - VLAN＝1台の物理スイッチを論理的に複数のブロードキャストドメインに分ける仕組み。VLANが異なればL2的には別セグメントで、VLAN間の通信にはL3（ルータやL3スイッチのSVI）が必須。自動化ホストが管理対象デバイスと別VLANに居るのに、ルーティングやデフォルトゲートウェイが未設定だと、同じ建物内でも到達できない。
6.1.2L3：IP・サブネット・ルーティング・ゲートウェイ
- IPアドレスとサブネットマスク/プレフィックスの組（例
10.1.10.20/24）が、そのホストの所属サブネットを決める。/24は255.255.255.0で、10.1.10.0〜10.1.10.255が同一サブネット。宛先が自サブネット内かどうかをホストはマスク演算で判定し、内なら直接ARP、外ならデフォルトゲートウェイへ送る。 - ルーティング＝ルータがルーティングテーブルを参照し、宛先IPに最も長く一致するエントリ（ロンゲストマッチ）の経路へパケットを転送する処理。該当経路が無ければ破棄される。デフォルトゲートウェイは「自サブネット外のすべて」を任せる出口（
0.0.0.0/0の既定経路の入口）で、これが誤っていると外部への通信が丸ごと失敗する。 - 接続性の階段：同一サブネット内の疎通はL2（MAC/スイッチ/VLAN）の問題、別サブネットへの疎通はL3（IP/サブネットマスク/ルート/ゲートウェイ）の問題。「ローカルは通るが遠くが通らない」ならゲートウェイ/ルートを、「同一VLANでも通らない」ならL2やIP重複を疑う、という切り分けの順序を持つ。
「同一サブネット内はL2(MAC/VLAN)・別サブネットへはL3(IP/ルート/ゲートウェイ)」「VLANが違えばL3ルーティングが必須」「宛先が自サブネット外ならデフォルトゲートウェイへ」「ルーティングはロンゲストマッチ・該当なしは破棄」が要点です。/24=255.255.255.0、ip route／show ip route、ip addr の読み方を押さえましょう。
あなたはCIランナー上で動く在庫管理スクリプトを運用しており、そのスクリプトはデータセンタのルータ群へ RESTCONF（HTTPS/443）で設定を取得しに行きます。ある日、新設したCIランナー（IP 10.1.10.20/24、VLAN 10）からだけ、全ルータ（10.9.0.0/24、VLAN 90）への呼び出しが connection timed out になりました。まず切り分けるのは「アプリのバグか、L2/L3の到達性か」です。同一データセンタ内の別ホスト（10.9.0.5/24、VLAN 90）から同じAPIを叩くと成功したので、スクリプトとRESTCONF設定は正常——問題はランナー固有のネットワークにあると判断できます。ランナーで ip addr を見ると 10.1.10.20/24 は正しく、ping 10.1.10.1（自VLANのゲートウェイ）は通りますが、ping 10.9.0.5（別サブネット）が失敗します。ここで ip route（Linux）を確認すると、デフォルトゲートウェイ（default via ...）のエントリが欠落していました。つまりランナーは自サブネット（10.1.10.0/24）内には届くが、10.9.0.0/24 は「自サブネット外」なのに出口（デフォルトゲートウェイ）を知らず、パケットを送り出せずに落としていたのです。VLAN 10とVLAN 90は別ブロードキャストドメインなので、L2では決して跨げず、L3ルーティング＝正しいデフォルトゲートウェイが不可欠でした。修正はデフォルトゲートウェイ（10.1.10.1）の設定一つで、以後 10.9.0.0/24 宛は既定経路経由でルーティングされ、RESTCONF が復旧します。教訓は、connection timed out を見て闇雲にアプリのリトライやタイムアウト値をいじる前に、「宛先は自サブネット内か外か」「外ならゲートウェイ/ルートは正しいか」をL2/L3の階段で順に確認することです。
| 要素 | 層 | 役割 | 診断のヒント |
|---|---|---|---|
| MACアドレス | L2 | 同一セグメント内のフレーム転送先 | 同一VLANで不通なら重複/L2を疑う |
| VLAN | L2 | 論理セグメント分割（別ブロードキャストドメイン） | VLAN間はL3ルーティングが必須 |
| IP＋サブネットマスク | L3 | 所属サブネットの決定（内/外の判定） | `/24=255.255.255.0`・マスク誤りに注意 |
| ルーティング | L3 | ロンゲストマッチで経路転送 | 該当経路なしは破棄→`show ip route` |
| デフォルトゲートウェイ | L3 | 自サブネット外への出口 | 遠隔だけ不通ならまず疑う |
ひっかけ： 「同じスイッチに挿さっていれば必ず通信できる」は誤りです——VLANが異なれば別ブロードキャストドメインで、VLAN間の通信にはL3ルーティングが要ります。また「別サブネット宛が届かない＝アプリのバグ」も早計で、実際はデフォルトゲートウェイ未設定やマスク誤り（例 /24 のつもりが /25）で、自サブネット外の判定/経路が壊れていることが多いです。
6.1.3この節のまとめ
- 同一セグメント内の到達はL2（MAC/VLAN）、セグメントをまたぐ到達はL3（IP/サブネット/ルート/ゲートウェイ）。VLANが違えばL3ルーティングが必須
- ホストはサブネットマスクで宛先が自サブネット内か判定し、外ならデフォルトゲートウェイへ送る。ゲートウェイ/ルート誤りは遠隔通信を丸ごと落とす
connection timed outは多くがアプリでなくL2/L3の到達性。内/外→ゲートウェイ/ルートの順で切り分けると原因に最短で届く
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 新設したCIランナー（`10.1.10.20/24`、VLAN 10）からだけ、別サブネットのルータ群（`10.9.0.0/24`、VLAN 90）へのRESTCONF呼び出しが `connection timed out` になる。同一DC内の別ホスト（VLAN 90）からは同じAPIが成功する。ランナーで `ping 10.1.10.1`（自VLANのゲートウェイ）は通るが `ping 10.9.0.5` は失敗する。最初に確認すべき最も適切な事項はどれか。
Q2. 自動化ホストと管理対象スイッチが同じ物理スイッチに接続されているのに、ホストからスイッチ管理IPへ疎通しない。ホストはVLAN 10、スイッチ管理IPはVLAN 90に属し、両者の間にL3のルーティング設定は無い。この状況の説明として最も適切なものはどれか。
Q3. ホスト `10.1.10.20` から `10.1.10.200` へは通信できるが、`10.1.11.5` へは通信できない。ホストのインタフェースは `10.1.10.20/25` で設定されている。原因として最も可能性が高いものはどれか。