【テクニカル・上級編】レイヤ2スイッチにおけるバックプレーン容量とフォワーディングレート（Mpps）の算出 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

レイヤ2スイッチの死角：バックプレーン容量とフォワーディングレート（Mpps）の極限チューニング

ネットワークエンジニアとして数多くのデータセンターやエンタープライズネットワークの設計・構築に関わってきたが、未だに「全ポートギガビット対応」という謳い文句のカタログスペックを鵜呑みにして痛い目を見る現場が後を絶たない。

「L2スイッチのポート数が24個で、1Gbpsだから、バックプレーンは余裕で足りるよね？」

もしあなたが設計レビューの場でこのような発言をしたなら、インフラアーキテクトとしてのシグネチャー剥奪ものである。レイヤ2スイッチの心臓部であるスイッチングファブリックの選定やサイジングにおいて、表面上のポートレートだけで判断するのは、航海士が海の表面の波だけを見て潮流の底流を見誤るようなものだ。

今回は、レイヤ2スイッチにおけるバックプレーン容量とフォワーディングレート（Mpps）の理論値と実効値の算出ロジックを、パケットレベルの内部挙動からLinuxカーネル、そして極限のパフォーマンスを引き出すためのチューニングの観点まで徹底的に解剖していく。

—

1. フォワーディングレート（Mpps）の数学的真実とパケットサイズ地獄

スイッチの性能を測る指標として、Gbps（帯域幅）とMpps（Million packets per second：百万パケット/秒）の2つが存在する。前者は「どれだけのデータ量を運べるか」、後者は「どれだけのパケット数を処理できるか」を表す。インフラの現場で真に恐ろしいのは、データ量ではなくパケット数なのだ。

最小フレームサイズ（64バイト）における地獄の計算式

IEEE 802.3イーサネットフレームの最小サイズは64バイトである。しかし、物理レイヤ（L1）でデバイス間を流れる際には、以下のオーバーヘッドが強制的に付加される。

プリアンブル (Preamble): 7バイト
SFD (Start Frame Delimiter): 1バイト
IFG (Interpacket Gap): 12バイト（最低96ビットタイム）

つまり、1つのパケットを処理するためにスイッチングASICは実質的に以下のバイト数を処理しなければならない。

$$\text{Total Frame Size} = 64\text{ (Payload + MAC Header + FCS)} + 7 + 1 + 12 = 84\text{ バイト}$$

ここで、1Gbps（1,000,000,000 bps）の回線で、64バイト（84バイト換算）の最小パケットがフルレートで流れ込んできた場合の理論上の最大フォワーディングレート（Line Rate Mpps）を算出してみよう。

$$\text{Mpps} = \frac{\text{Link Speed (bps)}}{\text{Total Frame Size (bits)}}$$

$$\text{Mpps} = \frac{1,000,000,000\text{ bps}}{84\text{ bytes} \times 8\text{ bits/byte}} = \frac{1,000,000,000}{672} \approx 1,488,095\text{ pps} \approx 1.488\text{ Mpps per 1Gbps port}$$

この「1.488 Mpps / Gbps」という数字は、ネットワークエンジニアなら脊髄反射で出てこなければならないマジックナンバーだ。
例えば、48ポートの1Gbpsスイッチと2ポートの10Gbpsアップリンクを持つL2スイッチ（全二重通信・双方向）の完全なノンブロッキング（Non-Blocking）性能を計算してみる。

ポート構成: 48 × 1Gbps + 2 × 10Gbps
双方向（Full Duplex）の総帯域: $(48 \times 1\text{ Gbps} + 2 \times 10\text{ Gbps}) \times 2 = 136\text{ Gbps}$ （バックプレーン容量の理論値）
必要なフォワーディングレート:
1Gbpsポートあたり: $1.488\text{ Mpps} \times 48 \times 2 (\text{Full Duplex}) = 142.848\text{ Mpps}$
10Gbpsポートあたり: $14.88\text{ Mpps} \times 2 \times 2 (\text{Full Duplex}) = 59.52\text{ Mpps}$
合計フォワーディングレート: $142.848 + 59.52 = \mathbf{202.368\text{ Mpps}}$

もし、ベンダのデータシートに「スイッチング容量: 136Gbps, フォワーディングレート: 95.2 Mpps」と記載されていた場合、それは「ジャンボフレーム（9000バイトなど）を前提とした数字」であるか、あるいは最小パケットサイズでは完全にパケットロス（ドロップ）が発生するオーバーブロッキング（Over-blocking）設計であることを意味する。

—

2. パケットレベルの内部挙動：ASICとキューイングの現実

パケットがL2スイッチのポートに到着した瞬間から、内部のクロスバー（Crossbar）スイッチファブリックを通り、出力ポートへ送出されるまでの挙動を追ってみよう。

[Ingress Port] --> [MAC/PHY] --> [Parser & Lookup (CAM/TCAM)] 
                                           │
                                           ▼
[Egress Port]  <-- [Buffer/QoS] <-- [Crossbar Fabric]

1. 物理受信とフレーミング検証: PHY/MACチップがプリアンブルを剥ぎ取り、FCS（Frame Check Sequence）を検証する。ここでFCSエラーがあれば即座に破棄される。
2. ルックアップフェーズ: 宛先MACアドレスがL2スイッチのMACアドレステーブル（CAM: Content Addressable Memory）に照会される。
3. ファブリック通過とバッファリング: クロスバーを経由して出力ポートへ転送されるが、ここで問題になるのがマイクロバースト（Microburst）だ。複数入力から同一の出力ポートへパケットが集中した場合、出力側の共有パッファ（Shared Memory Buffer）が枯渇する。

バッファ容量のサイジングとテールドロップ回避

近年のデータセンター向けスイッチでは、インメダリーキャッシュやAI/MLワークロード（RDMA over Converged Ethernet: RoCEv2など）の普及により、パケットロスが致命的なスループット低下を引き起こす。
TCPのウィンドウ制御やTLSハンドシェイクのバーストに対して、スイッチ側がどれだけのパケットバッファ（Deep Buffer vs Shallow Buffer）を持っているかが死活問題となる。

スイッチのCLIでバッファ割り当てやWRED（Weighted Random Early Detection）を適切にチューニングし、輻輳時のテールドロップ（Tail Drop）を防ぐ設定が不可欠である。

—

3. ホスト側（Linuxカーネル）からのアプローチ：RTT削減とTCPバッファチューニング

スイッチ側のバックプレーンとフォワーディングレートが完璧であっても、接続されるサーバ側のLinuxカーネルが貧弱であれば、ネットワークのパイプラインを十分に活かすことはできない。特に高スループット・低遅延が要求される環境では、カーネルパラメータの極限チューニングが必須となる。

以下のシステム設定（/etc/sysctl.conf）は、高速なL2スイッチング環境を終端するLinuxホストにおいて、RTT（Round Trip Time）の削減とスループットの最大化を図るための実戦的パラメーターである。

# ==========================================
# Linuxカーネル ネットワーク・パフォーマンスチューニング
# ==========================================

# 1. TCPソケットの送受信バッファのデフォルト値と最大値の拡張 (単位: バイト)
# 高BDP (Bandwidth-Delay Product) 環境におけるスループット低下を防ぐ
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

# 2. ネットワークデバイスの最大キュー長 (txqueuelen)
# バーストトラフィック時のパケットドロップを抑制
net.core.netdev_max_backlog = 10000

# 3. TCPウィンドウのスケーリングを有効化 (RFC 1323)
net.ipv4.tcp_window_scaling = 1

# 4. 輻輳制御アルゴリズムの変更 (BBRの採用)
# 従来のCubicに比べ、ロス耐性が高く、高レイテンシ・高スループット環境で圧倒的な性能を発揮
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 5. TCPタイムスタンプと選択確認応答 (SACK) の有効化
net.ipv4.tcp_sack = 1
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_timestamps = 1

これらの設定を適用した後、以下のコマンドで即時反映させる。

sudo sysctl -p

BBR（Bottleneck Bandwidth and RTT）輻輳制御アルゴリズムは、スイッチのバッファフルやマイクロバースト起因のパケットロスに対しても、損失を「輻輳」と誤認せずアグレッシブかつスマートに帯域を使い切るため、モダンなインフラでは標準採用すべきである。

—

4. トランスポート層・TLSハンドシェイクの最適化とヘッダー圧縮

L2スイッチは通常OSI参照モデルのレイヤ2で動作するため、IPパケットの中身（TCPやTLS）を直接認識して処理することはない。しかし、エンドツーエンドのパフォーマンスを最大化するためには、L2の転送効率と上位層の最適化が密接に絡み合う。

TLS 1.3とTCPファストオープン（TFO）によるRTT削減

レイヤ2の転送遅延（カットスルー方式なら数マイクロ秒）がどれほど優秀でも、TLSハンドシェイクのオーバーヘッドが大きければアプリケーションのレスポンスは悪化する。

1. TCP Fast Open (TFO): 3ウェイハンドシェイクの3つ目のパケット（ACK）にHTTPリクエスト（あるいはTLS Client Hello）を同梱することで、接続確立のRTTを1往復分削減する。
2. TLS 1.3: 従来のTLS 1.2で必要だった2往復のハンドシェイクを1往復（0-RTTモードであれば実質0往復）に短縮。

Linuxホスト側でTFOを有効化するには、以下のsysctl設定を行う。

# TCP Fast Openの有効化 (クライアント: 1, サーバ: 2, 両方: 3)
net.ipv4.tcp_fastopen = 3

—

5. 重大なネットワーク脆弱性とセキュリティの回避策

ハイパフォーマンスなL2スイッチング環境を構築する際、パフォーマンスの追求があだとなり、セキュリティホールを生み出すことがある。特にL2特有の攻撃ベクトルに対する防御は必須だ。

1. スイッチングファブリックの枯渇を狙うDDoS（MACフラッディング）

攻撃者が偽装した数万個のランダムなMACアドレスを持つパケットを高速で流し込むと、スイッチのCAMテーブルが溢れ、スイッチは一時的にハブと同じ「フラッディング動作（Fail-open）」に移行する。これにより、すべてのポートにトラフィックが転送され、バックプレーンとフォワーディングレートが一気に限界を迎え、ネットワーク全体が麻痺する。

対策: ポートセキュリティ（Port Security）や動的MACアドレス学習制限、BPDUガード、STP（Spanning Tree Protocol）のハードニングを必ず実装すること。

2. コントロールプレーン保護（CoPP: Control Plane Policing）

スイッチ自身のCPUへ送られるトラフィック（BGP, LACP, LLDP, 管理用SSHなど）が、データプレーンからのフォワーディングバーストに巻き込まれてドロップするのを防ぐため、必ずCoPP（Control Plane Policing）を設定し、コントロールプレーンへの帯域制限をかけること。

Cisco Catalyst / Nexusシリーズでの基本的なCoPPポリシー設定の例：

# コントロールプレーンへのトラフィックを制御するクラスマップの作成
ip access-list extended ALLOW_MANAGEMENT
  permit tcp any host 192.168.100.1 eq 22
  permit icmp any any

class-map match-all CM-MANAGEMENT
  match access-group name ALLOW_MANAGEMENT

policy-map PM-CONTROL-PLANE
  class CM-MANAGEMENT
    police rate 100000 bps burst 50000 bytes conform-action transmit exceed-action drop

control-plane
  service-policy output PM-CONTROL-PLANE

—

まとめ：真のインフラアーキテクトに求められる視点

L2スイッチのバックプレーン容量とフォワーディングレートの算出は、単なるカタログスペックの暗記ではない。「最小パケットサイズ（64バイト）の連続入力に対して、スイッチングASICが音を上げずにパケットを処理しきれるか」というハードウェアの物理限界との対話である。

さらに、スイッチのハードウェア性能を極限まで引き出すためには、LinuxカーネルのTCP BBRチューニング、TFOやTLS 1.3によるレイテンシ削減、そしてMACフラッディングやCoPPによる堅牢なセキュリティデザインが一体となって初めて完結する。

パケットが光の速度でケーブルを駆け抜け、ASICのクロスバーを通過し、カーネルのソケットバッファに到達するまでの全行程を頭の中でビジュアライズできるか否か。それこそが、凡百のオペレーターと一流のインフラアーキテクトを分ける境界線である。