【実務・中級編】 レイヤ3スイッチとSVI(Switch Virtual Interface)の基本設計とルーティング動作 – インフラ・物理&L2/L3ネットワーク基礎実践ガイド

ネットワークの「心臓部」を理解する:L3スイッチとSVIが紡ぐ高速ルーティングの真実

ネットワークエンジニアとして現場に立っていると、「L2スイッチとL3スイッチ、結局何が違うの?」という問いにぶつかる場面が多々あります。教科書を開けば「L3スイッチはIPルーティングができる」と書いてありますが、それだけでは不十分です。

今日は、Web APIのバックエンドやクラウド基盤を支える屋台骨、レイヤ3スイッチ(L3SW)におけるSVI(Switch Virtual Interface)の深淵に迫ります。パケットがスイッチのASIC(特定用途向け集積回路)を通り抜け、どのようにVLAN間を飛び越えていくのか、その舞台裏を紐解いていきましょう。

—

1. SVIという名の「仮想ルータ」

L3スイッチにおいて、SVIはVLANに対応する仮想的なインターフェースです。端的に言えば、「特定のVLANに所属するクライアントにとってのデフォルトゲートウェイ(DGW)」です。

物理的なポートを1つ占有してルータに繋ぐ「Router-on-a-stick」のような古典的な構成とは異なり、L3スイッチはスイッチ内部のバックプレーン(高速な内部バス)でルーティングを完結させます。このとき、L3スイッチは特定のVLANに対してIPアドレスを割り当てる必要があり、その役割を担うのがSVI(interface vlan <ID>)です。

なぜSVIを使うのか?

  • 物理ポートの節約: ルータを外付けする必要がない。
  • 線速転送: ASICによるハードウェア・スイッチングのため、CPU負荷を気にせずフルワイヤーレートで転送可能。
  • 管理の集約: L2のセグメンテーションとL3のルーティングを1台の筐体で完結できる。

—

2. パケットはどう流れるか:ハードウェア転送の魔法

ここで重要な概念が「CEF(Cisco Express Forwarding)」、あるいはそれに類するハードウェア転送メカニズムです。

一般的なCPUベースのルータは、最初のパケットを処理した後にルート情報をキャッシュしますが、L3スイッチは違います。RIB(ルーティングテーブル)からFIB(転送情報ベース)とAdjacency Table(隣接テーブル)を生成し、これをASICに叩き込みます。

通信フローのシーケンス

1. フレーム受信: 宛先MACアドレスがSVIのMACアドレスであるパケットが、アクセスポート経由で入ってくる。
2. L2/L3判定: スイッチは「宛先MACが自分だ」と認識し、L3層の処理に引き渡す。
3. ルーティング参照: FIBを参照し、宛先IPへの「出口(ネクストホップ)」を特定する。
4. 書き換え: ここが肝です。ASICがパケットの「送信元MACをSVIのMAC」「宛先MACをネクストホップのMAC」にその場で書き換えます(Rewriting)。
5. 送出: 書き換えられたフレームが、宛先VLANのポートから射出される。

このプロセスはCPUを介さず、完全にシリコンレベルで実行されます。だからこそ、数Gbpsのトラフィックが流れても遅延がほぼゼロなのです。

—

3. 実践:Ciscoライクな設定例

実際に現場でよく見る、VLAN10(社内LAN)とVLAN20(サーバーセグメント)をルーティングする設定例を見てみましょう。

! VLANの作成
vlan 10
 name Office_LAN
vlan 20
 name Server_Zone

! SVIの設定
interface vlan 10
 description Gateway for Office
 ip address 192.168.10.1 255.255.255.0
 no shutdown

interface vlan 20
 description Gateway for Servers
 ip address 192.168.20.1 255.255.255.0
 no shutdown

! ルーティングの有効化(機種による)
ip routing

この設定が入った瞬間、L3スイッチは192.168.10.0/24と192.168.20.0/24の間の橋渡し役として機能し始めます。

—

4. WebエンジニアのためのデバッグTips

開発中に「サーバーへの疎通が取れない」という事態に陥ったとき、ネットワーク層を疑うべきタイミングがあります。Pythonのrequestsやcurlを使ってテストする際、以下の観点を持っておくとトラブルシューティングが格段に早くなります。

curlでの疎通確認(TTLやルートを意識する)

# -v でHTTPレスポンスだけでなく、接続先のIPを確認
curl -v http://192.168.20.50:8080/api/v1/status

もしConnection Timeoutになる場合、それはアプリケーションの問題ではなく、「SVIのARPテーブルが死んでいる」か「ACL(アクセスコントロールリスト)で弾かれている」可能性が高いです。

トラブルシューティングの定石

1. show ip arp: SVIが宛先のMACアドレスを知っているか確認。これが空なら、そもそも宛先ホストが応答していません。
2. show ip route: 該当するサブネットへのルートが存在するか確認。
3. show ip interface vlan 10: SVI自体がup/upになっているか確認。稀にVLAN内の全ポートがダウンするとSVIも落ちる仕様のスイッチがあります。

—

最後に:ネットワークは「生き物」である

L3スイッチの設定は、単なるテキストの羅列ではありません。それは、パケットという「電子の旅人」に最適なルートを教える地図のようなものです。

Web APIの設計において、エンドポイントのレスポンスタイムを追求するのも大切ですが、その土台となるネットワークが「どうやってパケットを処理しているか」という視点を持つことで、インフラの堅牢性は劇的に向上します。

もし、皆さんの現場で原因不明のパケットロスに悩まされたら、まずは「ASICが正しくMACの書き換えを行えているか」という視点で、スイッチの統計情報を覗いてみてください。そこには、教科書には載っていない、リアルなネットワークの挙動が記録されています。

それでは、また次回のネットワーク深淵でお会いしましょう。ハッピー・ネットワーキング!

コメント

タイトルとURLをコピーしました